Hi, "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."
Indeed. We can at least generate a structural netlist (best in structural VHDL) using a common standard cell library naming convention, and have mapper files to map between different standard cell libraries from different tool / technology vendors, akin to the files under "quartus/lmf" installation directory for those who have access to Altera's tools. When using the NativeLink feature, I remember having the option to specify custom mapping files as well (in fact, you can specify the use of a different / custom synthesis tool, other than the ones provided in the drop-down list). I believe other FPGA vendors should have such a feature too. This allows us to generate a gate-level netlist, and map the netlist to Altera's (or any other vendor's) technology. Some place-and-route tools may not be able to read VHDL netlists directly, but at least their tools are able to run just one more iteration of synthesis on our VHDL gate-level netlist, then the tool will generate their own post-synthesis netlist file for use with their P&R tool. This will be handled by them already, so we need not worry about which format they are using as the input format for their P&R. regards, daniel On 29 April 2014 03:52, <[email protected]> wrote: > Hi ! > > Le 2014-04-28 21:23, [email protected] a écrit : > > The code generated for simulation is far too simulation oriented: a lot >> of checks, lot of low-level constructs, design is not elaborated... >> > > I don't think it's a real problem. > > My concern is that very high-level VHDL code > (behavioural) is "hard" to synthesise. > GHDL can do all the nice high level things, > why go back and reinvent the wheel again ? :-) > > The "target language" approach at least reduces > the coding/design problem to the low-level things > that you /can/ do (down to the logic level), > instead of the many many high-level constructs > that can be coded and must be infered. > > I believe that all the necessary informations are provided > to GCC and mcode, we just need to create a language that > is more suited for generating a graph in memory and then walking > though it (backwards from the outputs). > > Now it seems to me that all there is to do is reuse the mcode > version and ADD transparent/parallel code that generates > the gates netlist. For example, if you have something flagged > as a signal, the mcode+ backend would generate object code > for doing the operation AND generating the corresponding > gate in the netlist, in parallel. It would be transparent ! > > The output would be more bloated but > it would actually generate the netlist (and ensure code coverage > and identification of stuck values or their ranges) > during the simulation of the actual circuit. > > Unfortunately I'm not able to work on this > this year but i'd love to at least try one day to add > a new target language to GHDL. I'm sure it could be useful > for many other things :-) > > > Better to start after semantic analysis. >> > I'll love to see a proof of concept of your approach :-) > > In any case, I think I'll need a Free > full VHDL compliant analyser in the future. > > Tristan. >> > yg > > > > _______________________________________________ > Ghdl-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/ghdl-discuss >
_______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
