Subject: [sv-ec] RE: [sv-ac] Verification phase
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Fri Dec 06 2002 - 16:15:02 PST
> From Bassam@novas.com Fri Dec 6 15:49:37 2002
>
> Thanks Kev. I would like to take this opportunity to re-emphasize (Dave had
> a similar comment I think) that "verification phase" seems to encompass 2
> different things: assertion checking, and "testbench" stimulus. I would like
> to see a clear separation of these two: may be have "Design", "stimulus code
> (a better name needed)", "assertion (better name needed)". Also, it is a bit
> disconcerting that (as I understood the presentation) $monitor task and
> "assertion" were in different slots, and would give different results. The
> latter after "stimulus", the former before. I would think users would not be
> happy with this, and in general not sure that it makes sense.... reasonable
> people can disagree, but it has to be backward compatible... Also btw, I
> neglected to mention that conceivably assertions need to access the state
> of -variables- in the stimulus much like they do design (if indeed we think
> of everything together, after all that is the intent of putting the whole
> language together, right ???),
so really I think assertions should be last
> in a time step, again $monitor, convincing ? In any case, splitting the two
> things -clearly- would be better for discussion.
Being the last thing in one cycle is much the same as being the first thing
in the next, but it is harder to schedule something as "last" - usually you
have to look again when it deschedules to see if it is last and reshedule
if it isn't. Being the first thing is easier to arrange (when you know what
triggers the cycle).
Generally for synchronous logic the requirement is that data is stable by
the start of the next clock cycle, so you want to check the state when the
clock is triggered but before it has an effect on the design. I would
probably add to my last e-mail that a "super-sensitive" process should not
be synthesized, it should only be used for verification.
Regards,
Kev.
> Indeed Peter, Surrendra, and the guys, and Jay's feedbacl did a great job
> brainstorming on the scheduling aspects I hope we can have a detailed
> write-up and some discussion on this again soon.
>
> Salam,
> -Bassam.
>
> P.S. HaPpy Eid (end of Ramadan) to all ! Have a good Friday, and a great
> weekend!
>
>
> --
> Dr. Bassam Tabbara
> Technical Manager, R&D
> Novas Software, Inc.
>
> http://www.novas.com
> (408) 467-7893
>
> -----Original Message-----
> From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]On
> Behalf Of Kevin Cameron x3251
> Sent: Friday, December 06, 2002 9:38 AM
> To: sv-ec
> Cc: sv-ac@server.eda.org
> Subject: [sv-ac] Verification phase
>
>
>
> After Peter's presentation on the program block and Jay's comments about
> "preponed"
> processes, I was wondering if it would help to look at the problem of
> placing the "verification
> phase" slightly differently. Since the simulator usually has to maintain
> sensitivity lists for signals
> for evaluating all the "@(..." statements, you could (partially) sort the
> lists so that some processes
> are evaluated before others. All you would need to do then is tweak the
> sensitivity statement
> syntax to put the sensitive process earlier on the list if it is a
> verification process, e.g.:
>
> always @+(clock) // super-sensitive
> assert ...; // check data
>
> always @(clock) begin // process data
> q = d;
>
> - the assertion would always be processed first.
>
> While you could have more levels of sensitivity, two levels maps to front
> and back of
> a list so implementation might be quite easy.
>
> Just a thought,
> Kev.
>
> --
> National Semiconductor, Tel: (408) 721 3251
> 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
>
>
This archive was generated by hypermail 2b28 : Fri Dec 06 2002 - 16:15:52 PST