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

Hello All,

In reading some of the recent posts, I believe that people are
starting to lose track of the main reasons behind the creation
of Mantis 890 and the face-to-face meeting.

When testbenches and designs are well-constructed, there are currently
few issues with the LRM that would cause implementations to diverge.
Similarly, there are few instances in which user code will behave
in a surprising manner.

Mantis 890 is based on the fact that the LRM should define
behavior in *all* cases, not just "well constructed" cases.
The thread-based solution turns out to be one of those design
decisions which makes corner cases fold into being instances
of mainstream cases.  For those who did not attend the meeting,
or those who didn't closely follow the logic of the discussion
at the meeting, this may be hard to understand.

The alternative to the thread-based execution semantics solution
will be a very lengthy LRM chapter.  It will have to cover the
behavior of a large number of corner cases, all with different
and inconsistent behaviors.  I certainly wish all interested
parties could have attended, since reexplaining all the corner
cases that were discussed will not be possible over email.

Once again, I believe in well-constructed designs that follow major 
known methodologies, there will be minimal or no difference in
thread-based scheduling semantics vs. declaration-based semantics.
So this issue may not be as major as some people perceive.

Furthermore, thread-based scheduling semantics opens up the
possibilities for yet more methodologies and re-use.  Consider
a utility class defined in a package.  Currently, a program can't
make use of such a class, since items declared in packages are
considered to have "design region" scheduling semantics.
Thus, such a class would have to be written twice:  Once in a
normal package context, and once in an anonymous program block.
That is an undesirable repercussion of declaration-based
scheduling semantics. It will be removed if the consensus
reached at the face-to-face meeting becomse reality.

Regards,
Doug


> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Jonathan Bromley
> Sent: Sunday, November 26, 2006 9:31 AM
> To: sv-ec@server.eda-stds.org
> Subject: 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.
> 
>