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

Cliff,

I agree that an error would be useful - at least the ability to promote warning to errors.

But, I have a much simpler piece of advice: use only automatic functions, regardless of the context (design, testbench).

Someone on this thread already suggested a compiler directive to do precisely that. Wouldn't it be much better to not allow designer to unwittingly create these sort of errors in the first place? BTW, I don't think we can seriously change the default lifetime unless we were able to change all the tools simultaneously; otherwise a worse situation would ensue.

        Arturo

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Brad Pierce
Sent: Thursday, December 11, 2008 5:03 PM
To: sv-bc@eda.org
Subject: RE: [sv-bc] RE: functional if statement

> Like I said before, I can always revert back to always blocks and ignore the warnings.

There would be no benefit to doing so.

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

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

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.


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