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

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.
 

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Tuesday, October 16, 2007 2:19 PM
To: Steven Sharp
Cc: Thomas.Thatcher@sun.com; Seligman, Erik; sv-ac@eda.org;
sv-bc@eda-stds.org
Subject: Re: [sv-ac] RE: [sv-bc] Suppression of unique/priority glitches

Oh that is an interesting spin.

If we coupled that with default behavior for things like always_comb
that do in fact have well defined combinational behavior, I think that
we might end up in a good place.

Gord.


Steven Sharp wrote:
> Thinking a little outside the box...
> 
> Gord suggested thinking about the delayed reporting as a delayed child

> subprocess, and the discarding of pending violations as disabling 
> those subprocesses, much like "disable fork".
> 
> There has been disagreement about when to implicitly execute that 
> disabling operation.  What if it were made an explicit operation, like

> "disable fork" is?  You could stick a "disable assert" into the code 
> where you wanted to discard any pending unreported violations.
> 
> This seems like overkill for the typical usage of unique/priority, but

> perhaps it is warranted for more general usage of assertions.
> 
> Steven Sharp
> sharp@cadence.com
> 
> 

--
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com

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