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

From: Daniel Mlynek <daniel.mlynek_at_.....>
Date: Wed Sep 02 2009 - 22:45:45 PDT
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 MailScanner, and is
believed to be clean.
Received on Wed Sep 2 22:47:24 2009

This archive was generated by hypermail 2.1.8 : Wed Sep 02 2009 - 22:48:19 PDT