RE: [Fwd: Re: [sv-ec] programs discussion and resulting questions] - Dave Rich Summary

Hi Cliff,

Section 16.6 at the very end of the program block clause
has the answers to all your questions.  I think that the
answer to every question you asked is "Yes", based on my
read of 16.6.

Regards,
Doug 

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Clifford E. Cummings
> Sent: Friday, December 01, 2006 5:24 PM
> To: sv-ec@server.eda-stds.org
> Subject: RE: [Fwd: Re: [sv-ec] programs discussion and 
> resulting questions] - Dave Rich Summary
> 
> Hi, Dave -
> 
> Very nice summary.
> 
> Question about point #3 - maybe i missed this in the LRM.
> 
> If there is a free-running clock oscillator in the top-module, will 
> all-programs-executing-$exit kill the free running clock oscillator?
> 
> If a program thread terminates without a $exit (initial block just 
> runs out of statements) is it an implied $exit that can trigger the 
> implicit $finish?
> 
> Is this why we have $exit, to get the implicit $finish if one puts 
> all test code into programs, without the need to count clocks from 
> the top module or without the need to synchronize through an event 
> call to the top module to trigger the $finish?
> 
> The last time I checked, I did not find a working implementation of 
> $exit, but I may not have tried in a while.
> 
> Do you know where in the LRM this is discussed?
> 
> Thanks - Cliff
> 
> At 04:31 PM 11/29/2006, Rich, Dave wrote:
> 
> >Let me try to put a different spin on the new program block 
> >semantics from the face-to-face meeting.
> >
> >First of all, we are removing all the existing blocking versus 
> >non-blocking rules that program blocks had, and we are defining the 
> >scheduling semantics for continuous assignments and program ports 
> >that were previously undefined. This created an opportunity to 
> >simplify and clarify the rules that remain.
> >
> >There are now only four key rules for program blocks:
> >
> >1.      Identifiers declared in program blocks are only visible to 
> >it and other program block
> >
> >2.      An implicit call to $finish is made immediately after all 
> >program block instances have implicitly or explicitly called $exit.
> >
> >3.      Program blocks must be leaf instances in the hierarchy; they 
> >cannot contain instances of other programs/modules/interfaces/gates.
> >
> >4.      Initial blocks are scheduled as reactive processes, as well 
> >as all its child processes. The definition of a reactive process is 
> >new and applies to the action blocks of concurrent 
> assertions as well.
> >
> >So there is no longer a need to distinguish between program versus 
> >design variables other than its general visibility as an identifier 
> >in rule 1 above. All of the issues about program ports being program 
> >variables or design variables go away, as well any related issues 
> >concerning the target of any kind of assignment.
> >
> >For rule 4, refer to the example below. The assignments to A and B 
> >retain the same semantics as before, but the loophole in making a 
> >blocking assignment to a design variable has been made irrelevant. 
> >The assignment to C and D are now scheduled based on the thread that 
> >called them, not based on the fact that T is defined in a module. 
> >The semantics of scheduling of the assignments to C and D was 
> >already dynamic based on the conditional delay in front of them.
> >
> >The semantics of scheduling the return of T in the program block was 
> >also dynamic because you would know if T had blocked and needed to 
> >be resynchronized to the reactive region.
> >
> >module top;
> >
> >int A,B,C,D;
> >
> >p p();
> >
> >task T(bit i);
> >
> >A = i+1;
> >
> >B<=i+2;
> >
> >if (i) #1;
> >
> >C = i+3;
> >
> >D <=i+4;
> >
> >endtask
> >
> >initial begin
> >
> >         #1 T(0);
> >
> >         #1 T(1);
> >
> >         end
> >
> >endmodule
> >
> >program p;
> >
> >int X,Y;;
> >
> >initial begin
> >
> >         #5
> >
> >X = 1;
> >
> >T(0);
> >
> >         Y = 2 ;
> >
> >         #5 T(1);
> >
> >            Y = 3 ;
> >
> >         end
> >
> >endmodule
> >
> >
> >
> > > -----Original Message-----
> >
> > > From: owner-sv-ec@server.eda.org 
> > 
> [<mailto:owner-sv-ec@server.eda.org>mailto:owner-sv-ec@server.
> eda.org] On
> >
> > > Behalf Of Francoise Martinolle
> >
> > > Sent: Tuesday, November 28, 2006 7:15 AM
> >
> > > To: sv-ec@server.eda-stds.org
> >
> > > Subject: RE: [Fwd: Re: [sv-ec] programs discussion and resulting
> >
> > > questions]
> >
> > >
> >
> > >  Cliff,
> >
> > >
> >
> > > I think you may have misunderstood my questions in 3).
> >
> > > By tf I meant systemVerilog task and functions and not 
> PLI user defined
> >
> > > task and functions.
> >
> > >
> >
> > > Francoise
> >
> > >     '
> >
> > >
> >
> > > -------- Original Message --------
> >
> > > Subject: Re: [sv-ec] programs discussion and resulting questions
> >
> > > Date: Mon, 27 Nov 2006 12:53:24 -0800
> >
> > > From: Clifford E. Cummings <cliffc@sunburst-design.com>
> >
> > > To: sv-ec@eda.org
> >
> > > References:
> >
> > > 
> <E159629609B33A43989E19A33C5290F4015965DE@MAILNA1.global.cadence.com>
> >
> > >
> >
> > > Hi, Francoise -
> >
> > >
> >
> > > Thanks for getting back to us with the Cadence-questions 
> so quickly.
> >
> > >
> >
> > > Cliff's take on most of the questions shown below. 
> Awaiting confirmation
> >
> > > from Arturo, Doug, Gord and Dave Rich.
> >
> > >
> >
> > > Attached is a colorized version if you don't see the 
> colors in your
> >
> > > email.
> >
> > >
> >
> > > We had a discussion internally at Cadence about the 
> proposed changes to
> >
> > > program blocks. That discussion generated a few questions 
> which are
> >
> > > listed below and which we would like to see answers:
> >
> > >
> >
> > > With the new proposed scheme where tasks and functions 
> called from the
> >
> > > program block get reactive scheduling semantics whereas 
> if they are
> >
> > > called from a design process, they get regular scheduling 
> semantics:
> >
> > >
> >
> > > BTW - I believe the above statement answers most of your 
> questions, and
> >
> > > answers them more cleanly than what we were dealing with 
> before this
> >
> > > proposal was made.
> >
> > >
> >
> > > 1. NBAs:
> >
> > >
> >
> > > 1.1 Are NBAs to design variables inside a task being called by the
> >
> > > program be scheduled in the Reactive NBA region or the 
> design NBA region
> >
> > >
> >
> > > Reactive-region NBA (the key: called by a program)
> >
> > >
> >
> > > 1.2 What is the behaviour of a NBA to a
> >
> > > concatenation of a module variable and program variable 
> on the target of
> >
> > > the NBA?
> >
> > >
> >
> > > {mv, pv} <= 2'b00;
> >
> > >
> >
> > > If called from a module scope, assignment scheduled in 
> the NBA region.
> >
> > > If called from a program scope, assignment scheduled in 
> the reactive-NBA
> >
> > > region.
> >
> > > (This would have been messy and ambiguous using old semantics)
> >
> > >
> >
> > > 2. Called from a foreign language:
> >
> > >
> >
> > > What are the scheduling semantics for a SV task called 
> from another
> >
> > > language (VHDL, systemC, C, DPI)?
> >
> > >
> >
> > > This one is a bit tricky, but I don't think it is very tricky.
> >
> > > DPI-C function called from a module scope - Active region 
> (?? - I don't
> >
> > > know if this was well defined before??) DPI-C function 
> called from a
> >
> > > program scope - Reactive region Even if the C-function in 
> turn calls a
> >
> > > task or function from either a module or program scope.
> >
> > >
> >
> > > IEEE Std 1800-2005 does not define scheduling for VHDL or 
> SystemC. These
> >
> > > must be considered with respect to the next-gen 1800-PAR.
> >
> > >
> >
> > > 3. Program constructs restrictions
> >
> > >
> >
> > > 3.1 Since the proposal is that design tasks called from 
> the testbench
> >
> > > get reactive scheduling, are such tasks going to be 
> limited to language
> >
> > > constructs allowed in programs? For example blocking 
> assignments are not
> >
> > > allowed in programs, are we going to have to dynamically check for
> >
> > > blocking assignments if the task is called from a program 
> based process?
> >
> > >
> >
> > > Calling a module-scope task from a program-scope would 
> require the task
> >
> > > content to be legal when called from a program-scope. I 
> can't think of
> >
> > > any problems related to this at this time (although there 
> may be such
> >
> > > problems??). You can make blocking assignments from a 
> program but you
> >
> > > cannot make a blocking assignment using the clocking 
> block prefix, but
> >
> > > this is true in both the module-scope and program-scope, 
> so I don't see
> >
> > > a problem yet. Am I missing something?
> >
> > >
> >
> > > 3.2 Are task functions local variables considered to be program or
> >
> > > design variables? Do blocking assignment program 
> restrictions apply to
> >
> > > tf local variables?
> >
> > >
> >
> > > I semi-defer to PLI experts here. But again, one can make blocking
> >
> > > assignments from a program scope (just not clocking-blocking
> >
> > > assignments).
> >
> > > This may not be a problem?? Is this covered by the PLI regions??
> >
> > >
> >
> > > 3.3 A task or function can access a static variable 
> defined outside the
> >
> > > task or function, are blocking assignment to out of tf 
> static variables
> >
> > > allowed when the tf is called from the program?
> >
> > >
> >
> > > Sounds like another PLI-expert question(??)
> >
> > >
> >
> > > 4. Spawned processes
> >
> > >
> >
> > > What are the scheduling semantics of fork join processes 
> of a design
> >
> > > task or function when the task/function is called from a program?
> >
> > >
> >
> > > Again, the answer becomes much more simple with the new 
> paradigm. If
> >
> > > called from a program-scope, we are in the Reactive regions for
> >
> > > scheduling.
> >
> > >
> >
> > > 5. Class variables
> >
> > >
> >
> > > 5.1 Are class variables considered design or program variables?
> >
> > >
> >
> > > I believe the restrictions related to design or program 
> variables all go
> >
> > > away with the proposed enhancements. Life and the LRM get 
> much simpler.
> >
> > >
> >
> > > If assigned in a program, we are in the program scope and 
> we do not
> >
> > > consider where the variable was declared. Same is true for the
> >
> > > module-scope.
> >
> > >
> >
> > > 5.2 Are class properties considered design or program 
> variables? If we
> >
> > > were going to allow NBAs to class properties, where would 
> these NBAs be
> >
> > > scheduled? (There has been some user request to remove the current
> >
> > > limitation of no NBAs to class properties so we need to 
> have an answer
> >
> > > for the future).
> >
> > >
> >
> > > Similar answer. If called from a program-scope, we are in 
> the Reactive
> >
> > > regions ("the little
> >
> > > loop") and if called from a module-scope, we are in "the big loop"
> >
> > > regions. This will answer the question if nonblocking 
> assignments are
> >
> > > added to classes.
> >
> > >
> >
> > > 6. Continuous assignments
> >
> > >
> >
> > > Is it legal to have continuous assignments to wires in a program?
> >
> > >
> >
> > > *       Yes. Program continuous assignments to wires are legal.
> >
> > > *       No cb.port continuous assignments are permitted.
> >
> > > *       Cb.port assignments require clocking
> >
> > > drives (looks like an nonblocking assignment(<=) but it 
> is a clocking
> >
> > > drive and we cannot use <= with continuous assignments).
> >
> > >
> >
> > > 7. Program inout ports
> >
> > >
> >
> > > 7.1 Can a program have inout ports (wires)? There is an 
> example in the
> >
> > > LRM of a program with an inout wire port.
> >
> > >
> >
> > > *       For inout ports, the port must be a wire
> >
> > > (not a logic) and then driven by a cb.port clocking drive from an
> >
> > > initial block.
> >
> > > *       Continuous assignments and cb.port
> >
> > > clocking drives to the same wire are legal and have 
> normal resolution
> >
> > > semantics (multiple drivers).
> >
> > >
> >
> > > 7.2 How does the program drive the wire?
> >
> > >
> >
> > > I had this same question before the
> >
> > > clocking-program-scheduling summit a couple of weeks ago.
> >
> > >
> >
> > > *       A program can drive an inout port with a 
> continuous assignment.
> >
> > > *       A clocking block can drive an inout port
> >
> > > using a clocking drive from an initial block (the inout 
> port, of course,
> >
> > > has to be a net type).
> >
> > > *       It is legal for one or more continuous
> >
> > > assignments and one or more cb.port clocking drives to 
> drive the same
> >
> > > wire and they will have normal resolution semantics 
> (multiple drivers).
> >
> > >
> >
> > > Regards - Cliff
> >
> > >
> >
> > > ----------------------------------------------------
> >
> > > Cliff Cummings - Sunburst Design, Inc.
> >
> > > 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
> >
> > > Phone: 503-641-8446 / FAX: 503-641-8486
> >
> > > cliffc@sunburst-design.com / www.sunburst-design.com 
> Expert Verilog,
> >
> > > SystemVerilog, Synthesis and Verification Training
> >
> > >
> >
> > >
> >
> > > --
> >
> > > 
> ---------------------------------------------------------------------
> >
> > > Neil Korpusik                                     Tel: 
> 408-720-4852
> >
> > > Senior Staff Engineer                             Fax: 
> 408-720-4850
> >
> > > Frontend Technologies - ASICs & Processors (FTAP) Sun Microsystems
> >
> > > email: neil.korpusik@sun.com
> >
> > > 
> ---------------------------------------------------------------------
> >
> > >
> 
> ----------------------------------------------------
> Cliff Cummings - Sunburst Design, Inc.
> 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
> Phone: 503-641-8446 / FAX: 503-641-8486
> cliffc@sunburst-design.com / www.sunburst-design.com
> Expert Verilog, SystemVerilog, Synthesis and Verification Training
> 
>