Previous: Parameterized Mailboxes | Next: More on SV events

Last time: In Part 1 of this series, we learnt about new extentions in SystemVerilog to deal with dynamic event synchronization. We saw how semaphores can act as a key for a resource and how methods associated with semaphores help you to communicate among various processes looking for the same resource(s). We also learnt about mailbox and methods associated with it. Finally, we saw how to parameterize a mailbox for various message types.

This time, we are going to explore more about events in general, not just how they communicate with each other. We will see the enhancements made by SystemVerilog in this arena and how they can be used in your verification environment. But, first the basic.

Events are defined as a basic type in Verilog since its earliest days. You can define an event, for example, code_1 in Verilog as shown below and then associate a block of code with this named event. You can trigger this block of code using the ->code_1; in another part of your code. Furthermore, you can trigger another block of code code_2 when code_1 triggers by using the @(code_1) construct or native task wait(code_1).

event code_1;
   ...
   begin: code_1
      a = 1'b0; 
      // insert other code for event code_1 here
   end
   ...
   begin 
      ->code_1; // triggers code_1 above
      some_task();
      ...
   end
   ...
   @(code_1); // or wait(code_1);
   ...

SystemVerilog provides all these and then some more. Most notable of these are listed below.

A. The ->> construct

In order to understand the way the ->> construct works, first look at the example of -> one more time. Notice that when code_1 triggers, it blocks the execution of subsequent code (in this case, some_task()) until code_1 finishes execution.

The previous example is reproduced below where ->> places ->. The ->> construct works similar to the -> construct, but it does not block the code in the same sequential thread. In stead, the triggered event (such as, code_1) is scheduled to occur at the end of the simulation slot (where all other non-blocking assignments are done). A direct consequence of this is later code (such as some_task()) will not see an update of a variable (such as a) to occur in code_1.

event code_1;
   ...
   begin: code_1
      a = 1'b0;
      // insert code for event code_1 here
   end
   ...
   begin 
      ->>code_1; // triggers code_1 above
      some_task();
      ...
   end

Previous: Parameterized Mailboxes | Next: More on SV events