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

>From: "Seligman, Erik" <erik.seligman@intel.com>

>The process-waking-up model breaks that requirement in examples like the
>#0 case we discussed.  I think this could be very dangerous in its
>potential to deceive RTL designers.  For that reason, I think we should
>try to define this in terms of the process-entry model if it's at all
>viable.

In the last SV-BC meeting, I suggested that the #0 oddities could be
avoided by a minor adjustment to the process-waking-up model.  That
would be the process-waking-up-from-an-event-control model.  A wakeup
on a delay control would not discard violations.  Only a wakeup on an
event control would do that.

The zero-delay glitch issues are related to repeated triggering of
evaluations by event controls.  A wakeup on an event control can be
viewed as an evaluation in response to an evaluation request; a wakeup
on a delay control cannot.

Gord did not like the idea of distinguishing these two different kinds
of process wakeups (or more, when you consider wait statements, wait
fork statements, and waiting at join or join_any).  However, they are
distinct constructs and it is not ambiguous which one you are waking
up from.

Steven Sharp
sharp@cadence.com


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