In reply to Farhad:
1800 clarified this, though I never used the event_name.triggered.
15.5.3 Persistent trigger: triggered built-in method
SystemVerilog can distinguish the event trigger itself, which is instantaneous, from the named event’s triggered state, which persists throughout the time step (i.e., until simulation time advances). The triggered built-in method of a named event allows users to examine this state.
The prototype for the triggered() method is as follows:
function bit triggered();
The triggered method evaluates to true (1’b1) if the given event has been triggered in the current time step and false (1’b0) otherwise. If the named event is null, then the triggered method returns false.
The triggered method is most useful when used in the context of a wait construct:
wait ( hierarchical_event_identifier.triggered )
Using this mechanism, an event trigger shall unblock the waiting process whether the wait executes before or at the same simulation time as the trigger operation. The triggered method, thus, helps eliminate a common race condition that occurs when both the trigger and the wait happen at the same time. A process that blocks waiting for an event might or might not unblock, depending on the execution order of the waiting and triggering processes. However, a process that waits on the triggered state always unblocks, regardless of
the order of execution of the wait and trigger operations.
Example:
event done, blast; // declare two new events
event done_too = done; // declare done_too as alias to done
task trigger( event ev ); -> ev; endtask
...
fork
@ done_too; // wait for done through done_too
#1 trigger( done ); // trigger done through task trigger
join
fork
-> blast;
wait ( blast.triggered );
join
The first fork in the example shows how two event identifiers, done and done_too, refer to the same synchronization object and also how an event can be passed to a generic task that triggers the event. In the example, one process waits for the event via done_too, while the actual triggering is done via the trigger task that is passed done as an argument.
In the second fork, one process can trigger the event blast before the other process (if the processes in the fork-join execute in source order) has a chance to execute, and wait for the event. Nonetheless, the second process unblocks and the fork terminates. This is because the process waits for the event’s triggered state, which remains in its triggered state for the duration of the time step.
An event expression or wait condition is only reevaluated on a change to an operand in the expression, such as the event prefix of the triggered method. This means that the change of the return value of the triggered method from 1’b1 to 1’b0 at the end of the current time step will not affect an event control or wait statement waiting on the triggered method.