Introduction

Simple Testbenches built the smallest testbench that can possibly exist: one initial block, a handful of directed stimulus lines, an if/else comparing the DUT's output against a hand-computed expected value. That's genuinely all a five-input full adder needs. It is not what a real block — a FIFO, a UART, a small CPU — needs, and this topic exists to cover the gap between the two honestly, in code, rather than just asserting that "real testbenches are more complicated."

What breaks first, concretely

UVM's own introduction names the actual failure mode teams hit building this by hand: "every engineer wired components together slightly differently, nothing was reusable between projects, and onboarding a new verification engineer meant learning one more bespoke testbench style from scratch." That's not a hypothetical — it's the direct, lived consequence of what happens when stimulus generation, DUT driving, response checking, and scenario control all live in one undifferentiated initial block, which is exactly the shape Simple Testbenches and SystemVerilog's own capstone both still have, class-based or not.

The fix the industry converged on has a name — a layered testbench: stimulus generation, DUT driving, response observation, and checking each get their own component, talking to each other only through well-defined channels (mailboxes, virtual interfaces), running concurrently rather than as one serial script. This topic builds exactly that, from scratch, in plain SystemVerilog — no UVM base classes, no factory, no config_db, no phasing. Every one of those UVM mechanisms already has a page on this site; this topic's job is to make sure you've felt the specific problem each one solves before you ever read about the solution.

Why "well-defined channels" specifically, not direct calls

It's worth being explicit about why mailboxes and virtual interfaces are the connective tissue here, rather than one component simply calling a method on another directly. A generator that calls driver.drive(txn) directly has to know the driver's class, its method names, its argument types — and every other component wired the same way accumulates the same kind of dependency, until changing one component risks breaking several others that were never meant to know about its internals. Routing communication through a mailbox instead means the generator only has to know "put a transaction in this channel" — nothing about who reads it, how many readers there are, or what they do with it. That's what makes it possible to swap a driver's implementation, add a second consumer of the same stimulus, or reuse a component in an entirely different testbench without touching its neighbors' code. The same reasoning applies to virtual interfaces: a driver written against a virtual interface handle doesn't need to know which physical interface instance it's bound to until the testbench connects them, so the same driver class works unmodified against any DUT that exposes a compatible interface.

Where this fits between SystemVerilog and UVM

• SystemVerilog taught the raw language mechanics this topic depends on entirely — class, mailbox, fork/join, interface, randomize(), covergroup. Nothing here is new syntax.
• This topic teaches how those mechanics compose into an architecture — the generator/driver/monitor/scoreboard/environment shape — with no standardization layer underneath it at all. Every reuse mechanism you build here, you build by hand.
• UVM is the standardized version of the identical architecture. Once you've built a generator by hand and felt its lack of arbitration, uvm_sequence will read as a specific answer to a specific gap, not an arbitrary new API surface to memorize.

Read in that order — SystemVerilog → Testbench → UVM — and each one assumes exactly what the last one built.

The running example

Every page in this topic builds one testbench, for one DUT: a synchronous FIFO, with the identical interface UVM's own curriculum uses —

interface fifo_if (input bit clk, input bit rst_n);
  logic       wr_en;
  logic [7:0] wr_data;
  logic       full;
  logic       rd_en;
  logic [7:0] rd_data;
  logic       empty;
endinterface

That reuse is deliberate, not incidental. By the time this topic's capstone assembles the complete hand-rolled FIFO testbench, UVM's own capstone will already have built a driver, a monitor, a scoreboard, and an environment for the exact same DUT — which means the two can be read side by side, component for component, as a direct before-and-after of what standardization actually buys you.

What's next

The next page looks honestly at what this topic's two starting points — Verilog's directed testbench and SystemVerilog's class-based capstone — already have, and precisely what's still missing from each before either one deserves to be called a layered testbench.