AMBA AXI5 MPAM: Control and Visibility for Shared Memory Resources

As modern SoCs become increasingly heterogeneous, the shared memory system has become a critical performance and isolation boundary. CPUs, GPUs, AI accelerators, DMA engines, display controllers, and virtualized workloads often compete for shared cache capacity and memory bandwidth. In these systems, high performance depends on more than simply moving data quickly. Resources must be shared fairly, usage must be tracked accurately, and interference between workloads must be controlled.

Verifying MPAM, however, is challenging because the metadata must travel correctly with every memory transaction across the system. Arm Memory Partitioning and Monitoring (MPAM) addresses this challenge by adding transaction-level information to AMBA AXI5. This information identifies the resource partition associated with a memory access and the monitoring group to which its activity must be attributed. By making resource usage visible on the bus, MPAM supports more predictable performance, stronger workload isolation, and improved system-level observability.

Overview of Memory Partitioning and Monitoring

MPAM provides a framework for controlling and monitoring shared memory system resources. It allows system software and hardware to associate each memory transaction with a resource partition and a performance monitoring context. Components such as interconnects, caches, and memory controllers can use this information to apply resource policies and account usage.

Partitioning and monitoring are complementary but independent. Partitioning determines how shared resources are controlled, while monitoring records how those resources are used. This separation allows workloads within the same resource partition to be measured independently, or different partitions to be managed under distinct allocation policies.

Why AXI5 Needs MPAM Support

Standard AXI transaction attributes describe properties such as ordering, cacheability, protection, and Quality of Service. They do not, by themselves, identify the resource partition that should manage a transaction or the monitoring context that should account for its bandwidth and cache usage.

AXI5 MPAM support closes this gap by carrying partitioning and monitoring metadata with every read and write request. This enables downstream components to consistently recognize the workload context, enforce resource-management policies, and collect meaningful usage information across the memory hierarchy.

AXI5 MPAM Protocol Architecture

MPAM is defined as an optional AMBA 5 feature. Support is controlled through the MPAM_Support interface property. When MPAM is enabled, read and write address requests carry MPAM information using ARMPAM and AWMPAM. When the feature is not supported, these signals are not present on the interface.

The MPAM information contains three logical fields:

MPAM_NS: Security Context

MPAM_NS provides the security indicator associated with the transaction.

PARTID: Partition Identifier

PARTID identifies the resource partition associated with the transaction. Interconnects, caches, and memory controllers can use the identifier when applying controls to shared resources such as cache capacity or memory bandwidth.

PMG: Performance Monitoring Group

PMG identifies the context used for performance accounting, traffic monitoring, profiling, and debug. It enables resource usage to be attributed to the appropriate workload or monitoring group without changing the partition assignment.

How MPAM Information Flows Through the System

MPAM information travels as metadata alongside the transaction address. An MPAM-enabled master drives the appropriate value on a read or write address request, and downstream components sample the value with the corresponding valid address transfer. The interconnect can propagate the metadata toward caches, bridges, and memory controllers that implement partitioning or monitoring functions.

The values generated by a master are implementation-defined and are typically selected through software, firmware, or system configuration. MPAM identifiers have global scope, so an interconnect is not required to remap them or make them unique for each master. Where system components use different MPAM configurations, the implementation must define how widths, defaults, and unsupported fields are handled.

Key Protocol Features

• Configurable identifiers: Implementations can select partitioning and monitoring granularity appropriate to the system and interface configuration.

• Independent resource partitioning: PARTID values allow transactions to be associated with resource partitions used by components in the memory hierarchy.

• Independent monitoring: PMG values allow traffic within a partition to be accounted for through separate monitoring contexts.

• End-to-end metadata propagation: MPAM information can travel through compatible interconnects and protocol bridges while preserving the transaction context.

• Efficient signaling: Separating partitioning from monitoring avoids unnecessary coupling between resource-control and accounting requirements.

