MPAM Cache Partitioning Configuration and FVP Model Discrepancy
The Memory Partitioning and Monitoring (MPAM) feature in ARM-based systems is designed to provide fine-grained control over cache and memory bandwidth partitioning. This is particularly useful in multi-tenant systems where different applications or virtual machines require isolated and guaranteed access to shared resources. The MPAM architecture defines a set of registers, including the MPAMCFG_CMAX register, which controls the maximum cache capacity allocated to a particular partition. The CMAX field in this register is a fixed-point fraction whose width is determined by the CMAX_WD field in the MPAMF_CMAX_IDR register. According to the MPAM reference manual, the implemented bits of the CMAX field should be the most significant bits (MSBs) of the field, with unimplemented bits being Read-As-Zero (RAZ) and Write-Ignored (WI).
However, when configuring the MPAM system using the Fixed Virtual Platform (FVP) base model, a discrepancy arises. The FVP model appears to implement the least significant bits (LSBs) of the CMAX field instead of the MSBs. For instance, if the CMAX_WD parameter is configured to 8 bits and a value of 0x1234 is written to the MPAMCFG_CMAX register, reading back the register returns 0x34 instead of the expected 0x1200. This behavior contradicts the MPAM specification and suggests an implementation error in the FVP model.
This issue is critical because it directly impacts the ability to accurately configure and validate cache partitioning in a system. Cache partitioning is essential for ensuring performance isolation and resource fairness in multi-core systems. If the FVP model does not correctly implement the MPAM specification, it becomes challenging to develop and verify systems that rely on MPAM for resource management.
Incorrect Mask Generation and Limited MPAM Support in FVP
The root cause of the discrepancy lies in the incorrect mask generation for the CMAX field in the FVP model. The mask determines which bits of the CMAX field are implemented and should be based on the CMAX_WD value. According to the MPAM specification, the mask should isolate the MSBs of the CMAX field, but the FVP model appears to be isolating the LSBs instead. This suggests a bug in the source code of the FVP model, where the mask generation logic is flawed.
Additionally, the FVP base model has limited support for MPAM. While it supports in-cluster MPAM (within the CPU cluster), it does not support system-wide MPAM. System-wide MPAM requires support across multiple components, including the interconnect and memory controller, which are not fully implemented in the base FVP model. This limitation restricts the scope of MPAM investigations to the CPU cluster level, making it impossible to evaluate system-wide cache and memory partitioning scenarios.
The FVP model also lacks support for other types of MPAM controls, such as memory bandwidth partitioning and cache portion partitioning beyond the level-3 cache. This is evident from the IDR registers, which indicate that many MPAM features are either disabled or have zero bits implemented in their control fields. This further limits the utility of the FVP model for comprehensive MPAM testing and validation.
Debugging and Workarounds for MPAM Implementation in FVP
To address the incorrect mask generation issue, the first step is to verify the source code of the FVP model. The mask generation logic should be reviewed to ensure it aligns with the MPAM specification. Specifically, the mask should be generated such that it isolates the MSBs of the CMAX field based on the CMAX_WD value. If the source code is not accessible, a workaround can be implemented by manually adjusting the mask in the testbench or simulation environment. This involves creating a custom mask that correctly isolates the MSBs and applying it during register writes and reads.
For the limited MPAM support in the FVP model, the workaround is to focus on in-cluster MPAM testing. While this does not provide full system-wide MPAM validation, it allows for basic cache partitioning tests within the CPU cluster. To simulate system-wide MPAM, a more advanced FVP model with full MPAM support is required. This model is available to partners under a Non-Disclosure Agreement (NDA) and includes IP that is not yet publicly available.
In the absence of a fully functional FVP model, alternative verification strategies can be employed. One approach is to use a combination of RTL simulation and emulation to validate MPAM functionality. RTL simulation provides detailed visibility into the MPAM registers and their behavior, while emulation allows for faster execution and system-level testing. Another approach is to use a software-based MPAM emulator, which can simulate MPAM behavior in a virtual environment. This can be useful for early-stage development and testing, although it may not fully capture the timing and performance characteristics of a hardware implementation.
To ensure accurate MPAM configuration, it is essential to carefully review the MPAM reference manual and cross-verify the implementation against the specification. This includes checking the IDR registers to confirm which MPAM features are supported and ensuring that the control fields are correctly implemented. If discrepancies are found, they should be documented and reported to the FVP model developers for resolution.
In conclusion, while the FVP base model provides a starting point for MPAM investigations, its limitations and implementation errors necessitate careful debugging and workarounds. By focusing on in-cluster MPAM testing, employing alternative verification strategies, and ensuring accurate MPAM configuration, it is possible to mitigate these challenges and make progress in MPAM-based system development. However, for comprehensive system-wide MPAM validation, access to a more advanced FVP model or alternative verification platforms is essential.
