Re: [sv-ac] Verification phase

Subject: Re: [sv-ac] Verification phase
From: Bassam Tabbara (bassam@novas.com)
Date: Fri Dec 06 2002 - 18:14:28 PST

Indeed Erich, "simulation" is more fine grained than clock so I was side-stepping, of course change of clock is a trigger for all this. Now that you mention it, I am thinking of all the assertions (2 types) not just the declarative version .... Also another question I had raised is sampling testbench variables in assertions.

BTW, I am just talking semantics of what makes sense, this somehow digressed into implementation when I commented on Kevin's email, he just reminded me is all...

-Bassam.

Erich Marschner wrote:

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.
|
|

-- 
Dr. Bassam Tabbara
Technical Manager, R&D

Novas Software, Inc.
bassam@novas.com
(408) 467-7893
 

This archive was generated by hypermail 2b28 : Fri Dec 06 2002 - 18:15:07 PST