Layered Testbench Architecture

A one-process testbench does not scale. Real verification environments are built as layered, reusable components, each with one job, connected by transaction-level channels. This is the structure UVM formalises — and understanding it as plain components first makes UVM obvious later.

The components

  • Sequence/Generator — creates randomised transactions (abstract requests).
  • Driver — converts a transaction into pin-level wiggles on the DUT interface.
  • Monitor — watches the pins and reconstructs transactions (never drives).
  • Scoreboard — compares observed transactions against a reference model.
  • Coverage collector — records which interesting transactions occurred.
  • Environment — instantiates and connects all of the above.

The power of the split is reuse and abstraction: sequences describe what to test independent of pin timing; the driver owns the protocol; the scoreboard owns correctness. Change the protocol and only the driver/monitor change. The example models the generator→driver→monitor→scoreboard flow at transaction level in one runnable file:

module tb;
  typedef struct packed { byte unsigned a, b; } txn_t;   // a transaction

  function automatic byte unsigned dut_add(byte unsigned x, y); return x + y; endfunction
  function automatic byte unsigned ref_add(byte unsigned x, y); return x + y; endfunction

  int errors = 0;
  task automatic check(txn_t t);                 // scoreboard
    byte unsigned got = dut_add(t.a, t.b);
    byte unsigned exp = ref_add(t.a, t.b);
    if (got !== exp) begin errors++; $display("SB MISMATCH %0d+%0d got=%0d exp=%0d", t.a,t.b,got,exp); end
  endtask

  initial begin
    for (int i = 0; i < 20; i++) begin
      txn_t t;
      t.a = $urandom_range(0,255);               // generator
      t.b = $urandom_range(0,255);
      check(t);                                   // driver+monitor+scoreboard (modelled)
    end
    $display("env ran 20 transactions, errors=%0d %s", errors, errors? "FAIL":"PASS");
    $finish;
  end
endmodule
env ran 20 transactions, errors=0 PASS
- /var/folders/l0/gs5hnkm56g54bmxg32r6nnwr0000gn/T/tmpk_3jag_g/tb.sv:22: Verilog $finish

Check yourself

What is the single responsibility of a monitor, and what must it never do?

A monitor passively observes the DUT’s interface pins and reconstructs transactions from them for checking and coverage. It must never drive the interface — driving is exclusively the driver’s job. Keeping them separate lets the monitor independently witness what actually happened.

Why separate the sequence (stimulus intent) from the driver (pin timing)?

So the same stimulus description can be reused across projects and protocols, and so protocol/timing changes are localised to the driver. Sequences stay abstract (‘send a write of 0x10’), the driver handles how that becomes pin activity.

Have questions about this topic?
Share your question in comments or talk to our mentor team for batch guidance.

Need Fee, Duration, or Demo Class Details?

Talk to our admin team for the latest batch plan and career guidance.

Contact Admin Team
▶ Try it in the ChipXpert Lab

Compile and simulate this in the browser — no install. Edit the code and re-run instantly.

Open in Verification Lab

Learn Verilog with mentors, labs and placement support

This free series is maintained by the ChipXpert training team in Hyderabad & Bengaluru. Go deeper with instructor-led courses on real EDA tools.

Explore VLSI Courses
Next batch starts 18th November 2026
Start your VLSI career with ChipXpert

Live online and classroom batches in Hyderabad & Bengaluru. Fill in your details and a counsellor will call you back.

  • Real EDA tools in your browser: industry-standard EDAReal EDA tools in your browser
  • Recorded sessions on the elearn portalRecorded sessions
  • Placement assistance: resume, mock interviewsPlacement assistance
  • Merit scholarship up to 60% · EMI optionsScholarship up to 60%
Hi! Ask me about courses, fees, batches or discounts. ×
BENGALURU
HYDERABAD