Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • Start Here6
    • Who This Course Is For
    • How the Lessons and Examples Work
    • Words You Will Meet
    • The Testbench Picture
    • The PacketFIFO Project
    • What the Open Simulators Run
  • SystemVerilog Language Foundations35
  • Object-Oriented SystemVerilog for Verification35
  • Constraint Randomization — Interview-Critical Deep Dive66
  • SystemVerilog Assertions — Interview-Critical Deep Dive63
  • Functional Coverage in SystemVerilog28
  • Testbench Architecture in SystemVerilog38
  • Advanced Language & Integration30
  • Senior & Interview Preparation34
  • Principal-Level Verification28
Loading lesson

‹Start Here
  1. Topics
  2. SystemVerilog
  3. Start Here
  4. The Testbench Picture

Part 0 · Start Here · Beginner

The Testbench Picture

The four jobs every self-checking testbench does, shown in one small runnable bench, and where the course builds each job.

On this page

    Why this matters

    Testbenches grow into thousands of lines with many classes. Seeing the four jobs in one small bench first makes every later piece easy to place: it is stimulus, reference, checking or verdict.

    After this lesson you can: name the four jobs of a self-checking testbench and point to each one in a small Verilog bench.

    Four jobs

    However large it gets, a self-checking testbench does four jobs. It makes stimulus, computes the expected answer, compares the DUT with it, and reports one verdict.

    Stimulus feeds both the DUT and the reference model; the checker compares them and the run ends with one verdict. Part 7 splits the same jobs into classes.

    The bench below does all four jobs for a 4-bit adder. Each job is marked with a comment.

    add4.v
    1
    2
    3
    4
    5
    6
    7
    8
    // The design under test (DUT): a 4-bit adder with a carry-out bit.
    module add4 (
      input  wire [3:0] a,
      input  wire [3:0] b,
      output wire [4:0] sum
    );
      assign sum = a + b;
    endmodule
    
    Terminal
    PASS: add4 matched the reference model on all 256 input pairs
    Predict first How many checks does the bench make, and why does it print that count in the PASS line?

    256: 16 values of a times 16 values of b. Printing the count proves the checks really ran. A PASS that says 0 checks would be a bench that checked nothing.

    Terminal
    PASS: add4 matched the reference model on all 256 input pairs

    From four jobs to a class testbench

    Trying every input works for a 4-bit adder. It does not work for a bus with 32-bit addresses, so the course builds each job into something that scales.

    Job

    In this small bench

    Built properly in

    Stimulus

    Two loops

    Part 3 (random values with rules) and Part 7 (generator and driver)

    Reference model

    One function

    Part 7 (reference models and scoreboards)

    Checking

    One if and a counter

    Part 4 (assertions on every cycle) and Part 7 (scoreboard)

    Knowing you tested enough

    Every input, so nothing is missed

    Part 5 (functional coverage)

    Common pitfall

    A reference model copied from the RTL agrees with the RTL's bugs. Write the expected answer from the spec, in a different way from the design if you can.

    Check yourself The DUT and the reference model were both written from the same wrong reading of the spec. What does the bench report?

    PASS. Both agree, so the checker sees no difference. This is why a reference model should come from the spec and, ideally, from a different person or a different method.

    Remember

    • Four jobs: stimulus, reference model, checker, verdict.

    • The verdict line prints how many checks ran, so a bench that checked nothing cannot pass quietly.

    • Write the reference model from the spec, not from the RTL.

    Rule of thumb: if you cannot point at the reference model, the bench is not checking anything.

    How this was checked

    Run with Icarus Verilog 13 (iverilog -g2012) and Verilator 5.048 (--binary --timing) on 2026-10-18; both printed the PASS line shown, with no warnings.

    Exhaustive here means all 256 input pairs of a 4-bit adder; the same method does not scale to wide inputs, which is why Parts 3 to 5 exist.

    Related topics

    • Next: The PacketFIFO Project

    • The Layered Testbench (Part 7)

    Previous

    4 / 363

    Next: The PacketFIFO Project

    Up next

    Up nextThe PacketFIFO Project

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Who This Course Is For
    • How the Lessons and Examples Work
    • What the Open Simulators Run