EC-21.1 SystemVerilog, and a Testbench You Can Trust

The standard opening treatment of hardware verification: SystemVerilog features, testbench structure, self-checking tests and regression, September 2026

What this is and why it exists

Writing a digital design is the smaller half of the work. Proving it correct is the larger one.

In industry the two are usually done by different people, with different tools and different habits of mind. A student who has only written designs is qualified for perhaps a third of the jobs in the field.

The change that matters is self-checking. A test that prints waveforms needs an expert to read it. A test that compares against a reference model reports pass or fail. A machine can run it ten thousand times overnight, on every change.

The vocabulary

  • Testbench — the code that surrounds a design and exercises it.
  • Driver — the part of a testbench that applies stimulus.
  • Monitor — the part that observes what the design did.
  • Scoreboard — the part that decides whether the result was correct.
  • Reference model — an independent description of what the design should do.
  • Directed test — a test written to exercise one specific situation.
  • Constrained random — stimulus generated randomly within stated legality rules.
  • Regression — running the whole test suite automatically after every change.

The mental model

SystemVerilog adds a set of features that exist for the person testing rather than the person designing: interfaces, classes, randomisation and functional coverage. Recognising that split is the first step. Verification is a second job, not a chore appended to the first.

A testbench has a standard shape, and the shape scales. The driver applies stimulus. The monitor watches the interface and reports what it saw. The scoreboard compares that against a reference model. Keeping the four separate means each can be replaced without touching the others.

The reference model is the piece students most often skip. It is an independent description of correct behaviour, usually written in a higher-level style than the design. Two independent descriptions that agree are strong evidence. One description compared against itself is none.

Stimulus comes from two directions. Directed tests cover the corners you already fear. Constrained random stimulus finds the combinations nobody thought to write down. Real verification uses both, and noticing which kind found a bug tells you something useful about your own assumptions.

A simulator can only compare the design against your model of the world. Anything wrong in that model is invisible. Timing, physical effects and a misread specification all pass simulation happily. That limitation is why the rest of this module exists.

Finally, regression. A suite that has to be run by hand will not be run. The value appears only when every change triggers the whole suite automatically. A design with ten tests that always run is in better shape than one with a hundred that nobody starts.

What you should now be able to explain or do

  • Name the four parts of a testbench and say what each is responsible for.
  • Explain why a reference model has to be independent of the design.
  • Say what makes a test self-checking, and why that matters more than test count.
  • Choose between directed and constrained random stimulus for a given goal.
  • List three kinds of defect that simulation cannot find.
  • Explain why automatic regression changes what a test suite is worth.

Check yourself

It decides correctness itself and reports pass or fail. Nothing needs a person to read a waveform and form an opinion about it.

Because comparing a design against a copy of itself proves nothing. The evidence comes from two separate descriptions of correct behaviour agreeing.

Combinations nobody thought of. Directed tests can only cover situations somebody already imagined, which excludes most real bugs.

Whether the design meets its timing on real silicon. Simulation checks logic against your model, not the physical behaviour of the manufactured part.

Go deeper

Back to SystemVerilog, and a Testbench You Can Trust: work through the checklist