RE: [sv-ac] Re: [sv-bc] Suppression of unique/priority glitches

> But there is still no way to determine whether a new evaluation
> of the unique/priority construct is associated with a particular
> previous violation in the same constructs.  In addition to the
> loop situation, there can be tasks/functions called from multiple
> places.

Forgive me if I'm being dense, but I really don't follow
this argument.  My point about permitting this sort of 
behaviour only in an RTL-style always_? construct was to
ensure that it was associated with a static process. 
If the violations/passes could be associated with the 
static process, then it is presumably not too hard to
delete ALL stored violations/passes associated with
that process as soon as it is re-activated after 
quiescing at the end of its always_?.  Even if the 
unique/priority is in a function, or loop body,
I don't care about its lexical location in the code;
I care about the signals it's updating, and that
is precisely captured by associating any violations 
with the RTL process that executes the assertions.

We have only two cases to worry about that are of
practical significance:
- A clocked always_ff that executes once per clock,
  just before its output registers are to be updated.
  In this case, the currently-defined semantics of
  unique/priority are just fine (in this regard, at
  least).  Nothing new is required.
- A combinational RTL block using always_comb.  
  Such a block must represent combinational logic; so
  all outputs must be recalculated on each pass through the
  block.  It is therefore appropriate, at the moment such a
  process is re-activated by a change on its inputs, to throw 
  away *all* stored pass/fail information associated with 
  *any* unique/priority constructs that have been executed by 
  that block's process on a previous pass and not already dealt
  processed by the "glitch-reject" timing control.

I absolutely agree that you can't do this in the 
general case, but I hope I've made clear my reasons
for thinking that unique/priority are useless outwith
an RTL process anyway.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

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