RE: [sv-bc] RE: functional if statement

Cliff

> I still claim that synthesis tools should report errors and not
> warnings when the specified always_style block does not infer the
> requested logic.

For every request we see for being able to be more restrictive on certain things, we probably see 2 requests to "just let it go through, so I can see some interim results".

Designers need to be free to choose their own priorities.  They'll make a list of problems and put it in order.  Why I should force them to put "always_comb" violations at the top of their list?

-- Brad


-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Clifford E. Cummings
Sent: Friday, December 12, 2008 10:43 AM
To: sv-bc@eda.org
Subject: Re: [sv-bc] RE: functional if statement

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.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.