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

Francoise,

I'll take a stab at answering these remaining questions.
Please see below.

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Francoise Martinolle
> Sent: Thursday, November 30, 2006 6:40 PM
> To: Rich, Dave; sv-ec@server.eda-stds.org
> Subject: 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? 

No #0 should be required.
Perhaps some simulator implementations would naturally produce
such a delay?

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

Yes, the @(w) will be scheduled in the design's active region.
After the whole program's reactive cycle is finished, the design's
active region will become the active queue, and the process will
wake up.

>  
> 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
No #0 - There is immediate visibility, since the wire should
be fully collapsed.

>      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

Should be:
... and wake up the design region 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?
Yes.

> 
> 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).
Yes.

Regards,
Doug
<eom>

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