17³Ô¹Ï

Key Features of Arm AMBA 5 AXI-J

The Arm AMBA AXI-J specification brings a range of new Arm architecture features and additional enhancements. It is developed on the foundation of the existing AMBA AXI Issue H (AXI-H.c) specification, which we explored in our previous blogs on the AXI5 and ACE5-Lite protocols. These protocols are capable of operating in conjunction with the AMBA5 CHI-F protocol within a design. Please refer to our blog on the  AMBA5 CHI-F VIP for more details.

Realm Management Extensions

As on-premises workloads move to the cloud and utilize personal data, the need for privacy-enhancing computation methods in untrusted or shared environments is growing. Armv9 Confidential Compute Architecture (CCA) addresses this with hardware-based secure computation, including Realm Management Extensions (RME) for trusted, dynamic, and attestable execution regions. The following are the salient features of RME.

• New Physical Address Spaces:  RME adds Root and Realm physical address spaces to Arm Processing Elements (PE), enabling hardware isolation and confidential computing in specific execution environments called realms. This is achieved using the AxNSE signal and the existing AxPROT[1] signal.
• New Cache Maintenance Operations:  New Cache Maintenance Operations (CMOs) enable dynamic movement of memory granules across realms, with the Granule Protection Table (GPT) determining the current Physical Address Space (PAS) of a page. Point of Physical Aliasing (PoPA) indicates when updates to a location in one PAS are visible to all other PAS, and CMOs can target multiple PAS to ensure data visibility at PoPA.
• Remote invalidation: RME enables remote invalidation of non-snoopable cacheable memory locations, allowing cache maintenance by a different PE than the one that allocated it.
• Updates to DVM operations: New DVM operations and fields are added to support the new PAS and TLB invalidation for GPT caching in Arm v9.2 architecture.
• Updates to MPAM:  MPAM defines independent part ID spaces for each Physical Address Space (PAS). With the introduction of the Realm and Root PAS, the MPAM Space (MPAM_SP) is now a 2-bit setting encoded in the AxMPAM signal, increasing its width from 11-bit to 12-bit.
• Updates to Untranslated transactions: AxMMUSECSID signals are expanded from 1-bit to 2-bit to support realm and root encodings.

Other Features

Write Deferrable Transactions: This transaction is introduced to support the handling of PCIe Gen5 Deferrable Memory Write (DMWr) transactions. It is a 64-byte atomic write request that can be rejected by the completer. The completer has the option to reject the request and issue a Defer response to the requester.  The requester can then repeat the write request.

Page-Based Hardware Attributes (PBHA): PBHA values from page tables control various hardware system components during address translations. All translations to a specific physical address should provide the same 4-bit PBHA value to guarantee predictable results.

Other introduced features include: Subordinate Busy, Subsystem Identifier, Unstash Transaction, Invalidate Hint Transaction, Caching Shareable Lines, and Untranslated Transactions V3.

Key features of arm AMBA APB-E

The Arm AMBA APB-E specification is an extension of the AMBA APB5 Issue D (APB-D) specification. APB-D is the first version supporting the APB5 protocol features such as user signalling, wake-up signalling and Interface Parity for functional safety (FuSa). Several leading automotive semiconductor suppliers adopt 17³Ô¹Ï AMBA VIP solutions including AMBA APB5 VIP to verify the FuSa features in their designs.

APB-E introduces the new Armv9 architecture feature, Realm Management Extensions (RME).  The RME feature is already supported by other 17³Ô¹Ï industry first AMBA Verification IPs for the protocols AXI5, ACE5-Lite, ACE5-Lite+DVM and CHI-F, which are widely adopted. As discussed earlier in this blog, RME enables the creation of new physical address spaces, namely Root and Realm in addition to existing secure and non-secure physical address spaces. In APB-E, a new signal called PNSE is introduced to work in tandem with the existing signal PPROT[1] to distinguish between these different physical address spaces.

17³Ô¹Ï end-to-end protocol verification solutions for AMBA? 5 AXI5, AXI5-Lite, ACE5, ACE5-Lite, ACE5-Lite/DVM, APB5 provide performance analysis and comprehensive system-level debug capabilities to check for functional correctness, data integrity, and cache coherency. In-built sequence collection, functional coverage model, verification plans, and usage examples are included to ensure fast bring-up and achieve wholistic verification closure. 17³Ô¹Ï is collaborating with early customers and partners to extend the standard architecture for their next-generation designs with new features available now with latest specifications.

17³Ô¹Ï VIP is natively integrated with the 17³Ô¹Ï Verdi? Protocol Analyzer debug solution as well as 17³Ô¹Ï Verdi? Performance Analyzer. Running system-level payload on SoCs requires a faster hardware-based pre-silicon solution. 17³Ô¹Ï transactors, memory models, hybrid and virtual solutions based on 17³Ô¹Ï IP enable various verification and validation use-cases on the industry¡¯s fastest verification hardware, 17³Ô¹Ï ZeBu? emulation and 17³Ô¹Ï HAPS? prototyping systems.

More information on 17³Ô¹Ï AMBA? VIP and Test Suites is available at