Re: [sv-bc] Glitches in unique/priority case/if violations

Note that Erik's proposal also places restrictions on the kinds of
loops that these assertions can appear within.  Similar restrictions
would be required on unique/priority case/if to use this approach.
Since there are currently no restrictions on where unique/priority
if/case can appear in procedural code, this would not be backward
compatible.

Personally, I think it is a mistake to try to add a lot of complex
rules where the tools try to figure out what you are trying to do.
Computers are not very good at doing that, and LRMs are not very good
at specifying it.  It is better to provide basic flexible features
that the user can use to build exactly what they want, using their
own understanding of what they are doing.

In this case, I think it would be better to provide a mechanism
to save the success or failure of the unique/priority condition into
a user variable.  Then the user can write whatever code they want
to check it.  If they want to wait until a particular clock edge to
check it, then they can do so.  They can use a concurrent assertion
to check it, if those are the semantics they want.  If they need to
keep track of it for each iteration of a loop, they can use an array
to save the result for each iteration.

This could be done by adding some syntax to provide a place to write
the result.  For example

  unique(result) case (select)
  ...
  endcase
  

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.