Lesson 11.4's silicon corruption was the router sleeping with an output locked. The fix is decided (lesson 11.6). The job is not finished. The more important question for the team is why every simulation, emulation run and review let it through. A bug fixed without that question is a bug whose cousins are still in the design, and whose next relative will escape the next project too.
What do you do after an escape?
The obvious response is to fix the bug, add a test that reproduces it, and move on. The regression test stops this exact bug from returning. It does nothing about the reason it escaped: a missing check, an unreached state, a stimulus that never paused mid-packet, a rule nobody wrote down. Those reasons produced this escape and will produce others.
Gap (lesson 3.3) | Meaning | Typical fix |
|---|---|---|
Unreached (activation) | No stimulus ever created the triggering state | New scenario or bias; coverage bin on the trigger (Part 6) |
Masked (propagation) | The state occurred but the wrong value never reached a check | Internal or interface assertion close to the cause |
Unchecked (detection) | The wrong value was visible, but no check compared it | New checker, scoreboard rule or property (Part 5, Part 7) |
Unspecified | The behaviour was never a rule | Specification update, then all of the above |
Step | Action |
|---|---|
Classify | Unreached and unchecked: no test paused a source mid-packet long enough to sleep, and no assertion said "never sleep while locked" |
Test | A directed test: send half a packet, pause 20 cycles, finish the packet; check it arrives intact |
Check | The R13 assertion "never asleep mid-packet" (lesson 5.3's a_r13_no_lock) |
Coverage | A bin for "source paused longer than the idle threshold mid-packet" |
Sweep | Every block with an idle or power-down detector: does it account for transactions in flight? |
Plan and process | Add "power entry with work in flight" to the standard interaction features for every block (lesson 9.2) |
This course built exactly these artefacts for BUG_20 in Parts 4 and 5, which is why its testbenches catch it. Closing the loop is how real teams turn an escape into that kind of protection.
Bugs come in classes: the same misunderstanding usually appears in more than one place (lesson 1.1).
The sweep finds the cousins before they escape: other idle detectors, other counters cleared by writes, other ports with enables.
The plan change protects future projects: the class becomes a standard feature, check or coverage item.
Escape metrics (escapes per project, by class and by gap) measure whether the verification process is improving (Part 12).
Practice | Purpose |
|---|---|
Escape reviews for every bug found after sign-off | Each escape classified and acted on |
Escape databases by class and gap | Patterns across projects visible |
Standard checklists updated from escapes | Plans start with past lessons built in |
Bug seeding of past escape classes | Testbenches checked against bugs that have escaped before |
A team (illustrative) fixed each silicon bug with a patch and a regression test, project after project. Their escape list showed the same class, a counter cleared by a write while also incrementing, in three consecutive chips, in three different blocks. Nobody had swept for the class or added it to the plan template. One escape review, one assertion pattern and one checklist line would have ended the series.
It prevents this exact bug from returning but not its cousins; the gap that let it escape (a missing check, an unreached state) remains.
Checking every block with an idle or power-down detector for whether it accounts for transactions in flight.
An escape measures the verification process: classify which gap let it through.
Add a test, the missing check or coverage, and sweep for the same class elsewhere.
Change the plan and process so the same escape never happens twice.