MI example

From gem5
Jump to: navigation, search

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)
MI example cache FSM.jpg
  • 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
MI example dir FSM.jpg
  • 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.