SystemVerilog Virtual Interface

An interface can be instantiated inside a module, but never inside a class. That's a real problem the moment you start building an object-oriented testbench: a class-based driver, monitor, or scoreboard still needs to drive and sample real DUT signals somehow. A virtual interface is the handle that closes that gap — a class-compatible reference that points at an actual interface instance created elsewhere, letting class code reach out into the physical world without ever instantiating an interface itself.

7 min read | Intermediate Level

What You'll Learn

• Why a class can't directly instantiate an interface, and what problem virtual interfaces solve
• The syntax for declaring a virtual interface handle, with or without a modport
• How to pass a virtual interface into a class through its constructor
• How virtual interfaces work together with modports and clocking blocks
• The most common pitfall: using an uninitialized (null) virtual interface handle

Why Do We Need Virtual Interfaces?

SystemVerilog Interface covers how an interface bundles signals together, and SystemVerilog Modport covers restricting access to those signals per module. Both of those are still module-side constructs, though — a class cannot declare an interface instance as one of its own properties. Since class-based components (drivers, monitors, scoreboards, and similar) are exactly where most of a modern testbench's logic lives, there has to be some way for that class code to reach the actual interface signals living out in a module.

A virtual interface is that bridge. It's a handle — conceptually similar to a class handle — that can be declared as a class property, and later assigned to point at a real interface instance. Nothing about declaring one creates any new signals; it's just a reference, exactly like an unassigned class handle is just a reference until you call new() on it.

Basic Syntax

virtual interface_name  variable_name;

// Restricted to a specific modport's view, same as a module port would be
virtual interface_name.modport_name  variable_name;

Both forms declare a handle, not a new interface instance. The second form, with a modport, restricts what the class can access through that handle to exactly what the named modport allows — the same restriction a module would get by declaring its port as interface_name.modport_name instead of the whole interface.

A Complete Example

The interface below reuses the request-grant pattern from earlier in this chapter, with a clocking block and a TB modport that references it:

interface req_gnt_if (input logic clk);
  logic req;
  logic gnt;
  logic rstn;

  clocking cb @(posedge clk);
    default input #1step output #2ns;
    output req;
    input  gnt;
  endclocking

  modport TB (clocking cb, output rstn);
endinterface

A simple Driver class stores a virtual interface handle, typed to the TB modport, and takes it in as a constructor argument:

class Driver;
  virtual req_gnt_if.TB vif;   // handle only - no signals of its own

  function new (virtual req_gnt_if.TB vif);
    this.vif = vif;
  endfunction

  task drive_req (bit value);
    vif.cb.req <= value;
  endtask
endclass

The design and testbench modules stay exactly as they'd look without any class involved — the only new piece is passing vif into Driver's constructor:

module des (input logic clk, req, rstn, output logic gnt);
  always @ (posedge clk or negedge rstn)
    if (!rstn) gnt <= 0;
    else       gnt <= req;
endmodule

module tb;
  logic clk;
  always #10 clk = ~clk;

  req_gnt_if vif (.clk(clk));
  des dut (.clk(clk), .req(vif.req), .rstn(vif.rstn), .gnt(vif.gnt));

  Driver drv;

  initial begin
    vif.rstn <= 0;
    repeat (3) @(posedge clk);
    vif.rstn <= 1;

    // Pass the physical interface instance into the class through its constructor -
    // SystemVerilog automatically converts it to a virtual interface handle here
    drv = new (vif);

    repeat (2) @(posedge clk);
    drv.drive_req(1);

    repeat (5) @(posedge clk);
    $finish;
  end
endmodule

vif is declared in the module as a plain interface instance, exactly as in every other example in this chapter. Passing it into new(vif) is where the conversion happens: SystemVerilog automatically treats an actual interface instance as a valid value for a virtual interface parameter, so no explicit cast is needed. From that point on, drv.vif behaves like any other class handle — it can be reassigned, passed to other methods, or stored in an array of handles.

The Most Common Pitfall: An Uninitialized Virtual Interface

A virtual interface handle that's declared but never assigned defaults to null, exactly like an unassigned class handle. Using it before assignment produces a run-time error — not a compile-time one — because the compiler has no way of knowing at compile time whether the handle will actually be assigned before it's used. Suppose Driver had no constructor argument at all, and nothing else in the testbench ever assigned vif:

class Driver;
  virtual req_gnt_if.TB vif;   // starts out null - nothing assigned yet

  task drive_req (bit value);
    vif.cb.req <= value;   // fails at run time if vif was never assigned
  endtask
endclass

module tb;
  Driver drv;

  initial begin
    drv = new();       // vif was never passed in or assigned anywhere!
    drv.drive_req(1);  // run-time error: dereferencing a null handle
  end
endmodule

class Monitor;
  virtual req_gnt_if.TB vif;

  function new (virtual req_gnt_if.TB vif);
    this.vif = vif;
  endfunction

  task sample_gnt (output bit gnt_val);
    @(vif.cb);
    gnt_val = vif.cb.gnt;
  endtask
endclass

module tb;
  // ... clk, req_gnt_if vif, and des dut instantiated as before

  Monitor mon;
  bit     g;

  initial begin
    mon = new (vif);
    mon.sample_gnt(g);
    $display("gnt = %0b", g);
  end
endmodule