Subject: [sv-ec] RE: [sv-ac] Verification phase
From: Erich Marschner (erichm@cadence.com)
Date: Fri Dec 06 2002 - 19:01:22 PST
Hi Kevin,
| 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.
I agree - with one caveat (which is the point I was trying to make). It is easy to define "levels of sensitivity", and to schedule 'hypersensitive' processes to run before merely 'sensitive' processes. But when scheduling is conditional on other signals being updated (in the same cycle), as is the case with assertions/monitors that are dependent upon clock edges (and possibly on combinational clock gating logic as well), there may be no statically determinable order that works in all cases. Or at least, careful thought is required to be sure that assertions/monitors triggered by clocks gated by combinational logic are evaluated at the appropriate time, without forcing users to implement gated clocks in only one way.
Suppose we have a clock C, a gated clock GC <= C && G, and an assertion A clocked by GC. Supposed C is scheduled to change at some time T. Let's suppose we have defined the evaluation cycle to
1. update clocks
2. run assertions and monitors
3. run design logic
At time T:
In step 1, C will get updated.
In step 2, A won't be run, because GC hasn't been computed yet.
In step 3, GC will be computed as the 'and' of C and the combinational logic G.
At the next time step:
In step 2, A will be run, if GC has changed. By this time some inputs to A may have changed.
Depending upon what the user is expecting, this solution might result in what appear to be race conditions when gated clocks are involved.
The basic issue is this: if assertions/monitors are triggered by gated clocks, is the gating logic part of the clock evaluation (in which case it should happen in step 1), or is it part of the design (in which case it should happen in step 3)? Both answers are possible, and both may be true at the same time, in the same design. This makes it difficult to come up with a simple, static schedule for clock evaluation and assertions/monitors prior to design evaluation (although it should be said that scheduling assertions/monitors to run *before* clock evaluation is even more difficult).
But perhaps I'm just not seeing the obvious solution. Any suggestions?
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: Kevin Cameron x3251 [mailto:Kevin.Cameron@nsc.com]
| Sent: Friday, December 06, 2002 8:58 PM
| To: sv-ec@eda.org; Erich Marschner
| Cc: sv-ac@eda.org
| Subject: RE: [sv-ac] Verification phase
|
|
| > 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 - 19:02:37 PST