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