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

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

>I think some ability for explicit control here is a good idea.  But we
>should probably make it a separate Mantis, just because the basic
>concept in 2005 is controversial enough that I don't want to
>unnecessarily complicate things.
>
>From today's discussion, it sounds like the flush-on-event-reschedule
>alg suggested by Steven may be a good way to go.  I'll start working on
>a revised 2005 proposal on that basis.

Erik,

I wasn't suggesting that the explicit flushing control be in addition
to the implicit flushing.  That would only let you flush extra times,
not avoid flushing when you don't want to.

I was suggesting that the explicit flushing control be instead of
the implicit flushing.  That way you can flush when you want to, and
avoid flushing when you don't want to.

Gord suggested that implicit flushing would still be reasonable for
a few cases like always_comb.  Those don't have problems with multiple
event controls or delay controls or the position of the event controls,
because they don't allow anything but the implicit one which is at a
known position.  The explicit flushing would be used elsewhere.

I don't know that the explicit flushing is a better way to go than an
implicit flush-on-event-reschedule mechanism.  But if we wanted to go
that way, it isn't something that can be "added on" to the implicit
approach later.

Steven Sharp
sharp@cadence.com


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