Introduction to Cache Coherency

In the world of multi-core processors, caches play an important role in speeding up data access. However, with multiple cores accessing and modifying data simultaneously, how do we ensure that all cores see a consistent view of the memory?

Cache coherency refers to the mechanism that ensures data consistency across multiple caches in a system. When one core updates some data in its cache, other cores must either see that update or invalidate their own outdated copies. Without cache coherency, programs running on multi-core systems could produce unpredictable results, leading to bugs that are hard to debug.

In this blog, we’ll explore the basics of cache coherency, its implementation in systems, and the support RISC-V provides.

How Cache Coherency Works in Systems

In a multi-core system, each core has its own L1 cache to store frequently accessed data from the main memory. Since multiple cores share the same memory, they typically tend to cache the same data. If one core modifies its cached copy, the other cores’ copies become stale, leading to inconsistency.

To solve this, systems use cache coherency protocols such as MESI, MOESI etc. Each of these acronyms stands for different states the caches go through:

• Modified: The cache line has been updated and differs from main memory; no other cache has a valid copy.
• Owned: The cache line is modified and shared among multiple caches, with one cache acting as the owner.
• Exclusive: The cache line matches main memory, and no other cache has it.
• Shared: The cache line matches main memory and may exist in other caches.
• Invalid: The cache line is outdated and cannot be used.

When a core writes to a cache line, the protocol ensures that other caches either update their copies or mark them as invalid. This communication often happens over a coherency interconnect. This interconnect lets caches snoop each other’s activity and take action accordingly.

Cache Coherency in RISC-V

RISC-V is an open-source instruction set architecture (ISA) and is freely available for anyone to use, modify, and distribute. The base RISC-V ISA doesn’t mandate a specific cache coherency scheme. Instead, it leaves the implementation details to the hardware designers. This flexibility allows customization but requires system architects to define how coherency is achieved. However, RISC-V does provide some building blocks to support cache coherency:

1. Memory Model: RISC-V defines a weak memory ordering model by default. For coherency, the architecture offers the Zifencei extension (fence instructions) to enforce ordering. The FENCE instruction ensures that memory operations before it complete before those after it, which is crucial for synchronizing cache updates across cores.
2. Atomic Instructions: The A extension (Atomic) adds instructions like LR (load-reserved) and SC (store-conditional) for atomic memory operations. These are essential for implementing locks and semaphores, which higher-level coherency mechanisms often rely on.
3. Cache Management Instructions: While the base ISA doesn’t include cache-specific instructions, the Zicbom (Cache Block Operations Management) extension, introduced in recent specifications, provides instructions like CBO.INVAL, CBO.CLEAN, and CBO.FLUSH. These allow software to manage cache lines explicitly—invalidating, cleaning, or flushing them as needed to maintain coherency in systems without hardware-managed coherence.

In practice, a RISC-V system might implement hardware-managed coherency, where the caches and interconnect handle everything transparently, or software-managed coherency, where the operating system or application uses CBO instructions to keep caches in sync. Verification of cache coherence on a system requires the stressing of the system through multiple scenarios, which can lead to incoherency. A few of these scenarios are enumerated below:

• Invalidation – When a cache line is modified by one core in a multi-core system, the rest of the cores that have cached it should mark the address as invalid and force a load from the main memory.
• True sharing – True sharing is a scenario in which the same address location in a cache line is accessed by multiple cores. This can be a write or read access. In these scenarios, the cache coherence mechanism must ensure that the modified data is propagated to the main memory and the stale copies of the cache are invalidated.
• False sharing– False sharing is a scenario in which different address locations in the same cache line is accessed by multiple cores. This can cause performance degradation due to the cache line marked as invalid and the cores requiring to load the data from main memory even without a real necessity to do so.

In conclusion, cache coherency is critical for ensuring data consistency and system stability in multi-core architectures. While RISC-V provides the tools and flexibility to implement coherence, it also places the onus on designers to choose the right strategy—hardware- or software-managed—based on their system needs.

Whether you’re building or verifying such a system, understanding these fundamentals is key.

Have questions or insights to share? Write to us at sales@vayavyalabs.com—we’d love to hear from you!