Difference between @event and wait(event.triggered) in SystemVerilog and usage of non-blocking event

The event data type provides a handle to a synchronization object.

There are two ways through which we can wait for particular event to be triggered.
So let's understand what is the exact difference between those 2 ways.

-----------------------------------------------

	event e;
	// Triggered event 'e'
	->e;
	// wait for event 'e' to be triggered (instantaneous)
	@(e);
	// wait for event 'e' to be triggered (Persistent)
	wait(e.triggered);

view raw sv_event_1.sv hosted with ❤ by GitHub

-----------------------------------------------

An event trigger ->e is an instantaneous event. The event waiting process @ shall execute before the triggering process -> executes. If the trigger executes first, then the waiting process remains blocked.

The triggered event property evaluates to true (1'b1) if the given event has been triggered in the current time step and false (1'b0) otherwise.
Now you no longer have to worry which came first, the triggering process –> or the waiting process @ statement. But you still have to execute the waiting process @ in the current time slot to catch the event.

Let’s see the behavior with examples,
-----------------------------------------------

	class event_class;
	event ev;
	task trig;
	->ev;
	endtask : trig
	task execute1;
	@(ev);
	$display("Testing of the event @");
	endtask : execute1
	// First trigger event and after that
	// wait for event to be triggered in same simulation time
	task ex1;
	trig;
	execute1;
	endtask : ex1
	endclass : event_class
	module top();
	event_class E;
	initial begin
	E = new();
	fork
	begin
	E.ex1; // wait using @
	end
	begin
	#10;
	$display("Missed trigger of event");
	end
	join_any
	disable fork;
	end
	endmodule : top
	// Output:
	// Missed trigger of event

view raw sv_event_2.sv hosted with ❤ by GitHub

-----------------------------------------------

-----------------------------------------------

	class event_class;
	event ev;
	task trig;
	->ev;
	endtask : trig
	task execute2;
	wait(ev.triggered);
	$display("Testing of the event wait(.triggered)");
	endtask : execute2
	// First trigger event and after that
	// wait for event to be triggered in same simulation time
	task ex2;
	trig;
	execute2;
	endtask : ex2
	endclass : event_class
	module top();
	event_class E;
	initial begin
	E = new();
	fork
	begin
	E.ex2; // wait using wait(event.triggered)
	end
	begin
	#10;
	$display("Missed trigger of event");
	end
	join_any
	disable fork;
	end
	endmodule : top
	// Output:
	// Testing of the event wait(.triggered)

view raw sv_event_3.sv hosted with ❤ by GitHub

-----------------------------------------------

The other workaround is to use nonblocking event

Non-blocking event ->>
Nonblocking events are triggered using the ->> operator.

The effect of the ->> operator is that the statement executes without blocking, and it creates a nonblocking assign update event in the time in which the delay control expires or the event control occurs. The effect of this update event shall be to trigger the referenced event in the nonblocking assignment region of the simulation cycle.

-----------------------------------------------

	module top();
	event blocking_ev;
	event non_blocking_ev;
	process process_b;
	process process_nb;
	initial begin
	fork
	begin
	process_b = process::self();
	-> blocking_ev;
	@ blocking_ev;
	end
	begin
	process_nb = process::self();
	->> non_blocking_ev;
	@ non_blocking_ev;
	end
	join_none
	#10;
	$display("process_b.status:%s", process_b.status);
	$display("process_nb.status:%s", process_nb.status);
	end
	endmodule : top
	// Output:
	// process_b.status:WAITING
	// process_nb.status:FINISHED

view raw non_blocking_event.sv hosted with ❤ by GitHub

-----------------------------------------------