As verification engineers move to more-sophisticated techniques for system-on-chip (SoC) designs, their planning process is evolving as well. Traditional test-based planning is being supplanted by more sophisticated verification plans tracking coverage and assertions. One factor in this change is the widespread adoption of SystemVerilog, which supports the specification of functional coverage points, assertions and testbench constraints. The increasing use of constrained-random testbenches as an alternative to hand-written tests is another major factor.

Traditionally, the verification process entailed identifying all the important features in the design, defining a set of directed tests to verify the features, writing the tests by hand, and running and debugging the tests in simulation. This approach works well for small designs, but SoC devices require thousands of handwritten directed tests to verify all the features. Hiring limitations, time-to-market pressures and the sheer tedium of writing tests all mean that a better technique is required. Constrained-random testbenches require the verification team to specify constraints that define the rules for the design inputs.

Once this setup work is done, a testbench automation tool or simulator can generate input stimulus to exercise the design. Variations in the generated tests can be introduced by altering the constraints, selecting different random seeds or biasing the values generated for the inputs. SystemVerilog provides the constructs necessary to define constraints, seeds and biases.

Evolving from directed to constrained-random tests requires a corresponding change in the verification planning process. A traditional test plan includes a list of features for the design, the tests to verify each feature and the status of the test. As tests are written, run and debugged, their status is updated in the verification plan. That plan might be maintained by hand in the form of a document or spreadsheet, or it might be updated automatically as part of a verification process automation (VPA) flow.

Directed tests are written to verify specific parts of the design. Constrained- random tests, on the other hand, can exercise many parts of the design simultaneously. This creates a challenge because there is no longer a clear line between features and tests.

The best way for the verification team to match the automatic tests with their corresponding design features is via functional coverage metrics. Both designers and verification engineers can specify functional coverage points that represent important design behavior. Specifying such a point is an executable way of saying that "verification is not complete unless this happens." Some of these points represent normal operation, while others reflect corner-case conditions where bugs are most likely to lurk.

With the focus shifted from tracking tests to tracking functional coverage, the traditional test plan must evolve.

In a modern verification plan, features are more precisely defined so that there is a one-to-one correspondence between each feature and a functional coverage point. As verification progresses, the plan can be updated automatically as part of a VPA flow.

SystemVerilog provides two basic mechanisms for specifying functional coverage. The first, cover groups, derives from hardware verification languages. Cover groups can contain multiple individual coverage points, allow "binning" of multiple values and support cross-coverage to track combinations of values. Because they are not supported by some RTL tools, cover groups are most commonly specified in the testbench.

The other mechanism, cover properties, can be specified in the design or testbench. The cover property construct is part of the SystemVerilog Assertions (SVA) subset, sharing temporal sequences and other building blocks with assertion specifications. Both cover group and cover property metrics can be collected and reported in simulators. Cover properties also are supported by some formal tools that allow SVA for assertions. The modern verification plan also can be used to track the SystemVerilog assertions specified in the design and testbench.

Early in the project, features are identified in the verification plan. Textual descriptions are added for both coverage points and assertions. As coverage points and assertions are added to the design and testbench, links are added to the plan. Coverage results (covered or uncovered) and assertion results (passing or failing) are reported against the plan.

The adoption of constrained-random testbenches, functional coverage and assertions fits seamlessly with the adoption of SystemVerilog. The value of these technologies is enhanced with an evolution of the verification planning process from simple test plans to VPA-driven verification plans. All of the tools and methodologies needed to take this next step in SoC verification improvement exist today.

Thomas L. Anderson (toma@cadence.com) is a product director for Cadence Design Systems in San Jose, Calif. His responsibilities include formal analysis and assertion-based verification.

    See related chart