Part 7: Verilog Testbenches and Simulation

What this lecture covers

This lecture answers how to verify a Verilog design without uploading it to real hardware every time. It uses the clock divider module from Part 6 as a running example, building a test bench that drives its inputs, simulating it with Icarus Verilog, and inspecting the results as waveforms in GTKWave.

By the end you can write a test bench with an internal clock generator and a reset pulse, dump signal changes to a .vcd file, and read a waveform viewer closely enough to catch a genuine off-by-one bug in the clock divider's max-count parameter - which the lecture deliberately left unfixed in Part 5 to demonstrate here. It ends with a challenge to simulate the button-debounce design from Part 5.

Key ideas

• Unit under test (UUT): the module being verified, instantiated inside the test bench just like it would be in a top-level design, but with no physical pins involved.
• Test bench code doesn't need to be synthesizable: constructs like delays (#), initial blocks, and system tasks ($dumpfile, $finish) are valid for simulation but have no hardware equivalent.
• ` timescale ``: a compiler directive setting the time unit and precision used for delays in the test bench, analogous to setting the time-axis resolution on an oscilloscope.
• Simulated clock generation: since there's no physical oscillator in simulation, the test bench toggles a clock register in a loop using delays to approximate the target frequency.
• Value change dump (.vcd): $dumpfile and $dumpvars record how signals change over the simulation run, viewable afterward in GTKWave.
• apio's _tb convention: apio sim looks for a file ending in _tb.v to identify the test bench and runs Icarus Verilog and GTKWave automatically.
• Finding the bug: measuring the divided clock's period in GTKWave showed it was longer than intended, revealing that the max-count parameter needed a - 1 because the counter starts at zero.

Walkthrough

Why simulate before using real hardware (1:12)

The lecture explains that synthesizing and uploading a design takes time, and that observing real hardware at megahertz speeds requires equipment like an oscilloscope or logic analyzer. Simulating a module with a test bench and viewing the output in a waveform viewer is presented as a faster, cheaper way to catch bugs.

Structuring the test bench module (6:55)

The test bench for the clock divider module has no ports, since everything is internal. It declares registers for clock and reset (so they can be driven directly) and a wire for out, and sets initial values for the clock and reset registers - something only valid in simulation.

Generating a clock and pulsing reset (8:33)

An always block with no sensitivity list toggles the clock register every ~41.67 ns to approximate a 12 MHz signal, using the # delay syntax. A separate initial block pulses the reset line high briefly near the start of the simulation, running concurrently with the clock-generation block.

Instantiating the unit under test with scaled-down parameters (11:12)

The clock divider is instantiated as uut, overriding its count_width and max_count parameters to much smaller values than real hardware would use, so the simulation only needs to run a manageable number of clock cycles instead of waiting for a full-scale divide ratio.

Dumping signals to a VCD file (14:15)

$dumpfile names the output .vcd file, and $dumpvars(0, ...) records every signal in the test bench and all instantiated modules beneath it. A fixed simulation duration and $finish ensure the simulation stops instead of running indefinitely.

Debugging with GTKWave (19:59)

After running apio sim, the lecture loads the clock, counter, reset, and divided-output signals into GTKWave, uses markers to measure the divided clock's period, and finds it's longer than the intended 500 ns. Because the counter starts at zero, the max-count parameter needs to be one less than expected; adding - 1 and re-simulating confirms the fix.

Before you watch

• Complete Part 6 ("Verilog Modules and Parameters"), since this lecture tests the same clock divider module built there.
• Recall the finite state machine from Part 5; its clock-divider timing bug is the one diagnosed in this lecture.

Check your understanding

1. Why can test benches use constructs like delays and initial blocks that wouldn't be valid in synthesizable code?
2. How does the test bench generate an approximate 12 MHz clock without real hardware?
3. What does $dumpvars(0, ...) do, and how would using 1 instead of 0 change what gets recorded?
4. Why does apio require a test bench file to be named with a _tb suffix?
5. What was the actual bug found in the clock divider, and why did the counter starting at zero cause it?