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

Hi, Brad -

At 05:03 PM 12/11/2008, Brad Pierce wrote:
> > Like I said before, I can always revert back to always blocks and 
> ignore the warnings.
>
>There would be no benefit to doing so.

I absolutely agree. The proper course of action is to fix the problem 
and if the synthesis compiler reports an error when it is found, the 
designer is likely to fix the problem immediately. I tell engineers 
that they always have a backup option to go back to the warnings with 
regular always blocks knowing full well that no reasonable designer 
would ever do that (but the option is there).

> > 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.
>
>I'm not aware of a customer with a design flow that would allow such 
>RTL through the next decision gate, but I'll gladly take your word 
>for it that they exist.  I would advise these valued customers to 
>contact a local sales representative and ask about methodology consulting.

I think most companies have such a decision gate before tape-out but 
why hide the problem until then. A good tool should assist the 
customer to find the problems sooner without the need to hire 
methodology consultants. I think your methodology consultants would 
be tickled to have this warning turn into an error so that they can 
find the problems sooner.

We often joke on the SystemVerilog Standards Group that it is okay to 
add hard-to-understand features because it just gives more for Cliff 
& Stu to discuss in training, but oddly enough, Cliff & Stu are often 
the first to request that a feature be simplified. Cliff & Stu have 
plenty to teach without adding more obscure features to the language :-)

Using the new always_style blocks, the designer has expressed the 
design intent. If that intent is not matched by the inferred logic, 
either the designer should change the expressed intent or fix the 
code so that the intent is met. An error should be reported if the 
intent is not met.

Regards - Cliff


>-- Brad
>
>
>-----Original Message-----
>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of 
>Clifford E. Cummings
>Sent: Thursday, December 11, 2008 4:17 PM
>To: sv-bc@eda.org
>Subject: 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

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