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