Cortex-A15 DCIMVAC Operation: Cleaning and Invalidating Cache Lines
The Cortex-A15 processor, a high-performance ARM core, implements cache maintenance operations to ensure data consistency between the cache and main memory. One of the key operations in this context is the Data Cache Invalidate by Modified Virtual Address to Point of Coherency (DCIMVAC). According to the ARM Cortex-A15 Technical Reference Manual (TRM), DCIMVAC is expected to invalidate a cache line without cleaning it, meaning it should discard the data without writing it back to memory if the line is dirty. However, experimental observations on the TI AM5718 SoC, which features a Cortex-A15 MPCore (revision r2p2), reveal that DCIMVAC behaves differently: it cleans the cache line (writes back dirty data to memory) before invalidating it. This behavior aligns more closely with the Data Cache Clean and Invalidate by Modified Virtual Address to Point of Coherency (DCCIMVAC) operation, which is explicitly documented to clean and invalidate the cache line.
This discrepancy raises questions about whether the observed behavior is a documented feature, an undocumented implementation detail, or a chip-specific anomaly. The ARM Architecture Reference Manual (ARMv7-A and ARMv7-R edition) and the Cortex-A15 TRM do not explicitly state that DCIMVAC will clean dirty cache lines before invalidation. However, a closer examination of related documentation, such as the Cortex-A53 TRM and Cortex-A7 TRM, reveals that similar behavior is documented in those architectures. Specifically, the Cortex-A53 TRM states that DCIMVAC operations in AArch32 and DCIVAC instructions in AArch64 perform a clean before invalidating if the data is dirty. This suggests that the Cortex-A15’s behavior might be consistent with a broader architectural trend, even if it is not explicitly documented.
Furthermore, the Cortex-A15 errata notice (item 794724) provides additional context. It mentions that the DCISW (Data Cache Invalidate by Set/Way) instruction is treated as DCCISW (Data Cache Clean and Invalidate by Set/Way) in the Cortex-A15. This behavior is not described as an errata but rather as a given in the workaround explanation. This observation is significant because it parallels the behavior observed with DCIMVAC, where an invalidate operation is effectively upgraded to a clean and invalidate operation. This suggests that the Cortex-A15 might have a design philosophy of ensuring data consistency by default, even at the cost of additional cycles for cleaning dirty cache lines.
Virtualization Extensions and Cache Maintenance Behavior
The Cortex-A15 processor supports virtualization extensions, which introduce additional complexity to cache maintenance operations. In systems with virtualization, cache maintenance operations must consider the security state (Secure or Non-secure) and the privilege level (PL1 or PL2). The ARMv7-A-R manual notes that upgrading DCIMVAC to DCCIMVAC is functionally acceptable for any data invalidate by Modified Virtual Address (MVA) executed in a Non-secure PL1 mode. This means that the processor might internally upgrade DCIMVAC to DCCIMVAC under certain conditions, particularly in Non-secure PL1 mode, to ensure data consistency across different security domains.
The TI AM5718 SoC, which features the Cortex-A15 MPCore, includes virtualization extensions. This could explain why DCIMVAC behaves like DCCIMVAC in this context. The ARMv7-A-R manual explicitly states that the implementation documentation might not specify the exact conditions under which this upgrade occurs, leaving room for variability across different implementations. This lack of specificity in the documentation can lead to confusion, as developers might expect DCIMVAC to strictly invalidate without cleaning, based on the TRM description.
The Cortex-A7 TRM also provides relevant insights. It mentions that DCIMVAC can be upgraded to DCCIMVAC under certain conditions, particularly in systems with virtualization extensions. This behavior is consistent with the Cortex-A15’s observed behavior, suggesting that it might be a deliberate design choice rather than an undocumented anomaly. The Cortex-A7 and Cortex-A15 share many architectural features, and their cache maintenance behaviors are likely influenced by similar design considerations.
Resolving Cache Maintenance Ambiguities: Best Practices and Workarounds
Given the ambiguity surrounding the DCIMVAC operation in the Cortex-A15, developers must adopt strategies to ensure predictable cache behavior in their systems. One approach is to assume that DCIMVAC might clean dirty cache lines before invalidation, even if the documentation suggests otherwise. This conservative approach ensures that data consistency is maintained, even if it results in additional cycles for cleaning dirty cache lines.
For scenarios where strict invalidation without cleaning is required, developers can use alternative cache maintenance operations or sequences. For example, the Data Cache Invalidate by Set/Way (DCISW) operation can be used to invalidate cache lines without cleaning, provided that the specific implementation does not upgrade it to a clean and invalidate operation. However, as noted in the Cortex-A15 errata, DCISW is treated as DCCISW in this architecture, making it unsuitable for strict invalidation.
Another approach is to use memory barriers and explicit cache cleaning operations to ensure data consistency before performing invalidation. For example, developers can use the Data Cache Clean by Modified Virtual Address to Point of Coherency (DCCMVAC) operation to clean dirty cache lines explicitly, followed by the Data Cache Invalidate by Modified Virtual Address to Point of Coherency (DCIMVAC) operation to invalidate the cache lines. This sequence ensures that dirty data is written back to memory before invalidation, providing predictable behavior regardless of whether DCIMVAC cleans dirty cache lines internally.
In systems with virtualization extensions, developers must also consider the security state and privilege level when performing cache maintenance operations. The ARMv7-A-R manual provides guidelines for cache maintenance in Non-secure PL1 mode, where upgrading DCIMVAC to DCCIMVAC is functionally acceptable. Developers should ensure that their cache maintenance sequences account for these architectural nuances to avoid unexpected behavior.
Finally, developers should consult the errata and technical documentation for their specific processor revision and SoC implementation. The Cortex-A15 errata notice (item 794724) provides valuable insights into the processor’s cache maintenance behavior, highlighting the treatment of DCISW as DCCISW. Similarly, the Cortex-A53 TRM’s documentation of DCIMVAC behavior provides a useful reference for understanding similar architectures. By combining these resources with empirical testing, developers can develop robust cache maintenance strategies that account for the Cortex-A15’s unique behavior.
In conclusion, the Cortex-A15’s DCIMVAC operation exhibits behavior that deviates from the documented description, cleaning dirty cache lines before invalidation in certain contexts. This behavior is consistent with broader architectural trends observed in the Cortex-A53 and Cortex-A7 processors and is influenced by the presence of virtualization extensions. Developers must adopt conservative cache maintenance strategies, leveraging explicit cleaning operations and memory barriers to ensure predictable behavior. By understanding the architectural nuances and consulting relevant documentation, developers can effectively manage cache maintenance in Cortex-A15-based systems.
