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

Hi Jonathan,

Your concerns about legacy BFM behavior are valid.
However, those problems exist with or without the
proposal created at the face-to-face.

A program is allowed to directly call a task or function
in design scope.  When that task or function executes, at
least some of its statements will execute in the reactive
region, contrary to the fact that the task or function was
declared in design scope.  This happens with or without
the 890 proposal.

I'm not overly worried about porting legacy BFM's into
modern SV environments. First, one should be able to
insulate them with clocking blocks, as Francoise mentioned.
Second, if those BFM's are really high value, and it's not
possible to interpose clocking blocks, it may be worthwhile
to keep the testbench environment entirely in the design
region.  That has worked pretty well for 20 years.
I imagine such hybrid SV environments would lead
to problems regardless of the declaration-based vs.
thread-based scheduling semantics we are discussing.

Regards,
Doug

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Jonathan Bromley
> Sent: Thursday, November 30, 2006 7:35 AM
> To: sv-ec@server.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.
> 
>