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

 
Thanks Dave for the summary on the new program block semantics.

However I am still looking for a clarification to my earlier question:
  what happen when there is a continuous assignment in a program to wire

  which is in the design.

1. Does the wire effective value (resolution of the drivers) happens
immediately and
is immediately visible a #0 later in the program block? 
2. When is any fanout of the wire triggered?
if there is a @(w) in the DUT, does the process wakes up once the whole
reactive cycle is finished?
 
Is the sequence of actions:
     1. the simulator executes the continous assignment  and updates the
driver of the wire in the program,
     2. resolution of the wire effective value 
     3. #0 new wire value is now visible in the program
     4. continue executing the little loop in the reactive region until
done 
     5. execute the big design cycle and wake up the fanout of the wire
 
 

Also what is the behaviour of an SV task called from DPI or from a
foreign process? Does it inherit the program
or design semantics depending on the parent thread?

Finally I would like to confirm that if the program assigns a design
variable, that happens immediately in the reactive loop 
but any process sensitive to the variable wakes up in the loop
corresponding to the process parent scope
(either design or program).
 
Francoise
    '

________________________________

	From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
	Sent: Wednesday, November 29, 2006 7:32 PM
	To: Francoise Martinolle; sv-ec@eda-stds.org
	Subject: RE: [Fwd: Re: [sv-ec] programs discussion and resulting
questions]
	
	

	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