Events are static objects useful for synchronization between the process. Events operations are of two staged processes in which one process will trigger the event, and the other processes will wait for an event to be triggered.
- Events are triggered using -> operator or ->> operator
- wait for an event to be triggered using @ operator or wait() construct
SystemVerilog events act as handles to synchronization queues. thus, they can be passed as arguments to tasks, and they can be assigned to one another or compared.
Named events are triggered via the -> operator. Triggering an event unblocks all processes currently waiting on that event.
Non-blocking events are triggered using the ->> operator.
Waiting for event trigger
wait for an event to be triggered is via the event control operator, @.
- The @ operator blocks the calling process until the given event is triggered.
- For a trigger to unblock a process waiting on an event, the waiting process must execute the @ statement before the triggering process executes the trigger operator, ->
Note: If the trigger executes first, then the waiting process remains blocked.
If the event triggering and waiting for event trigger with @ operator happens at the same time, @ operator may miss detecting the event trigger.
Whereas wait(); construct will detect the event triggering.
The wait_order construct is blocking the process until all of the specified events are triggered in the given order (left to right). event trigger with out of order will not unblock the process.
Blocks the process until events a, b, and c trigger in the order a –> b –> c. If the events trigger out of order, a run-time error is generated.
wait_order( a, b, c ) else $display( "Error: events out of order" );
In this example, the fail statement specifies that upon failure of the construct, a user message is displayed, but without an error being generated.
bit success; wait_order( a, b, c ) success = 1; else success = 0;
In this example, the completion status is stored in the variable success, without an error being generated.
When one event variable is assigned to another, the two become merged. Thus, executing -> on either event variable affects processes waiting on either event variable.
the event waiting with @ operator
The below example shows the event triggering and waiting for the event trigger.
module events_ex; event ev_1; //declaring event ev_1 initial begin fork //process-1, triggers the event begin #40; $display($time,"\tTriggering The Event"); ->ev_1; end //process-2, wait for the event to trigger begin $display($time,"\tWaiting for the Event to trigger"); @(ev_1.triggered); $display($time,"\tEvent triggered"); end join end endmodule
0 Waiting for the Event to trigger 40 Triggering The Event 40 Event triggered
trigger first and then waiting for a trigger
In the below example,
event triggering happens first and then the waiting for trigger happens. As the waiting happens later, it will be blocking, so the statements after the wait for the trigger will not be executed.
event ev_1; //declaring event ev_1 initial begin fork //process-1, triggers the event begin #40; $display($time,"\tTriggering The Event"); ->ev_1; end //process-2, wait for the event to trigger begin $display($time,"\tWaiting for the Event to trigger"); #60; @(ev_1.triggered); $display($time,"\tEvent triggered"); end join end initial begin #100; $display($time,"\tEnding the Simulation"); $finish; end endmodule
0 Waiting for the Event to trigger 40 Triggering The Event 100 Ending the Simulation
event examples are continued in the next page