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  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 


-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 


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

attached mail follows:

I don't have my LRM handy (I'm away this week) so I
can't look up the section reference but there is
an  explicit example that shows that event assignment
does NOT change the underlying sensitivity -- i.e. having:
   @e1;

   e1 = e2;
   -> e1;  // or -> e2
does not cause the event control to trigger since the
waiting process is waiting on a particular synchronization
object.

Although the case that you raise isn't directly addressed,
given the above, I think that one should conclude that
when one waits on the synch object, one remains waiting
there even if the class handle changes.  As you observe,
there is no "value change" related to an event so
different rules apply.  If the class object goes away, the
waiting process won't ever wake up (as with the LRM example
that doesn't use class refs).

Gord.

-----Original Message-----
From: owner-sv-ec@server.eda.org on behalf of Daniel Mlynek
Sent: Tue 8/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, and is
believed to be clean.