In reply to ben@SystemVerilog.us:
Ben,
The triggered() method returns 0 when called in a time slot before the trigger ( → or ->>). The key is knowing what situation causes the method to get called when used in an event control.
In my example, triggered() gets called at time 0 upon encountering the event control
@(event_control.triggered()) which returns 0 and suspends the always process. Then at time 10, event_name triggers which causes the second evaluation of the
event_control.triggered() method. It returns 1 which causes the always process to resume and prints the $display statement. And since there are no other delays in the always block, it starts from the top and encounters the
@(event_control.triggered()) for the third time, which still returns 1. Finally the event_name triggers again and the triggered method gets called for the fourth time returning 1, which is the same value the expression had the last time it got evaluated.
So other than time 0, there is no event that causes evaluation of the triggered method to return 0. That would change if I put a unit delay in the always block
always @(event_name.triggered) #1 $display($time,,"@(event_name.triggered)");
Now the event control gets encountered at times 0,11, and 21. The triggered() method would return 0 each time. [br]
The crux of of this discussion hopefully leads you way from using events unless you are one of thetwo dozen people who really understand them. And that the triggered method no longer has any use since the non-blocking trigger construct ->> was added to SystemVerilog to prevent races between → and @event_name.