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

Jonathan,

One way I've thought of to address the finite time glitch
scenarios you brought up in combinational logic is by
introducing the concept of a "pulse reject delay" into
the syntax for deferred unique/priority if/case.

The idea would be to allow potential violations to live
not only across one or more scheduling regions of the current
time unit, but also across multiple future time units.  Finally,
at the Observed (or possibly Postponed) region of the appropriate
future time unit, any surviving violations would be reported.

At the end of the discussion, the new syntax may well have a
mandatory syntax specifying either an event control or delay 
control for deferred unique/priority if/case.

I'm not ready to give up on these constructs yet.
I do agree with you that they are intended for RTL, and should
be useful in RTL, and all other scenarios are low priority.
But I don't think they are useful enough for RTL if left as-is.
We can do better!

Thanks,
Doug



-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Jonathan Bromley
Sent: Saturday, October 13, 2007 4:14 AM
To: Steven Sharp; Vreugdenhil, Gordon; Greg.Jaxon@synopsys.com
Cc: sv-bc@server.eda.org
Subject: RE: [sv-ac] Re: [sv-bc] Suppression of unique/priority glitches

Thanks to Steven for clarifying things thus:

> There are other ways of avoiding this kind of combinational glitches.
> One synthesizable coding style combines the combinational logic with
> the sequential logic in a sequential block.  The combinational logic
> is only evaluated on the clock, when the data is being latched.  This
> gives you a clocked check and avoids glitch problems.

unique/priority are clearly designed for use in synthesis.  The
specialised assertions that they represent in simulation are 
only of genuine interest as a way to legitimize certain useful
synthesis optimizations that would be unacceptable without the
unique/priority qualifiers.  For behavioral code that's not
designed for synthesis, unique/priority impose a runtime overhead 
and obfuscate the assertion that's really being applied.  

So let's stop worrying about the general case, and start 
focusing on what makes sense for synthesis; if someone is
then foolish enough to use unique/priority in other contexts,
they deserve all they get (though, of course, the LRM must be
clear about exactly _what_ they will get).

Synthesis typically targets synchronous designs, but it is 
common for such designs to contain non-trivial blocks of purely
combinational logic - which, of course, will in almost all
cases ultimately feed registers.  The standard RTL abstraction
somewhat hides a rather important issue here.  If you write a
single clocked process to represent some combinational logic
and its output registers, then as Steven says the code executes
only on a clock, and - much more important - it executes on 
the same clock that will load the registers.  The code that
represents combinational logic executes just once, and sees
the final settled values of its inputs as they were just
before the moment of the clock.  By contrast, if you split 
the logic into clocked registers and combinational next-state 
logic, the combinational code executes whenever the signals 
driving it change - typically, just after the clock
that updates the registers, a whole clock cycle before the
logic's outputs are needed.  Of course, it may execute again 
later, before the clock that uses its results, if any of its
inputs changes again.

No amount of trickery to deal with "glitches" (whatever they
are, in simulation of RTL code) will ever cope with this.
It is a simple and obvious fact that the RTL code that models
any purely combinational logic may execute at many different 
times up to and including the moment of the clock edge that 
registers its results.  Why "many different times"?  Consider 
inputs from external synchronous logic that has a clock-to-
output delay model, or inputs from registers clocked by a 
different phase of the same clock.

Of those various executions at various widely-spaced times,
only the very last is significant from the point of view of
unique/priority, because only the last execution up to the 
next clock will affect the values captured by registers.  
I believe it's pointless to try to find an auto-magic 
mechanism to solve this.  Either 
a) leave things as they are, and make it clear to users 
   that they should use unique/priority only within an
   always_ff or other clocked process; or 
b) provide a way to decorate the unique/priority
   qualifier with a clock, and then have it treated
   as a concurrent assertion triggered by that clock. 

I think that (b) would mean that the entire block of 
combinational code containing the unique/priority would 
need to make a special execution, triggered by the clock 
and using not the current values of its inputs but the 
Preponed-sampled values as for true concurrent assertions; 
and that the unique/priority should be ignored in all the
"normal" executions.  Please note that I don't regard that 
as a sane solution.
-- 
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.



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