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

That is what I meant earlier by a "well constructed design". 

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Francoise Martinolle
> Sent: Thursday, November 30, 2006 6:24 PM
> To: Jonathan Bromley; sv-ec@server.eda-stds.org
> Subject: 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.
> 
> 
>