"Draw me a testbench" is one of the most common requests in a verification interview, and one of the most revealing: the drawing shows whether you know where the oracle is, where checks sit and what makes it self-checking. Each drill below gives the task, the order to draw in, what to say, and a model to compare with. Do each on paper first.
Task. Draw a testbench for a block with one input interface and one output interface, and explain how it decides pass or fail.
Draw in this order: the DUT; the driver on its input; the stimulus generator feeding the driver; a monitor on each interface; the reference model fed by the input monitor; the scoreboard comparing model and output monitor; assertions on the interfaces; coverage fed by the monitors.
Say while drawing: the monitors are passive, so they can be reused at higher levels; the reference model is independent of the RTL; the scoreboard and assertions decide pass or fail; coverage measures what was exercised.
An independent reference model, passive monitors separate from drivers, a scoreboard and assertions that decide pass or fail automatically, coverage fed from monitors, and an end-of-test check for leftovers. Bonus: where back-pressure and error injection come in.
Task. Draw a functional coverage model for a packet router with 4 inputs, 4 outputs, 2 priorities and packet lengths 1 to 15.
Coverpoint or cross | Bins | Why |
|---|---|---|
Destination | 0, 1, 2, 3 | Every route |
Length | 1, 2-14, 15, plus 0 (error) | Boundaries and the illegal value |
Priority | low, high | Both arbitration classes |
Destination × priority × length class | 4 × 2 × 3 = 24 | Arbitration and length handling meet at the header |
Contention | 2, 3, 4 inputs to one output | Arbitration under load |
Errors | bad CRC, length 0, per input | Error paths |
Back-pressure | output stalled while full | Credit and buffer corners |
Bins chosen for boundaries and errors, crosses only where values interact (not everything with everything), illegal or ignored bins named, and coverage tied to plan features. Bonus: the arithmetic of how crosses multiply (lesson 6.4).
Task. Draw coverage against tests run and explain what you would do at each stage.
Draw: a steep rise, a bend, a long flat approach towards but below 100%; mark the bend.
Say: early, random stimulus fills common bins fast; after the bend each new bin is rarer (the long tail, lesson 4.5); more seeds on the flat part buy little, so analyse the holes and change the stimulus, write targeted tests, or exclude unreachable bins with reasons (lesson 6.5).
Add if time: a second curve after a targeted test, jumping up from the flat part; and the bug curve beside it, normalised by effort.
That you know why the curve flattens, that more of the same stimulus is the wrong response, and that closure means holes explained (hit, excluded with reason, or waived), not 100%.
Task. Sketch the structure of a verification plan for any block on one side of the board.
Section | Content |
|---|---|
Scope and references | Design version, specification, what is out of scope |
Features | ID, feature, rule, risk |
Per feature | Check, method (directed, random, formal), coverage item, status of evidence |
Environment | Oracle, stimulus, checkers, VIP |
Formal plan | Which properties, on which blocks, why |
Regression | Tiers and seeds |
Sign-off criteria | Agreed now: evidence, coverage, proofs, planted bugs, bug trend, open bugs, residual risk |
Features traced to rules with risk, a check and a method per feature, a formal decision with reasons, and sign-off criteria agreed at the start. The plan is a living document that becomes the sign-off evidence (lessons 9.1 and 14.6).
A testbench drawing must show where the oracle is and what decides pass or fail.
Coverage models cross only what interacts; closure curves flatten and need new stimulus, not more.
A plan traces features to rules, checks, methods and agreed sign-off criteria.