Re: [sv-bc] Re: Fwd: Re: Priority / Unique Errors

Hi Cliff, et al.,

My apologies for the late response; a result of being 12 time zones away.

My understanding of immediate assertions is exactly as described by Steve.
Immediate assertions always execute as part of the procedural code leading 
to the assertion. This is how the LRM defines their semantics. As Doug
mentioned, only concurrent assertions require sampling of data and schedule
their evaluation in the observed region. If the existence of these two types of
assertions is causing confusion, I suggest that we add an sentence in the LRM
to explicitly distinguish them.

Assuming we have settled the issue of immediate assertion's semantics, I believe 
that Cliff is raising several important issues, and they do merit some thought.

The first issue is what is the nature of the priority/unique warnings? Cliff suggests
they are immediate assertions, and I agree that the error reporting semantics 
of the unique and priority constructs are essentially immediate assertions. In fact, 
one can easily explain a "priority case" warning via a code transformation that
adds a default label whose action is an immediate assert.

The problem with considering priority/unique as just immediate assertions is
that they are also intended to provide information for synthesis. The assertion 
semantics exist only to ensure consistency between verification and synthesis 
tools. Hence, if a priority/unique assertion is triggered during simulation, it is
intended to alert designers that their intended synthesis semantics are incorrect.
Herein lies the problem. In order for these constructs to be adopted by designers,
the tools must eliminate false-negatives (or reduce to an absolute minimum). 
Otherwise, they become simple linting tools, which are often ignored, and designers 
will simply revert to using full_case / parallel_case pragmas --- which will not be
verified during simulation. And, I believe that is the point that Cliff was trying to 
make.

I recognize that all the mechanisms that have been proposed to address this
problems are imperfect or unfeasible. Cliff's proposal to schedule evaluation of the 
assertion in the observed region (my paraphrase) has serious implementation
problems. Likewise, Steve's proposal to schedule the error reporting in the observed
region to allow filtering of the "steady-state" disposition of the assertions has the 
serious drawback of failing to report real errors. Also note that unlike user-written
assertions in which the user code could actually deal with some of these situations
in a case by case basis, the priority/unique warnings are built into the tool, thus
giving users no access to such mechanisms.

Finally, any solution that relies on the execution regions to filter assertions due to 
0-delay glitches will fail when the inputs to the block containing the priority/unique 
statement are driven by blocks with finite propagation delays, for example, a gate 
level block. A more general solution may be needed.

    Arturo

----- Original Message ----- 
From: "Steven Sharp" <sharp@cadence.com>
To: <Arturo.Salz@synopsys.COM>; <sv-bc@eda.org>; <cliffc@sunburst-design.com>
Sent: Tuesday, April 05, 2005 8:07 PM
Subject: Re: [sv-bc] Re: Fwd: Re: Priority / Unique Errors



>Steve raises interesting points, which I belive apply to all assertions, 
>clocked or immediate (I am hoping for assertion comment from Arturo and Adam).
>
>I believe all the points raised by Steve apply equally to assertions, and I 
>think they are just the nature of assertion-based design, one that needs to 
>be taught to engineers. Sampled assertions can obviously miss between-clock 
>events and multiple calls to the same function leaves us with the last 
>function-call values, because assertions evaluate in different regions from 
>RTL code.

There is not an inherent problem with assertions.  They work the way
they are defined to work, and it is up to the engineer to understand
that and how to use them to accomplish what they want.  That may
include choosing between immediate and concurrent assertions as appropriate
for the task.

The problem with trying to apply this to priority/unique case is that
these are inherently immediate assertions.  They execute at a specific
point in procedural code, only if and when execution reaches that point,
and use the current values of objects (including temporary variables
that may have been computed just before and change immediately after).

What you are trying to do is convert these automatically into concurrent
assertions.  These concurrent assertions are supposed to be equivalent
except that they don't produce certain types of failures you consider
to be spurious.

I don't see how this transformation can be performed in general.

The most practical approximation for the situation you describe would be 
to wait until the observed region and then produce an error only if the
most recent evaluation of the priority/unique if/case violated the
assumptions.  As noted, this can miss real failures when used in loops
or functions.  It also won't filter out glitches that are not zero-width
(which I assume comes up with the NBAs with #1 delays that you mentioned).


>Steve accuses me (it's okay Steve!) of trivial RTL coding examples, when in 
>fact, I discourage many of the problem areas he notes below (and I am 
>feeling even better about discouraging their use now   ;-)

We have different viewpoints.  This sort of thing occurs a lot with
language extensions proposed by users.  You plan to use them in a certain
way, and don't worry about what would happen if they were used in a way
you don't plan on.  You can write your code avoiding any situations you
don't like.  As an implementor, I have no control over the source code
my implementation has to handle.  I need a definition of how all possible
input source code is supposed to behave, not just the things you have in
mind.


>Steve's proposal to generate the warnings iteratively and on the fly within 
>the same time step should indeed catch all problems ... along with a myriad 
>of non-problems.

It isn't my proposal.  It is how the LRM says they work.  This idea that
they are checked at a time other than when the if/case is executed seems
to have come from somewhere other than the text in the LRM.


>Evaluating in the observed region is really very simple. When a case- or 
>if-variable changes in one of the RTL regions, an assertion event is 
>scheduled in the observed region. When the observed region events are 
>activated, we find out if there are any violations. If multiple changes 
>occur on a case- or if-variable within a time step, it behaves like 
>nonblocking assignments and the last stored event is evaluated, potentially 
>missing other error events in the same time step.

No, this won't work.  You can't just evaluate the "assertion" in the
observed region.  Execution might not have reached the if/case because
of conditional code around it, and you can't just assume it did.  If it
didn't execute, there wasn't a failure.  You also don't have access to
the values of any temporary variables that were computed in the code
around it.  The only time you can evaluate the "assertion" is when the
if/case actually executes.

What you *can* do is delay producing the error until the observed region.
If the most recent time the if/case executed did not have a violation,
then you don't produce the error.  But you have to rely on the if/case
to do the evaluation itself and provide it to the process running in
the observed region.

As noted previously, if the same if/case is executed repeatedly in the
same time slice for reasons other than glitching inputs in combinational
blocks (e.g. for-loops and functions), this filtering may lose actual
errors.

There may be better alternatives.  For example, the single-block FSM
approach (that you dislike) does not seem to have this problem.  It
appears to work fine with the "immediate assertion" treatment.  Since
the combinational logic is in the clocked block, it won't get evaluated
by the simulator until its result is about to be used.  Any glitches
will be gone.  It will only get evaluated once in a time slice, at the
clock edge.  If there is a loop, each value computed by the loop will
get checked, and no errors will get lost.

This may not work for everything, but there may be other solutions.  There
may be other design styles that avoid this problem.

Steven Sharp
sharp@cadence.com