SystemVerilog Callback

A callback lets you hand a function to someone else's program. When that program reaches a certain point, it "calls back" your function and runs it, without needing to know exactly what your function does — a way for different parts of a system to work together more flexibly, without being tightly connected.

In SystemVerilog, a class method is written to call placeholder methods. A user can later extend the class and implement those placeholder methods — the placeholders are the callback methods, and the calls to them are the callback hooks. The major benefit is decoupling: a verification environment can register behavior to run during simulation without ever modifying the original code that invokes it.

8 min read | Intermediate Level

What You'll Learn

• What a callback is, and why it decouples components from each other
• The four steps to building a callback in SystemVerilog: define, register, implement, invoke
• How a callback differs from calling a regular method directly
• The lighter-weight "empty placeholder method" pattern used throughout real verification environments

Building a Callback: 4 Steps

1. Define the Callback Class

Callback functionality is usually implemented in a class with a virtual method that can be overridden or extended by other classes:

class MyCallback;

  virtual function void callback_function();
    // Default implementation (optional)
  endfunction

endclass

2. Register the Callback

The class that will invoke the callback needs a way to store a reference to it, provided later at run time:

class MyTest;
  MyCallback cb;

  // 2. Registration of callback
  function void register_callback(MyCallback callback);
    cb = callback;
  endfunction

  function void execute();
    if (cb != null) begin
      cb.callback_function();
    end
  endfunction
endclass

3. Implement the Callback

The actual behavior lives in a class that extends the callback class and overrides its method:

// 3. Callback implementation
class UserCallback extends MyCallback;

  function void callback_function();
    $display("User-defined callback called!");
  endfunction

endclass

4. Invoke the Callback

The invoking class doesn't know (or need to know) what the callback actually does — it just calls whatever was registered:

module tb;

  initial begin
    MyTest        test;
    UserCallback  user_cb;

    test    = new;
    user_cb = new;

    // Register user-defined callback
    test.register_callback(user_cb);

    // 4. Execute which will invoke the callback
    test.execute();
  end
endmodule

Output

xcelium> run
User-defined callback called!
xmsim: *W,RNQUIE: Simulation is complete.
xcelium> exit

test.cb is a MyCallback-typed handle, but it actually points to a UserCallback object. Because callback_function() is declared virtual, calling it through cb correctly dispatches to UserCallback's overridden version — the same polymorphism mechanism covered earlier in this tutorial is what makes the whole callback pattern work.

How Is a Callback Different From a Regular Method Call?

A regular function or task is called directly by name, and its behavior is fixed unless the code itself is rewritten. A callback is registered by one part of the code and invoked by another, and the invoking part never needs to know what the registered callback actually does.

Using Empty Placeholder Methods as Callbacks

Empty tasks can be positioned at key points in a class, allowing behavior to be added at those exact spots later, without touching the original code at all:

class MyTest;
 ...

  virtual task body();
     // some statements
     pre_err_callback();
     err_inj_seq();
     post_err_callback();
     // more statements
  endtask

  virtual task pre_err_callback();
    // Empty callback
  endtask

  virtual task post_err_callback();
    // Empty callback
  endtask
endclass

class MyTestExt extends MyTest;

  virtual task pre_err_callback();
    // Implement things to be done before error injection
  endtask

  virtual task post_err_callback();
    // Implement things to be done after error injection
  endtask
endclass

This achieves the same decoupling as the 4-step pattern above, through a simpler mechanism: instead of a separate registration step, the "registration" is just choosing to instantiate MyTestExt instead of MyTest. pre_err_callback() and post_err_callback() are placeholders in the base class, and MyTestExt fills them in — body() itself never needs to change to support that new behavior.

Common Beginner Mistakes

class MyTest;
  virtual task body();
     pre_err_callback();
     err_inj_seq();
     mid_err_callback();
     post_err_callback();
  endtask

  virtual task pre_err_callback();  endtask
  virtual task mid_err_callback();  endtask
  virtual task post_err_callback(); endtask
endclass

class MyTestExt extends MyTest;
  virtual task mid_err_callback();
    $display("Mid-injection callback fired");
  endtask
endclass