As discussed in the previous installments of the blog, the recent update of the AMBA ® 5 ACE/AXI specification introduced several performance improvement features which align the AMBA5 ACE/AXI protocol with AMBA 5 CHI (Coherent Hub Interface) specification. Among them is the new class of atomic transactions, discussed in-depth previously. 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 of them are now supported in the Cadence dual-mode ACE/AXI Verification IP (VIP) which has been recently updated to support the latest in AMBA5 functionality. Like any high-quality VIP, Cadence ACE/AXI VIP delivers three major capabilities. They are: 1. Stimulus generation: Mimicking all possible scenarios to cover the full verification space 2. Protocol checking: Ensuring full compliance to the specification 3. Coverage: Measuring functional coverage and ensuring verification completeness 1) Stimulus generation The complexity of verifying AMBA5 designs requires the use of Verification IP which fully models the protocol behavior of the 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 be teamed with an interconnect VIP component – Interconnect Validator - 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 Interconnect Validator 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’s master and slave 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 Interconnect Validator 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 sufficient. 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 provides 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 masters have been snooped, or issued snoops, etc. Such coverage model is an integral part of Interconnect Validator which will be discussed in-depth in the next installment of the blog. Stay tuned!![]()
↧