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

Hi, Brad (and other synthesis tool vendors) -

What is the best way to make this request? Keep in mind that most 
engineers do not interact directly with vendor Apps Engineers so they 
don't have a direct path to make this request. Whenever I teach this 
section in SystemVerilog training and whenever I mention that the 
synthesis tool should report errors and not warnings, I always 
get  lots of nod and murmured "yes" comments. I wish I could talk 
some of the developers on the committee to sit in on my training to 
watch how engineers react to some of the features and restrictions. 
Heath, Stu, Don and I all try to give feedback to the committees 
based on reaction from engineers that take our training and I testify 
that engineers would rather have errors on these constructs than warnings.

Should designers treat warnings seriously before moving on? Yes. But 
most don't. The reason most don't is because the warnings zip past 
them on the screen, they never notice the warnings, and they don't 
grep for warnings in the log files after every run. The reason most 
of us designers want errors is because it forces us to quickly 
correct probable problems in the code.

Like I said before, I can always revert back to always blocks and 
ignore the warnings. I want the nex constructs to give me better 
checking on my designs.

Steve Sharp pointed out:
 >This seems reasonable for always_ff and always_latch, which are like
 >normal always blocks except for extra checking.  But it won't work for
 >always_comb, since you need the sensitivity that it creates.  You
 >cannot just replace always_comb with a plain old always block; even
 >always @* may not give the same behavior.

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 officially grant all synthesis vendors permission to blame the 
issuing of error messages for the always_style blocks on me and you 
may hand out my email address to any customer that complains and tell 
them to take it up with me. I will gladly explain it to the designers 
and when I am done, the designers will agree.  :-)

Regards - Cliff

At 04:34 PM 12/10/2008, Brad Pierce wrote:
>Cliff,
>
> > Unfortunately, we can't even get synthesis tools to choke when an 
> always_comb block
> > infers a latch (it is just a warning the last time I tested this).
>
>I'm not aware of any customer asking for this to be an 
>error.  Designers know to treat all warnings seriously before moving 
>on, but they don't want tools forcing them to do this early.  First 
>things first.
>
>-- Brad
>
>
>
>--
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.

----------------------------------------------------
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.