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

From: Adam Krolnik <krolnik@lsil.com>
Date: Fri Nov 05 2004 - 07:18:01 PST

HI Brad, Steven;

Brad wrote:
>>Does this mean that it is actually legal to violate the
>>uniqueness assertion, or just that a simulator could get confused
>>about whether the assertion was violated?

Steven replied:
>I assume that he means that the simulator determines that the assertion
>is violated (without being confused), but that the user may not care
>about the violation except at certain times. For example, there might
>be a zero-width glitch into an illegal state and then back to a legal one.
>Say a one-hot encoding is changing state and it momentarily passes through
>a state with two bits hot. This might depend on event ordering that is
>considered nondeterministic.

Steven gives a good example. A second example would be state changes that are affected
by signals with timing (through IO buffers, or other modules with propagation delays.)

I wrote previously:

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

Steven replied:
>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.

This is correct. I do not want my users to tell me that system verilog is reporting
problems and then terminating the simulation when they are in fact not a problem. All
that this will do is make people avoid this feaure.

Andrew suggested:

"should there be a mechanism to set further conditions on those assertions so
that there are no false warnings/errors?"

This is an idea that I also had - some way to promote unique functionality into an a
clocked assertion format. Maybe this is a a simulator specific thing, or something that
a future revision could handle.

BTW, on the defininition of errors and warnings, SV-AC created a set of system tasks
to report the severity of assertion failures. These tasks are also useable in general to
report messages with various severities. I would suggest using these as a base for any
definition of error and warning.

    Adam Krolnik
    Verification Mgr.
    LSI Logic Corp.
    Plano TX. 75074
    Co-author "Assertion-Based Design"
Received on Fri Nov 5 07:18:07 2004

This archive was generated by hypermail 2.1.8 : Fri Nov 05 2004 - 07:18:39 PST