Verification Central


Synopsys Introduces the Industry’s First Verification IP for Arm AMBA 5 CHI-F

Arm recently announced the availability of the next iteration of the Arm® AMBA® 5 CHI protocol – CHI Issue F (CHI-F). AMBA 5 CHI-F is built on top of the existing AMBA CHI Issue E (CHI-E) specification (read our blog on AMBA CHI-E here), and introduces several exciting features related to the latest Arm architecture and optimized transaction flows.

Synopsys, a close partner of Arm, offers a broad set AMBA protocol solutions for early modelling, design, implementation, verification, validation, and system bring-up. Synopsys leading verification solutions for Arm protocols cover a full range of AMBA specifications including next generation AMBA ACE5, AXI5 and now AMBA 5 CHI-F. Synopsys’ verification automation solutions also offer testbench generation with Synopsys VC AutoTestbench and performance verification of Arm based SoCs with Synopsys VC AutoPerformance.

“Synopsys offers comprehensive protocol verification solutions for all existing and next-generation AMBA specifications, including AMBA 5 CHI-F,” said Vikas Gautam, vice president of R&D for the Synopsys Verification Group. “Our verification solutions leverage Synopsys leading IPs to drive best-in-class verification credibility, and our offerings for Simulation, Emulation and Prototyping platforms ensure that our customer get end-to-end IP to SoC level verification closure. By working closely with Arm to deliver and deploy first-in-industry customer-proven solutions, we enable the market makers to adopt the latest specifications rapidly.”

This blog will explain the key features of the recent AMBA CHI-F release.

New Features Related to Arm Architecture

Realm Management Extensions

With the increasing trend of moving on-premise workloads to the cloud and increased usage of private/personal data for compute/ML, the requirements for enhanced private computation for data processed in untrusted/shared environments is rising. Arm’s Confidential Compute Architecture (CCA) caries such computations in a hardware-based secure environment, even protected from privileged software.

Realm Management Extensions (RME) is one of the key hardware changes introduced as part of CCA. Along with other components of CCA, RME enables support for trusted, dynamic, and attestable execution regions.

The salient features of RME are:

  • New physical address spaces: In addition to existing Secure and Non-Secure Physical Address Spaces (PAS), RME supports two new physical address spaces called Root and Realm for the Arm Processing Elements (PE). Through this hardware isolation, RME facilitates the confidential compute of the data in these execution environments (realms).
  • New cache maintenance operations: New Cache Maintenance Operations (CMOs) help with the dynamic movement of memory granules (pages) across these realms. The Granule Protection Table (GPT) determines the current PAS for a page. The point in the system at which updates to a location in one PAS are visible to all other PAS is termed as a Point of Physical Aliasing (PoPA).
    CMOs may target more than one PAS to ensure that data written earlier is fully visible to other intended PAS at PoPA.
  • Remote invalidation: RME requires the ability to remotely cache invalidated memory mapped as non-snoopable. This enables cache maintenance of the non-snoopable locations by a PE, which is different to the one that caused allocation in the cache.
  • Updates to DVM operations: Additional DVM operations and fields are introduced to cater to the following requirements of Arm v9.2 architecture:
    • To support the new PAS
    • To support TLB invalidation for GPT caching, as the PAS association with memory pages info contained in GPT is cacheable within TLBs
  • Updates to MPAM: MPAM defines independent part ID spaces for each PAS. Prior to CHI-F, this was single bit field corresponding to Secure, non-secure PAS. With the two new Realm and Root PAS, this is now a two-bit field to encode MPAM Space (MPAMSP).
Deferrable Writes

WriteNoSnpDef is a single copy 64-byte atomic write request which can be rejected by the completer. The transaction flows are similar to the WriteNoSnp transaction. One of the typical use cases of this transaction is where a gathered 64-byte data is sent as atomic write to shared queues within an accelerator. The completer can reject the write request and issue a Defer response to the requester which is an indication that the write could not be processed but might be successful if issued at a later point in time. The requester can later repeat the write request.

Page Based Hardware Attributes (PBHA)

PBHA values are obtained from page tables during address translations. These four-bit values are propagated through the memory system with transactions and can be used to control hardware system components. For predictable results, it is expected that all the translations to a given physical address (PA) provide the same PBHA value.

Memory Tagging Enhancements (MTE)

Permitted TagOp settings are updated for ReadOnceMakeInvalid, ReadOnceCleanInvalid and MakeReadUnique Transactions.

Changes For Transaction Optimizations

  • Pseudo migration of cached data: This optimization is aimed at minimizing the bandwidth utilization for CopyBack requests. In the case of CopyBack, a request is initiated by a requester that has not modified the corresponding cache line and a copy of the cache line is already available at the Home node’s System cache. This feature enables the Home node to complete the CopyBack transaction without requesting data from the requester.
  • DCT Flow for ReadOnceMakeInvalid: ReadOnceMakeInvalid transaction flows are enhanced to support Direct Cache Transfer (DCT) involving SnpUniqueFwd snoop type.
  • ReadOnce transactions with partial data: ReadOnce, ReadOnceMakeInvalid and ReadOnceCleanInvalid transactions now support data sizes less than 64 bytes, to support partial cache line read operations.
  • DataSource Width: The DataSource field width is extended from four to five-bits. This additional bit can help components on the remote chip identify the source of the data in case of multi-chip topologies.

Synopsys VIP for Arm AMBA 5 CHI provides performance analysis solutions, comprehensive system level protocol-checks, data integrity checks 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. Synopsys is collaborating with early customers and partners to extend the standard architecture for their next-generation coherent designs with new features us the Synopsys VIP for the AMBA 5 CHI-F specification.

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

To learn more about Synopsys VIP & Test Suites for AMBA protocols please visit