In many verification environments, we reuse the same configuration cycles across different testcases. These cycles may involve writing and reading from different configuration and status registers, loading program memories, and other similar tasks to set up a DUT for its targeted stimulus. In many such environments, the time taken during these configuration cycles is very long. Also, there is a lot of redundancy as verification engineers have to run the same set of verified configuration cycles for different testcases leading to a loss in productivity. This is especially true for complex verification environments with multiple interfaces which require different components to be configured.
In the last post of this series, we focused on the first level of testing required for verifying an AXI/ACE Compliant Interconnect — Integration/Connectivity testing. In this post, we will focus on basic coherent transaction testing. We use the term basic to signify something that is a prerequisite before we move on to more advanced testing. Coherent transactions are a set of transactions used in the AXI/ACE protocol to perform load and store operations. Each of these transactions have a different set of response requirements from the Interconnect. Further, each of these transactions can be used in multiple configurations. We need to verify that the Interconnect works correctly for each of these transaction types. We will first give an overview of the protocol before moving on to a testing strategy for these.
Posted in AMBA
As designers, we face many challenges during the SoC design cycle: the architecture goes through several iterations; bus speeds can vary; peripherals may be added or removed; the software becomes more complex. How can we ensure that our selection of memory will keep up with all these changes, some of which can occur a few weeks before functional closure?
The AMBA 4 specification for the connection and management of functional blocks in a system-on-chip (SoC) now features Advanced eXtensible Interface (AXI) coherency extensions (ACE) in support of multi-core computing. The ACE specification enables system-level cache coherency across clusters of multi-core processors. The verification of such a system poses significant challenges. When planning the functional verification of such a system, we need to have an effective testing strategy to ensure not only that all aspects of the protocol are tested, but also that bugs are caught with the least effort. In other words, we need to have a hierarchical testing strategy where we progress from simple sequences to more complex sequences. The aim is to catch as many issues with the simpler sequences so that as we move to the more complex sequences where the problem space is much larger, we have fewer bugs to deal with. In this series, we will propose such a hierarchical verification strategy. Each post in this series will describe:
Posted in AMBA