RE: [sv-ec] event control on class member of event type

Daniel,

I believe that the array examples add value because arrays whose index changes should be treated consistently with handles whose handle changes. The reason for this is that at conceptual (low) level, an array select is a fixed address (the array base) plus some indexing value to get to the element of interest:
address(item) = address(array) + index
And, a class member select is similar: the address of the object plus the (fixed) offset of the member:
            address(member) = address(object) + offset(member)
The only difference between the two is that in the former, the address (array base) is fixed and index is variable, while in the latter the address is variable and the offset is fixed. But I find it useful to derive consistent semantics this way.

Base on what I wrote, the right answer is (b) - the expression is reevaluated, which in the case of a handle involves changes to the handle and in the case of an array it involves changes to the index.

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:

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.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.