Gord makes good points regarding testbench usage of the always_style blocks. I do not propose that we change the LRM in any way. The 1800-2005 Standard, Clause 11.2 included: Software tools can perform additional checks to warn if the behavior within an always_comb procedure does not represent combinational logic, such as if latched behavior can be inferred. The 1800-2009 Draft 8, Clause 9.2.2.2, changed "can" to "should" Software tools should perform additional checks ... I don't think simulation tools will ever do this and I have told my students that simulators would have to acquire more synthesis capability to make this happen (so they should not expect their simulators to do this checking). Gord has just given me another good reason to explain why this will not happen in a simulator. But I do believe synthesis tools should check and give errors. This does not require any change to the LRM. Designers generally do not synthesize their testbenches and the few that do synthesize their testbenches for insertion into hardware accelerators are required to follow RTL coding guidelines in their testbench code. I still claim that synthesis tools should report errors and not warnings when the specified always_style block does not infer the requested logic. Regards - Cliff At 07:19 AM 12/12/2008, Gordon Vreugdenhil wrote: >Clifford E. Cummings wrote: >>Hi, Brad (and other synthesis tool vendors) - >[...] > >>Steve is correct if you are calling functions with buried signals >>that are added by always_comb and ignored by always @*, but I >>guarantee you that designers would overwhelmingly choose >>always_comb errors and fix them as opposed to trying to back-track >>to using an always @*. >>Believe it or not, designers really do want the errors to find the >>bugs quickly as opposed to missed warnings. > >I agree that the actual chip designers generally do care. Unfortunately, >I also see a huge amount of "key stroke elimination" use of >always_comb and @(*) in *testbench* code where users will have >a fit if you mandate errors. Then there are the interesting >assumptions at times about the semantics of always_comb with >class method calls, virtual interface references, etc. > >The LRM has caused issues in trying to be "synthesis friendly" with >assignment rules, sensitivities, etc. You cannot mandate errors >since what constitutes the exact permissible synthesis set is >not defined. Anyone care to write up the *real* synthesis rules >for always_comb sensitivities or proc/cont assignments? They certainly >are not always the same as the "longest static prefix" rules. >Would you *really* want hard errors on code that is synthesizable >but breaks the LRM rules? Putting an error requirement into the LRM >would then be silly since it would be uniformly ignored (for very >good reasons) and adding universally ignored "requirements" to an >LRM does no one any good. > >In general, I really don't like having the LRM mandate this kind >of thing as an error or warning -- the words "error", "fatal error", >etc. all carry assumptions in people's minds about the use model >that they like. > >Give rules about what is legal/illegal/undefined and let the vendors >worry about the management of the level of the error. > >Gord. >-- >-------------------------------------------------------------------- >Gordon Vreugdenhil 503-685-0808 >Model Technology (Mentor Graphics) gordonv@model.com ---------------------------------------------------- Cliff Cummings - Sunburst Design, Inc. 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005 Phone: 503-641-8446 / FAX: 503-641-8486 cliffc@sunburst-design.com / www.sunburst-design.com Expert Verilog, SystemVerilog, Synthesis and Verification Training -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Dec 12 10:43:32 2008
This archive was generated by hypermail 2.1.8 : Fri Dec 12 2008 - 10:44:06 PST