The present day designs use standard interfaces for the connection and management of functional blocks in System on Chips (SoCs).These interface protocols are so complex that, creating in-house VIPs could take a lot of engineer’s development time. A fully verified interface should include all the complex protocol compliance checking, generation and application of different test case scenarios etc.
Our tool IDesignSpec automatically generate registers and memory interface which can interface with all the standard bus protocols. One of the outputs from IDesignSpec product is the Bus client RTL. The generation of this IP is challenging since what gets generated is based on the specification that the user provides.
For the reliability and credibility of our design, we need to ensure that it is fully compliant with the standard protocol. Testing out such dynamic designs is a huge task since the customer can create virtually any possible specification. So it is not a static IP that needs to be verified, nor is it a configurable IP. It really is a generated IP, so the task is an order of magnitude, more complicated.
If we take a look at the AMBA® buses, AXI4Lite bus protocol has different channels for reading and writing, which are designed to work simultaneously and this gives rise to a lot of complexity in the verification of the protocol. The AMBA AHB bus supports features required for high performance like interfaces with multiple slaves and masters and other complex functionalities like split transactions. So verification of such behavior with constrained resources, within a very tight schedule is challenging, to say the least.
We were fortunate enough to get access to Questa VIP (QVIP) for our design IP verification. Questa VIP provides a huge benefit to verify the DUT by plugging it into their testbench.
QVIP is easy to use and provides plug-n-play verification environment to verify the IP design and it has enabled the achievement of higher functional coverage results. It provides comprehensive test suite, which is well documented and covers different scenarios like simple read write transaction, back to back read write transaction with N cycle delays, simultaneous read and write transaction from different address channels, read and write channel with N cycle delays and so on. It helps to verify dual port and single port memory which is connected to the slave side. It also helped to verify the custom logic at the slave side.
QVIP enabled our team to verify the bus interfaces quickly and thus reducing the effort required by the engineers to develop a very comprehensive verification solution. As a result we were able to focus on other crucial task in our project and also maintained the quality and reliability of our design as expected by our customers.
Using QVIP for the end-to-end verification of IDesignSpec generated AXI4-lite, APB4 and AHB slave RTL
It provides complete UVM verification test bench environment for verifying any AMBA slave with sample wrappers for connecting to user’s slave and inbuilt sequences.
The easily understandable built-in examples in the VIP, explains different usage models like tests for simple read write, for coverage, to check backdoor access and ARM compliance. It covers memory models with N delays and provides proper response signals for the read and write transaction.
By the comprehensive protocol compliance checkers in the VIP, we were able to find bugs in areas like back to back transactions to the memories, with and without delays, simultaneous read write to different channels in AXI4-lite interface.
It provides easily configurable test bench environment, with knobs which enable configuration of the VIP for AHB and AHB-Lite.
VIP has examples of interface having multiple masters and slaves with inbuilt arbitration and address decoding mechanism. The number of masters and slaves are easily configurable.
The built-in sequence covers all kinds of master transfers and slave responses, ensuring maximum protocol coverage.
The VIP monitor checker contains assertions that warn the violation of interface protocol. These assertions can also be disabled through configuration.
It enables application of user’s stimulus very easily through sequences, with ability to provide inline constraints.
QVIP allows the closed loop verification, where it provides the verification plan and has inbuilt reusable scoreboards to collect the coverage data.
Couple of things that came up while using QVIP
To use the AHB/APB QVIP for verifying our slave RTL, we needed to constrain the addresses generated by the master, in order configure the slave for some specific addresses. We had to manually set the slave address range configuration in the test by using the methods “set_config_slave_end_address_range” and “set_config_slave_end_address_range”. The good thing is that in the newer version of QVIP (10.4c), slave address range is automatically set in the BFM through the system address map settings and hence we will not need to use the configuration variables to set the slave address range manually.
Another thing that came up is that most of the addresses in the range specified by the slave address range configuration methods as discussed above, were not hit. So we applied constraints directly to the slave address variable “rand bit [((AHB_ADDRESS_WIDTH) - 1):0] address” in the transaction class “ahb_master_burst_transfer”. My constrained address range was crossing the 1kb boundary, which is a protocol violation. But in QVIP, constraints to prevent crossing the crossing of 1kb boundary for a burst were already applied. This led to a randomization failure. To prevent this randomization failure, we could turn off the constraint specified by the QVIP, by setting constraint_mode(0).
The QVIP enabled us to easily find buggy areas that would have been hard to reach. We rely on Mentor Graphics for its complete verification IP solutions and excellent customer support. They empowered us to give a positive proof to our customers that our generated IP is compliant with the standard.