RE: [sv-ac] Semantics of "calling subroutines on match of a seque nce" is not well defined.

Sorry Bassam, but I do not see a difference between $dsiplay or any
other task, or a boolean expression for that matter. Any boolean after
the join that refers to the local variable x will see both values (i.e.,
if both branches match). So what is so different regarding the task or
$display? In fact, we used this to pass local variable values from all
threads to a covergroup for sampling, by calling a task that stores the
value in a global variable and immediately calls cg_inst.sample() where
cg_inst is an instance of a covergroup. 

ed

> -----Original Message-----
> From: Bassam Tabbara [mailto:Bassam@novas.com] 
> Sent: Tuesday, November 01, 2005 4:05 PM
> To: Eduard Cerny; Doron Bustan
> Cc: Bustan Doron-DBUSTAN; vhdlcohen@aol.com; sv-ac@eda.org
> Subject: RE: [sv-ac] Semantics of "calling subroutines on 
> match of a seque nce" is not well defined.
> 
> Ed,
> 
> We seem to agree on the crux of the matter but not the final 
> conclusion.
> I also say that $display should indeed see what any other 
> expression in
> its place sees ... and no amount of padding/changing code will affect
> this general argument. 
> 
> Fact is the 2 observation points are different -- one "inside", one
> after the join. I think that $display(var) should not get any special
> treatment ... for example swap $display(var) with any other $task(var)
> that the testbench is reactive to and you will see how misleading this
> would be: Assuming there were no side-effects in $task(var) 
> so we focus
> on lvar issue at hand, merely commuting the $task(var) is 
> different than
> leaving it outside i.e. should not be allowed. 
> 
> Thx.
> -Bassam.
> 
> --
> Dr. Bassam Tabbara
> Architect, R&D
> Novas Software Inc.
> (408) 467-7893
> 
> -----Original Message-----
> From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] 
> Sent: Tuesday, November 01, 2005 12:29 PM
> To: Bassam Tabbara; Eduard Cerny; Doron Bustan
> Cc: Bustan Doron-DBUSTAN; vhdlcohen@aol.com; sv-ac@eda.org
> Subject: RE: [sv-ac] Semantics of "calling subroutines on match of a
> seque nce" is not well defined.
> 
> Hi Bassam,
> 
> I think that it is important to see what thread continues or not. In
> particular, the $display can see what flows out of an OR (same
> variables) or AND (distinct variables) join, much like any boolean
> expression that uses the local var after the join. 
> 
> so, I think that 
> 
> (
>   ((a, x = e1)##1(1'b1,$display(x)))
>   or
>   ((b, x = e2)##1(1'b1,$display(x)))
> )
> 
> should see the same outcome in terms of output as
> 
> (
>   ((a, x = e1)##1(1'b1))
>   or
>   ((b, x = e2)##1(1'b1))
> ) ##0 (1'b1, $display(x))
> 
> That is each thread if it passes through the join should continue with
> the ##0 Both values of x are visible to the $display, the same way as
> they would be visible to any boolean expression that follows the join.
> 
> Do you agree? 
> 
> ed
> 
> 
> > -----Original Message-----
> > From: Bassam Tabbara [mailto:Bassam@novas.com]
> > Sent: Tuesday, November 01, 2005 3:00 PM
> > To: Eduard Cerny; Doron Bustan
> > Cc: Bustan Doron-DBUSTAN; vhdlcohen@aol.com; sv-ac@eda.org
> > Subject: RE: [sv-ac] Semantics of "calling subroutines on 
> match of a 
> > seque nce" is not well defined.
> > 
> > Hi All,
> > 
> > Ed: I would not want us to get distracted by terms, of 
> course they are
> 
> > separate threads that's not the point, if easier my use of 
> "join" here
> 
> > means a *flow join* i.e. there is a flow point where things 
> are agreed
> 
> > upon -- I say this *particularly* because I am viewing the $display 
> > issue in light of local var flow, that's the key point, and 
> it makes 
> > no difference when it comes to visibility inside whether I 
> am doing a 
> > disjunctive or a conjunctive join.
> > 
> > Doron: I think the $display in the rest of the sequence should not 
> > "see"
> > the inside. You know a simple argument for this can be made 
> if you add
> 
> > distinct vars along the branches, the $display outside 
> should not have
> 
> > access to the individual vars (they get killed at the flow 
> join). If 
> > you agree then that's it, that's the general rule. If you 
> want to see 
> > the values inside, add a $display within.
> > 
> > Again, my take is if we did not have local vars, the question would 
> > not be raised to begin with -- The only difference between 
> commuting 
> > the $display and not, is the internal state and we already 
> have rules 
> > governing which values are visible to the outside, so this 
> is already 
> > specified in LRM.
> > 
> > Thx.
> > -Bassam.
> > 
> > --
> > Dr. Bassam Tabbara
> > Architect, R&D
> > Novas Software Inc.
> > (408) 467-7893
> > 
> > -----Original Message-----
> > From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]
> > Sent: Tuesday, November 01, 2005 11:11 AM
> > To: Doron Bustan; Bassam Tabbara
> > Cc: Bustan Doron-DBUSTAN; vhdlcohen@aol.com; sv-ac@eda.org
> > Subject: RE: [sv-ac] Semantics of "calling subroutines on 
> match of a 
> > seque nce" is not well defined.
> > 
> > Hi,
> > 
> > I agree, the or-ed sequences are not joined - they form separate 
> > threads.
> > This is also why the local variables that flow out of them 
> must have 
> > the same names, since both must continue with the same sequence the 
> > follows the or.
> > Similarly for intervals in ## or [*], they may create 
> separate threads
> 
> > if more than one situation match.
> > 
> > ed
> > 
> > > -----Original Message-----
> > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
> Behalf Of 
> > > Doron Bustan
> > > Sent: Tuesday, November 01, 2005 1:17 PM
> > > To: Bassam Tabbara
> > > Cc: Bustan Doron-DBUSTAN; vhdlcohen@aol.com; sv-ac@eda.org
> > > Subject: Re: [sv-ac] Semantics of "calling subroutines on
> > match of a
> > > seque nce" is not well defined.
> > > 
> > > Bassam, Ben,
> > > 
> > > 
> > > I disagree on the fact that the ## operator functions as 
> a join of 
> > > "ORed" subsequences.
> > > As far as I understand the LRM, when two sub threads are
> > forked at an
> > > "or" operator, they are never joined again.  It is not explicitly 
> > > written in the LRM, but that is how I understand section
> > 17.8 p252 (in
> > 
> > > the D5 version).
> > > 
> > > 
> > > To make my point stronger, consider the following sequence
> > > 
> > >  sequence s3d;
> > >  logic [2:0] v;
> > >  (
> > >  ((a ##1 a), v=1) // A subthread
> > >  or
> > >  ((b ##2 b), v=2) // B subthread
> > >  ) ##1 (c, $display("c, v=%d", v));
> > >  endsequence,
> > > 
> > > if a,b, and c hold at the first 4 cycles, then I will expect two
> > > displays: one after the third cycle
> > > and one after the forth. The reason for that is that sub
> > threads that
> > > are forked by an "or" operator are not joined. similarly I
> > expect two
> > > displays in s3 after the third cycle.
> > > 
> > > Thanks
> > > 
> > > Doron
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> 
>