In this chapter, we discuss the verification of the HW/SW components of the design that result from the earlier partitioning step. Some people may ask the question, “Why does verification start after the partitioning phase?” The truth is that it does exist before this point, but it is dealt with in a different manner than is typical after this point. The primary difference is that after partitioning, pieces of the complete system have been separated into chunks—such as hardware and software—and very quickly within each of these, further subdivisions are performed. This means that large parts of the original system context are lost, which requires that the problem be looked at in a different manner. In addition, a division of labor tends to begin at this point. Many companies employ different teams of people to perform the system architecture, design, and verification tasks. This leads to a specialization in the groups, which probably means that not every reader of this book will be as interested in this chapter as they are in some of the others, whereas others will see this as one of the more important chapters of the book. Another way to look at the differences is that many of the aspects that are verified before this point are statistical in nature rather than relying on discrete events. As an example, most performance characteristics are about throughput over a period of time and would be captured in a statistical manner, whereas verification at this point in the development process would be more concerned with finding the one case where a minimum throughput was not achieved, as required by the specification.

There is another important distinction that happens at this point. Although many people would claim that the entire design process is an art rather than a science, this is especially true before the partitioning stage. It is the world of estimation, approximation, and, in many cases, discovery. That requires a very different process than would normally be used for implementation at the RT level. Discovery and experimentation tend to be too expensive at the RT level, but are quite feasible when dealing with abstract models. This means that making a decision and checking its impact in the post-partitioned models are very closely coupled in a loop that, it is hoped, converges on an acceptable solution. Verification is very much a part of the design process itself. As in the scientific process, we have a problem; we make a hypothesis as to how it can be solved; and then perform an experiment to see if it has the desired effect. We expect it to be iterative.

10.1 Introduction
    10.1.1 Facets of Verification
10.2 Verification Planning
    10.2.1 What Is the Scope of the Verification Problem?
        10.2.1.1 Specification Analysis
        10.2.1.2 Coverage Model Top-Level Design
        10.2.1.3 Coverage Model Detailed Design
        10.2.1.4 Hybrid Metric Coverage Models
    10.2.2 What Is the Solution to the Verification Problem?
        10.2.2.1 Stimulus Generation
        10.2.2.2 Response Checking
    10.2.3 Verification Planning Automation
10.3 Verification Environment Implementation
    10.3.1 Write Verification Environment
10.4 Verification Results Analysis
    10.4.1 Failure Analysis
    10.4.2 Coverage Analysis
10.5 Abstract Coverage
10.6 Other Approaches
    10.6.1 Turning the Tables
    10.6.2 Mutation Analysis
    10.6.3 The Role of Prototyping
    10.6.4 Platform Verification
10.7 Provocative Thoughts
10.8 Summary
10.9 The Prescription

Errata

Feedback