Everyone starts with the same permission and value model. Your role changes the questions you emphasise, not the correctness rules.
The course assumes digital-design basics and the cache organisation covered in the Architecture course: lines, sets and associativity, and write policies (start at Cache Organisation if those are new). It does not assume any coherence protocol. If you have met MESI before, read Parts 1 and 2 anyway: the course separates permission, newest data and dirty responsibility more strictly than most overviews.
The lessons that carry each part's central idea, in order. Use it for a first pass or for revision; the full route fills in the cases and the races.
Part | Read these lessons |
|---|---|
1 | |
2 | SWMR Precisely, The Data-Value Invariant, MSI Protocol, MOESI and Dirty Sharing, Directory, Home and Sharers |
3 | |
4 | Racing Requests at the Home, Eviction Versus Intervention, MSHRs and Pending Entries |
5 | A Protocol Deadlock, Deadlock, Livelock, Starvation, Snoop Filter Correctness |
6 | Coherence Is Not Consistency, Litmus Tests: SB and MP, Fences Are Not Flushes |
7 | |
8 | |
9 | Inclusive, Exclusive and Non-Inclusive, Coherent Versus Non-Coherent DMA |
10 | |
11 | Check Values, Not States, Safety Versus Liveness, Race and Cross Coverage |
12 | |
13 | |
14 | Capstone Brief: read what the capstone asks, even if you do not build it yet. |
Every lesson of every part, in the order below. Each section page lists its lessons with an "After it you can..." column and a suggested order.
Part | Section | Read after |
|---|---|---|
1 | Prerequisites only | |
2 | Part 1 | |
3 | Part 2 | |
4 | Part 3 | |
5 | Part 4 (controller resources) | |
6 | Part 4 (pending work and races) | |
7 | Part 4; the metadata lessons also use Part 5's snoop filters | |
8 | Part 4; the channel-priority rules reuse Part 5's message classes | |
9 | Part 5; the completion lessons also use Part 6 | |
10 | Part 5 (message classes and progress) | |
11 | Part 4; the observation-point rule uses Part 6 | |
12 | Parts 5 and 11 | |
13 | Any parts you want to practise; each question links the lesson it tests | |
14 | Parts 2 to 5 and Part 11's reference model |
Parts 1 to 4 are strictly in order. Every later part reuses their traces, notation and race rules.
After Part 4, Parts 5 and 6 are independent of each other: read whichever your work needs first.
Parts 7 to 10 are applications and can be read in any order once their "Read after" part is done. Part 8 is the only place that uses ACE, CHI and TileLink names.
Parts 11 and 12 can come before Parts 7 to 10 for a verification focus; Part 12 leans on Part 5's deadlock classification.
Part 13 can be used at any time as practice for the parts you have finished. The capstone comes last.
Route | Exercise for every lesson | Parts to dwell on |
|---|---|---|
Design | For each transition, name the incoming event, state change, data movement, permission change and the resource it holds. | 4, 5, 7, 8, 9 and 10. |
Verification | For each snapshot, check both permissions and values. Invent a failure that one check misses. | 4, 6, 11 and 12. |
Interview | Draw an initial state, a message sequence and a final state without reading the answer. | 2, 3, 4 and 13, then the parts the bank shows you are weak in. |
After Part 2: you can explain why memory may be stale without the system being incoherent, distinguish MESI's E from M under the same exclusive(C0) entry, and explain why MOESI O is dirty responsibility but not write permission.
After Part 3: you can spot a trace that grants M before another cache has lost its read permission, and say where the newest value is between PutM and Put-Ack.
After Part 4: for any race you can say who wins at H, who waits, and which buffer protects the data.
After Part 5: you can name the held and requested resources in a hang and say whether it is deadlock, livelock, starvation or backpressure.
After Part 6: you can give SB and MP outcomes under SC, TSO, Armv8-A and RVWMO without guessing.
After Part 11: you can explain why a checker must judge values, and how you would know an assertion is not vacuous.
No. An assertion needs a specification: which event grants permission, which copy is authoritative, and what value a read may return. Otherwise it can prove the wrong abstraction. That is why the verification path still reads Parts 1 to 4 first.