Hi, > Having a truly free synthesiser is something that people have dreamed > about > for more than a decade, maybe two. GHDL in itself is already an > incredible > achievement... and is as important as GCC !
There are already relatively advanced approaches, in their field of expertise: http://code.google.com/p/vtr-verilog-to-routing/ https://code.google.com/p/odin-ii/ http://torc-isi.sourceforge.net/index.php It seems that the major point still missing is the ability to target a real technology. I mean, from a placed-and-routed netlist, generate the actual bitstream... > place&route require "fitting" first, which is technology-dependent. > that is : each technology has its own requirements about inputs, > outputs, > naming... A full-blown synthesiser does a LOT of things like > minimisation, > optimisation, duplication to reduce load on the wires, countless checks, > there are tons of work to do before even considering place&route. Logic synthesis for a given technology is a world of expertise in itself. The VPR project seems to have reached a very interesting point but is still unable to target a real architecture (and as far as I know it still lacks handling or carry chains, but to verify). This is why when I described a generic library to parse and reformat VHDL, I wasn't thinking of something able to dump a netlist. IMHO, such a library should only perform transformation of a high-level description with many and elaborate syntax contructs into, yes something as structural as possible, but that do not remove the "behavioural" aspect of it, in order to let all transformation and conversion possibilities to the synthesis tool. I don't known if it's clear enough? Also, ideally, such an "intermediate representation" should be generic enough to be built from Verilog (but I don't known up to which point this remains feasible)... Anyway, the VTR implementation should be analyzed before beginning something new. These guys could also have very valuable opinions on the various aspects of the present discussion. > But even the ability to plug into a commercial, technology-limited > synthesiser, even if it only parses VHDL into crude EDIF, is a progress > : > this brings the ability to use recent constructs from the latest VHDL > updates for example :-) > > And from there, "we" can go down further into the toolchain. This is just what I meant. > We need to carefully choose which language to use though. About the language the library I mentioned should be programmed in, I only wish there is a C interface that has as low overhead as possible from the version in the language it is programmed in. An efficient C++ interface also seems necessary, for it is the most common language synthesis tools are programmed in (if not C). Maybe the fact that C++ is hugely widely used would bring more experts having an eye into the code, contribute, maintain and help/enable them integrate it in their tools. But I'm saying this with a bit of remorse because the existing GHDL code would have to be rewritten... Does anybody know if, in such a situation, improvement or regressions should be expected about code size and readability? (sorry I'm just a raw C guy) > I have started an effort for synthesis, but it is currently too > preliminary. Tristan, it would be very interesting if you shared some of the ideas/directions you were thinking of about this project? Regards, Adrien _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
