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