Verification reuse enables design reuse

Perhaps the largest single factor in the limited success of IP design reuse has been the lack of attention to corresponding verification reuse. It has too often been the case that any savings in design time gained by using VCs has been more than offset by an increase in the verification time. Given that functional verification already consumes 60-80% of the effort on many SoC projects, this is not a formula for market success. Even if the VC provider does an outstanding job of stand-alone verification, the VC must ultimately be verified (essentially re-verified) in the context of the full SoC.

The solution is clear. The VC provider (internal or external) must consider verification reuse when providing the total IP package to the SoC team; VC integrators in turn must dem and reusable verification components from their providers.

VC verification is a complex problem. The typical stand-alone VC verification environment consists of many components, including transaction and stimulus generators, verification test suites, results checkers, protocol monitors on the ports and internal assertions to check that the VC is always operating correctly.

Certain portions of stand-alone VC verification environments may easily be reused at the full-SoC level. An interface VC such as a PCI or UTOPIA controller typically sits on the external I/O of the SoC, so the interface ports connect to chip pins. Thus, the bus stimulus generation and results checking elements from the stand-alone verification environment may also be used at the chip level. Any tests that stimulate only the external bus may be reusable as well, since these VC ports are directly accessible from the SoC verification environment.

However, an interface VC always has another set of ports, often cal led the application interface, connecting the VC to the rest of the SoC. Any generators that stimulate this interface are not directly reusable since the application interface is buried within the SoC and not directly accessible. Adding to the complexity, many VCs, including embedded processors, have only application interfaces, making verification reuse even more challenging. Stand-alone VC test vectors may be reusable within the SoC if direct access to all the VC ports is provided via a test bus or an internal boundary scan chain.

For any VC — interface, processor or anything else — assertion-based elements of the stand-alone verification environment are inherently reusable. The protocol monitors on the VC ports can be built on assertions; each temporal protocol rule can be captured by an assertion that can be combined with other assertions to build monitors for complete protocols. Thorough protocol monitors are essential for verifying that all rules for legal interaction between parts of a design are being followed.

Violations reported
The monitors on application interfaces are very useful when integrating a VC into the SoC. If the SoC designer makes a mistake hooking up the VC and stimulates it incorrectly, then an assertion violation is reported in simulation.

Some VCs also contain assertions that watch for proper behavior of internal structures. If a FIFO overflows, or a state machine makes an illegal transition, or data is corrupted within the VC, then an assertion violation is reported. This may indicate a misuse of the VC or a design bug within the VC itself. Either way, it is far better for the SoC designer to detect the problem during simulation and take corrective action than to build silicon with a bug.

Internal assertions are most common and most valuable for VCs delivered in RTL form, since the assertions can be written in-line, within the RTL code describing the design. Pseudo-comment formats are ideal since they allow asser tions to be specified in the context of the RTL itself without interacting with synthesis or RTL analysis tools.

Beyond simulation, formal verification can provide even more leverage for the VC port and internal assertions. Formal methods provide more thorough verification of stand-alone IP; small, simple VCs may be verified with static formal tools such as model checkers or property checkers. In these cases, the internal assertions usually constitute the properties to check while the assertions on the ports form the basis for protocol rule constraints. Larger and more complex VCs benefit from the greater capacity of dynamic formal verification, which layers formal methods on top of existing simulation tests to explore new behaviors and find corner-case bugs.

Some SoC teams also use formal methods as an essential part of their functional verification process. Since it can operate at the full-chip level, dynamic formal verification also is effective at checking that VCs are integrated cor rectly. Assertions within application interface protocol monitors can be used as formal constraints for the SoC logic that connects to the VC as well as for the VC itself. This allows VC integrators to formally check their own logic to ensure that they are not misusing the IP they have adopted. Robust interface assertions with dynamic formal verification provide a symmetrical solution: the provider ensures that the VC operates properly when connected to any type of application logic while the integrator checks that the application logic handles all possible behavior from the VC.

All of t hese issues covered are being addressed by the Functional Verification Development Working Group (DWG) within the Virtual Socket Interface Alliance (VSIA). The DWG is in the final stages of developing a specification for thorough stand-alone functional verification of VCs as well as effective verification reuse at the SoC level. This specification will foster effective design reuse of all kinds, encourage VC p roviders to encompass verification reuse within their total package and help SoC teams demand the best from their internal or external semiconductor IP suppliers.