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

Hi guys-- 

    (Sorry to enter this conversation late, I wasn't subscribed to
sv-bc.)   I think from the conversation below, the latest Mantis 2005
proposal may be pretty close to what you are suggesting:  concurrent
assertions are enabled even in unclocked locations.  An unclocked
concurrent assertion is defined as taking effect at the end of each time
step.  Have you taken a look yet?  Any suggested rephrasings /
improvements would be appreciated; I'm not quite sure if the way we've
specified it in the current draft is acceptable.


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

That's approximately what I'm after. I thought I stated as much in the
thread.  Anyway, I'm after a combinational assertion that can be placed
in procedural for-loops and functions and everywhere else that should
enable good assertion practice of location with relevant code-- and get
evaluation semantics closer to that of a concurrent assertion.

unique/priority are follow-ons IMO.  I was proposing adding a modifier
to them such that their built-in check could be evaluated with this new
semantic instead of the current, immediate semantic.

Matt
--
Matt Maidment
mmaidmen@ichips.intel.com
  

>-----Original Message-----
>From: Steven Sharp [mailto:sharp@cadence.com]
>Sent: Monday, September 10, 2007 8:01 PM
>To: sharp@cadence.com; sv-bc@eda-stds.org; Brad.Pierce@synopsys.com; 
>Maidment, Matthew R
>Subject: RE: [sv-bc] Glitches in unique/priority case/if violations
>
>
>>From: "Maidment, Matthew R" <matthew.r.maidment@intel.com>
>
>>I think any restrictions regarding for-loops should be removed.
>>If there's some need to clarify the behavior in a for-loop, that's 
>>fine.
>
>Those restrictions appear to be necessary to make Erik's proposed 
>mechanism work.
>
>>I agree with your statement about simplicity and feel that some very 
>>simple feature is missing-- glitch insensitive combinational 
>>assertions.  Not all assertions require a clock and using one can 
>>actually hide problems.
>
>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?
>
>However, that still doesn't solve the problem of unique/priority.
>Those are effectively immediate assertions.  The existence of 
>combinational concurrent assertions doesn't solve the problem of 
>converting an immediate assertion into a concurrent assertion.
>
>>I don't believe forcing users to write a function to handle the 
>>process however they choose is practical.  I don't believe there are 
>>enough features in the language to enable code execution in the 
>>appropriate order in/at/around each simulation region.
>
>Would the addition of combinational concurrent assertions allow 
>execution of the user check in the appropriate region?
>
>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.