The capstone turns the course into one piece of work you can show. You write a runnable model of a three-core MESI directory protocol on the course model, with a checker that judges every value after every event. Then you switch on three planted defects, the kinds of race that reach silicon, and find each with the right check: a lost invalidation and a stale writeback by the value checker, a buffer deadlock by a progress check. You fix them, measure what MOESI would change on the same trace, and write the memo a design review would ask for.
Lesson | After it you can... | Time (estimate) |
|---|---|---|
State the system, the deliverables and how they are graded. | 30 minutes | |
Run a MESI directory model with a golden checker and show the races occur. | 2 to 3 hours | |
Find each planted defect with the right check and reduce it to a trace. | 2 hours | |
Restore the broken rules, prove the fix, and compare MESI and MOESI traffic. | 1 to 2 hours | |
Write a two-page memo with a recommendation, risks and a verification plan. | 1 to 2 hours |
About 7 to 9 hours in total if you write your own model; about 2 hours to read and run the worked solution. The estimates are a guide, not a measurement.
The course model and its notation.
SWMR and the data-value invariant (Part 2), upgrades, forwarding and writebacks (Part 3), races and controller resources (Part 4), deadlock and message classes (Part 5).
The Part 11 reference model, which this one extends. Python 3 with the standard library only.
Because the point is to prove each check can fire on the bug class it exists for. If the lost invalidation were only ever caught by an end-of-run check, nobody would know whether the per-event value checker works; if the deadlock were only caught by a timeout, the progress check would be unproven. Matching each bug to its intended check measures the testbench, not just the design.