Simulation and testbenches
Before a design becomes a chip, you run it in a simulator. Watch a testbench wrap a full adder: it makes a clock, drives each test vector onto the inputs, checks the outputs with an assertion, and draws every signal as a waveform. A mismatch is flagged and fixed, then you see when to test every case and when to use random and directed tests, measured by coverage.
5 quick questions
Pick an answer to see why. Your score saves with your progress.
01What is a testbench?
A testbench only exists in simulation. It feeds the design under test and checks what comes out; it is never built into the chip.
02In this testbench the clock is high for 5 ns and low for 5 ns. When are the outputs checked?
New inputs go in on the rising edge; half a period later, on the falling edge, the checker compares the outputs with the expected ones.
03The waveform shows cout = 0 where the expected cout is 1 for inputs 0 1 1. What does that tell you?
0 + 1 + 1 = 2, which is binary 10: s = 0 and cout = 1. The design gave cout = 0 because it forgot the carry-in.
04Why can't you test a 32-bit adder exhaustively?
Each extra input bit doubles the cases. 2^64 is about 1.8 × 10^19, far too many, so big blocks use random and directed tests instead.
05Six random tests tried only four of the eight input cases. What tells you which ones were missed?
Coverage counts which cases (bins) the tests actually hit. Empty bins show where to aim directed tests.
Glossary
- Simulation
- Running a hardware design as a program on an ordinary computer, to see what every signal would do before the chip is built.
- Testbench
- Code written only for simulation that drives the inputs of a design and checks its outputs. It is never built into the chip.
- DUT (design under test)
- The block being tested, placed inside the testbench.
- Test vector
- One test case: the inputs to apply and the outputs they should give.
- Assertion
- A statement that must be true at a given moment; the simulator reports an error when it is false.
- Waveform
- A drawing of a signal against time: a high line for 1, a low line for 0.
- Exhaustive, random and directed tests
- Exhaustive tries every input case; random picks cases at random; directed tests are chosen by hand to hit specific cases.
- Coverage
- A measure of how much of the design's behaviour the tests actually exercised, for example how many input cases were tried.
Notes and sources
- The clock, the vector file and the rising-edge apply / falling-edge check pattern follow the self-checking testbench in Harris and Harris, Digital Design and Computer Architecture (2nd ed.), section 4.9.
- Delays such as #5, $display and the value change dump (VCD) files that waveform viewers read are part of Verilog, IEEE Std 1364. Immediate assertions, constrained random stimulus and covergroups are part of SystemVerilog, IEEE Std 1800.
- In Python, ^ and & on the numbers 0 and 1 are XOR and AND, and assert raises an AssertionError when its condition is false. The cocotb library lets you write testbenches like this in Python for real Verilog simulators.
- 2^64 = 18,446,744,073,709,551,616. At one billion tests per second that is about 1.8 × 10^10 seconds, roughly 585 years.
- Intel announced a pre-tax charge of US$475 million on 17 January 1995 to replace Pentium chips with the FDIV division bug, caused by missing entries in a lookup table.
- The random picks here are one fixed example draw, so the figure plays the same way every time; a real testbench draws new ones from a seed.
- Harris and Harris, Digital Design and Computer Architecture (section 4.9, testbenches)
- IEEE Std 1364-2005, Verilog Hardware Description Language
- IEEE Std 1800-2017, SystemVerilog (assertions, constrained random, coverage)
- cocotb: Python testbenches for HDL simulators
- Python reference: the assert statement
- Pentium FDIV bug (history and the US$475 million charge)
Quiz Unlocks after the last step.