|
Functional coverage systematically creates functional coverage models, each containing a large set of verification (coverage) tasks, and monitors the testing to see if these tasks are performed. Functional coverage models come in many flavors. Models can cover the inputs and outputs of the program, or they can look at the internal state of the program (e.g., values of variables). Functional coverage models can be snapshots of program state ( snapshot models), that look at the state of the program at a certain point in time, or they can be temporal models, scenarios. Usually, functional coverage models involve looking at several properties in parallel. Functional coverage models can be based on the specifications of the application (Black Box), but they can also be derived from the implementation (WhiteBox). Using a black box functional coverage model most strongly differentiates functional coverage from code coverage, whereas a white box approach brings the technique very close to traditional code coverage.
In the functional coverage process, the first and most important step to choose a coverage model (that is, what are the "interesting" attributes of the program). For coverage to impact the testing process, it is critical to create good coverage models. Models should cover areas which the user thinks are risky or error prone, and the size of the model should be chosen in accordance with the testing resources. The model size (number of tasks) should not be so large as to make, impractical to cover the model.
One historical problem of functional coverage is lack of generic tools. This stems from the uniqueness of coverage models More recently, tool builders have recognized common processes and generic needs [7]. In every application of functional coverage, Tasks must be updated in tables, regression suites must be created, and coverage reports must be made on sub models and on progress. Using these generic tools at HRL, we have successfully created more than 100 coverage models for a number of customers to use with a wide variety of applications (mainly hardware).
The ability of functional coverage (and hence testing) to focus on points of interest carries a certain risk. If only functional coverage is used, then only the points of focus will be tested thoroughly (and other points will be neglected). Creation of coverage models then requires effort, the parts which are not of special concern could be neglected. For these parts, it is better to use generic, off-the-shelf, code coverage models, rather than nothing at all.
| 