• Throughput management and workload isolation: By making each transaction’s resource context visible, MPAM helps memory-system components reduce workload interference, avoid unfair bandwidth usage, and improve performance predictability when multiple agents compete for shared resources.

Practical System Use Cases

Cloud and Virtualized Workload Isolation

Hypervisors and system software can associate virtual machines, containers, or applications with distinct resource partitions and monitoring groups. This helps prevent one workload from monopolizing shared cache capacity or memory bandwidth, while enabling usage to be profiled or accounted for independently.

AI Accelerators and Heterogeneous SoCs

CPUs, GPUs, AI accelerators, and DMA engines frequently share DRAM bandwidth. Assigning different PARTID values enables the memory system to distinguish traffic classes for resource control, while PMG values provide visibility into the bandwidth consumed by each monitored workload.

Monitoring, Debug, and Accounting

Because monitoring information accompanies the transaction, memory-system usage can be attributed at multiple points in the hierarchy. This supports workload profiling, bottleneck analysis, latency debug, resource accounting, and placement optimization.

Automotive and Real-Time Systems

In systems where predictable latency matters more than peak throughput, MPAM information can distinguish safety-critical or latency-sensitive traffic from background activity. Resource controls can then limit interference, while monitoring provides visibility into actual consumption.

Functional Verification Challenges

MPAM verification adds resource-context correctness to standard AXI protocol verification. A complete environment must verify not only that the AXI transfer is legal, but also that MPAM information is configured, generated, propagated, interpreted, and monitored consistently.

IP-Level Verification

• Validate the presence and configuration of the partition and monitoring information.

• Check identifier values against the configured widths and legal constraints.

• Verify boundary configurations, including zero-width identifiers and maximum supported widths.

• Confirm protocol consistency across read and write transaction types.

• Validate interoperability between MPAM-capable and non-MPAM-capable interfaces.

SoC-Level Verification

• Confirm end-to-end preservation of MPAM information through interconnects, caches, bridges, and memory controllers.

• Validate that transactions are associated with the intended resource partition and monitoring group.

• Exercise width adaptation, tied-off fields, truncation, default values, and potential identifier aliasing.

• Check behavior through virtualization events, context switches, and heterogeneous protocol configurations.

• Cover partition identifiers, monitoring groups, identifier crosses, width configurations, and bridge interoperability.

Cadence AXI5 VIP Solution

Cadence AXI/ACE Verification IP provides a comprehensive solution for creating, observing, and checking MPAM-aware traffic across configurable AXI environments. It enables verification teams to validate protocol behavior at the IP level and preserve MPAM transaction context through system-level scenarios.

Cadence AXI5 VIP accelerates MPAM verification closure by providing:

• Ready-to-use generation of MPAM-aware read and write transactions

• Configurable partition and monitoring signaling

• Protocol checks for MPAM configuration and transaction consistency

• Validation of identifier widths and interface interoperability

• Functional coverage for MPAM values, configurations, and feature interactions

• End-to-end observability for MPAM metadata across the verification environment

These capabilities help teams progress beyond basic signal checks and validate MPAM behavior under heterogeneous traffic, configurable widths, protocol bridges, and realistic resource-monitoring flows.

Conclusion

AMBA AXI5 MPAM makes shared memory-resource usage identifiable, controllable, and measurable at the transaction level. By carrying partition and monitoring information with read and write requests, it gives SoC implementations a practical mechanism for improving workload isolation, applying resource policies, attributing usage, and increasing performance predictability across heterogeneous systems.

As MPAM behavior spans interface configuration, transaction signaling, metadata propagation, resource control, and monitoring, verification must address both protocol compliance and end-to-end system intent. Cadence AXI5 VIP provides the traffic generation, checking, coverage, interoperability validation, and observability needed to verify robust MPAM implementations from IP-level configuration through full-system operation.

For more information on Cadence AXI/ACE VIP for AMBA AXI5 MPAM verification, visit the Cadence Functional Verification community or contact the Cadence VIP team.