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