RE: [sv-bc] Glitches in unique/priority case/if violations

I was aiming for a similar effect in the current 2005 proposal with this
wording:

"If the assertion appears in a context with no defined clock, it shall
be treated as if clocked by a virtual clocking event that is triggered
at the beginning of every time step."



-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Warmke, Doug
Sent: Tuesday, September 11, 2007 12:00 PM
To: Steven Sharp; sv-bc@server.eda-stds.org; Brad.Pierce@synopsys.com;
Maidment, Matthew R
Subject: RE: [sv-bc] Glitches in unique/priority case/if violations

I think the following suggestion from Steve Sharp should be considered
as part of any comprehensive proposal to address the usability problems
with unique/priority case/if.
This is what I was alluding to when I mentioned some kind of "pulse
reject" mechanism in my earlier mail.

Regards,
Doug

-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Steven Sharp
Sent: Monday, September 10, 2007 8:01 PM

I would think you could have the concept of a concurrent assertion that
is "clocked" by a change in any of its operands (like a combinational
block) and waits until an appropriate end-of-time queue to evaluate in
order to filter out glitches.  Is that what you meant?


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