>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.Received on Mon Sep 10 20:01:32 2007
This archive was generated by hypermail 2.1.8 : Mon Sep 10 2007 - 20:01:42 PDT