gem5 documentation
Development
Building
Using KVM
Doxygen
gem5 APIs
Full System
Checkpoints
Directed Testers
Debugging
Architecture Support
Power and Thermal Model
Compiling Workloads
Stats Package
Stats API
Develop Branch
v19.0.0.0
v20.0.0.0
v20.0.0.2
v20.0.0.3
v20.1.0.0
v20.1.0.1
v20.1.0.5
v21.0.0.0
v21.0.1.0
v21.1.0.0
v21.1.0.1
v21.1.0.2
v21.2.0.0
v21.2.1.0
v21.2.1.1
v22.0.0.0
v22.0.0.1
v22.1.0.0
v23.0.0.0
v23.0.0.1
gem5 standard library
Standard Library Overview
Hello World Tutorial
X86 Full-System Tutorial
Developing Your Own Components Tutorial
How To Create Your Own Board Using The gem5 Standard Library
How to use local resources and data sources in gem5
gem5 Resources
Creating Disk Images
Devices
m5term
Building Linux ARM Kernel
Building Android Marshmallow
Guest binaries
Memory System
Memory System
gem5 Memory System
Replacement Policies
Indexing Policies
Classic memory system coherence
Classic caches
Ruby Memory System
Ruby
Cache Coherence Protocols
Garnet 2.0
HeteroGarnet
MOESI CMP directory
Garnet Synthetic Traffic
SLICC
MI example
Garnet standalone
Interconnection network
MOESI hammer
MOESI CMP token
MESI two level
CHI
Replacement Policies
CPU Models
GPU Models
M5ops
authors: Jason Lowe-Power
last edited: 2024-11-05 22:13:18 +0000
last edited: 2024-11-05 22:13:18 +0000
MI Example
Protocol Overview
- This is a simple cache coherence protocol that is used to illustrate protocol specification using SLICC.
- This protocol assumes a 1-level cache hierarchy. The cache is private to each node. The caches are kept coherent by a directory controller. Since the hierarchy is only 1-level, there is no inclusion/exclusion requirement.
- This protocol does not differentiate between loads and stores.
- This protocol cannot implement the semantics of LL/SC instructions, because external GETS requests that hit a block within a LL/SC sequence steal exclusive permissions, thus causing the SC instruction to fail.
Related Files
- src/mem/protocols
- MI_example-cache.sm: cache controller specification
- MI_example-dir.sm: directory controller specification
- MI_example-dma.sm: dma controller specification
- MI_example-msg.sm: message type specification
- MI_example.slicc: container file
Stable States and Invariants
States | Invariants |
---|---|
M | The cache block has been accessed (read/written) by this node. No other node holds a copy of the cache block |
I | The cache block at this node is invalid |
The notation used in the controller FSM diagrams is described here.
Cache controller
- Requests, Responses, Triggers:
- Load, Instruction fetch, Store from the core
- Replacement from self
- Data from the directory controller
- Forwarded request (intervention) from the directory controller
- Writeback acknowledgement from the directory controller
- Invalidations from directory controller (on dma activity)
- Main Operation:
- On a load/Instruction fetch/Store request from the core:
- it checks whether the corresponding block is present in the M state. If so, it returns a hit
- otherwise, if in I state, it initiates a GETX request from the directory controller
- On a replacement trigger from self:
- it evicts the block, issues a writeback request to the directory controller
- it waits for acknowledgement from the directory controller (to prevent races)
- On a forwarded request from the directory controller:
- This means that the block was in M state at this node when the request was generated by some other node
- It sends the block directly to the requesting node (cache-to-cache transfer)
- It evicts the block from this node
- Invalidations are similar to replacements
- On a load/Instruction fetch/Store request from the core:
Directory controller
- Requests, Responses, Triggers:
- GETX from the cores, Forwarded GETX to the cores
- Data from memory, Data to the cores
- Writeback requests from the cores, Writeback acknowledgements to the cores
- DMA read, write requests from the DMA controllers
- Main Operation:
- The directory maintains track of which core has a block in the M state. It designates this core as owner of the block.
- On a GETX request from a core:
- If the block is not present, a memory fetch request is initiated
- If the block is already present, then it means the request
is generated from some other core
- In this case, a forwarded request is sent to the original owner
- Ownership of the block is transferred to the requestor
- On a writeback request from a core:
- If the core is owner, the data is written to memory and acknowledgement is sent back to the core
- If the core is not owner, a NACK is sent back
- This can happen in a race condition
- The core evicted the block while a forwarded request some other core was on the way and the directory has already changed ownership for the core
- The evicting core holds the data till the forwarded request arrives
- On DMA accesses (read/write)
- Invalidation is sent to the owner node (if any). Otherwise data is fetched from memory.
- This ensures that the most recent data is available.
Other features
- MI protocols don’t support LL/SC semantics. A load from a remote core will invalidate the cache block.
- This protocol has no timeout mechanisms.