1. MOESI State Definitions

The ARMv8 architecture uses the MOESI protocol to maintain data consistency across multiple cores. The MOESI protocol describes the state of a shared cache line in L1 Data Cache as follows:

• M, Modified, Unique Dirty, only exists in the current cache (unique) and the data in this cache line is different from that in the next level of storage (dirty). In other words, the latest data in the cache line is located in the current cache, and there are no backups in other caches, making the content of the cache line inconsistent with the main memory.
• O, Owned, Shared Dirty, describes a cache line as dirty and may exist in multiple caches (more than one). An Owned state cache line holds the latest and correct data. Only one core’s cache can keep the data in the Owned state, while other cores are in the shared state.
• E, Exclusive, Unique Clean, the data only exists in the current cache line and is clean. The data in the cache line is consistent with the main memory, and there is no backup of this address in the caches of other cores, existing in only one cache.
• S, Shared, Shared, the data in the cache line may not necessarily be consistent with the main memory, corresponding to the Owned state cache line, where the data from Owned is copied to the shared cache line, thus the data in the shared cache line is also the latest.
• I, Invalid, invalid data.

The Data Cache Unit (DCU) will store the MOESI state information of the cache line in tag RAM and dirty RAM.

2. MOESI State Transitions

The following diagram illustrates the state transition of the MOESI protocol.

Next, this article will explain specific MOESI state transitions using a state transition use case.

2.1 Invalid after Reset

Assuming there are four cores in the current system, each with its own independent data cache. After powering on the system, all cores’ cache lines are in the invalid state:

2.2 Invalid => Exclusive

Then core0 attempts to read data from memory at address 0x44013F00, and the state of the cache line related to this address in core0’s cache will change from Invalid to VE, where V stands for Valid, indicating that the data in this cache line is valid. E stands for Exclusive, indicating that this data exists only in core0.

2.3 Exclusive => Modified

Then, core0 attempts to write a new value to this address, and the state of the cache line will change from VE to VDM, where V is valid, D is Dirty, indicating that the data is dirty, and the data in the current cache line is inconsistent with that in the main memory. M stands for Modified, indicating that the data in this cache line is Unique and Dirty.

2.4.1 Modified => Owned, Invalid => Shared

Next, when core1, core2, and core3 attempt to read from this address, the state of core0 will change from VDM to VDO, while the cache lines of the other three cores will change from Invalid to VS, where O indicates Owned, and S indicates Shared. The Owned and Shared states are corresponding. Additionally, from the following diagram, it can be seen that the data read by core1, core2, and core3 is a backup from core0’s cache, not the actual value in memory.

2.4.2 Modified => Invalid, Invalid => Modified

If core1 writes a new value, and the data in core0 is not written back to DDR, data corruption occurs, and the previously saved data in core0 disappears, changing the state of the cache line to invalid. Meanwhile, core1’s state will change from Invalid to Modified, which is also dirty.

2.5 Owned => Invalid, Shared => Invalid, Shared => Modified

Following the steps of 4.1, if core1 attempts to write a new value to this address, core0’s state will change from Owned to Invalid, while the cache lines in core2 and core3 will change from Shared to Invalid, and core1’s state will change from Shared to Modified (VDM). Additionally, since a write-back strategy is used, the current write operation only writes to the cache, and the content in the main memory remains unchanged.

In this example, two cores sequentially read and write to the same memory address. The value written by core0 (blue) was not written back to the main memory, and then core1 wrote a new value (green) to this address, overwriting the value written by core0.

2.6 Clean and Invalidate Operations’ Impact on MOESI States

2.6.1 Clean & Invalidate on Owned State

As shown in the figure below, the relevant cache line of core0 was previously in VDO state. After performing clean & invalidate operations, core0’s state changes to Invalid, while the states of the other three cores remain VS, and the data in core0’s cache has been written back to the main memory.

2.6.2 Clean & Invalidate on Shared State

As shown in the figure below, the relevant cache line of core1 was previously in VS state. After performing clean & invalidate operations, core1’s state changes to Invalid, while the states of the other two cores remain VS, and the data in core1’s cache has been written back to the main memory. However, core0’s relevant cache line remains in VDO state. At this point, the data in the main memory and the data in the cache are synchronized, but core0’s cache line is still in dirty state due to the fact that the Clean & Invalidate operation is performed actively by software, interfering with the normal synchronization process of data at the hardware level.

3. Considerations

Maintaining data consistency at the hardware level requires enabling the CPU Extended Control Register’s SMPEN bit, which provides additional processor configuration and control options. The SMPEN bit:

CPUECTLR[6]: SMPEN, enables hardware management of data consistency across multiple cores in the current cluster. When set to 0, it disables the data consistency maintenance function across multiple cores, which is also the reset value. When set to 1, it enables data consistency functionality. Therefore, even in a system with only one core, it is recommended to set SMPEN to 1 before enabling the cache; otherwise, the data in the cache will not be synchronized with other cores, which may lead to data corruption.

Reference Article: DDI0500J_cortex_a53_trm.pdf 

This article is transferred from CSDN, author: SOC Luo Sanpao, the article has obtained the original author’sauthorization