[sv-ec] RE: Behavior of named events through a dynamic reference such as a class handle or virtual interface

Dave,

I think that without a more formal specification we won't be able to resolve these types of issues. Consider the following example:

event q[$];
class EC;
   event e;
endclass

always@ q[1] $display( "q[2]" );

initial begin
   EC eo = new;
   q.push_front( eo.e );
   eo = new;
   q.push_front( eo.e );
   -> eo.e;
   q.delete(1);
   q.push_front( eo.c ); // same object
   -> eo.e;
   q.delete(1);
   eo = new;
   q.push_front( eo.c ); // new object
   -> eo.e;
end

The issue is that classes provide for the dynamic creation of new event objects and for the new objects to be aliased to existing bindings. One might argue that the name binding constitutes a "merging" or not.

Arturo

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Rich, Dave
Sent: Wednesday, October 06, 2010 3:36 PM
To: sv-ec@eda.org
Subject: [sv-ec] Behavior of named events through a dynamic reference such as a class handle or virtual interface

Section 15.5.5.1 Merging events describes assigning one named event to another without using the term "handle". It also says "If a process is blocked waiting for event1 when another event is assigned to event1, the currently waiting process shall never unblock."

This is in contrast to 9.4.2 Event control expressions which says "An implicit event shall be detected on any change in the value of the expression" and "Changing the value of object data members, aggregate elements, or the size of a dynamically sized array referenced by a method or function shall cause the event expression to be reevaluated" Meaning that only a change in the value of the resulting expression can cause an event trigger.

But what happens when a class handle changes that while a waiting process is blocked. Consider the following example (also attached)

1. class container;

2. event e1,e2;

3. bit b3;

4. function void triggers;

5. $display("Triggering at %t",$time);

6. ->e1;

7. ->e2;

8. ++b3;

9. endfunction

10. endclass : container

11. module top;

12. container c=new();

13. always @c.e1 $display("e1 trigered at %t",$time);

14. always @c.e2 $display("e2 trigered at %t",$time);

15. always @c.b3 $display("b3=%b trigered at %t",c.b3,$time);

16. initial begin

17. container saved;

18. #10 c.triggers;

19. #10 $display("w = new;");

20. saved = c; c = new(); // c.b3 initializes back to 0 - event generated

21. #10 c.triggers;

22. $display("c = saved;");

23. c = saved; // c.b3 is already 0 - no event generated

24. #10 c.triggers;

25. #10 $display("c.e1 = c.e2");

26. c.e1 = c.e2;

27. #10 c.triggers;

28. end

29. endmodule : top

Note that on line 20, when a new instance of container is created, there are no assignment to the named events e1 and e2, so the concept of "merging" cannot apply. Should it? I my opinion, user would expect all three always block to fire every time the triggers() method is called.

Dave Rich
Verification Technologist
Mentor Graphics Corporation
New Office Number: 510-354-7439
[cid:image001.png@01CB66F3.736C3AF0]<http://www.twitter.com/dave_59> [cid:image002.png@01CB66F3.736C3AF0] <http://go.mentor.com/drich>

--
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.