As of July 1, 2021, Google will discontinue the RSS-to-email subscriptions service.
Hence, the email alerts will be impacted while we explore other options. Please stay tuned for further communication from us.
As discussed in the previous blog, the AMBA® 5 specification updates introduced several performance improvement features which align the AMBA5 ACE/AXI protocol with AMBA® 5 CHI (Coherent Hub Interface) specification.
Among them is a new class of atomic transactions which make operations at the remote locations more streamlined and efficient. Another new transaction class includes the new cache stash transactions which install a cache line in the cache of another component in the system, moving it closer to the point of use, thus improving the overall system performance. There are new ReadOnceCleanInvalid and ReadOnceMakeInvalid de-allocating transactions which essentially combine ReadOnce transaction with cache line invalidating CleanInvalid or MakeInvalid transactions. The primary use of these transactions is to read the cache line data and de-allocate it in the remote cache when it is known that the cache line is no longer required. This helps to ensure better availability of the cache resources in the system.
And then, there are other miscellaneous improvements such as Data Check and Poison functionality, Trace and Loopback signaling, and others.
All AMBA5 features, including the recent Issue G and Issue H updates, are supported in Cadence dual-mode ACE/AXI Verification IP (VIP). Like any high-quality VIP, Cadence ACE/AXI VIP delivers three major capabilities listed below.
1) Stimulus generation
The complexity of verifying AMBA5 designs requires the use of Verification IP which fully models the protocol behavior of various types of masters and slaves in the system. This offloads the user from having to know the intricate protocol details required to create all legal transactions defined in the spec. Any high-quality VIP must also provide the capability to issue illegal transactions for negative testing and include an assortment of callbacks for low-level transaction control.
2) Protocol and Coherency checking
Each master and slave DUT must be verified individually to ensure its compliance with the specification. While it is very important, it is not sufficient in the interconnect-based systems. In such systems, the ACE/AXI VIP must team up with an interconnect verification component – System Verification Scoreboard - that watches traffic on all the interconnect’s interfaces. This is necessary to ensure correct operation of the entire system. This means the ACE/AXI VIP and System Verification Scoreboard are required to perform two key tasks:
a) Ensure that each individual component (e.g. processor, memory controller) behaves correctly according to the protocol
b) Monitor the interconnect to ensure that communication between all components is accurate and in compliance with system requirements
Item (a) is enabled by the ACE/AXI VIP agents. Once the user has integrated the SoC's IP blocks with the interconnect, the VIP can be used as a passive agent so it can monitor each individual interface to ensure protocol compliance.
To enable item (b), a separate System Verification Scoreboard is required. Without such an interconnect VIP, it is impossible to verify full interconnect-based system, including its coherent functionality. This monitor must check data integrity and correctness of the interconnect itself to be sure it is behaving in compliance with the specification.
3) Coverage Simply defining all the complex scenarios to be tested is a major investment in and of itself. Yet, this is not enough. A proper verification solution must also enable users to measure and ensure completeness of the verification space.
A functional coverage model is used as the metric for determining verification completeness. Therefore, it is imperative that the VIP provide the complete coverage map based on the target specification.
Beyond the protocol coverage there is also a need for system-level coverage which enables verification engineers to see which masters communicate with which slaves, which agents have been snooped, or issued snoops, etc. Such coverage model is an integral part of System Verification Scoreboard which will be discussed in-depth in the next installment of the blog. Stay tuned!