Every lesson in this course has used DCRouter, whose bugs were planted and whose answers were known. Real escapes are different: the full story is rarely public, the people involved know far more than they can say, and retellings drift into legend. This part reads three well-documented public escapes. To learn from them, we need a disciplined way to read.
How should you read a public escape so that it teaches something true?
The obvious way is to read the story and draw the moral: "they should have tested more". That moral fits every escape and teaches nothing. Worse, popular retellings often add details nobody documented (who knew what, which test was skipped), and a lesson drawn from an invented detail is an invented lesson. Reading well means asking specific questions and keeping track of which answers are documented and which are inference.
Question | What to look for | Course link |
|---|---|---|
What failed? | The observable failure, its trigger and its scope | Part 1: the bug class |
Where could it have been caught? | Which technique's pool contains this bug: specification, stimulus, checking, coverage, formal, validation, margins | Parts 2-11 |
Why was it not caught? | Unreached, masked, unchecked or unspecified; or outside what pre-silicon verification models | Lesson 3.3 and 11.7 |
What changed afterwards? | Fixes, process changes, new methods in the industry | Part 12: the cost of finding it late |
For each answer, mark whether it is documented (in a public statement, paper or contemporary report, listed in the course's fact sheet) or inference (the course's reading of what the documented facts imply). Both are useful; confusing them is how myths start.
Only publicly documented facts, each with a source in the fact sheet (facts C1-C7).
No invented internal stories: no claims about who decided what, or which test was skipped, unless documented.
Inference labelled as inference: "the course's reading" marks it.
No blame: every team that shipped these chips had capable engineers and serious verification; the question is what kind of bug got through, not who failed.
Case | What failed (documented) | Kind of escape (the course's reading) |
|---|---|---|
Pentium FDIV (1994) | Missing entries in a division lookup table gave rare wrong quotients (facts C1, C4) | Functional, rarely triggered, in a small fully specified structure that could be checked exhaustively |
Cougar Point SATA (2011) | A transistor overstressed by its bias voltage could degrade SATA ports over time (facts C2, C5) | Electrical and reliability, outside what functional RTL verification models |
Spectre and Meltdown (2018) | Speculative execution left secret-dependent traces in the cache (facts C3, C6) | Every result correct; a security property nobody had stated |
Three escapes, three different gaps: a check that was not exhaustive where it could have been, a margin that functional verification cannot see, and a property that was not in anyone's specification. That spread is itself the lesson: no single technique would have caught all three.
Practice | Purpose |
|---|---|
Reading published errata and post-mortems in the same domain | Learn the bug classes that escape similar designs |
Adding each class to the plan's checklist of interaction features | The lesson outlives the people who read it |
Asking "which of our checks would have caught this?" | Tests the plan against a real failure |
A team (illustrative) circulated a retelling of a famous escape that blamed a skipped regression. The detail was not in any public source. The team added more regression runs, which addressed nothing in its own risk, while its real gap, an unchecked class of configuration, stayed open. The documented facts would have pointed at a different lesson.
It fits every escape and says nothing about which technique, check or property was missing.
A documented fact comes from a public statement, paper or contemporary report; an inference is the reader's interpretation of what those facts imply, and must be labelled as such.
Read every escape with four questions: what, where, why not, what changed.
Keep documented facts and inference apart; never invent internal details.
Turn each escape into: which of our checks would catch this kind of bug?