I don't necessary want to go further in that direction and I'm not debating about replacing verilog for now. The fact is that: - 1) asic syntax does syntax specialization but you have to look at the verilog backend to understand what is exacly done - 2) We sometimes also want to avoid polluting code for FPGA targets. (When a code is intended only for synthesis and you are not going to do a simulation you may also want to remove the insertion of dummy signal as it's done for ASIC).
For 1) I just added names to what is done (reg_initialization, blocking_assign, dummy signal) and what is done for ASIC is now clearly understandable just looking at ASICSyntaxSettings. For 2) I'm just want to expose the syntax specialization parameters to the user to allow the user to use these. The main reason I'd like to have 2) is to provide clean code to my customers and avoid having to justify myself about what is this dummy signal and what is is intended for... So if we can do that at no additional cost as it's done here, I think there is no reason not doing it. Florent 2015-04-23 6:20 GMT+02:00 Sébastien Bourdeauducq <[email protected]>: > Hi, > > My impression is that proprietary EDA software produces a lot of > pointless warnings all the time, and that the specification of what > causes a warning and what does not varies widely from EDA program to EDA > program. > > Adding proper support for suppressing those warnings: > 1) is a lot of work as one would need to understand all the > idiosyncrasies of every common EDA program > 2) makes the Migen Verilog backend more complex and harder to understand > 3) makes the backend less maintainable > 4) is a low-importance feature > > The asic_syntax patch was marginally acceptable as it is simple enough, > and I understand the need for removing features such as register > initialization that have no equivalent in ASIC and may cause synthesis > tool errors or simulation/synthesis mismatches. But I do not think we > should go much further in this direction. > > I think that the development time would be much better spent getting rid > of the proprietary Verilog synthesizers, which is definitely feasible > for FPGA targets. > > HardCaml already has such a feature: > http://www.ujamjar.com/hardcaml/introduction.html#Transformation > Migen has a EDIF backend (for those designs that consist exclusively of > instances): > https://github.com/m-labs/migen/blob/master/migen/fhdl/edif.py > and there was an effort to implement direct synthesis in Migen: > https://github.com/nakengelhardt/mist > > Sébastien > > > On 04/22/2015 11:12 PM, Florent Kermarrec wrote: > > Hi, > > > > we should have something more generic for syntax specialization. (we > > sometimes want some of the features added with asic_syntax for FPGA > > targets to avoid polluting synthesis with warnings). > > > > Here are two patches to try to be more generic. In the second patch, the > > async_syntax test is renamed to test_syntax and can be used as our > > syntax test for all supported syntax specializations. > > > > What do you think about that? > > > > Regards, > > > > Florent > >
_______________________________________________ M-Labs devel mailing list https://ssl.serverraum.org/lists/listinfo/devel
