RE: [sv-ec] programs discussion and resulting questions

 
Perhaps the real correct and safe way to create a verification
environment is to use clocking blocks
like Jonathan says to communicate between TB and DUT. 


-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Jonathan Bromley
Sent: Thursday, November 30, 2006 10:35 AM
To: sv-ec@eda-stds.org
Subject: Re: [sv-ec] programs discussion and resulting questions

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.