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

Doug wrote:

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

I don't see any objection to that.  Allow the existing syntax
to remain unchanged and to mean a true immediate assertion, 
and add "pulse-reject delay" syntax something like this:

  // when @e fires, process only the pass/fail results
  // of the most recent execution
  unique @e case ...

  // delete any pending pass/fail results, schedule the
  // processing of this execution's pass/fail results
  // until #T
  unique #T case ...

But there remains the problem of procedural loops.  For
example, suppose we have an instruction decoder that uses
"unique case", and then we loop it procedurally over the
multiple instructions in a VLIW, generating multiple
decoded results.  We certainly don't want each iteration 
of the loop to zap violations from previous iterations
of the same run of the loop, so we must be prepared to 
retain all violations from a given "run" and then allow 
them to be superseded by the next "run" - with the 
double-quotes rather carefully indicating that I don't 
quite know what "run" means.

Given my earlier point that this is useful only for RTL,
I'd like to suggest that any such enhancement be restricted
to within an always_comb, always_ff or always_latch block.
That would help to mitigate the concerns about what a "run"
of the process really means - it is unquestionably just a
new iteration of the always_?, because we are not permitted 
any other blocking event controls within the always_? 
constructs.  Preserving the immediate-assertion semantics 
of the existing syntax would maintain full backward 
compatibility.  Insisting on the use of always_? for the 
new, delayed flavour would send a clear message that it's 
something aimed squarely at RTL coding, and would make it 
much easier to define the expected behaviour.  unique #0
would provide zero-time deglitching.  unique @(posedge clk) 
would provide deglitching for combinational logic whose 
outputs are to be sampled by registers clocked by 
@(posedge clk) - note that linters and synthesis tools 
could check that relationship automatically.

Some very great care is needed in deciding when to process
the "winning" pass/fail in a given timeslot.  I am pretty
sure that you need to process them only in the first pass 
through Observed after the given event or time-delay expires.
Later today I'll try to work up a few examples explaining 
why I believe that. 
-- 
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.


> -----Original Message-----
> From: Warmke, Doug [mailto:doug_warmke@mentor.com]
> Sent: 14 October 2007 06:05
> To: Jonathan Bromley; 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
> 
> 
> Jonathan,
> 
> 
> 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.