Clarification: I am NOT asking that GHDL is rewritten from toe to neck!
But if adding a fourth "flavour" is possible - in addition to gcc, llvm and mcode - which would be generation of shared lib of the parser (or anything not gcc or llvm specific) + corresponding headers for C/C++/bindings-for-your-preferred-language, then it would certainly be of great help for many synthesis and design instrumentation projects (there are many in my lab, even if I'm not working on that). Also YG: such a lib would also certainly be of great help to create your virtual machine as a new systhesis tool attempt :-) Tristan: How hard would it be to add such a "shared lib" flavour? Adrien On Mon, 2016-10-03 at 20:46 +0200, Adrien Prost-Boucle wrote: > I'm not sure about what whar your idea consists in... > > Are you suggesting to integrate a special back-end to GHDL? > I think the problen of interfacing the generated stuff with the rest of > the world would remain. > > Or should GHDL perform the discovery / coverage of the directed > dependency graph and generate that in a data format that others can > import? > > But for synthesis your approach would drop attributes that are very > often used in VHDL to guide synthesis, such as implementation of arrays > (RAM blocks vs. distributed RAM vs. registers), attribute KEEP, etc. > List alsolutely not exhaustive xD > > Also I think your approach would be of little help for translation to > Verilog and for auto-formatting of VHDL or modifying it for certain > functionalities. > > I have always been thinking that making the GHDL parser a shared > library would be very useful. With headers for use by external tools > written in other languages, C/C++ in particular. That way synthesis > tools that use it would have full design information and be able to do > their own implementation choices (possibly target-dependant) + other > functionalities such as synthesize PSL rules and asserts (ok these are > rare uses, but I am really sensitive to genericity :-) ). > > Adrien > > > > On Mon, 2016-10-03 at 20:19 +0200, why...@f-cpu.org wrote: > > > > Le 2016-10-03 20:09, Adrien Prost-Boucle a écrit : > > > > > > > > > Hi, > > > > > > Synthesis and simulation are indeed completely different things. > > <snip> > > > > > > > > > > > > Even if you consider that as the "simplest" part, it's still a big > > > part, and any reuse of good stuff would saves a lot of > > > reinvent-the-wheel time and allow to better focus on the the rest. > > > > > > Regards, > > > Adrien > > > > Let's think again about an idea I suggested, probably in 2009... > > > > GHDL is a VHDL compiler. > > Let's create a pseudo-machine target where the generated code > > can be simulated, when run by a virtual machine, which will also > > tag data as they pass throught function, ports etc. > > > > A few runs will "discover", or simply "cover" all the datapaths > > and thus create a directed dependency graph, which can be then > > traced back from the outputs. > > > > There, you have a synthesiser which would seamlessly integrate > > with the best open source VHDL simulator. > > > > yg > > > > _______________________________________________ > > Ghdl-discuss mailing list > > Ghdl-discuss@gna.org > > https://mail.gna.org/listinfo/ghdl-discuss > > _______________________________________________ > Ghdl-discuss mailing list > Ghdl-discuss@gna.org > https://mail.gna.org/listinfo/ghdl-discuss _______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
