RE: [sv-ec] Program Block / Reactive Region Use Cases & Requirements

See comments below

> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Michael Burns
> Sent: Thursday, December 07, 2006 2:08 PM
> To: Ryan.S.Warner@seagate.com
> Cc: sv-ec@server.eda.org
> Subject: Re: [sv-ec] Program Block / Reactive Region Use Cases &
> Requirements
> 
> 
> Hi folks,
> 
> I have two comments (actually, the second is a question):
> 
> 1. The syntax of this proposal would seem to break backwards
compatability
> with
> the existing 1800-2005 spec. 
[DR>] But it breaks backwards compatibility with something that was
already broken. You are already in a heap of trouble if your threads
cross between programs and modules.

I like this idea - basically the program is
> syntactically analogous to an initial or always rather than a module,
> correct?
> Too bad it wasn't done that way to begin with...
> 
> 2. [general question, not specific to this proposal] With the new
proposed
> program execution semantics, is the clocking block now the one and
only
> way for
> a reactive thread to read and write values in the active/inactive/NBA
> update
> regions?
[DR>] I think so. As long as the clocking block s defined outside of a
program.
> 
> 3. [I thought of another question] If a reactive testbench wanted to
> respond to
> some design event in zero time (e.g., TB sees a signal change on the
DUT
> and
> wants to drive a response back into the DUT in the same simulator
cycle),
> is
> this possible? I assume that if it was, it would at least entail a
"delta
> cycle"
> delay; is this the case?
[DR>] Yes, this is no different then using active/NBA events. But you
can't using clocking blocks or .triggered events because they require
time to advance.


> 
> Thanks,
> Mike Burns
> 
> Ryan.S.Warner@seagate.com wrote:
> > With the discussion of the region a task runs in being ruled by
where
> the
> > thread was started, let me propose an alternative to the possibility
for
> > the program block.  It should just define a reactive process.  So
the
> > following would be equivalent:
> >
> > // P1800
> > program tb;
> >   initial begin
> >     // reactive process
> >   end
> > endprogram
> >
> > // suggested change
> > module tb;
> >   program begin
> >     //reactive process
> >   end
> > endmodule
> >
> > This is essentially what is being proposed anyway, correct?  This
always
> > seemed the most natural representation of a program to me anyway.
It is
> a
> > thread (or set of threads), not a physical piece of hierarchy.
> >
> > Please correct me if I'm wrong here.  But under the current
proposal, I
> > could put my entire testbench in modules (using classes if desired)
and
> > have it run in the reactive region.  I'd just need an artificial
level
> of
> > hierarchy containing the program to start the testbench thread.  In
> other
> > words:
> >
> > class sys_env extends rvm_env;
> >   // blah blah
> > endclass
> >
> >
//----------------------------------------------------------------------
> --
> > //What I want to happen based on what I expect SV3.1 and P1800 today
> > automatic program sys_tb;
> >   sys_env env;
> >   initial begin
> >     env = new;
> >     env.run();
> >   end
> > endprogram
> >
> > module top;
> >   sys_tb tb;
> > endmodule
> >
> >
//----------------------------------------------------------------------
> --
> > // Proposed change allows
> > program start_tb;
> >   initial begin
> >     top.env = new;
> >     top.env.run();
> >   end
> > endprogram
> >
> > module top;
> >   sys_env env;
> >   start_tb start;
> > endmodule
> >
> >
> >
//----------------------------------------------------------------------
> --
> > // I propose
> > module top;
> >   sys_env env;
> >   program begin
> >     env = new;
> >     env.run();
> >   end
> > endmodule
> >
> > Regards,
> > Ryan Warner
> > ryan.s.warner@seagate.com
> >