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
<http://www.twitter.com/dave_59> <http://go.mentor.com/drich>
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Received on Wed Oct 6 15:36:26 2010
This archive was generated by hypermail 2.1.8 : Wed Oct 06 2010 - 15:36:37 PDT