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