Coverage Cookbook/Coverage Examples (Practice)
Глава 1.4 из книги glasser_m__open_verification_methodology_cookbook__2009.pdf
Layered Organization of Testbenches
Just as a design is a network of design components, a testbench is a network of verification components. The OVM defines verification components, their structure, and interfaces. This section describes the essential OVM components.
OVM testbenches are organized in layers. The bottommost layer is the DUT, an RTL device with pin-level interfaces. Above that is a layer of transactors, devices that convert between the transaction-level and pin-level worlds. The components in the layers above the transactor layer are all transaction-level components. The diagram below illustrates the layered testbench organization. The box on the left identifies the name of the layer. The box on the right lists the type of components in that layer. The vertical arrows show which layers communicate directly. For example, the control layer communicates with the analysis, operational, and transactor layers, but not directly with the DUT.
You can also view a testbench as a concentric organization of components. The innermost ring maps to the bottom layer, and the outermost ring maps to the top layer. Some find it easier to understand the relationships between the layers using a netlist style diagram.
Figure 1-8 Concentric Testbench Organization
Transactors
The role of a transactor in a testbench is to convert a stream of transactions to pin-level activity or vice versa. Transactors are characterized by having at least one pin-level interface and at least one transaction-level interface. Transactors come in a wide variety of shapes, colors, and styles. We’ll focus on monitors, drivers, and responders.
Monitor. A monitor, as the name implies, monitors a bus. It watches the pins and converts their wiggles to a stream of transactions. Monitors are passive, meaning they do not affect the operation of the DUT in any way. Driver. A driver converts a stream of transactions (or sequence items) into pin-level activity.
Responder. A responder is much like a driver, but it responds to activity on pins rather than initiating activity.
Operational Components
The operational components are the set of components that provide all the things the DUT needs to operate. The operational components are responsible for generating traffic for the DUT. They are all transaction-level components and have only transaction-level interfaces. The ways to generate stimulus are as varied as the kinds of devices there are to verify. We’ll look at three general kinds of operational components: stimulus generators, masters, and slaves.
Stimulus Generator. Stimulus generators create a stream of transactions for exercising the DUT. Stimulus generators can be random, directed, or directed random; they can be free running or have controls; and they can be independent or synchronized. The simplest stimulus generator randomizes the contents of a request object and sends that object to a driver. OVM also provides a modular, dynamic facility for building complex stimulus called sequences. These are discussed in detail in Chapter 8.
Master. A master is a bidirectional component that sends requests and receives responses. Masters initiate activity. Like stimulus generators, they can send individual randomized transactions or sequences of directed or directed-random transactions. Masters may use the responses to determine their next course of action. Masters can also be implemented in terms of sequences.
Slave. Slaves, like masters, are bidirectional components. They respond to requests and return responses (in contrast to masters, which send requests and receive responses).
