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

Hi Erik and others,

After some internal discussions, I wanted to clarify that neither
Gordon nor I are totally sold on explicit disables of these checks.
If we can find a way to stay with implicit rules, even for the
complex cases, the language constructs be simpler to specify
and reason about.

The point I was trying to make earlier is that we should hash out
the topic of "explicit disable" right now, rather than doing that
in the future.  We are close to something good and we have momentum.

I'll try to write up our understanding of the state of this issue
sometime in the next day.  Including "finite time pulse reject".

We think that "deferred immediate assertions" and "deferred
unique/priority" are high value enhancements to SV RTL, so I'd like
to make sure we can get something done for the 2008 deadline, even
if only for the RTL-only cases.

Thanks,
Doug

-----Original Message-----
From: Seligman, Erik [mailto:erik.seligman@intel.com] 
Sent: Wednesday, October 17, 2007 3:20 PM
To: Warmke, Doug; Steven Sharp; Vreugdenhil, Gordon
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

 

> 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 see... So always_comb will have implicit flushing, but other use cases
will probably be by expert users anyway.  I guess that does make sense.

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

Can you remind me again what it is you are referring to by "finite time
pulse reject"?

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