Yes, for the OR, there is a separate copy of the variable in each such thread (or subthread. ed > -----Original Message----- > From: vhdlcohen@aol.com [mailto:vhdlcohen@aol.com] > Sent: Tuesday, November 01, 2005 5:14 PM > To: Eduard.Cerny@synopsys.COM; Bassam@novas.com; dbustan@freescale.com > Cc: doron.bustan@freescale.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 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Received on Tue Nov 1 14:23:07 2005
This archive was generated by hypermail 2.1.8 : Tue Nov 01 2005 - 14:23:26 PST