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

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

It seems like you might not agree with Jonathan Bromley's premise,
which I might paraphrase as "Let's make things work well for simple
combinational logic cases, like 'always_comb'".  For the TB usages, it
doesn't matter if things get more complex, or we simply don't support
the feature for now.

Personally I like Jonathan's premise, and I like where Gordon and Steven
have arrived at.

For always_comb, there is no need for any explicit flushing mechanism.
For complex processes with multiple activation points, those aren't
synthesizable anyways, so your scenario of "average designers writing
RTL code and adding checks as they write" won't even apply.
If those designers use always_comb, they will automatically
get the benefit of implicit flushing.

I agree with Gordon that we should try to add explicit checks right
now, while the iron is hot.  That will avoid potential incompatibilities
in the future when we try to retrofit the functionality.  Also, I think
we should add the "finite time pulse reject" consideration to the
proposal, for the same reasons. It seems like we are very close,
and I advocate pushing through to the end to see what comes out.

Regards,
Doug




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



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