Course map
- 1 lesson
Starts with How to Use This Course
- 1 lesson
Starts with Reading Path
- 1 lesson
Starts with Cache Coherency Glossary
- 1 lesson
Starts with The Shared Course Model
- 1 lesson
Starts with Cache Coherency Revision Sheet
- 8 lessons
Starts with Caches, Lines and Write-Back
- 12 lessons
Starts with SWMR Precisely
- 12 lessons
Starts with Cold Read Miss
- 8 lessons
Starts with Why Transient States Exist
- 16 lessons
Starts with A Protocol Deadlock
- 12 lessons
Starts with Coherence Is Not Consistency
- 12 lessons
Starts with True Versus False Sharing
- 12 lessons
Starts with When the Owned State Pays
- 12 lessons
Starts with Inclusive, Exclusive and Non-Inclusive
- 12 lessons
Starts with Flushing Before Power-Down
- 12 lessons
Starts with Check Values, Not States
- 12 lessons
Starts with Trace-First Debug
- 17 lessons
Starts with The Answer Framework
- 5 lessons
Starts with Capstone Brief
About this course
Why can two cores hold the same address without agreeing on its value? Start with that question, then build the permissions and messages that make shared memory work. The aim is to explain who may read, who may write, where the newest data lives, and what must finish before write permission moves, and then to carry those answers into real protocols, verification, silicon debug and design review.
Who it is for
Design engineers who build or change cache controllers, home agents, snoop filters or coherent interconnect.
Verification engineers who must decide whether a returned value is correct, not only whether a state is legal.
Architects and senior engineers who compare protocols, directory formats and LLC policies, or review a protocol change.
Candidates preparing for CPU, SoC, interconnect or verification interviews where coherence questions are standard.
You need basic digital design and the cache basics (lines, associativity, write-back and write-through) taught in the Architecture course's cache organisation topic. No prior coherence knowledge is assumed.
Start with one small system
We use C0 and C1 with private write-back caches, a home H and memory. X is one location inside a 64-byte line and starts at 0. The shared course model fixes the notation so the diagrams, tables and examples tell the same story. Later parts add a third core, finite buffers, power states or clusters only where a lesson needs them, and say so.
Show how the course is organised
Three paths
All three paths begin with Parts 1 to 4, because every later part reuses their traces and notation. They differ in what comes next.
Path | Read in this order | Emphasis |
|---|---|---|
Design engineer | 1. Why Coherence Exists, then 2. States and Protocols, then 3. Transactions, then 4. Races and Controller Design, then 5. Progress and the Fabric, then 7. Performance and Scalability, then 8. Real Protocols, then 9. SoC Integration, then 10. Power, Clocking and Reliability, then 6. Ordering and Synchronization, then 14. Capstone | Transitions, pending resources, the request < forward < response rule, directory cost, real-protocol mapping, power and RAS. Use Part 13's design-review lessons before a review. |
Verification engineer | 1. Why Coherence Exists, then 2. States and Protocols, then 3. Transactions, then 4. Races and Controller Design, then 6. Ordering and Synchronization, then 11. Verification, then 12. Debug and Bring-up, then 5. Progress and the Fabric, then 14. Capstone | Values, not states; which older observations a memory model allows; reference models, formal safety and liveness, race coverage, and trace-first silicon debug. |
Interview | 1. Why Coherence Exists, then 2. States and Protocols, then 3. Transactions, then 4. Races and Controller Design, then 13. Interview and Design Review | Learn the four-step answer framework and work the 50-question bank; follow each question's "Taught in" link back into Parts 5 to 12 where you are weak. |
What you will be able to do
State SWMR and the data-value invariant, and tell a legal state vector from a correct returned value (Parts 1 and 2).
Derive MSI, MESI and MOESI, and say who supplies data and when memory is stale (Parts 2 and 3).
Trace any read, upgrade, forward or eviction with a numbered message sequence and a state/value table (Part 3).
Resolve the classic races with transient states, MSHRs, pending entries, ack counting and credits (Part 4).
Find and break a protocol deadlock, keep a snoop filter inclusive, and state the assumptions behind a progress claim (Part 5).
Give exact SB and MP outcomes under SC, TSO, Armv8-A and RVWMO, and connect fences, acquire/release, atomics and LR/SC to the protocol (Part 6).
Count coherence traffic, find false sharing and size a directory format (Part 7).
Map the course protocol onto AMBA ACE, AMBA 5 CHI and TileLink, citing the specification revision (Part 8).
Integrate an LLC, a DMA device and a memory controller without breaking coherence (Part 9).
Take a cache out of the domain for power-down, cross clock domains safely and contain ECC errors with poison (Part 10).
Build a reference model with a golden value checker, write non-vacuous properties and plan race coverage (Part 11).
Triage stale data and hangs on silicon from a trace, and choose a verified workaround (Part 12).
Answer and grade interview questions, review a protocol change and write a design memo (Part 13).
Build a runnable three-core MESI directory model, find three planted races with the right checks, fix them and defend the result (Part 14).
Section map
Part | Section | After it you can... |
|---|---|---|
1 | Explain why private copies need permissions, and follow the newest value and dirty responsibility. | |
2 | Use SWMR and the data-value invariant, derive MSI, MESI and MOESI, and choose snoop or directory. | |
3 | Trace cold reads, upgrades, forwarding and notified evictions without losing the newest value. | |
4 | Say who wins, who waits and where the data is safe in each race, and map obligations to controller resources. | |
5 | Separate deadlock, livelock, starvation and backpressure; filter snoops safely; reason about hierarchies. | |
6 | Separate coherence from consistency and decide litmus outcomes under a named model. | |
7 | Count traffic, fix false sharing, cost directory formats and place homes. | |
8 | Choose MESI, MOESI or MESIF, and read ACE, CHI and TileLink against the course model. | |
9 | Pick an LLC inclusion policy, connect devices and DMA, and keep same-address order below the home. | |
10 | Power a cache down, cross clocks and recover from metadata errors without breaking the invariants. | |
11 | Check values with a reference model, prove SWMR on a small model and close race coverage. | |
12 | Rebuild a failing transaction from a trace and keep a known bug contained after tape-out. | |
13 | Answer with assumption, mechanism, trade-off and evidence; review designs and manage coherence risk. | |
14 | Show one piece of work: a model, failing traces, fixes, a MESI versus MOESI comparison and a memo. |
What to produce as you read
A state/value table that includes both caches, H and memory, not just a list of state letters.
A numbered message sequence with the same events and values as the table.
An explanation of the permission rule and the data-value rule for that example.
An answer to each check-yourself before opening its explanation.
From Part 4 on, for every race: who wins at H, who waits, and where the newest value sits meanwhile.
Time and scope
Allow about 35 hours to read the course, and about 60 with the examples, exercises and the capstone (the capstone alone is about 7 to 9 hours if you write your own model). These are estimates, not measurements. The course develops engineering reasoning; a small educational model does not certify an industrial coherence implementation.
Check yourself Why do we study permissions before tuning coherence traffic?
Reducing traffic is useful only if the new design preserves who may read or write and which value a read may return. A faster but incorrect permission handoff is still incorrect.