[sv-ec] RE: [sv-ac] Verification phase


Subject: [sv-ec] RE: [sv-ac] Verification phase
From: Erich Marschner (erichm@cadence.com)
Date: Fri Dec 06 2002 - 17:22:12 PST


Bassam,

If I might add a little to this ...

Note that the boundary of interest here is not merely the boundary between successive simulation cycles - it is the boundary between successive *clock* cycles. So scheduling assertions and monitors at the end of a simulation cycle (e.g., rosynch time) or at the beginning of a simulation cycle is not sufficient; scheduling must be further restricted so assertions and monitors occur at the end (or beginning) of a clock cycle also. Since the beginning of a clock cycle is defined by a change on the clock, you either need to look ahead in the event queue to see if the clock is about to change (if scheduling at the end of the clock cycle), or you need to update clocks first in each simulation cycle, and run assertions and monitors immediately after that, before anything else (if scheduling at the beginning of the clock cycle.

Of course, things get a bit more complex when you want to deal with gated clocks ....

Regards,

Erich

-------------------------------------------
Erich Marschner, Cadence Design Systems
Senior Architect, Advanced Verification
Phone: +1 410 750 6995 Email: erichm@cadence.com
Vmail: +1 410 872 4369 Email: erichm@comcast.net

| -----Original Message-----
| From: Bassam Tabbara [mailto:bassam@novas.com]
| Sent: Friday, December 06, 2002 8:00 PM
| To: Kevin Cameron x3251; sv-ec@eda.org
| Cc: sv-ac@eda.org; Dr. Bassam Tabbara
| Subject: RE: [sv-ac] Verification phase
|
|
| Kev., the last thing in one cycle is not the same as the
| first thing in the
| next cycle, by virtue of that pesky "next" word there. -My-
| opinion is that
| $monitor and assert should be in same spot. As you know, the issue of
| rosynch callback, rwsynch callback, nonblocking,
| $monitor/$strobe has been
| interpreted, re-interpreted, and mis-interpreted for ages,
| and that is when
| only "design" is there, with "stimulus" this is bound to be
| even more vague.
|
| My point is this should be clearly defined ... so that both
| -your- opinion
| and mine can at least be resolved by clearly defined
| semantics in the LRM,
| if not made allowance for i.e. one could argue that this is
| a degree of
| freedom that must be left to tool providers, in which case
| that statement
| should be made. Therefore re-emphasizing the need for
| splitting the two
| stages, assertion and stimulus.
|
| My point clear now ?
|
| Salam
| -Bassam.
|
|



This archive was generated by hypermail 2b28 : Fri Dec 06 2002 - 17:22:48 PST