Events in System Verilog

19 Sep 2022

4 mins

Events or named events are static objects like what we have seen in Verilog. In System Verilog, basic operation of events remains the same as that of the Verilog, but some enhancements are done in System Verilog. In this article we will learn more about the events in detail.

What are events?

Events are a static object which can be used to synchronize 2 processes running parallelly. The handle of the event can be used to trigger the event. -> or ->> is used to trigger an event whereas @ or wait() to wait for the event to be triggered.

Syntax

event ev;
-> ev;

Enhancement in events

In Verilog, the triggered state of the events does not persist and has no duration. Even triggered state does not persist in the time step in which the event is triggered. In System Verilog, this is not the case. The triggered state persists for the entire time step in which the event is triggered and thus it makes it easy to synchronize the events.

System Verilog also supports passing of events as an argument to tasks. This makes it easy to combine events in different components and synchronize the different components of the test bench.

Triggering an event

An event is triggered using the -> operator. Triggering an event unblocks all the processes that are currently waiting for that event.

Non-blocking triggering of an event

A non-blocking event can be triggered using the ->> operator. The difference between the blocking and non-blocking triggering is that in non-blocking triggering the event is triggered in the non-blocking region of event semantics. Thus, in some scenarios it can be used to prevent race conditions while triggering an event.

Waiting for a trigger

An event will stop the execution of subsequent code until the event has been triggered. @ operator or wait keyword is used to wait for a particular event to be triggered.

When an event is triggered, it is instantaneous in nature. It means that the event trigger will not persist in entire time step. And thus, if event is triggered before the @ operator in a time step, @ operator will not be able to detect trigger.

To solve this issue, SV also provides with a triggered property. This property is part of event class, and the value of this property will persist throughout the time step. This means that if an event is triggered, the triggered property will be 1 for the entire time step unlike event trigger itself.

This property can be accessed using event_name.triggered

Generally, this is used with the wait construct. This can avoid any race condition which might happen otherwise.

Event sequencing

Till now we have seen that we can wait for a single event to get triggered. SV provides a wait_order construct which can be used to provide multiple events. Also, this construct ensures that the code execution is unblocked only if the events are triggered in the order mentioned in the construct (left to right). Thus, for the code execution to unblock the leftmost event should be triggered first and then the subsequent events.

Merging Events

In System Verilog one event can be assigned to another event. By doing this, we merge the 2 events with each other. This means that if we trigger an event the other event will also be triggered automatically.

This property of SV events is very useful in synchronising different components of a test bench.

Example

event a, b;
a = b;
->a; // This will also trigger event b

Events Comparison

System Verilog provides basic comparison with events. These comparisons are helpful to know whether 2 events are same, or null is assigned to an event.

• Equality (==)
• Inequality (!=)

An event can be assigned to a null value. This means that the link between event variable and the synchronization queue is broken. Once a event is assigned null, it cannot be triggered and can led to run-time issues.

Example

event a, b, c;

a = b;
if(a == b)
    $display("Event a and b are same");
if(a != c)
    $display("Event a and c are not same");

a = null;
if(a == null)
    $display("Event a is assigned to null")