As the complexity of today’s ASIC and SoC designs continues to
increase, the challenge of verifying these designs intensifies at an even
greater rate. Advances in this discipline have resulted in many sophisticated
tools and approaches that aid engineers in verifying complex designs. However,
the age-old question of when is the verification job done, remains one of
the most difficult questions to answer. And, the process of measuring verification
progress is poorly understood.
For example, consider automatic random stimulus generators, modelbased
test generators, or even general-purpose constraint solvers used by
high-level verification languages (such as e). At issue is knowing which portions
of a design are repeatedly exercised from the generated stimulus — and
which portions of the design are not touched at all. Or, more fundamentally,
exactly what functionality has been exercised using these techniques. Historically,
answering these questions (particularly for automatically generated
stimulus) has been problematic. This challenge has led to the development
of various coverage metrics to aid in measuring progress, ranging from code
coverage (used to identify unexercised lines of code) to contemporary functional
coverage (used to identify unexercised functionality). Yet, even with
the development of various forms of coverage and new tools that support
coverage measurement, the use of these metrics within the verification flow
tends to be ad-hoc, which is predominately due to the lack of well-defined,
coverage-driven verification methodologies.