Cache Coherency

Overview

In the provided evidence, cache coherency appears in several related roles:

1. a microarchitectural function associated with multiprocessor systems and complex external interfaces,
2. a system-integration feature for heterogeneous CPU-FPGA platforms,
3. a target for SoC functional-coverage closure, exercised alongside stashing, snoopable transactions, and read-sharing patterns between cores and IO masters,
4. a hardware-security property of instruction-cache coherence in RISC-V processors, where mishandling it can lead to exploitable behavior from unprivileged software, and
5. a commercial verification target addressed by automated test-suite synthesis tooling such as Breker's Cache Coherency TrekApp 2.0 and its RV64 MultiCore MoesiStates test set, which generates planned cache-state transitions and stress patterns for RISC-V multicore designs. [1][2][3][4][5][6][7]

Cache coherency in multiprocessor microprocessors

Verification literature treats cache coherency as part of a broader microarchitectural concern: high-performance microprocessors use complex external interfaces that buffer requests, allow multiple outstanding loads and stores, maintain multi-level caches, and perform cache coherency in multiprocessor configurations. The combination of many interface states and asynchronous events from other devices makes this area especially challenging to verify.

Multiprocessor validation work is described in terms of code-generation tools targeting multiprocessor behavior. MPVer is presented as a multiprocessor verifier that targets the sharing of information across the processors of an MP system and the communication between processors. Multiprocessor verification is tied to testing cache coherency protocols alongside other multiprocessor primitives.

Sharing patterns relevant to coherency stress testing include:

• False sharing, which can be exploited to increase processor interaction and exercise cache-coherency mechanisms without relying heavily on expensive locking and synchronization.
• True data sharing, which uses locks and whose results are checked only after the relevant multiprocessor operations are guaranteed to have completed.

A separate concern is traffic diversity: the multiprocessor verifier is parameterized by how frequently each CPU accesses different memory segments so that different traffic patterns can be programmed to stress routing algorithms and observe multiprocessor-system stability. [1]

Verification tools connected to cache coherency

The evidence links several verification tools to cache coherency:

SBVer

SBVer is described as a code generator that focuses on exercising the external interface and cache management units of a microprocessor. Because that external interface performs cache coherency in multiprocessor configurations, SBVer is directly relevant to coherency-oriented verification. [1]

MPVer

MPVer is presented as a multiprocessor verifier that targets the sharing of information across processors and communication between processors. The cited work states that multiprocessor verification requires testing cache coherency protocols, and that MPVer generates interacting code streams to verify such behavior with fine granularity. It can run on either a simulation model or a true multiprocessor system. [1]

Cache coherency and stashing in SoC functional-coverage closure

The SoC bug-hunting methodology presented in the embedded.com source treats cache coherency as a first-class verification scenario. Among the randomized scenarios used to drive full functional coverage closure, the source identifies:

• Scenario #5 – Cache coherency and stashing. The source defines stashing as a behavior in which data is placed in the L1/L2 cache at the same time it is sent to memory. L2 registers are configured for stashing, the core executes in non-sharing mode, and IO masters stash data in the L2 cache in a randomized fashion for snoopable transactions while the core continues its own execution. The final check observes whether the core fails for overridden addresses, and any failed patterns are qualified against an expected stashed array. [2]
• Read sharing between cores. Each master is the primary master for a memory block and has full read/write access to that block; other masters may be allowed to read the block but only the primary master can write to it. Blocks are divided on cache-line boundaries so that a cache line is never in more than one memory block. [2]
• Read sharing between core and IO masters. The IO masters issue snoopable reads from the core's read-write memory block. The testbench maintains an expected data array that is updated on a snoop push. [2]

The same source also describes complementary randomization strategies that interact with coherency traffic:

• AXI transaction IDs are randomized across all masters so that unordered transactions are thrown to different slaves concurrently, and the test checks that the appropriate BID/RID is reflected by the slave.
• Ordered transactions are used to verify that masters and slaves without AXI transaction IDs still process transactions in the order they are issued.
• Back-to-back transactions from the IP blocks are sent with randomized delays between transactions from every master, both to check successful completion and to verify minimum and maximum latency against architecture-team expectations. [2]

