A verification lead starting a new block does something before writing any test: they ask what could be wrong, sort the possibilities into kinds, and decide which technique will hunt each kind. That table becomes the backbone of the plan. You can now do the same for DCRouter, with one advantage real projects never have: the Bug Zoo will tell you, part by part, whether your predictions were right.
Which classes of bug does DCRouter contain, and which technique should find each?
The obvious approach is to start writing tests and see what fails. That finds the bugs your first tests happen to reach, usually the easy classes, and gives no warning about classes nobody is hunting. Predicting first turns the plan into a set of testable claims: if a technique you expected to catch a class misses it, you have learned something about the technique or the class before silicon teaches you.
The Bug Zoo's 24 bugs by class (from the DCRouter specification). Lessons 0.7 to 1.8 have already described many of them as examples; the full bug-catch matrix comes in Part 14.
Class | Bugs | Count | Rules involved |
|---|---|---|---|
Corner case and boundary | 1, 3, 8, 12, 15 | 5 | R1, R3, R4, R8, R9 |
Concurrency and race | 2, 9, 11, 24 | 4 | R2, R3, R7, R10 |
Configuration and mode | 6, 7, 13, 23 | 4 | R1, R6, R8 |
Performance and fairness | 5, 10 | 2 | R6, R7 |
Error handling and specification | 4, 18 | 2 | R5, R12 |
Registers and integration | 14, 16, 19 | 3 | R9, R10 |
Reset | 17 | 1 | R11 |
Low power | 20, 21, 22 | 3 | R13 |
These are predictions, made before any run, of how likely each technique is to catch each class: high, medium or low. Write your own before reading this table; later parts measure the truth.
Class | Smoke test (0.7) | Directed tests (4.1) | Constrained random (4.10) | Assertions (5.3) | Scoreboard (5.4) | Formal (7.9) |
|---|---|---|---|---|---|---|
Corner case and boundary | low | medium | medium | medium | high | high |
Concurrency and race | low | low | high | medium | high | high |
Configuration and mode | low | medium | medium | low | medium | medium |
Performance and fairness | low | low | low | medium | low | medium |
Error handling and specification | low | high | medium | low | high | low |
Registers and integration | low | high | low | low | low | low |
Reset | medium | high | low | low | low | medium |
Low power | low | medium | low | medium | medium | medium |
Step 1 has already tested the first column: the smoke test caught one concurrency bug (BUG_2), one corner case (BUG_8) and the reset bug (BUG_17), 3 of 24, consistent with "low" everywhere and "medium" for reset.
Scoreboards catch data corruption of any cause, so they rate high for corner cases and races that corrupt packets, but low for bugs that corrupt nothing (performance, registers).
Random traffic creates simultaneous events constantly, so it rates high for races, but rarely writes registers or idles long enough to sleep.
Directed tests catch what someone listed: registers, reset values and error codes are easy to list.
Formal is strong on small control logic (FIFOs, arbiters, credit counters) and weak on registers and integration that span the design.
Performance bugs need performance checks: no technique that compares data will see them.
Practice | Purpose |
|---|---|
Class-by-technique matrix in the plan | Shows which classes have a strong technique and which have none |
Revisiting it as bugs are found | Corrects wrong assumptions early |
Escapes mapped onto it | Shows which cell failed |
A plan (illustrative) listed random simulation as the technique for "everything". Mapped onto a class matrix, its column was empty for performance, power and registers. The team added a fairness monitor, sleep-and-wake scenarios and a register test sequence; each found bugs within a week.
Performance (nothing is corrupted), registers (packets are fine, counts are wrong) and some configuration bugs that change behaviour but not data.
So the results test a hypothesis: a miss where you expected a catch reveals a weakness in the technique or your understanding, before silicon does.
DCRouter's 24 bugs span eight classes; each class favours different techniques.
Predict which technique catches each class before running anything.
Every later part measures one column of the bug-catch matrix against these predictions.