Difference between revisions of "Cache Coherence Protocols"

Revision as of 23:25, 8 July 2013

Common Notations and Data Structures

Coherence Messages

These are described in the <protocol-name>-msg.sm file for each protocol.

AccessPermissions

These are associated with each cache block and determine what operations are permitted on that block. It is closely correlated with coherence protocol states.

Data Structures

• Message Buffers:TODO
• TBE Table: TODO
• Timer Table: This maintains a map of address-based timers. For each target address, a timeout value can be associated and added to the Timer table. This data structure is used, for example, by the L1 cache controller implementation of the MOESI_CMP_directory protocol to trigger separate timeouts for cache blocks. Internally, the Timer Table uses the event queue to schedule the timeouts. The TimerTable supports a polling-based interface, isReady() to check if a timeout has occurred. Timeouts on addresses can be set using the set() method and removed using the unset() method.

Related Files:

src/mem/ruby/system/TimerTable.hh: Declares the TimerTable class

src/mem/ruby/system/TimerTable.cc: Implementation of the methods of the TimerTable class, that deals with setting addresses & timeouts, scheduling events using the event queue.

Coherence controller FSM Diagrams

• The Finite State Machines show only the stable states
• Transitions are annotated using the notation "Event list" or "Event list : Action list" or "Event list : Action list : Event list". For example, Store : GETX indicates that on a Store event, a GETX message was sent whereas GETX : Mem Read indicates that on receiving a GETX message, a memory read request was sent. Only the main triggers and actions are listed.
• Optional actions (e.g. writebacks depending on whether or not the block is dirty) are enclosed within [ ]
• In the diagrams, the transition labels are associated with the arc that cuts across the transition label or the closest arc.

Network_test

This is a dummy cache coherence protocol that is used to operate the ruby network tester. The details about running the network tester can be found here.

Related Files

• src/mem/protocols
  • Network_test-cache.sm: cache controller specification
  • Network_test-dir.sm: directory controller specification
  • Network_test-msg.sm: message type specification
  • Network_test.slicc: container file

Cache Hierarchy

This protocol assumes a 1-level cache hierarchy. The role of the cache is to simply send messages from the cpu to the appropriate directory (based on the address), in the appropriate virtual network (based on the message type). It does not track any state. Infact, no CacheMemory is created unlike other protocols. The directory receives the messages from the caches, but does not send any back. The goal of this protocol is to enable simulation/testing of just the interconnection network.

Stable States and Invariants

Cache controller

• Requests, Responses, Triggers:
  • Load, Instruction fetch, Store from the core.

The network tester (in src/cpu/testers/networktest/networktest.cc) generates packets of the type ReadReq, INST_FETCH, and WriteReq, which are converted into RubyRequestType:LD, RubyRequestType:IFETCH, and RubyRequestType:ST, respectively, by the RubyPort (in src/mem/ruby/system/RubyPort.hh/cc). These messages reach the cache controller via the Sequencer. The destination for these messages is determined by the traffic type, and embedded in the address. More details can be found here.

• Main Operation:
  • The goal of the cache is only to act as a source node in the underlying interconnection network. It does not track any states.
  • On a LD from the core:
    • it returns a hit, and
    • maps the address to a directory, and issues a message for it of type MSG, and size Control (8 bytes) in the request vnet (0).
    • Note: vnet 0 could also be made to broadcast, instead of sending a directed message to a particular directory, by uncommenting the appropriate line in the a_issueRequest action in Network_test-cache.sm
  • On a IFETCH from the core:
    • it returns a hit, and
    • maps the address to a directory, and issues a message for it of type MSG, and size Control (8 bytes) in the forward vnet (1).
  • On a ST from the core:
    • it returns a hit, and
    • maps the address to a directory, and issues a message for it of type MSG, and size Data (72 bytes) in the response vnet (2).
  • Note: request, forward and response are just used to differentiate the vnets, but do not have any physical significance in this protocol.

Directory controller

• Requests, Responses, Triggers:
  • MSG from the cores

• Main Operation:
  • The goal of the directory is only to act as a destination node in the underlying interconnection network. It does not track any states.
  • The directory simply pops its incoming queue upon receiving the message.

Other features

• • This protocol assumes only 3 vnets.
  • It should only be used when running the ruby network test.