Yes, I believe the modified version will trigger the always block. And, I believe that was Dave's opinion as well. Arturo -----Original Message----- From: Gordon Vreugdenhil [mailto:gordonv@model.com] Sent: Thursday, September 03, 2009 10:58 AM To: Arturo Salz Cc: Daniel Mlynek; 'Rich, Dave'; sv-ec@eda.org; 'Marek Nadrowski' Subject: Re: [sv-ec] event control on class member of event type I certainly don't like the "may be". In your opinion, will the modified version trigger the always or not? The comment leads me to believe that your answer is that it must satisfy the wait condition. I'm going to follow-up on this topic more generally later today. Gord. Arturo Salz wrote: > I didn't write that "it was triggered" - I wrote "may be triggered". Yes, I agree that the particular sequence would not satisfy the triggered method; that was a typo. I meant to leave out the second #1, that is, the initial block looks like: > > initial begin > #1 ->c2.e; > c1 = c2; //here c1 changes -- and wakes up always block > end > > Arturo > > -----Original Message----- > From: Gordon Vreugdenhil [mailto:gordonv@model.com] > Sent: Thursday, September 03, 2009 7:01 AM > To: Arturo Salz > Cc: Daniel Mlynek; 'Rich, Dave'; sv-ec@eda.org; 'Marek Nadrowski' > Subject: Re: [sv-ec] event control on class member of event type > > Ar > > Arturo Salz wrote: >> Daniel, >> > [...] >> I believe that we all agree that the is no event triggered when changing >> the handle (or index), but it might be triggered if waiting on the >> triggered condition: > > ??? > > If you are waiting on "triggered" of an event, why do you think > that the triggered method is satisfied in any way in your example? > "triggered" is true for an event from the event "edge" through > the time step. At time 1 you trigger c2.e but at time **2** > you are changing c1. At time 1 clearly nothing should cause > c1.e.triggered to be true. At time 2, neither c1.e.triggered > nor c2.e.triggered should be true, so how could this possibly get > past the "wait"? > > I don't believe it can, independent of whether you re-evaluate > that path "c1.e" when c1 changes. > > Gord. > >> >> >> class C; >> >> event e; >> >> endclass >> >> module top; >> >> C c1=new, c2=new; >> >> always wait( c1.e.triggered() ) $display("event triggered"); >> >> initial begin >> >> #1 ->c2.e; >> >> #1 c1 = c2; //here c1 changes -- and wakes up always block >> >> end >> >> endmodule >> >> >> >> Arturo >> >> >> >> *From:* Daniel Mlynek [mailto:daniel.mlynek@aldec.com] >> *Sent:* Thursday, September 03, 2009 12:27 AM >> *To:* 'Arturo Salz'; 'Rich, Dave'; sv-ec@eda.org; 'Gordon Vreugdenhil' >> *Cc:* 'Marek Nadrowski' >> *Subject:* RE: [sv-ec] event control on class member of event type >> >> >> >> Array examples doesn't show anything new. >> >> The question is still how @c.e should work. Please see Gordons earlier >> respone attached to the email. >> >> >> >> IMHO >> >> 1. @c.e should not be triggered when c changes (event has no value so >> c.e doesn't change the value when c changes). This interpretation is >> same as when event gets mergerd - then there is no event trigger either >> like in: >> >> module top; >> >> event e1,e2; >> >> always @(e1) $display("event);//the situation here is similar to >> changing handle in expression @c.e1 - because in both expression >> under @ starts to show other event >> >> initial #1 e1=e2; >> >> endmodule >> >> 2. The questionable issue is that if @c.e should be reevaluated when c >> changes: >> >> a) solution a is it should stick to the event pointed by c at the >> moment when code @c.e is executed, >> >> b) solution b is it is reevealuated when c changes. Event if so then >> there should be no event triggered at c change (see point 1), but c.e1 >> should be sensitive to triggers from event from new object pointed by c. >> The only way to trigger @c.e should be to trigger event pointed event by >> ->, or ->> >> >> >> >> >> >> >> >> Maybe using event as class member should be shortly described in LRM. >> >> >> >> >> >> DANiel >> >> >> >> ------------------------------------------------------------------------ >> >> *From:* Arturo Salz [mailto:Arturo.Salz@synopsys.com] >> *Sent:* 3 września 2009 08:52 >> *To:* Daniel Mlynek; 'Rich, Dave'; sv-ec@eda.org >> *Cc:* 'Marek Nadrowski' >> *Subject:* RE: [sv-ec] event control on class member of event type >> >> Daniel, >> >> >> >> I believe that Dave is correct. While an event has no value, it does >> have a persistent triggered state. Why do you believe classes should >> behave differently from arrays, by that I mean modifying your previous >> example a bit: >> >> >> >> class C; >> >> event e; >> >> endclass >> >> module top; >> >> C c[1:2]; >> >> int j = 1; >> >> c[1] = new; >> >> c[2] = new; >> >> always @c[j].e $display("event triggered"); //what happens when c1 >> will change? >> >> initial begin >> >> #1 j = 2; //here c[j] changes -- but the event (c[j].e) is not >> triggered >> >> #1 ->c[j].e; // here the event is triggered >> >> end >> >> endmodule >> >> >> >> Likewise for Dave's example, it is often useful to cast the problem in >> terms of arrays: >> >> >> >> class C; >> >> bit e; >> >> endclass >> >> module top; >> >> C c[1:2]; >> >> int j = 1; >> >> c[1] = new; >> >> c[2] = new; >> >> always @c[j].e $display("event triggered"); //what happens when c1 >> will change? >> >> initial begin >> >> #1 j = 2; //here c[j] changes -- but not c[1].e (the blocking >> expression) >> >> #1 c[2].e++; // here it does change >> >> end >> >> endmodule >> >> >> >> While the LRM can certainly be improved, I'm unsure as to what you'd >> like it to say. >> >> >> >> Arturo >> >> >> >> *From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On Behalf Of >> *Daniel Mlynek >> *Sent:* Wednesday, September 02, 2009 10:46 PM >> *To:* 'Rich, Dave'; sv-ec@eda.org >> *Cc:* 'Marek Nadrowski' >> *Subject:* RE: [sv-ec] event control on class member of event type >> >> >> >> Well - 2 experts - 2 different asnwers - that surely means that >> description in LRM could be improved. >> >> Dave you've ignored the fact that event has no value. >> >> What about simpler case: >> >> module top; >> >> event e1,e2; >> >> always @(e1) $display("event); >> >> initial #1 e1=e2; >> >> endmodule >> >> If we will assume that even is kind of handle - then assigning other >> handle to e1 should trigger @ (value have changed). While LRM defines >> that this should not happen. @ cannot be triggered at all in this case >> as it was overriden by e2. >> >> Similarly for classes. in example which you gave there will be event >> executed only if value of bit "e" changes at the moment when c1 is >> assigned c2 (so both object has to have different value of b) - in case >> of event there is no value - why handle change should trigger an event? >> >> >> >> >> >> DANiel >> >> >> >> ------------------------------------------------------------------------ >> >> *From:* Rich, Dave [mailto:Dave_Rich@mentor.com] >> *Sent:* 3 września 2009 01:41 >> *To:* Daniel Mlynek; sv-ec@server.eda.org >> *Cc:* Marek Nadrowski >> *Subject:* RE: [sv-ec] event control on class member of event type >> >> I think the problem is with the definition of the SV enhanced event, >> which I believe that feature is no longer needed as long as a class is >> allowed to contain an event as its member. Section 15.5.5.1awkwardly >> uses the termed "merged" rather than "handle" to talk about named >> events. "When events are merged, the assignment only affects the >> execution of subsequent event control or wait operations." >> >> >> >> What if you had >> >> >> >> class C; >> >> bit e; >> >> endclass >> >> module top; >> >> C c1=new, c2=new; >> >> always @c1.e $display("event triggered"); //what happens when c1 will >> change? >> >> initial begin >> >> #1 c1=c2; //here c1 changes - what about c1.e ??? >> >> #1 c1.e++; >> >> end >> >> endmodule >> >> >> >> This code should not behave any differently than what you wrote below.. >> The LRM 9.4.2 clearly defines that changing an object handle will cause >> a re-evaluation of an event expression. Your example does not merge any >> events; it has "merged" two class variables to point to the same object. >> So ->c1.e and c2.e both point to the same member of the same object. >> >> >> >> Dave >> >> ------------------------------------------------------------------------ >> >> *From:* owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] >> *On Behalf Of *Daniel Mlynek >> *Sent:* Tuesday, August 25, 2009 1:36 AM >> *To:* sv-ec@server.eda.org >> *Cc:* 'Marek Nadrowski' >> *Subject:* [sv-ec] event control on class member of event type >> >> >> >> I cannot find description of such case in LRM. Event has no value in >> contrast to other types - so this case is quite different than event >> control on class member on not event type. >> >> IMHO this should be explicitly defined by the LRM. >> >> >> >> class C; >> >> event e; >> >> endclass >> >> module top; >> >> C c1=new, c2=new; >> >> always @c1.e $display("event triggered"); //what happens when c1 will >> change? >> >> initial begin >> >> #1 c1=c2; //here c1 changes - what about c1.e ??? >> >> #1 ->c1.e; >> >> end >> >> endmodule >> >> >> >> >> >> DANiel >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is >> believed to be clean. >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is >> believed to be clean. >> > > -- > -------------------------------------------------------------------- > Gordon Vreugdenhil 503-685-0808 > Model Technology (Mentor Graphics) gordonv@model.com > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Sep 3 14:08:42 2009
This archive was generated by hypermail 2.1.8 : Thu Sep 03 2009 - 14:09:33 PDT