IP Verification : Standards eye functional verification

Unfortunately, design reuse does not always work out as well as SoC project teams hope. This may be due to a number of factors, but functional verification is often the biggest issue. To have any chance of first-silicon success, four critical areas must be addressed by anyone providing design IP in the form of a virtual component (VC) for integration into an SoC. The VC provider must:

• Perform thorough standalone functional verification of the VC;
• Furnish documentation of the standalone verification;
• Supply a verification environment along with the VC;
• Enable the VC integrator to verify the VC in the context of the full SoC.

Recognizing the importance of effective verification to SoC success, considerable industry resources are committed to developing appropriate standards and solutions. Some of the earliest work was done by Motorola, whose Semiconductor Reuse Standards (SRS) encompassed functional verification as part of effective design reuse. Much recent activity has occurred within the Virtual Socket Interface Alliance (VSIA), which develops guidelines and specifications for VCs and SoCs containing VCs.

The VSIA Functional Verification Development Working Group (DWG) is looking at many aspects of functional verification for VCs and SoCs. The DWG has released a taxonomy of functional verification that is available on the VSIA Web site and is currently developing a specification defining how a VC provider should document the standalone VC verification and provide reusable elements as pa rt of the verification environment.

In many ways, verification reuse is as important as the functional verification performed on the VC itself. Even if the VC provider successfully performs thorough standalone verification on a VC, ultimately the integrator must confirm that the VC is working properly within the context of the SoC. A VC that is not properly connected within the SoC, or a VC that is being used in a way for which it was not designed, will end up as an example of design reuse failure. It is often said that design reuse can't be successful without verification reuse.

Most VC providers supply a verification environment along with the VC itself; a typical environment will include behavioral models to stimulate the VC inputs, behavioral models to check the results at the VC outputs, and a set of verification tests and protocol monitors for the VC interfaces. The integrator can use this environment to perform an "out-of-box" test on the VC to be sure that it was received correctly, but would also like to reuse some elements of the environment during SoC functional verification.

The most obvious form of verification reuse is the ability to run the same set of tests on the VC even after it is embedded in the SoC. Traditionally, designers have simply multiplexed the VC ports to the chip pins under control of a test-mode pin. This approach breaks down when the number of VC ports exceeds the number of chip pins or the SoC routing overhead for the additional signals becomes too high. Recent standards efforts have developed more-sophisticated methods to apply VC tests within an SoC. The VSIA Manufacturing Related Test DWG and the IEEE P1500 committee have aligned efforts to define scan-based rings around VCs to isolate them for application of dedicated test vectors. However, like the multiplexing approach, this technique is intended more for test purposes than for true in-context verification.

Reusable elements
It is generally hard to reuse the behavioral models fr om standalone VC verification since the VC ports are no longer directly accessible once they are embedded in the SoC. One exception is a VC connecting to a standard interface that also will appear on the SoC pins. In such a case, certain elements of the verification environment may be reusable for providing stimulus to the SoC or checking responses on the standard interface. VSIA's On-Chip Bus DWG has defined the VCI, a flexible standard interface applicable to most buses, suitable for this purpose.

Many VC integrators find that the protocol monitors on the VC interfaces are the most valuable part of the verification environment. Since protocol monitors passively monitor the interfaces, they are inherently reusable during functional verification of the SoC. The protocol monitor on the application interface is especially valuable since it alerts the VC integrator whenever the rules for use of the VC are violated.

The interface rules captured within a protocol monitor are actually particular e xamples of assertions-statements of design intent. Assertions can be made about many aspects of a VC, including rules for proper operation of data flow elements and control structures as well as the interfaces. The scope of the VSIA Functional Verification DWG includes assertions as well as leverage of these assertions in simulation and formal verification.

As a matter of fact, assertions are probably the most active area of functional verification standardization today. The Accellera language-standards organization has technical committees working on assertion libraries for Verilog and VHDL, an intrinsic assertion construct for the next version of Verilog (VHDL already has such a construct), and a formal verification language that will serve designs expressed in both RTL languages. Although these efforts are not specific for design reuse, they are highly relevant to VC verification and integration.

See related chart