²ÝÁñÉçÇø

Atomic Transactions

Atomic transactions solve the non-deterministic latency problem in the most elegant way.  They enable sending the operation along with the data, permitting the operation to be performed closer to where the data is located instead of pulling the data towards the requester for modification. Typically, the read-modify-write operation can be achieved with a single atomic operation. Verification IP (VIP) supports all four types of atomic transactions: AtomicStore, AtomicLoad, AtomicCompare and AtomicSwap. AtomicStore and AtomicLoad transactions can support eight different operations.

Trace Signals

Trace signals support the debugging and tracing across the system. Trace signals are associated with each of the following channels: ARTRACE, RTRACE, AWTRACE, WTARCE, BTRACE.

User Loopback Signaling

User Loopback signaling enables a component to store transaction information in an indexed table and then use a fast table index to obtain the required information to respond to the transactions, rather than requiring a more complex lookup that uses the transaction AxID.

Quality of Service (QoS) Accept Signaling

QoS Accept signals are additional interface signals that enable the subordinate to indicate the minimum QoS value of transactions that it accepts. This permits the manager interface to only issue transactions that are likely to be accepted, which avoids unnecessary blocking of the interface.

Untranslated Transactions

The untranslated transaction feature permits components in the system to use their own virtual address space but ensures that the addresses for all transactions are eventually translated to a single physical address space for the entire system. Additional signals are added with this feature to provide sufficient information for a System Memory Management Unit (SMMU) to determine the translation that is required for a particular transaction and permit different transactions on the same interface to use different translation schemes.

Non-secure Access Identifiers (NSAID)

AXI5 provides a set of signals that enable access to non-secure memory locations AXI5 provides a set of signals that enable access to non-secure memory locations, which needs to be controlled to support the storage and processing of protected data. These signals provide an NSAID with the transactions request. This identifier can be checked to permit or deny access to a memory location.

Read Data Chunking

When an AXI manager issues a read request, there was previously a requirement for data to be returned in an order and width determined by the read address and burst type. The read data chunking feature enables the subordinate interface to return read data in any order and partial read data beats. To enable read data chunking, additional signals are added to the read address and read data channel.

Unique ID Indicator

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. The AXI5 unique ID feature 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.

Memory Partitioning and Monitoring (MPAM)

MPAM is a feature for partitioning and monitoring memory system resources for physical and virtual machines. MPAM partition identifiers are attached to transactions, transported through AXI interfaces and system components to partition resources appropriately.

Poison Signaling

Previously, the poison signaling feature was used to identify data corruption. With AXI5, passing the poison signaling alongside the data permits any future user of the data to be notified that the data might be corrupt. ²ÝÁñÉçÇø Verification IP for AMBA AXI5 has a mechanism to track the poison value associated with a given address.

Parity Check Signals

Interface parity extension is specifically helpful for use in applications such as automotive designs, which have resilience or functional safety requirements that need to detect errors and possibly correct. AXI5 VIP uses odd parity so check signals are supported with all data signals and control signals.

Key features of AXI5 that are supported by ²ÝÁñÉçÇø VIP for AMBA AXI5 include: Atomic operations to improve the performance, data check and poisoning to identify data corruption, low power wakeup signal to support the low power requirements of the designs, convert detected parity error into associated poison values, and track the same for a given address, and an elegant mechanism from subordinate VIP agent, to dynamically control the QoS Accept signal values.

²ÝÁñÉçÇø offers a broad set of verification solutions for next generation Arm AMBA protocols, including the AXI5 protocol that is part of the AMBA AXI and ACE Issue H specification. ²ÝÁñÉçÇø has collaborated with Arm during the development of ²ÝÁñÉçÇø VIP for AMBA AXI5, that has helped result in faster verification closure of several AXI5 based designs.

²ÝÁñÉçÇø 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.

You can read some of our past AMBA-related blogs . To learn more about ²ÝÁñÉçÇø VIP & Test Suits for AMBA protocols please visit