Subject: RE: [sv-ec] RE: [sv-ac] Verification phase
From: Erich Marschner (erichm@cadence.com)
Date: Mon Dec 09 2002 - 19:34:54 PST
Michael,
| a) there are already good definitions on a simulation
| schedule have to look like (VHDL, OMI). Do we really need to
| define a new one?
Only if you want to accurately handle the imposition of cycle-oriented semantics (needed for accurate evaluation of assertions) on top of event-oriented simulation semantics. If you don't really want or need accuracy, you can use the existing event-driven simulation cycle and ignore the false firings that result.
| b) given the above scheduling, isn't a "post-propagation"
| process of simulation cycle tx.y nothing else than a
| "hypersensitive" of simulation cycle tx.(y+1) ???
Yes, it is. The point, however, is we need to evaluate assertions ONLY "at" (either pre- or -post) simulation times that correspond to clock events - and determination of when a clock event occurs, when the clock may be delayed or gated, requires looking at the combinational logic associated with the clock - SO there is an issue about whether that combinational logic is evaluated as part of the clock event detection (i.e., selection of simulation times at which to run the assertion) or as part of the design itself.
| c) why do we need to distinguish between clocks and
| non-clocks ("design logic") as done below?
We need to distinguish clock cycles (i.e., simulation cycles in which clock events occur) because assertions are clocked - just like the state machines that typically appear in the underlying HDL description. More to the point, we need to detect - dynamically - the occurrence of such cycles, so we know when to schedule assertion checkers to run. And when clocks become complex (e.g., gated clocks), we have two choices - handle the complexity as part of the clock cycle detection process, or handle the complexity as part of simulating the design. My point was simply that neither answer will be the right answer in all cases, so we have a challenge to address.
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: Michael Rohleder [mailto:michael.rohleder@motorola.com]
| Sent: Monday, December 09, 2002 1:49 PM
| To: Erich Marschner
| Cc: Kevin Cameron x3251; sv-ec@eda.org; sv-ac@eda.org
| Subject: Re: [sv-ec] RE: [sv-ac] Verification phase
|
|
| Hello Erich,
|
| please excuse, if I am speaking up here and iterate things
| that are well known or not of interest. I just don't
| understand some of the discussions here, and would like to
| identify why. So please help me out on this a little bit:
| a) there are already good definitions on a simulation
| schedule have to look like (VHDL, OMI). Do we really need to
| define a new one? As an example, both above (significantly
| simplified -- I am just using them to use a clearly
| terminology here) define a scheduling of the form
| time step t1:
| advance time to t1
| simulation cycle t1.1
| simulation cycle t1.2
| simulation cycle t1.3
| time step t2:
| advance time to t2
| simulation cycle t2.1
| simulation cycle t2.2
| time step t3:
| ...
| Also VHDL (due to the 'delayed) and OMI (due to
| post-propagation statements) permits a split of each
| simulation cycle into:
| a loop to run all sensitive processes (yes, yes, there
| is much more detail here ...)
| run 'delayed or post-propagation processes
| b) given the above scheduling, isn't a "post-propagation"
| process of simulation cycle tx.y nothing else than a
| "hypersensitive" of simulation cycle tx.(y+1) ???
| c) why do we need to distinguish between clocks and
| non-clocks ("design logic") as done below?
|
| When I use the above definitions on Erich's problem, don't
| distinguish between clocks, gated clocks, and non-clocks,
| and make an assertion A a post-propagation process, the
| result is (same notation used as above ...):
|
| At time T:
| <advance time to T>
| In step T.1, C will get updated.
| In step T.1post-prop: A won't be run, because GC hasn't
| been computed yet.
| In step T.2, GC will be computed as the 'and' of C and the
| combinational logic G.
| In step T.2post-prop: A will be run, if GC has changed
| At the next time step:
| <advance time to T>
|
| If you don't like the notion of "post-propagation"
| processes, make them first processes of the next simulation
| cycle, but not of the next time step. (I would consider this
| mostly an implementation detail). The result would be rather
| similar ...
|
| At time T:
| <advance time to T>
| In step T.1pre-prop: <always nothing to do>
| In step T.1, C will get updated.
| In step T.2pre-prop: A won't be run, because GC hasn't
| been computed yet.
| In step T.2, GC will be computed as the 'and' of C and the
| combinational logic G.
| In step T.3pre-prop: A will be run, if GC has changed
| In step T.3, nothing more is to do, network has already settled
| At the next time step:
| <advance time to T>
|
| Also the calculation of a static schedule should be not a
| major problem here. A simulation cycle tx.(y+1) need only to
| be called, if the processing of simulation cycle tx.y
| requested some later processing in the time step.
| VHDL simulator does it, why should Verilog simulators not be
| able to do it?
|
| Just my $0.01 (not worth 2).
|
| - Michael
|
| Erich Marschner wrote:
|
| > 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.
| > | > |
| > | > |
| > | >
| > | >
| > |
| > |
| > |
|
| --
|
| NOTE: The content of this message may contain personal views
| which are not neccessarily the views of Motorola,
| unless specifically stated.
|
| ___________________________________________________
| | |
| _ | Michael Rohleder Tel: +49-89-92103-259 | _
| / )| Software Technologist Fax: +49-89-92103-680 |( \
| / / | Motorola, Semiconductor Products, System Design | \ \
| _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_
| (((\ \>|_/ > < \_|</ /)))
| (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////)
| \ /_______________________________________________\ /
| \ _/ \_ /
| / / \ \
|
| The information contained in this email has been classified as:
| Motorola General Business Information (x)
| Motorola Internal Use Only ( )
| Motorola Confidential Proprietary ( )
|
|
| *** This note may contain Motorola Confidential Proprietary or
| Motorola Internal Use Only Information and is intended to be
| reviewed by only the individual or organization named above.
| If you are not the intended recipient or an authorized
| representative
| of the intended recipient, you are hereby notified that
| any review,
| dissemination or copying of this email and its
| attachments, if any,
| or the information contained herein is prohibited. If
| you have received
| this email in error, please immediately notify the sender by
| return email and delete this email from your system.
| Thank you! ***
|
|
This archive was generated by hypermail 2b28 : Mon Dec 09 2002 - 19:36:46 PST