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. 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?

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?

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
>