| The new Amba Advanced eXtensible Interface (AXI) is the next-generation Amba interface developed by ARM and targeted at high-performance, high-frequency system-on-chip designs. The new functionality and complexity of the AXI bus structure demand a higher degree of SoC verification to ensure a right-first-time design. Effective use of verification methodologies, tools and verification intellectual property (IP) ensures that the validation task is efficient, simplified and effective. A typical AXI-based SoC includes buses using the Amba AXI, AHB and APB protocols, plus additional interfaces to off-chip buses such as PCI Express, USB, Serial I/O and I2C. Writing models from scratch for those protocols would entail hundreds of thousands of lines of code and engineer-years of effort. This makes in-house development of the complete testbench environment impractical. Therefore, one of the primary building blocks for efficient AXI-based testbench development is a range of qualified, proven verification IP to test the various standards on the chip. Verification IP should be sourced from a trusted and established supplier. Debugging low-cost, low-quality verification IP prolongs SoC project schedules and does not provide the foundation for an effective verification environment. At a minimum, verification IP reduces the verification coding demands and provides the base protocol functionality for the testbench. However, verification IP must also provide the infrastructure and communication necessary to enable a self-checking, coverage-based, automated verification environment. In the race to achieve coverage goals, traditional directed-test methods are not sufficient to achieve what's needed in the time available. A layered testbench based on constrained random testing (CRT) provides a more effective strategy for achieving the highest coverage in the shortest amount of time. Constrained-random methods enable engineers to meet coverage goals using a small amount of directed tests to complete the task. The use of CRT significantly shortens the time needed to develop testbenches by removing the need to explicitly write every test. A CRT environment verifies most of the basic protocol transactions, such as read and write operations, in the early stages. Once in place, the randomization covers a wider range of tests, including sequences of operations and corner-case behaviors. The verification environment records and scores the results of the constrained-random verification runs to provide functional coverage. Code coverage can also be assessed at the same time using built-in simulator features. After analyzing the results of the test runs, constraints can be adjusted to exercise areas of the design with low functional coverage. In some cases, it may be preferable to develop a few directed tests to target specific areas that were not covered by the CRT process. Using verification IP enables verification engineers to quickly assemble a testbench environment for the design under test (DUT). Features integral to the verification IP support this verification. Verification IP supports transaction coverage reporting and the ability to notify the test environment that a specific event has occurred, for example, that a read transaction to address c0c0 (hex) has completed. This makes functional coverage assessment much easier. The problem of verifying an AXI-based SoC can be broken down into three basic phases: block level, subsystem level and chip level. Since a different mix of verification IP and the actual RTL design is used at each level, a layered testbench is needed to support verification progress through those phases. Built on the foundation of verification IP, a layered testbench provides a structure for reuse and efficient verification. Thus, verification of an AXI-based SoC requires adoption of a layered, CRT-based testbench built on a portfolio of verification IP and supported by effective coverage metrics. The use of verification IP and the development and use of the testbench should be performed under the guidance of a comprehensive methodology. An effective methodology must address how to efficiently assemble and use a constrained-random verification environment and how to use coverage metrics to drive the verification process. For instance, Synopsys provides a Vera reference verification methodology that serves those purposes. As a design example, consider the development of an AXI slave. Verifying this design requires effective use of advanced verification techniques in all three phases. At the block level, a verification IP model for an AXI master is connected to the DUT with the associated bus interconnection. With the master verification IP connected to the slave DUT, tests can be built to verify address mapping and the ability of the DUT to handle all the different types of AXI transactions. Combining those tests with the ability to generate constrained-random transactions allows testing of the DUT's capabilities in handling various sequences of transactions. Moving up to the subsystem level, the same strategy is used but more elements of the system are added into the verification environment. An AXI-based SoC can contain multiple masters and slaves along with an interconnect switch matrix to route transactions between elements in the system. Verification must address more complex interactions within the subsystem. One possible problem is that when different masters access a variety of slaves, latency caused by a particular master-slave combination can monopolize the interconnect matrix. The following is a typical verification process that detects this type of problem: - Develop a sanity check test to verify that address mapping is correct and the DUT responds to transactions in the subsystem configuration.
- Configure all masters and slaves for CRT.
- Run the constrained-random tests with transaction coverage feedback from the monitor to gauge the completeness of the testing.
- Write a few directed tests to fill in any coverage areas not addressed by CRT.
The goal of verification at the subsystem level is to gain a high confidence that the DUT will function in the overall SoC without problems. For chip-level verification, verification IP models for the AXI masters and slaves are replaced with the corresponding RTL models. The AXI elements that implement standard protocol interfaces are connected to other verification IP models that provide stimulus and response to each of the AXI component blocks. With this broad portfolio of verification IP, the verification team can quickly assemble a full SoC simulation. The same strategy used at the subsystem level works for the full SoC: Do a quick sanity check to verify that all elements can be configured and can send and receive data; set up the CRT to drive transactions to the SoC and monitor the coverage; and develop directed tests based on the coverage information to test any uncovered areas. The most effective methodology for verifying all levels of an Amba AXI-based system is to use a defined and structured constrained-random test approach built on a foundation of high-quality verification IP. A wide portfolio of verification IP may be required as the verification process moves from block level to chip level. Using verification IP with a consistent methodology eases testbench development and leads to better interaction between the verification IP and the design itself. Neill Mullinger (Neill.Mullinger@synopsys.com) is the DesignWare product marketing manager and Jay Hopkins (jay.hopkins@synopsys.com), is the CAE manager at Synopsys Inc. (Hillsboro, Ore.). | 
