Re: [sv-bc] Errata in SV 3.1a LRM Section 18.4: inconsistent use of error and warning

Erratum 26 is simply about the inconsistency between the severity
of the diagnostic messages prescribed for unique if vs. unique case

    http://www.eda.org/sv-bc/hm/1967.html

As Stu says "The inconsistency of error versus warning does not
make sense. These should both be warnings or both be errors."

I think they should not be errors, hence they should be warnings.

I would like to propose that this erratum be made a duplicate of
the more difficult erratum 218 by Steven Sharp regarding how to
handle side-effects --

    http://www.eda.org/sv-bc/hm/1953.html

I made a proposal for 218 on October 3, and I've attached a copy
of that proposal here.

Considering the difficulty in simply deciding between warning or
error, it's clear that this proposal is going to at least require
some wordsmithing.

If you could provide some feedback on the current draft proposal
(attached) it would be much appreciated.

Thanks for the help,

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of
Steven Sharp
Sent: Wednesday, November 10, 2004 3:26 PM
To: Shalom.Bresticker@freescale.com; Neil.Korpusik@sun.com
Cc: Brad.Pierce@synopsys.COM; sv-bc@eda.org
Subject: Re: [sv-bc] Errata in SV 3.1a LRM Section 18.4: inconsistent
use of error and warning

>1. Which tools are being referred to

In the Verilog standard, the term "implementation" is used, for a tool
that implements the defined semantics of the language. That would be
a simulator, since that is the tool that implements the semantics of
the language. A synthesis tool attempts to implement them in hardware,
but can really only approximate the precise language semantics. Other
tools may manipulate Verilog designs based on those semantics, but they
don't "implement" the semantics.

>2. How often are the checks performed

I think it is pretty clear that the checks are performed when the
case statement is executed. This is not a separate stand-alone
assertion, it is a special case-statement that does extra checking
as part of its evaluation. All this talk about performing the
checks at different times seems to have gone far astray.

If you want it to be checked only on the clock edges, then you need
to put it in the clocked block. If you want it checked whenever the
inputs change, put it in a separate combinational block. This will
result in it being evaluated (and checked) at those times. I believe
that there are different modeling styles that promote putting the
combinational logic in the sequential blocks versus putting them in
separate combinational processes. How you want this checking done
would be one reason for choosing one over the other.

It wouldn't even be legal to do the checks at some other point, since
it would require evaluating the expressions again, which might have side
effects. The proposal Brad put together for issue 218 allows for
flexibility in order and short-circuiting of evaluation of the
expressions when the case is executed, but it doesn't allow them to
be evaluated at any old time. This isn't a problem in realistic
situations, since there won't be side effects, but the language still
has to define the behavior.

>3. During which event region should the check take place

Again, the check is performed when the statement is executed. Though
there are some similarities, this is not a separate assertion. It is a
case statement that does extra checks when it is executed.

>4. Severity of the check
>
> A simulation should not terminate based on these checks. The simulation
> log would be post-processed to determine the correct course of action.
> A warning is appropriate.

Agreed. This is supposed to help the user, not impede them.

>The benefits of this construct could end up getting outweighed by the
>drawback of slower simulations.

Which is another good reason not to have the check done as a separate
process. It would be inefficient to simulate. If you want it done that
way for some reason, you can write an assertion.

Steven Sharp
sharp@cadence.com