RE: [sv-ec] package classes and anonymous programs

[Arturo Salz]
>> At the recent face2face meeting we discussed and have
>> a preliminary agreement that the scheduling should be
>> based on the process call graph rather than where the
>> class is defined or the object is instantiated.

[Steven Sharp]
> I was not at the face2face, and I disagree rather
> strongly with this idea.  A subroutine is an
> encapsulation of behavior, which should be independent
> of where it is called from.

At the face-to-face I didn't comment on this suggestion
because I hadn't thought carefully about the issues,
and I could see that the call-graph scheme would fix
some specific issues of concern.  On reflection
I am much more inclined to Steven Sharp's view.

For verification methodologies in which the division
between Reactive execution (testbench) and Active
execution (design) is captured in a clocking block,
the call-graph scheme works well.  However, there are
many ways to skin a cat.  Some published verification
methodologies rely on subroutine call from one level
of the verification hierarchy to the next lower level,
probably via task calls in an interface or module,
all the way down to procedural call into a BFM that is
coded in a module or interface.  In such an environment,
the ultimate execution of code in a module is very far
removed from the root of the call stack, an initial 
block in a program at the top of the verification
hierarchy.  In effect we end up with writers of 
lower-level verification code having no idea 
whether it will be executed in Reactive or Active.
It is bad enough that the language gives us no 
control over users' behaviour in this regard,
worse still that there is no well-defined mechanism
for switching the flow of execution across the
reactive/active divide - so we can't even offer users
a methodology fix.

Re-affirming the distinction between program code 
and module-level code, based on where that code
is defined, gives users and IP authors the localized
control over scheduling that they need.  Of course, 
it requires very clear definition of the semantics of
transferring control from Reactive to Active execution 
and back again.  I think that effort of definition
is well worth it.

Discussion in a class I led recently gave me an 
alternative insight into the usefulness of Reactive
execution that I hadn't articulated heretofore:  The
Reactive region of the scheduler makes it possible for
testbench code to execute atomically with respect to
design code.  HVLs that hook to a simulator through 
the PLI have always had that luxury.  Testbench 
writers in SV probably need it as well.
-- 
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.