Driver, Monitor, Reference Model, and Scoreboard

Separate command driving, DUT observation, prediction, and result comparison.

A chain of responsibilities

A layered environment separates jobs so failures are easier to locate:

1. the generator creates a transaction;
2. the driver turns it into signal changes;
3. the monitor reconstructs transactions actually seen on the interface;
4. the reference model predicts the result;
5. the scoreboard compares expected and observed values.

The driver should not decide whether a result is correct. The monitor should not drive the DUT. These boundaries prevent one piece of code from hiding its own mistake.

The driver applies a protocol

task automatic drive(input request_t req);
  bus.valid <= 1'b1;
  bus.addr  <= req.address;
  bus.data  <= req.data;
 
  do @(posedge bus.clk); while (!bus.ready);
 
  bus.valid <= 1'b0;
endtask

The driver receives an abstract transaction and follows the handshake cycle by cycle. It must not inspect a DUT internal signal to take a shortcut.

The monitor observes reality

task automatic monitor();
  forever begin
    @(posedge bus.clk);
    if (bus.valid && bus.ready) begin
      observed_t tr = new();
      tr.address = bus.addr;
      tr.data    = bus.data;
      observed_mb.put(tr);
    end
  end
endtask

The monitor reconstructs what was actually transferred. It remains passive. An input monitor feeds the reference model, while an output monitor feeds comparison.

Reference and scoreboard

The reference model should be simpler than the RTL. It can use software-style types, a clear function, or an external model as long as it follows the specification exactly.

The scoreboard stores expected results and compares them with observed results. A queue is enough for in-order responses. An associative array indexed by identifier fits reordered responses.

A useful mismatch message includes:

• transaction or identifier;
• expected value;
• observed value;
• time and, if possible, cycle number;
• enough context without flooding the log.

Do not trust the environment too early

The testbench needs tests of its own. Deliberately inject a wrong response and check that the scoreboard detects it. Drop a response to exercise timeout behavior and leave an expected item pending to test end-of-run checks.

High coverage cannot compensate for a scoreboard that fails to detect errors.

Key points

• The driver converts a transaction into protocol-correct signals.
• The monitor stays passive and reconstructs what actually happened.
• The reference model comes from requirements, not copied RTL.
• The scoreboard selects storage based on response ordering.
• Test the environment with deliberately injected failures.

📝 Test your knowledge - Chapter quiz