Coverage is an important measure for the quality and completeness of the functional verification of hardware logic designs. Verification teams spend a significant amount of time looking for bugs in the design and in providing high-quality coverage. This process is performed through the use of various sampling strategies for selecting test inputs. The selection of sampling strategies to achieve the verification goals is typically carried out in an intuitive manner. We studied several commonly used sampling strategies and provide a probabilistic framework for assessing and comparing their relative values. For this analysis, we derived results for two measures of interest: first, the probability of finding a bug within a given number of samplings; and second, the expected number of samplings until a bug is detected. These results are given for both recurring sampling schemes, in which the same inputs might be selected repeatedly, and for nonrecurring sampling schemes, in which already sampled inputs are never selected again. By considering results from the theory of search, and more specifically, from the well-known multiarmed bandit problem, we demonstrate the optimality of a greedy sampling strategy within our defined framework.

We present a framework for validating the compliance of a design with a given architecture. Our approach is centered on the concept of misinterpretations. These include missing behavior, wrong understanding of a behavior, or confusion with similar behavior described in the architecture or elsewhere. We formally capture the architecture behavior in the form of flowcharts and automatically derive a list of architecture misinterpretations from these flowcharts. These misinterpretations constitute the backbone of coverage models targeted by a suite of tests. The suite is automatically generated by a model-based test case generator. A compliance validation system based on these principles has been developed and used in two actual industrial processes of checking compliance with the PowerPC architecture.

Coverage analysis is used to monitor the quality of the verification process. Reports provided by coverage tools' help users identify areas in the design that have not been adequately tested. Because of their sheer size, the analysis of large coverage models can be an intimidating and time-consuming task. This paper presents several techniques for coverage analysis. These techniques range from highly interactive and dynamic analysis that allows users to focus on certain aspects or areas of interest in the coverage model to fully automated coverage analysis, which identifies uncovered or lightly covered areas. The proposed techniques provide additional means for extracting relevant, useful information, thereby improving the quality of the coverage analysis. A number of examples show how the proposed method improved the verification of actual designs

This paper describes the efforts made and the results of creating an Architecture Validation Suite for the PowerPC architecture.Although many functional test suites are available for multiple architectures, little has been published on how these suites are developed and how their quality should be measured.This work provides some insights for approaching the difficult problem of building a high quality functional test suite for a given architecture.By defining a set of generic coverage models that combine program-based, specification-based, and sequential bug-driven models, it establishes the groundwork for the development of architecture validation suites for any architecture.

Even though the importance of microprocessor design verification is widely acknowledged, no rigorous methodology is being commonly followed for its realization. This paper attempts to delineate such a methodology, and shows how it is promoted by Genesys, an automatic pseudo-random test-program generator. The methodology relies on a verification plan which induces smart sets of tests that carry out the verification tasks. The paper reports on an application of this methodology, using Genesys, to verify an x86 design and describes, in particular, how this methodology could have helped to avoid known escape bugs, such as the recent two infamous Pentium Floating Point bugs.