How to Read a Simple Testbench

The parts of a supplied testbench — DUT, stimulus, expected values, and checks — and how to trace a failing line back to its input.

Updated 2026-07-08

A testbench is a module whose job is to test another module. It is not synthesizable — it never becomes hardware. It exists only to drive inputs into your design and check that the outputs match what you expect. In this course we supply the SystemVerilog testbenches so you can focus on the design; being able to read one is a real skill on its own.

Every simple testbench has the same four parts:

  • The DUT — the design under test. It appears as an instance, usually named dut, wiring your module's ports to local signals.
  • The stimulus — lines that set the input signals to specific values and wait, so the design has time to respond.
  • The expected values — the values the testbench compares against, written into each check.
  • The checks — comparisons (often an if guarding a $display) that print a PASS or FAIL message.

When a check fails, it tells you almost everything you need. A line like FAIL: a=1,b=1 expected 1 got 0 names its own input pattern (a=1, b=1), what it expected (1), and what your design produced (0). Trace that failing line back to the stimulus set just before it, and you know exactly which case your design got wrong. Reading failures this way turns a red test into a precise to-do item.