This places cache coherency inside a verification methodology that explicitly couples coherency, stashing, and read-sharing behavior with AXI-level traffic randomization, latency validation, and CSR/random regression.

Cache coherency in CPU-FPGA and SoC-FPGA systems

The public context extends cache coherency beyond conventional multiprocessor CPUs.

One source states that, unlike other accelerators, FPGAs are capable of supporting cache coherency, making them more than peripheral accelerators. It also notes that many existing FPGA deployments are either non-cache-coherent or only support an asymmetric model in which the CPU controls coherency. The ECI work is presented as an FPGA-side cache-coherency stack that supports both symmetric and asymmetric protocols and exposes the protocol more openly to applications. [3]

A second FPGA source says modern heterogeneous SoC-FPGA platforms support multiple I/O cache coherence options between CPUs and FPGAs, but that these options can affect achieved bandwidth differently depending on the application and data-access pattern. According to that source, understanding transaction behavior and selecting the appropriate I/O cache-coherence method is important for efficient CPU-accelerator communication; its reported software and hardware modifications improved overall performance by an average of 20%. [4]

Cache coherency as a hardware-security concern in RISC-V processors

Newer evidence from processor-fuzzing work treats cache coherency as a correctness and security property of the processor itself, not just of the multiprocessor system. The RISC-V FENCE.I instruction is described as enforcing cache coherence in the processor by flushing the instruction cache and instruction pipeline, and as ensuring that the correct instruction memory is used when performing memory-sensitive operations such as updating instruction memory. [5]

The fuzzing source documents concrete defects tied to instruction-cache coherence:

• Bug B1 (Ariane): The decoder does not ignore the imm and rs1 fields of a FENCE.I instruction as the RISC-V specification requires, and instead expects them to be zero, causing valid FENCE.I encodings to be flagged as illegal. The source notes this mismatch could have been avoided if the RISC-V specification or the Ariane processor detected violations of cache coherency in hardware. [5]
• Bug B4 (Ariane): When the instruction memory is modified, software is required to handle cache coherency with FENCE.I; failure to do so results in undefined behavior in which the processor may use stale data and execute incorrect instructions. The fuzzer detected this as a mismatch between the Ariane trace and the spike golden reference when the generated program modified instruction memory without using FENCE.I. [5]
• CWE classification: The source classifies cache-coherency mishandling of this kind as a memory and storage vulnerability under CWE-1202. [5]

The source also describes an exploit (Section 6.3.1) that leverages Bugs B1 and B4 to cause incoherence in the instruction cache. Using a contrived "safe" just-in-time (JIT) compiler, an attacker can load a region of executable code into the cache, overwrite that region with new instructions, and then execute code that jumps to cache lines the attacker wishes to invalidate. The exploit relies on an extended FENCE.I that should fall back to standard fence behavior and flush the entire instruction cache, but is not understood by spike or Ariane. The attack is mountable from unprivileged software. [5]

Additional processor bugs reported in the same source are categorized using CWE entries that are independent of cache coherency (e.g., CWE-1262 for improper access control of EPCR in mor1kx, CWE-1201 for incorrect overflow-flag logic, CWE-1242 for undocumented instructions). [5]

Cache coherency in commercial RISC-V verification (Breker)

Newer industry evidence treats cache coherency as a primary verification product target. The Breker SystemVIP Library lists Cache Coherency TrekApp 2.0 alongside the RISC-V System Integrity TrekApp, ARM System Integrity TrekApp, Firmware-First, Power Management, Security, and Networking TrekApps. The library uses test-suite synthesis to generate end-to-end use cases for RISC-V core and SoC verification, including coherency tests targeted at RV64 multicore designs. [6][7]

RV64 MultiCore MoesiStates

