A coherence testbench has to answer one question after every load: was that value allowed? This topic builds the answer in four steps: the specification a checker compares against, a runnable reference model of the course protocol with a golden-memory checker, three injected bugs the checker must catch, and the scoreboard that carries the same checks into a real testbench. The Python model in the second lesson is the course's central executable model: the course protocol and its invariants in a form you can run.
Lesson | After it you can... |
|---|---|
Write the per-location specification a load is checked against, and show a run whose states all look legal but whose load is wrong. | |
Build and run an MSI model with a home directory, unordered delivery and a checker that asserts SWMR and every value after every event. | |
Inject three classic protocol bugs, show each one is caught, and explain why some need a particular interleaving. | |
Place monitors, a write-order tracker, a value checker, protocol checkers and end-of-test checks in a real testbench. |
Read in order. You need the data-value invariant, the MSI protocol and the race lessons of Part 4. The general testbench ideas (what a scoreboard is, how deep a reference model should go) are taught in the First Principles of Verification Strategy course and linked from each lesson; this topic applies them to coherence.
No. Both checks look at labels. A design can keep every label legal and still hand a reader an old value, for example by sending the wrong buffer's data with a correct S grant. The sign-off check is the value every load returns, compared against the write order of that location.