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

-- On Nov 5 2004 at 12:15, Greg Jaxon sent a message:
> To: sharp@cadence.com, sv-bc@eda.org, Brad.Pierce@synopsys.com
> Subject: "Re: [sv-bc] Errata in SV 3.1a LRM Section 18.4: inconsistent use of error and warning"
> Steven Sharp wrote:
> >>Adam says, however, in http://www.eda.org/sv-bc/hm/2047.html
>
> >> "We have shown in early sv-ac discussions that error checking
> >> synchronized to a clock is the safest way to avoid false failures.
> >>
> >> "Thus I think the change to warnings is prudent."
> >
> >
> > I would interpret this as an argument that violations should not be
> > treated as fatal to the simulation, since there may be violations that
> > the user wants to ignore.
>
> Fair enough. In a synthesized unique case, such glitches could
> activate multiple drivers of a net or have other, less severe,
> repercussions. It probably takes human judgement to decide which
> are critical and which aren't.
>
> Is there likely to be enough information in the warning message to
> allow a user to come to good judgements about how serious it is?
>
> Or is Adam saying that the evaluations to determine a "halt"
> outcome should be separated from the evaluation of the ordinary
> "simulation flow" outcome, and moved to nearby clock edges? Does
> doing this increase the reliability of the detection method?
>
> The way I view "unique" is this: synthesis is going to assume that
> it has a one-hot set of signals driving some selectors. The user
> would like confirmation that this (derived) signal set is indeed
> one-hot over some time intervals. A simulation compiler should
> help him construct that assertion and test it throughout the
> relevant time period. I realize that pinning down what this means
> is the heart of the matter, and I am personally not a bit savvy
> about simulation, so I cannot do it. What do users do now to get
> simulators to check their "parallel case / full case" directives?
> Is there some bullet-proof recipe for adding checks that we can
> standardize? Failing that, is there anything close enough?
>
> Greg Jaxon

Perhaps it is rather obvious to all, but I believe is should be
explictly recognized that the value of this feature drops considerably
if there is not a easy to fullfil requirement that every simulator
shall issue an error/warning when a selector holds a value which
enables multiple case items in a unique case.

If such a requirement can not be easily met by all simulator vendors
to warn precisely in the right circumstances of a violation, and we
are then forced to then relax the requirement so that a simulator
shall be compliant by essentially ignoring these signals, then the
addition of unique (and priority) case keywords to the language will
have been of very little positive value, and it will deliver only its
negative value of removing two words from the users existing
namespace.

-mac
Received on Fri Nov 5 14:13:41 2004