RE: [sv-bc] RE: Suppression of unique/priority glitches (new proposal at http://www.verilog.org/mantis/view.php?id=2005)

Hi Erik,

Thanks for the write-up.
We've had a lot of internal discussions, and we arrived at
a few conclusions.  I can write up more formally in a couple
days when I get more time.

1. I've come to the conclusion that I don't like explicit
   flushing.  There are some big problems with it:
a) Limited usefulness.  The example in your proposal is
   simple, since there is only one assertion in the process.
   If there had been more than one, and the user desires to
   flush only one of them, the explicit flushing mechanism
   doesn't allow that.  It's an all-or-nothing proposition.
b) Needless complexity.  A deferred assertion can be placed
   in a fork/join_none, and then a "disable fork" can be
   called to kill any pending assertion reports when desired.
   I like this approach better than explicit flushing,
   since you have full addressability to any assertion
   in your process.  There is little chance of making a
   mistake and disabling unintended assertions.

2. My proposed syntax would be
    assert [ #0 | event_control] (expression) action_block

   For the simple case of pure RTL code, the #0 delay_control can
   be used to model deferred immediate assertions as in Erik's
   proposal (implicit flushing model).  I prefer #0 to 
   introducing a new keyword (defer) as in your proposal.

   Note that I abandoned my previous notion of allowing
   arbitrary delay controls in the syntax.  Steve Sharp's
   comments about problems with false suppression of
   assertion were good.  We can't come up with a decent
   way around those problems, so I'm letting go of that one.

   As per event_control, that will be useful for filtering
   finite-time glitches due to gate level activity.
   More on that later (with examples).

3. I think maturing assertion reports should be processed in
   the Observed region rather than the Postponed region.
   The reason is that existing concurrent assertions are
   handled in this way.  Arbitrary action block code is
   then run in the reactive region.  If we do this, then the
   need for your restrictions on allowable action code can
   be removed, and we gain more consistency with concurrent
   assertions.

4. All other aspects of the proposal would remain the same.

That's all for now - just wanted to give you an update
on where my thinking had gone.  All comments welcome.

Regards,
Doug




-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Seligman, Erik
Sent: Friday, October 19, 2007 9:12 AM
To: sv-ac@server.eda.org
Cc: sv-bc@server.eda-stds.org
Subject: [sv-bc] RE: Suppression of unique/priority glitches (new
proposal at http://www.verilog.org/mantis/view.php?id=2005)

 
OK, I've made my first attempt to write up a description of the deferred
assertions we have been discussing.  For those who have been interested
in this topic, please take a look and send me any suggestions,
corrections, or comments.  (BTW-- suggestions of a better name than
'assert defer' are also welcome.)  I've attached the new pdf doc for
your convenience.  Thanks!

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