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
endmoduleenv 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.
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 TeamCompile and simulate this in the browser — no install. Edit the code and re-run instantly.
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