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

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

Ah, I see.

I think explicit flushing would be kind of impractical from the design
engineer's point of view-- they would have to think not only about where
they want to check some logic with an assertion, but also manually
figure out a sync point to reset the checks.    Writing assertions to
check code you just wrote comes somewhat naturally; I don't think the
same can be said of defining the flush point.  

How about this:
	- In the current proposal, automatic flush-on-event-reschedule
as we've been discussing.
	- In a later proposal, add a command for explicit flushing,
which also turns off all future implicit flushing in the process.  (You
should also be able to execute it in a 'null mode' to turn off future
implicit flushes without flushing at the current time.  We can hash out
the details when we get there.)

I like the idea of advanced users being able to control the flushing,
but want to do it in a way that minimizes any burdens on the average
user.  Remember that what started this whole thing is that normal users
try to intuitively use immediate assertions (in current SV code) to
check values in functions, etc, and run into glitch headaches as a
result. 



-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Steven Sharp
Sent: Wednesday, October 17, 2007 12:51 PM
To: gordonv@model.com; sharp@cadence.com; Seligman, Erik
Cc: Thomas.Thatcher@sun.com; sv-ac@server.eda.org;
sv-bc@server.eda-stds.org
Subject: 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.

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