Week 4 · Day 16 · 7 hours

Verilog Verification – TB Fundamentals

Testbenches, self-checking, regression, debugging

Open supporting lesson → Week 4 assessment View in full programme
Daily plan

What you will learn and practise

Complete the stages in order and retain the requested evidence.

Theory · 2h

Testbench architecture
DUT instantiation
Clock/reset generation
Tasks/functions
System tasks and waveform dumping

Guided lab · 2h

1. AND-gate TB
2. DUT instantiation
3. Parameterized clock
4. Reset task
5. Directed stimulus
6. Loop stimulus

Independent lab · 2h

7. Random stimulus
8. Driver task
9. Checker function
10. $display/$monitor/$strobe
11. $dumpfile/$dumpvars
12. PASS/FAIL counters

Debug and assignment · 1h

Fix race-prone stimulus timing
Create reusable TB skeleton

Expected deliverable

Reusable Verilog TB template

Practical work

Build a reusable Verilog testbench skeleton that instantiates a DUT, generates clock/reset, applies directed and loop stimulus, checks results automatically, reports PASS/FAIL, and captures a VCD waveform.

Setup
  1. Create project_workspace/week4_verilog_verification/day16_tb_fundamentals with rtl, tb, sim and logs directories.
  2. Use Icarus Verilog for compile/simulation and GTKWave for waveform inspection.
  3. Use plain Verilog testbench constructs only; do not use SystemVerilog classes, interfaces, assertions or UVM.
Execution steps
  1. Create a small synchronous counter DUT with clock, reset and enable inputs.
  2. Instantiate the DUT in tb_counter.v and generate a parameterized clock.
  3. Create a reset task and apply reset before functional stimulus.
  4. Apply directed enable/disable stimulus and a loop of repeated cycles.
  5. Add a reusable checker task that compares count against the expected value and increments PASS/FAIL counters.
  6. Use $display for checkpoints, $monitor for selected signal activity, and $strobe where end-of-time-step observation is useful.
  7. Enable $dumpfile/$dumpvars and inspect reset, enable and count in GTKWave.
  8. Introduce race-prone stimulus at a clock edge, observe the failure, then move stimulus away from the sampling edge and rerun.
  9. Finish with a TOTAL/PASS/FAIL summary and a non-zero error indication when any check fails.
Written assignment
  1. Draw and explain the DUT-to-testbench architecture: DUT, clock/reset generation, stimulus, checker and reporting.
  2. Explain the difference between $display, $monitor and $strobe with one appropriate use for each.
  3. Explain why changing stimulus on the same simulation event as the active clock edge can create a race.
  4. Describe what evidence is required before a self-checking simulation can be called PASS.
Debug challenge

A testbench drives enable exactly on posedge clk and intermittently reports the previous/next count. Reproduce the race, capture the failing log/waveform, correct stimulus timing, and prove the corrected run is repeatable.

Evidence to retain
  • rtl/counter.v and tb/tb_counter.v
  • Compiler output with no errors
  • logs/day16_tb.log containing TOTAL/PASS/FAIL summary
  • sim/day16_tb.vcd showing reset, enable and count
  • Short before/after note describing the race and the correction
Completion criteria
  • DUT instantiation, clock generation and reset task work correctly.
  • Directed and loop stimulus execute deterministically.
  • Checker detects an intentionally injected mismatch and the clean DUT run finishes with FAIL=0.
  • VCD can be opened and the learner can explain reset, enable and count timing.
  • Reusable TB skeleton is retained for Days 17–20.
Technical visuals

Understand the architecture and debug flow

Reusable Verilog Testbench Architecture
Reusable Verilog Testbench Architecture
Clock/reset, reusable stimulus, DUT, checker and retained log/waveform evidence.
Race-Prone vs Deterministic Stimulus Timing
Race-Prone vs Deterministic Stimulus Timing
Why stimulus aligned to a DUT sampling edge can race, and how deterministic timing avoids it.
Executable lab

Build, run and retain evidence

project_workspace/week4_verilog_verification/day16_tb_fundamentals/

Required files
  • rtl/counter.v
  • tb/tb_counter.v
  • sim/day16_tb.vvp
  • sim/day16_tb.vcd
  • logs/day16_tb.log
Mandatory tests
  • Reset establishes the documented initial count.
  • Enable=1 advances the count on the intended clock edge.
  • Enable=0 holds the count.
  • Loop stimulus covers multiple consecutive enabled and disabled cycles.
  • Checker PASS and FAIL paths are both demonstrated by intentional mismatch injection followed by a clean rerun.
  • Race-prone edge stimulus is reproduced and corrected.
  • $dumpfile/$dumpvars produce a usable VCD waveform.
Compile
iverilog -g2012 -Wall -o sim/day16_tb.vvp rtl/counter.v tb/tb_counter.v
Run
vvp sim/day16_tb.vvp | tee logs/day16_tb.log
Waveform
gtkwave sim/day16_tb.vcd
PASS criteria
  • Compile completes without errors.
  • Clean run reports TOTAL > 0, PASS = TOTAL and FAIL = 0.
  • Injected mismatch is detected by the checker.
  • Corrected timing removes the race on repeated runs.
  • Log and waveform evidence are retained in project_workspace.
Knowledge check

Review before completing Day 16

  1. Concept

    What are the five essential responsibilities of the Day 16 testbench?

    Review answer

    Instantiate/connect the DUT, generate clock/reset, create stimulus, observe/check DUT behavior, and report/capture evidence such as PASS/FAIL logs and waveforms.

  2. Reasoning

    Why should reset behavior be verified before normal functional stimulus?

    Review answer

    The checker needs a known starting state. If reset is wrong or not established first, later mismatches may be caused by initialization rather than the function being tested.

  3. Debug

    Why can driving a DUT input on the same posedge used by the DUT create a race?

    Review answer

    The DUT and testbench processes may execute in the same simulation time slot without a guaranteed ordering, so the DUT may sample either the old or new stimulus. Drive stimulus away from the sampling edge or otherwise establish deterministic timing.

  4. Tool

    What is the purpose of $dumpfile and $dumpvars?

    Review answer

    $dumpfile selects the waveform dump file and $dumpvars selects the hierarchy/signals to record so simulation activity can be inspected in a waveform viewer such as GTKWave.

Skills and assessment traceability

TB fundamentals

  • Instantiate and connect a Verilog DUT.
  • Generate deterministic clock and reset stimulus.
  • Use tasks/functions and loop stimulus for reusable testbench behavior.
  • Create automatic expected-versus-actual checks with PASS/FAIL counters.
  • Capture logs and VCD evidence and diagnose a testbench timing race.

Assessment: Week 4 automated testbench, regression/debug assessment