Parts 1 to 7 used one generic protocol on purpose: GetS, GetM, Fwd-GetS, Fwd-GetM, Inv, Inv-Ack, Data, the Put messages and Put-Ack. Real interfaces use their own names, add states the course did not need, and make different choices about where data comes from and how completion is signalled. This part maps each of them back onto the course model, so you can read a specification by asking the same questions the earlier parts asked: who serializes the line, who may supply data, when memory is stale, and which message tells the home that a transaction is complete.
Lesson | After it you can... |
|---|---|
Count the memory writes O saves and the duties it adds. | |
Explain how one clean sharer answers reads instead of memory. | |
Run one trace under MSI, MESI and MOESI and compare the counts. | |
Pick a state set from the sharing pattern and costs. | |
Map ACE channels, states and transactions to the generic protocol. | |
Name CHI node types and why its four channels are separate. | |
Follow CHI reads, upgrades and writebacks against course traces. | |
Translate between course, ACE and CHI state names. | |
Relate TileLink channels and permissions to course states. | |
Map Acquire, Probe and Release flows to course messages. | |
Evaluate a protocol extension before adopting it. | |
Compare the generic model, ACE, CHI and TileLink side by side. |
Specification details are cited by document and revision in each lesson: AMBA AXI and ACE (Arm IHI 0022, Issue H.c), AMBA 5 CHI (Arm IHI 0050, Issue E.a) and the SiFive TileLink specification (version 1.8.1). The lessons map each interface onto the course model and do not describe any particular implementation.
All of them. Find the serialization point for a line (the home, whatever its name), which agents may supply data and when memory is stale, which message ends the requester's transaction, and which message tells the home it may start the next conflicting transaction. The names change; the questions do not.