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.