How Virtual Interface can be pass using uvm_config_db in the UVM Environment?

UVM components are classes, and classes are created at run time. The DUT and its interface are static, elaborated once at time zero. A class cannot point straight at a static interface, so UVM uses a virtual interface, a handle to the real interface, and passes that handle down using uvm_config_db.

Why a virtual interface is needed

A testbench has two worlds. The class-based world (test, environment, agents, driver, monitor) is created at run time. The structural world (the DUT and the interface wired to it) is static. The driver has to wiggle real pins, so it needs a way to reach into the static interface from inside a class. That bridge is the virtual interface.

A simple way to picture it

Think of a TV remote. The remote (your class-based driver) does not hold the wires inside the TV. It holds a link to the TV so it can change channels. The virtual interface is that link: the driver keeps a handle to the real interface and drives the pins through it, without owning the wires itself.

Step 1: declare the interface and connect it in the top module

First define an interface, instance it in the top module, and connect it to the DUT. Then place the handle in the config database so the testbench can find it.

interface apb_if(input logic pclk);
  logic        preset_n;
  logic [31:0] paddr;
  logic        pwrite;
  logic [31:0] pwdata;
  logic [31:0] prdata;
  logic        psel, penable, pready;
endinterface

module top;
  logic pclk = 0;
  always #5 pclk = ~pclk;

  apb_if apb_vif(pclk);          // real interface instance

  apb_dut dut(.apb(apb_vif));    // connect to DUT

  initial begin
    // put the handle in the database for the whole testbench
    uvm_config_db#(virtual apb_if)::set(null, "uvm_test_top.env.agt*",
                                        "vif", apb_vif);
    run_test("apb_test");
  end
endmodule

Step 2: pass it down with uvm_config_db

The interface handle now travels down the hierarchy through the config database. The test does not need to touch it; UVM carries it to the agents, which then hand it to the driver and monitor. The diagram below shows this flow.

Step 3: get the handle in the driver and monitor

Each component that touches pins reads the handle in its build_phase. Always check the return value, and stop the test with a clear message if the handle is missing.

class apb_driver extends uvm_driver #(apb_seq_item);
  `uvm_component_utils(apb_driver)
  virtual apb_if vif;

  function new(string name, uvm_component parent);
    super.new(name, parent);
  endfunction

  function void build_phase(uvm_phase phase);
    super.build_phase(phase);
    if (!uvm_config_db#(virtual apb_if)::get(this, "", "vif", vif))
      `uvm_fatal("NOVIF", "No virtual interface set for the driver")
  endfunction

  task run_phase(uvm_phase phase);
    forever begin
      apb_seq_item tr;
      seq_item_port.get_next_item(tr);
      // drive real pins through the virtual interface
      @(posedge vif.pclk);
      vif.psel   <= 1;
      vif.paddr  <= tr.addr;
      vif.pwrite <= tr.write;
      vif.pwdata <= tr.data;
      seq_item_port.item_done();
    end
  endtask
endclass

The monitor reads the same handle the same way, then samples vif signals instead of driving them. Both sit inside the agent, so the wildcard path env.agt* from the top reaches them together.

Where to set and where to get

Common mistakes to avoid

• Getting the handle in run_phase instead of build_phase, so early code sees a null handle.
• A path mismatch: setting on agt but the real instance is agent. The names must match or use a wildcard.
• Skipping the return check on get, then hitting a null virtual interface at the first pin access.
• Setting the wrong type, for example virtual apb_if on the set and a different interface type on the get.
• Connecting the interface to the DUT but forgetting the set call, so the handle never enters the database.

Keep learning

This builds directly on the config database. Read more about uvm_config_db and uvm_resource_db, see the typical UVM testbench architecture, and find related topics in the UVM category and the interview questions.

Frequently asked questions

Share this post: on Twitter on Facebook