We are pleased to announce two major revisions of the AMBA specifications: Issue G of the AMBA AXI and ACE Protocol Specification and Issue D of the AMBA CHI (Coherent Hub Interface) Architecture Specification. These releases are part of the existing fifth generation of AMBA (AMBA 5) and extend the successful and widely adopted AXI and CHI interfaces. They introduce the support for key Arm Architecture features and a series of performance and transaction improvements that are aligned with the requirements for the next generation of system on chips (SoCs).
This blog post gives an overview of some of the functionality introduced in the new releases of the AXI and CHI specifications.
AMBA is the open standard for on-chip communications. AMBA ensures compatibility between different components, which enables design reuse, low-friction integration, and thus a lower cost of ownership and faster time to market. AMBA specifications are freely available, royalty free, developed collaboratively, and widely adopted. AMBA is trusted by a global ecosystem of partners and developers, used in multiple market segments and shipped in billions of devices.
Back in 2013 we announced the AMBA 5 CHI architecture, to provide the performance and scale required for infrastructure applications such as networking and data center. CHI has been highly successful with broad industry adoption and has been the foundation for systems with a very large number of processors on a single SoC. It is now adopted in many other applications, such as in mobile and automotive, where full hardware coherency and high-performance are required.
The various generations and interface types of AMBA AXI and ACE remain widely adopted across the industry, particularly for non-coherent and IO coherent processors, accelerators and peripherals. AXI, together with other AMBA specifications, carries a comprehensive list of features, as well as a long heritage of dependability and trust.
AXI originally defined an ID-based ordering model. That imposed additional requirements on interconnects to track IDs and to ensure that transactions were done in order. However, components are increasingly using unique IDs and maintaining ordering at source which provides a better overall system performance.
AXI Issue G introduces the Unique ID indicator, which reduces the complexity of interconnect tracking logic. Components can indicate that they are using a set of unique IDs, which then eliminates the need for interconnects and downstream components to track those IDs for ordering purposes. Requests can be sent very quickly without tracking, and responses can bypass any ordering logic in the return path.
The ordering model chapter in the AMBA AXI specification was updated and rewritten to improve clarity. Previously, details of the AXI ordering model were spread around various parts of the document. Issue G does not introduce any functional changes – instead, it brings the ordering requirements together into a single chapter and defines them in a more formal and concise way. It provides a step change in terms of improvements and clarity of the specification.
When an AXI Manager issues a read request, there has previously been a requirement for data to be returned in an order and width determined by the read address and burst type. However, some interconnects and Subordinates cannot provide data in the prescribed order or width without significant buffering. For example, when bridging between AXI and CHI of different widths, the bridge is required to re-order and merge read data. That requires sufficient buffering for all outstanding transactions.
This is solved in AXI Issue G with the support for read data chunking, which permits out-of-order and partial read data beats to be returned by the Subordinate if supported by the Manager. This greatly reduces the buffering requirements and the complexity when bridging from AXI to CHI.
AXI/ACE Issue G adds an option to transport Cache Maintenance Operations (CMOs) on write channels instead of read channels. Using the write channels can result in improved channel utilization. For example, the write response channel is narrower and less utilized than the read data channel, so can be more appropriate for transporting CMO responses. Moving forward, we expect implementations to use write channels for CMOs and particularly for persistent CMOs.
The new AMBA AXI Issue G and CHI Issue D specifications introduce the AMBA interface parity extension for use in applications such as automotive, which have resilience or functional safety requirements.
End-to-end protection of on-chip communication can be achieved by taking a modular approach:
This modular approach enables resilient systems, even when using components developed by different vendors or with alternative interfaces.
Figure 1. End-to-end protection of on-chip communications enabled by AMBA Interface Parity Protection
The Armv8.4-A Architecture added a feature called Memory System Resource Partitioning and Monitoring (MPAM) - you can read about it in this blog. MPAM enables, for example, hypervisors to monitor and control how virtual machines use caches, memory and other system components. Hypervisors can then limit the memory system performance impact of one virtual machine on other virtual machines, just as they may limit the number of cores or amount of DRAM that can be allocated by a virtual machine.
The new AMBA specifications describes how the (software defined) MPAM partition identifiers are attached to transactions, transported through AMBA interfaces and system components to partition resources appropriately.
Persistent memory (also known as storage class memory) is increasingly being used to enable more efficient access to persistent data, as well as to extend the memory capacity with high-density and low-cost memory.
Previous CHI and AXI/ACE specifications introduced the support for persistent memory through Persistent Cache Maintenance Operations (Persistent CMOs). Persistent CMOs enable pushing data to the Point of Persistence (PoP), more specifically, getting a response that guarantees memory writes to be persistent even, for example, in the event of a power failure. The new issues of the AXI/ACE and CHI specifications add Persistent CMOs with two-part responses and Deep Persistent CMOs, which are aligned to the support for Deep Persistent Memory introduced in the Armv8.5-A Architecture. Two-part Persistent CMO responses separate the observability of a CMO from the persistence guarantee. Deep Persistent CMOs extend the support to cover both shallow PoP, typically where battery backup is used to ensure persistence, and deep PoP, where persistence is guaranteed even in the event of battery backup failure.
Additional features and performance enhancements specific to CHI and introduced in Issue D include:
Building on the success of previous AMBA CHI and AXI releases, these new specifications add significant features and performance improvements. Together, they enable IP and SoC designers to address the requirements for the next generation of products in target markets ranging from mobile and automotive, to networking and data centers. We would like to take the opportunity to thank our various partners who have contributed to and helped develop these new specifications. This is a testament to the collaborative nature of AMBA and its active global ecosystem. Arm is always trying to improve things for our partners and developers, such as Flexible Access. In future, we are also looking to provide advanced specification information to further facilitate integration of compatible products.
The AMBA AXI Issue G and CHI Issue D specifications are freely available from the Arm Developer website. As with all AMBA specifications, they are provided with a royalty free license to develop, manufacture and sell compliant products. They are also platform independent and technology neutral, meaning they can be used and are used in a variety of architectures, processors, accelerators and peripherals.
[CTAToken URL = "https://developer.arm.com/documentation/ihi0022/g" target="_blank" text="AMBA AXI Issue G Specification" class ="green"] [CTAToken URL = "https://developer.arm.com/documentation/ihi0050/D" target="_blank" text="AMBA CHI Issue D Specification" class ="green"]
Quite informative.
Thank you!