Re: [sv-ec] programs discussion and resulting questions - Jonathan's Testbench Concern

Hi, Jonathan -

I don' think there will be a general problem with existing 
testbenches, whether or not we use clocking blocks with new 
SystemVerilog testbenches.

If you have an example, I would like to see it.

I think we are okay, because there were two schools of thought with 
existing Verilog testbenches.

(1) apply stimulus away from the active clock edge (typically on the 
negedge clock) to avoid races between testbench and design (this is 
typically what I did) and to keep the same testbench without 
modification for a gate-level version of the design with 
back-annotated setup and hold times.

(2) apply stimulus on the active clock edge as if the testbench were 
another 0-delay RTL model driving the design. This method required 
some special handling when gate-level models with back-annotated 
setup and hold times were applied (to avoid violating hold times with 
the instantly changing input stimulus). Adding nonblocking 
assignments with #1 RHS delays removed 99% of these problems.

Point is (for #2 above), engineers typically had to drive stimulus 
directly using nonblocking assignments or indirectly source the 
stimulus through signals driven by nonblocking assignments to ensure 
that stimulus did not change the inputs of the DUT before they were 
captured by the active clock edge. Stimulus driven from a program 
block can now be assigned using either program-blocking or 
program-nonblocking assignments, because they all will happen after 
the RTL clocked logic reads the previous stimulus inputs, so we don't 
have to worry about stimulus being applied to RTL data inputs that 
are clocked immediately through the design.

The only potential problem that I foresee is if program-stimulus 
interacts with module-stimulus, causing unwanted stimulus settling 
races, but I can't even think of a good example of this "potential" problem.

I use the attached diagram to explain this relationship in my 
SystemVerilog training classes.

Regards - Cliff

At 07:35 AM 11/30/2006, Jonathan Bromley wrote:
>Dave Rich's discussion is clear and useful, but doesn't
>answer my concern about the impact on typical
>verification environments of the proposed change
>to the scheduling rules.
>
>[Dave Rich]
> > 4.   Initial blocks are scheduled as reactive processes,
> >      as well as all its child processes. The definition
> >      of a reactive process is new and applies to the
> >      action blocks of concurrent assertions as well.
> > So there is no longer a need to distinguish between
> > program versus design variables other than its general
> > visibility as an identifier in rule 1 above. All of the
> > issues about program ports being program variables or
> > design variables go away, as well any related issues
> > concerning the target of any kind of assignment.
>
>"Issues go away" in the sense that what happens when you make the
>assignment is now easily defined; but as I pointed out in an
>earlier email, this may be at odds with what users want or need.
>
>Typical methodologies for testbench architecture call for some
>kind of protocol stack where high-level activities, which
>together form the testcase that a verification engineer wishes
>to exercise, are passed through successive levels of the stack
>and ultimately decompose into a succession of pin-wiggles at
>the lowest level.  The low-level, BFM-like pin-wiggler is quite
>likely to be written as a Verilog module, and may have been
>carefully coded so its timing works right when executed as
>a Verilog module - i.e. as an active, rather than reactive,
>process.
>
>Now we're saying that a top-level testbench program
>may call into a high-level transactor, which in turn may call
>lower-level transactors, all the way down to a BFM that was
>written five years ago - and, miraculously, the BFM finds
>itself executing as a reactive process.  I'm having a very
>hard time trying to persuade myself that this won't break
>lots of existing verification infrastructure.
>
>Note that it even opens the possibility that the same
>BFM may find itself executing in both Active and Reactive
>regions when called from different parts of the same test
>environment; and the BFM itself, and its surrounding
>infrastructure, are quite ignorant of this.  That's an
>idea that scares me a lot.
>
>This will not be a problem for TB architectures in
>which the bridge from reactive to active process is
>provided by a clocking block.  The problem arises when
>the path from high-level program activity down to
>low-level signal manipulation is entirely through
>subprogram calls.
>
>[re. Dave Rich's example:]
> > The semantics of scheduling of the assignments to
> > C and D was already dynamic based on the conditional
> > delay in front of them.
>
>So wouldn't it be preferable to solve this problem
>by ensuring that, when a subprogram is called, the
>call is defined to be the creation of an execution
>event in the reactive region for subprograms in a
>program, and the active region for other subprograms?
>
>And yes, I know this needs further thought because
>of class methods that might be created in a module
>but instantiated in, or referenced from, a program.
>--
>Jonathan Bromley, Consultant
>
>DOULOS - Developing Design Know-how
>VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
>Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
>Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
>Fax: +44 (0)1425 471573                           Web: http://www.doulos.com
>
>The contents of this message may contain personal views which
>are not the views of Doulos Ltd., unless specifically stated.

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training