Subject: [sv-ec] RE: [sv-ac] Verification phase
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Fri Dec 06 2002 - 17:57:54 PST
> From erichm@cadence.com Fri Dec 6 17:20:18 2002
>
> 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
My original point was that you can sort the sensitvity lists within the simulator
to stratify the process evaluation - and it wouldn't be a major change to how the
language and simulators function currently. The effect is the same as your second
approach above.
You can have as many levels of priority as you want within the list processing
- two might do.
The new functionality would be available for any signal.
Regards,
Kev.
> -------------------------------------------
> 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:59:05 PST