Verification IP adapts to SoC complexity

In order to meet a project's coverage goals, engineers are increasingly adopting constrained random test generation environments. This methodology allows the user to quickly get to first test then randomly test the interface within the constraints of the application to achieve higher coverage with a significantly reduced testbench develop ment effort. By using constrained random testing in combination with directed tests, users are able to verify corner cases and find unanticipated usages. The creation of these tests can be developed in an extraordinarily short amount of time because a few dozen lines of constrained random expressions will create thousands of tests. This then allows users to focus on getting as close as possible to complete protocol and application-specific coverage by filling in the gaps with directed testing.

To illustrate this, let's consider an AMBA-based design with two AHB master devices and two AHB slave devices. The AMBA bus has a high-speed main processor (AHB) bus and a low-speed peripheral bus (APB) that is connected to the AHB by a bridge. There is arbitration and control logic for the AHB. The AHB can support multiple master and slave devices, and the APB can support multiple slave devices. This is common among today's new bus designs but makes the verification task more complex.

The individual blocks are first tested stand-alone for protocol compliance using a mixture of directed and randomized tests, and then the complex interaction and data flow between the devices must be modeled and verified. If we just focus on the AHB slave devices, there are four types of possible responses that the slave can send to the master: OKAY, SPLIT, RETRY and ERROR. In addition to the responses, there are N wait states that the slave device can insert while servicing a request. Multiply this by two slaves, and there is a large number of potential states that needs to be accounted for during verification. Trying to cover all of these states with standard, directed HDL testbench techniques would be a huge task. In the example design, the goal is to verify the arbitration and control logic under a variety of conditions and loading. Given the potential number of states and transactions, directed testing is not a viable option for verifying the design.

Next-generation verification IP must provide mechanisms to e asily define and monitor application specific behavior. Therefore, verification environments must not only generate and respond to constrained random stimulus, but the monitor (the portion of the VIP that does protocol checking and performs coverage checking) must also be able to check for complex coverage rules, including application-specific sequences of transactions, and application-specific coverage points.

Techniques such as constrained random testing and programmable coverage monitoring greatly increase verification productivity, but they do not fulfill their full promise unless they are available to everyone on the project doing verification. This means that to be fully effective, verification IP must offer FULL functionality not only for those using hardware verification languages (HVLs), but Verilog, VHDL, C, SystemC, and SystemVerilog. For example, a verification engineer may be driving subsystem verification using Vera, but the design engineer may verify his block using Verilog. The verif ication goals of the project are greatly enhanced if the engineer designing the block can:

a. Run a full suite of constrained random tests

b. Write block-level application-specific tests and coverage points

c. Pass this information to the verification engineer using Vera

Assertion-based verification IP, which supports formal verification methods, is a logical next step to accelerating the productivity of verification engineers. Assertion checkers alone, however, are not sufficient. Assertions will become the engines of verification IP monitors, enabling formal verification methods to be easily added to the verification engineers' arsenal. To use assertion checkers, users must already have the means in place to generate protocol-compliant transactions and respond to requests from the device under test. To write these into the testbench requires an extensive knowledge of the protocol. Therefore, the better approach is to use verification IP to provide driver and responder functi onality combined with assertions to enable a complete protocol testing environment.

See related chart