²ÝÁñÉçÇø

Introduction

Arm? recently announced the availability of the next version of the Arm? AMBA? 5 CHI Protocol Specification, .

²ÝÁñÉçÇø offers a broad set AMBA protocol solutions for early modelling, design, implementation, verification, validation, and system bring-up. ²ÝÁñÉçÇø¡¯ industry leading verification solutions for Arm protocols cover a full range of AMBA specifications including next generation AMBA 5 AXI-K and now AMBA 5 CHI-G. ²ÝÁñÉçÇø¡¯ verification automation solutions also offer testbench generation with ²ÝÁñÉçÇø VC AutoTestbench and performance verification of Arm based SoCs with ²ÝÁñÉçÇø VC AutoPerformance.

¡°²ÝÁñÉçÇø offers comprehensive protocol verification solutions for all existing and next-generation AMBA specifications, including AMBA 5 CHI-G,¡±?said Vikas Gautam, vice president of R&D for the ²ÝÁñÉçÇø Verification Group. ¡°Our verification solutions leverage ²ÝÁñÉçÇø 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.¡±

The CHI-G update introduces numerous new features and optimizations, with some of these tailored specifically for the recently introduced Arm CHI chip-to-chip (CHI C2C) protocol. You can refer to our earlier blog on CHI C2C for more details regarding the CHI C2C protocol. In this blog, we'll explore some of key features introduced in the CHI-G protocol. Let¡¯s delve a little deeper into each of these features.

Memory Encryption Contexts (MEC)

In our previous blog on CHI-F, we talked about Arm's Realm Management Extension (RME) which is part of Confidential Compute Architecture (CCA), under Arm v9 architecture. RME provides a set of features for creating and managing isolated execution environments called Realms. Memory Encryption Contexts (MECs) extensions to RME allow each Realm to have its own unique encryption context. This feature plays a key role in assigning MECs to all memory accesses within the Realm Physical Address Space. All memory transactions are associated with a MECID, which is used by the Memory Encryption Engine as an index into a table of encryption contexts, which contributes to the external memory encryption. So, each set of Realm data can be encrypted in a different way. This means, that a malicious agent that has access to the physical memory device and can decipher one set of Realm data, cannot use the same decryption method to access other sets of Realm data. Overall, MEC plays a crucial role in ensuring the confidentiality of data within the context of confidential computing. 

In CHI-G, this feature can be enabled only when RME is enabled. A new field ¡°MECID¡± is added to the request, data and snoop flits whose width must be sixteen in case MEC Support property is set to True for a CHI node.  

Limited Data Elision

Limited Data Elision is a feature that optimizes data transfer between components by reducing the number of data flits required to be transmitted for a given transaction. This optimization can be leveraged when multiple flits need to carry the same data fields, or when the data fields in some or all data flits are zeroes. Through this feature, for a given transaction, a single flit can encapsulate one or more subsequent flits. New fields are added in the data flit which indicate the number of additional data flits that are represented by this single data flit as well as the properties of the elided data flits.

Features and Optimizations Focused on CHI C2C Links

• RME-DA: This is part of the Realm Management Extension architecture that enables the secure assignment of assignable device interfaces. CHI-G supports RME-DA and RME-CDA in multiple accelerator device topologies, where the accelerators are connected to a host. The devices are typically partially trusted, which means they are permitted to access only specific realm and non-secure physical address spaces in the host controller memory OR peer device memory. The host is responsible for ensuring that it grants access to requests sent by a device only when they target addresses in the trusted zone. New fields to support RME-DA or RME-CDA are added in the request channel when an interface supports these features. 

• DataSource Extensions: The existing DataSource field in Read and Snoop data flits is resized and divided into sub-fields with each sub-field representing specific information about the location, distance and type of the completer that issued the data flit. Some of these sub-fields hold particular importance in multi-chip(let) systems, where the data flits might traverse one or more chips(lets) enroute to its destination.

• DataTarget: The CHI-E feature SLCRepHint was targeted at providing hints to System Level Caches about the likelihood of a particular cacheline being used again, to allow the SLCs to manage and replace stored cache lines more optimally. This becomes especially significant in multi-chip(let) systems where there is an increase in the cache hierarchy. In CHI-G, SLCRepHint has been renamed as DataTarget and an extra sub-field is added to it. This sub-field serves as a recommendation, suggesting the number of cache levels a CopyBack request should propagate to.

• PrefetchTgtHint: A new field called PrefetchTgtHint is added in read requests, which acts as a hint to the receiver that prefetching the location before executing the read could be advantageous. This is a more optimal alternative to a standalone PrefetchTgt instruction especially in cases where the transactions need to traverse across the chip(let)-to-chip(let) link.

Additional Updates

• MPAM Part ID Extension: Memory Partition and Performance Monitoring (MPAM) defines independent partition ID (PARTID) spaces for each Physical Address Space (PAS). CHI-G provides an option to extend the MPAM PARTID width from 9 bits to 12-bits.
• ¡®Reduced¡¯ MTE Support: For Memory Tagging Extensions (MTE) support, a new option ¡®Reduced¡¯ is introduced. This new option can be used by components that can support the reading and writing of tags, but not the tagmatch operation or partial tag updates. 
• UDP and SD state support: CHI-G introduces new properties to enable/disable UDP and SD states. In earlier versions of the CHI protocol, these states were always enabled. 
• Relaxation of ReadPreferUnique Initial cache states: CHI-G allows ReadPreferUnique with TagOp Transfer to be issued from any initial cache states. This is because ReadPreferUnique would be the most preferable option for a Requester to obtain tags in cases where it wants to perform a store, but the cache only contains data but no tags. 
• RetToSrc applicability in case of SnpUniqueStash: CHI-G allows RetToSrc field to be set to 1 in case of SnpUniqueStash to allow the Home node to obtain data from the Stash target in case it is holding the line is SharedClean state.

Conclusion

²ÝÁñÉçÇø end-to-end protocol verification solutions for?AMBA? 5 AXI5, AXI5-Lite, ACE5, ACE5-Lite, ACE5-Lite/DVM, AXI C2C, CHI C2C, CHI-G?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. ²ÝÁñÉçÇø is partnering with early customers and collaborators to enhance the standard architecture for their next-generation designs, incorporating new features now available with the latest specifications. 

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

More information on ²ÝÁñÉçÇø AMBA? VIP and Test Suites is available at?