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

From: Rich, Dave <Dave_Rich_at_.....>
Date: Wed Sep 02 2009 - 16:41:22 PDT
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, and is
believed to be clean.
Received on Wed Sep 2 16:43:36 2009

This archive was generated by hypermail 2.1.8 : Wed Sep 02 2009 - 16:44:26 PDT