For RV64 multicore designs, the Breker evidence presents a MoesiStates test set that exercises planned cache state transitions across cores. The slides title the relevant section "RV64 MultiCore MoesiStates" and explicitly identify "Planned Cache State Transitions" as the focus, indicating that MOESI (Modified/Owner/Exclusive/Shared/Invalid) protocol state machines are exercised directly rather than as a side-effect of traffic generation. [6][7]

Atomics, memory ordering, and false-share stress tests

The Breker presentation pairs coherency testing with complementary multiprocessor patterns:

• Atomics testing – checks that results are the aggregate of synchronized atomic operations across cores.
• Dekker memory ordering – exercises the classic two-core Dekker-style ordering pattern as a coherency-adjacent stress.
• False-share memory stress tests – each core runs a free-running write/check loop against an array of addresses; the published code loops over the address list, writes a pattern, then re-reads and compares, accumulating an error count, with the outer loop driving 1000 iterations. The shared trek_microloop_write_check8 function writes a byte pattern, reads it back, and reports any mismatch through trek_runtime_error. [6][7]

Real coherency bugs found in production designs

The Breker slide deck lists concrete bugs discovered in real designs that are directly tied to cache coherency:

• Coherent Mesh Network (CMN) programming issues – software/ firmware incorrectly programs the CMN.
• Misconfigured ARM CMN pin – a pin configuration error prevents coherent traffic from being enabled.
• Common cache line access reveals deadlock – a real deadlock triggered when multiple cores contend on a common cache line.

Other bugs in the same list are tangentially related or independent: RISC-V specification misunderstanding between core vendor and user, DDR model unable to handle AXI "wrap" transactions, custom instruction bugs discovered by stress tests, result mismatches with ultrawide address strides, incorrect exception handling for guest virtual address[63:38] = 0x1ffffff, and a bad mcause value for guest physical address[63:31] != 0x0. [6][7]

Automated vs directed coherency coverage

The Breker deck presents a side-by-side SystemVIP Test Suite Synthesis Coverage Comparison between typical directed coherency coverage and Breker automated coherency tests. The visual comparison is offered as evidence that constraint-random, AI-planning-driven synthesis can reach coherency states that directed tests leave uncovered. The slides explicitly contrast constrained-random and AI planning-algorithm synthesis, motivating the move away from directed testbenches for coherency. [6][7]

Takeaways from the provided evidence

Across the sources, cache coherency is not treated as an isolated protocol detail. Instead, it is shown as a cross-cutting concern involving:

• external-interface behavior and cache-management logic in microprocessors, [1]
• multiprocessor sharing patterns, synchronization, and traffic generation during verification, [1]
• a specific SoC functional-coverage scenario that combines cache coherency with stashing, snoopable transactions, and read sharing between cores and between cores and IO masters, all driven alongside randomized AXI transaction IDs and latency checks, [2]
• architecture-level integration choices in CPU-FPGA systems, where protocol style and access pattern can materially affect performance, [3][4]
• instruction-cache coherence semantics in RISC-V processors, where bugs that violate the coherence contract of instructions like FENCE.I become security vulnerabilities classifiable under CWE-1202 and can be exploited by unprivileged software, [5]
• commercial verification products (Breker's Cache Coherency TrekApp 2.0 and RV64 MultiCore MoesiStates) that explicitly target MOESI cache state transitions, atomics, Dekker memory ordering, and false-share stress on RISC-V multicore SoCs, with concrete bugs found in CMN programming, ARM CMN pin configuration, and common-cache-line deadlock. [6][7]

That combination explains why specialized generators and verifiers are associated with cache coherency, why modern SoC functional-coverage methodologies treat stashing and read sharing as named verification scenarios, why newer heterogeneous platforms expose coherence choices as a first-class system-design decision, why recent fuzzing work treats instruction-cache coherence as a target for hardware-security analysis, and why commercial verification vendors now sell cache-coherency TrekApps whose automated coverage demonstrably exceeds typical directed coherency tests. [1][2][3][4][5][6][7]