Drivers, Monitors and Bus Functional Models

The driver and monitor are the two components that touch the DUT’s pins. Together they form the bus functional model (BFM) — the translation layer between abstract transactions and the real protocol.

Driver: transaction → pins

A driver pulls a transaction from its sequencer and performs the exact handshake the protocol demands — assert valid, present data, wait for ready, deassert. It is the only component allowed to drive the interface. A monitor does the mirror image: it samples the same handshake and emits a reconstructed transaction to the scoreboard and coverage, driving nothing.

This example shows a valid/ready handshake being driven and simultaneously monitored, with the reconstructed transaction checked against what was sent:

module tb;
  reg clk=0, rst_n=0;
  reg        valid; reg [7:0] data;      // interface
  reg        ready = 1;
  always #5 clk = ~clk;

  // driver: send one byte with a valid/ready handshake
  task send(input [7:0] b);
    begin
      @(posedge clk); valid <= 1; data <= b;
      @(posedge clk); while (!ready) @(posedge clk);
      valid <= 0;
    end
  endtask

  // monitor: capture accepted bytes
  reg [7:0] seen; integer got = 0;
  always @(posedge clk) if (valid && ready) begin seen = data; got = got + 1; end

  initial begin
    valid=0; data=0; #3 rst_n=1;
    send(8'hA5); send(8'h3C);
    #10 $display("driver sent 2 bytes, monitor captured %0d, last=%h", got, seen);
    $finish;
  end
endmodule

driver sent 2 bytes, monitor captured 2, last=3c