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.