Introduction

Functional verification is the process of confirming that an implementation has preserved the intent of the design. The intent of the design might be initially captured in an architectural or micro-architectural specification using a natural language, while the implementation might be captured as an RTL model using a hardware description language. During the verification planning process, there are three fundamental issues that must be addressed: what functionality of the design must be checked (observability), how the design is to be checked (input scenarios and stimulus), and when the verification process is complete (which is often defined in terms of a functional or structural coverage model). Although input stimulus generation, coverage measurement, and output checking are tightly coupled conceptually, contemporary simulation test bench infrastructures generally separate these functions into loosely coupled verification components. This chapter discusses response checking, monitors, and assertions as techniques of specifying design intent in a form amenable to verification.

Identifying what to check

Prior to creating response checkers, monitors, or assertions, it is necessary to identify what must be checked, which is generally part of a project's verification planning process. Figure 3.1 illustrates an abstract view of a typical design flow. The flow begins with developing a natural-language requirements document, which we refer to as an architectural specification. Next, we create an architectural model to validate the algorithmic concepts. Once validated, the architectural specification is refined; this shifts the focus from an algorithmic view of the design to a performance and feature view required for implementation. We refer to this as the micro-architectural specification, which partitions the architecture into a number of functional blocks.