Achieving Functional Verification Closure

by Tom Anderson

It is human nature to prefer yes/no answers to yes/no questions. Design and verification engineers, being human, are no exception. As much as possible, engineers like to prove that something is (or is not) so. This achieves closure to the question or problem at hand and makes it easier to move on to the next issue. For example, a design engineer may want to know whether or not a chip will operate at its intended frequency. The combination of accurate silicon delay prediction and a robust static timing tool may answer the question of whether the chip meets timing with a definitive "yes" and give the engineer the confidence to tape out.

Unfortunately, very little of the chip verification process is amenable to yes/no answers. Perhaps the most difficult area of all is functional verification - answering the question of whether the chip functions as the designer and architect intended. It is very hard, perhaps impossible, to say definitively that a design has been completely functionally verified. Project managers, being human too, always want to know when the chip is "done" even if no simple answer is feasible. The engineers may hedge their answers for a period of time, but ultimately someone must either decide that functional verification is "done enough" to tape out, or give up and cancel the project.

The bottom line is that achieving true functional verification closure, and therefore taping out with full confidence, never happens. The decision to tape out is always a judgment call. Successful engineers achieve a sufficient level of closure and confidence based on a combination of verification thoroughness metrics, the rate and complexity of functional bugs being found, and their own experience and judgment. This article focuses on the various metrics that might be available from different stages of the functional verification process and discusses how they can be used to assess the degree of closure.