Cache Coherency CHI vs MOESI
-Aviral Mittal (avimit att yhaoo dat cam)

Connect @

This techrature maps 1:1 the MOESI stat to ARM CHI States. It also expalin how some of the names in here are confusing. It also explains how MOESI allows sharing of  'Dirty' Data.
Assumption: This techrature assumes that the cache-coherency is maintained using 'Cache-Directory' Method and Cache-Coherency is Write-Invalidate protocol (as opposed to Write-Update)

The following table gives the CHI eq State names for MOESI State names.

M(Modified) UD (Unique Dirty)
O(OWNED) SD (Shared Dirty)
E(Exclusive) UC (Unique Clean)
S(Shared) SC (Shared Clean)
I(Invalid) I(Invalid)

O(Owned) state which maps to Shared Dirty sounds like Owned? Let us see:
Shared Dirty (SD) by it name sounds like it does not sound like "Owned". Well while it may not sound intuitive, it still makes sense, because Shared State is a state where a cache line may exist in more than one cache, but ONLY 1 cache has a responsibility of writing it to memory, and this cache is the Owner of this line, even though this line is shared among more caches.

The other state which causes confusion by its name is the ARM CHI state called Shared Clean (SC). A Shared Clean state may not be technically 'clean'. It may NOT have same data as the Main memory.
The line in Shared Clean state can be modified (Dirty) with respect to Main memory OR it may have same data (Clean) as main Memory. How? just keep on reading.

Q. How does a line ends up in a Shared Clean (SC) State or Shared Dirty State (SD)? What is the meaning of Sharing of 'Dirty' Data. How does MOESI protocol support Sharing of Dirty Data?
If you have any of the above questions in your mind, here is your answer:

Consider 2 Request Nodes RN0 and RN1 Both have a cache line at 'I' state which is the reset state.

RN0 issues a ReadUnique Command. Its a Cache Miss at RN0, and say this line is not present in any of the other caches, then the data comes from the Main Memory and the Cache line is installed in RN0 Cache as UC.
I -> ReadUnique -> UC.

Now, RN1 issues a ReadShared Command for the same CacheLine. This line is present in RN0, RN0 gets snopped by command SnpSharedFwd and it supplies data to RN1.  RN1 gets the line with response CompData_SC. Now RN1 has it in SC and RN0 also has the line in SC. Both End up in SC. And both as the same data as main memory (Clean).

However, if before RN1 issued ReadShared, RN0 modifies the line, then the cache state an RN0 will go from UC to UD. Note now the data is modified w.r.t Main Memory and it is 'Dirty'.
Now RN1 issues ReadShared, then again this cache line is present in RN0, so RN0 gets Snooped it receives SnpSharedFwd command, and it supplies the Dirty data to RN1. Now RN0 goes from Unique Dirty (UD) to Shared Clean (SC). RN1 on the other hand receives data with response CompData_SD_PD, which means install the cache line in SD state, and pass the 'Dirty' responsibility to RN1.

Now RN0 ends up in Shared Clean (SC) state, and RN1 ends up in Shared Dirty (SD) state. Both have same data, but the data is modified w.r.t main memory. Its 'Dirty' not 'Clean'.

Conclusion: This is how SC state at any node may hold the 'Clean' and 'Dirty' data both (though at different times). This is what it means when ARM defines SC state as The cache line 'might' have been modified w.r.t Main memory. And this is how MOESI allows sharing of 'Dirty' data. As it can be observed, that now the Dirty data is present in RN0 and RN1 both but only 1 RN will ever have the responsibility to write it back to Main Memory, and currently this responsibility lies with RN1. If another Cache say RN2 issues 'ReadShared' while it was in 'I' for same line, then RN2 will end up in 'SD' while RN0 and RN1 both will be in 'SC'. Now RN0, RN1 and RN2, all are sharing 'Dirty' data, and RN2 now has the responsibility of updating the Main Memory.

Further to above, now if RN2 decides to write the data to Main Memory, it may use 'WriteBackFull' or 'WriteCleanFull'. With The former, the Cache Line state at RN2 will end up 'I', with the later, it will retain a copy so the Cache state at RN2 will be 'SC'.

Let us assume that RN2 did issue WriteCleanFull, so that it still has copy in SC state. After all this, say if RN3 issues a ReadUnique to same Cache line, then it may get its data from RN0, RN1 or RN2 (Implementation Dependent, say for now RN0), as all of these now have this cache line in SC state., with a response of ComopData_UD_PD. At RN3 the cache line will go from 'I' to UD, at RN0, RN1 and RN2, the line will go to 'I'. RN0 will receive SnpUniqueFwd, while RN1 and RN2 will get some snoop command to make the data Invalid. SnpMakeInvalid would do.
State Change Diagram at RN0. For all the above state changes, following is the State Change diagram of the Cache Line in question:


State Change Diagram for RN0 Cache.