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.