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

Hi Ed,

Sorry for misreading your basic statement, you're saying 2 values of the
same var in an or, agreed. Indeed the $display(v) would process this
like any other expression in the thread continuation. So yes for that
var $display of it at the 2 observation points (last point) inside/out
would be same. I got too wrapped up in the principle of
visibility/generality across and/or flows (I have no idea now why ...)
and was not mindful it's being evaluated twice, thx for correcting me. 

Doron, if that's the intent then that's also clear ... somehow your
example of a commuted $display set me on this "keep $display outside"
issue -- for some reason I thought you wanted to add a special case or
something.

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 1:53 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.

Bassam,

Then I do not follow your flow - variables of the same name flow out of
OR, different names flow out of and / intersect. For example, in the
following property, if both a and b are true, both values assigned to x
will be tested in x == e3 (and must match for the property to succeed.
 (
   ((a, x = e1)##1(1'b1))
   or
   ((b, x = e2)##1(1'b1))
 ) 
   |-> (x == e3) 

similarly,

 (
   ((a, x = e1)##1(1'b1))
   or
   ((b, x = e2)##1(1'b1))
 ) 
   |-> (1'b1, task_call(x)) 

will execute twice, once with value e1 and 2nd time with value e2. 

ed




> -----Original Message-----
> From: Bassam Tabbara [mailto:Bassam@novas.com]
> Sent: Tuesday, November 01, 2005 4:34 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, I have no idea how/where you read in my email that there's a 
> difference. Anyway, if you are saying:
> 
> > Any boolean after the join that refers to the local variable x will
> see both values (i.e., if both branches match).
> 
> Then we disagree on the basics -- above goes against the local var 
> flow for or.
> 
> Note that my argument is general it applies to any kind of join -- 
> i.e.
> in case of end same questions can be raised about which value (e.g. 
> the absolute latest or you see older ones too ...) is observable.
> 
> ** Summary of my take: As long as there is a flow rule then it 
> applies, can't go against the flow :).
> 
> 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 1:10 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.
> 
> 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
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> 
>