MI example

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

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.