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.
MOESI State
ARM (AMBA) CHI State
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:
