> 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...
I think this is a dream. There is no open-source FPGA, so the bitstream format or the timing features aren't known :-( > > 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)... I think this is clear and I agree with that. I just want to lower the vhdl code into a non-optimised and generic net list. > 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 don't plan to go that direction. If a net list could be generated, it could be written in a format which is known by other tools, or if needed we can interface directly with a library. No need to rewrite in another language. > > 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? I think I have given the few ideas I have. But this is very preliminary effort. Tristan. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
