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

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


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