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

A little commentary on this mail thread...

<snip>

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

Note that in SystemVerilog, concurrent assertions are always associated
with a clocking event.  This hasn't even been brought up in the thread,
and it's quite important.

> 
<snip>

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

Delaying notification of warning/error to the Observe region of
the time step in which the violation occurred is not sufficient.
The notification really must be delayed until an appropriate
user-defined clocking event has been reached.  And currently
there is no syntax designed to associate a clocking event with
a unique or priority construct.  In fact it may be difficult
to do so given the use of functions at  multiple call sites.

Associating these constructs with clocking events would take
care of Steve's NBA's with #1 delays.  It would also take care
of instantiated gate level logic with timing delays.

I believe that all tools will eventually provide a means to
upgrade or downgrade whatever error/warning severity the LRM
says to provide as default.  So I'm not too concerned about
these coming out as errors or warnings - IMHO the status quo
of camouflage warnings might be a little better than the
false errors that are the alternatives.

I agree with Steve that teaching a methodology of using
unique/priority constructs in clocked processes, or in
glitch-free combinational processes, is probably the best
hope of cleanly using these constructs in a methodology.

For those who don't follow such methodology, using tool
severity switches and Perl scripts to filter output logs
could be cobbled into a decent enough methodology.

Regards,
Doug