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

Mike,

 

Some quick answers inlined below.

 

            Arturo

 

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Michael Burns
Sent: Thursday, December 07, 2006 2:08 PM
To: Ryan.S.Warner@seagate.com
Cc: sv-ec@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. 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...

 

I would argue that the same expressive power is available today. Instead
of writing:

module tb;

   program begin

     //reactive process

   end

endmodule

You can write:

module tb;

   program x; initial begin   

       //reactive process

   end endprogram 

endmodule

The existing solution allows for the approach shown above (testbench
encapsulated by a module),

Or it allows the testbench to connect to the design via ports, which may
be interfaces. Or even

virtual interfaces.

 

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?

 

I assume you are referring to the proposed program execution semantics
that is set depending

on where the process originates. The answer is no. Users can still write
to variables directly or 

via nonblocking assignments. The sensitivity of the processes associated
with the changing

variables would now depend entirely on the origin of the process and not
where the variable was

declared. A clocking block is still the only safe mechanism (that
doesn't rely on methodology) to 

gain access to the sampled values. And a clocking block is also the only
mechanism able to

automatically drive asynchronous signal changes on specified
(synchronous) clock edges plus

a skew.

 

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?

 

This has always been possible (and not particular to the new proposal)
and it has always 

entailed a "delta cycle", or, since it's not defined for Verilog a
subsequent re-activation of the

Active region(s). 

 

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

>