> > Eventually I need to change my code that parses UUT VHDL sources, > > because it doesn't handle generics. I'm considering maybe looking > > to see > > if I can take part of the GHDL code to create a separate executable > > that > > will give me the ports information. Then I'll use this executable > > with > > GHDL, or any other simulator. I also need to look at VPI. I also > > want to > > get my Tcl testbenches to work with Verilog as well. But of course > > I'll > > want to use the simplest method, and I don't know what that is yet > > either. > > This is another illustration that building a versatile "libvhdl", as > CLang is to C/C++, would be hugely useful for many people and many > objectives. Currently for each task (parsing, wrapping, verifying, > replacing stuff, hanlding 93 to 2008 standards etc) each developer > writes a specilized script, tries to reuse existing scripts when > there's > a colleage aroud that have crafted something not too wobbly etc. > I think it's a painful situation for everybody. > > If some "part of the GHDL code" is taken, please please at least take > the parser and ship the minimal API to read the tree, and as much as > possible, stuff to modify that tree and dump it as VHDL. > In the hope that, later, GHDL shifts to using this lib as front-end > ;-)
Well, GHDL has 95% of that. It has a parser, a semantic analysis, dumpers, and passes that transform the tree. The API to read and modify the tree is iirs.ads, and you can dump it using disp_vhdl.ads. If you need a standalone library with a C interface, you just have to create C prototypes for these packages. Shouldn't be hard, and even possible to create that automatically (for iris) given it is read by a tool (see xtools). Finally, you may prefer to dump the tree as XML (or any other format). Again, this is not particularly difficult. Tristan. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
