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

ED,
I neeed some clarification.   Does each subthread maintain its copy of 
the local variables, or is there a single copy of the local variables 
for each thread and subthreads.  From your example, it would seem that 
the tool must maintain a copy of the local variable per subthread, but 
yet, the local variable is declared once.
Now I am confused!
Ben

-----Original Message-----
From: Eduard Cerny <Eduard.Cerny@synopsys.com>
To: Bassam Tabbara <Bassam@novas.com>; Eduard Cerny 
<Eduard.Cerny@synopsys.com>; Doron Bustan <dbustan@freescale.com>
Cc: Bustan Doron-DBUSTAN <doron.bustan@freescale.com>; 
vhdlcohen@aol.com; sv-ac@eda.org
Sent: Tue, 1 Nov 2005 13:53:23 -0800
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
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>