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

Just to contribute a little institutional memory into the process since
we've now made a 3 1/2 year circle.

Please see:
(From Feb 27, 2003)

http://www.eda-stds.org/sv-ec/hm/0863.html

Where Kevin suggests exactly the same use of 'program' keyword on a
procedural block.

and

(From March, 1 2003)
http://www.eda-stds.org/sv-ec/hm/att-0870/01-SV-EC-Minutes-2003-February
-27.txt

In this face-to-face meeting we discussed the fundamental question of
"Is a program a "design unit that hooks into the hierarchy through ports
and parameters and could in turn contain other programs hierarchically"
OR "Is a program a procedural context that contains sequential code and
does not contain hierarchy".

From the votes at that meeting, the consensus was that it was a design
unit. The "Initial" keyword was added so that you could have multiple
initial blocks in the same program (since it was now a hierarchical
scope).

Jay

===================================
Jay Lawrence
Distinguished Engineer
Automated Verification Systems
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================  

>-----Original Message-----
>From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On 
>Behalf Of Rich, Dave
>Sent: Thursday, December 07, 2006 9:12 PM
>To: michael.burns@freescale.com; Ryan.S.Warner@seagate.com
>Cc: sv-ec@eda.org
>Subject: 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
>> >
>
>
>