SoC Test and Verification -> Coverage analysis essential in ATE

Once there is enough line or statement coverage, designers will add more sophisticated control-path metrics such as branch, expression and path coverage to ensure the thoroughness of tests in covering control flow through the HDL code. Toggle coverage is often used to ensure that all block-interface signals have toggled from 0 to 1 and 1 to 0; it is also sometime used as a presynthesis guide for toggle vectors required in manufacturing test.

Leading commercial coverage analysis solutions provide most or all of these metrics in a common environment, allowing coverage closure to be assessed in a single view. Some tools even provide this single view across multiple simulators and design languages, allowing for additional flexibility in selecting desig n and verification resources.

With the increasing use of both internal and third party design IP, coverage analysis results have become an important independent measure of the thoroughness of an IP creator's verification process. In fact, leading IP portals such as Design & Reuse (www.design-reuse.com) now provide a way for IP vendors to publish coverage analysis results, among other things, as a measure of IP quality.

Performance is a concern for all simulator users, and much progress has been made in recent years in reducing the simulation overhead imposed by coverage measurements. Modern coverage analysis tools eliminate PLI calls during simulation run time, thus allowing the instrumented design to run at the full rated speed of the simulator. This approach results in an overhead of typically between 20 percent and 2X, depending on the design style and the metrics used. In addition, advanced coverage tools can generate instrumentation written in synthesizable RTL, allowing coverage to be coll ected on hardware emulators, providing for even faster throughput as well as a consistent view of verification status between simulation and emulation.

FSM coverage deserves special attention given the important role FSMs play in controlling many designs. It has been shown that developing tests to increase FSM coverage has detected difficult-to-find bugs. Traditional FSM coverage metrics include visited state coverage, which ensures that every state of an FSM has been visited, and FSM arc coverage, which ensures that every transition between FSM states has been traversed. Design teams usually aim for more than 95 percent coverage on these metrics, but it is possible to achieve even 100 percent state and arc coverage without exercising all functionality of the FSM. Thus, visited state and FSM arc and coverage do not necessarily measure the extent to which the control functionality of the FSM has been tested.

The FSM path-coverage metric overcomes these shortcomings. Although state and arc coverage are very useful measures because of their close correspondence to the behavior of the design, FSM path coverage provides a more complete representation of a design's control functionality. FSM paths are a combination of arcs that connect states in the FSM. However, there are a large number of potential paths in typical state machines, so measuring their coverage has been problematic.

A recent innovation in commercial coverage analysis tools such as TransEDA's VN-Cover is the ability to automatically extract all FSM paths and provide a concise metric that fully represents the FSM paths without explicitly listing all of the individual sequences through the FSM. Criteria to concisely represent FSM paths and their coverage:

• Separate initialization behavior from cyclic.

• Identify cyclic behavior.

• Combine small cycles into the larger cycles that may be present in an FSM.

• Allow measurement of paths reached compared with possible paths.

By identifying the cyclic beh avior, FSM path coverage metrics provide a representation of the design's functionality without being lost in the details of each individual FSM sequence. Three types of paths can clearly describe FSM behavior. First is a link that is a directed set of states that does not repeat — for example, an initialization sequence. Second includes a cycle that is a directed set of states that returns to its starting state without passing through any state more than once. And third is a supercycle, a longer cycle that connects with shorter repeating cycles. Supercycles are used to identify the high-level design functionality and provide a concise summary of the overall structure of the FSM. Supercycles report design functionality that is not apparent to the user when looking at the FSM.