Просмотр исходного текста страницы 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.


<center>'''Figure 1-7 OVM Testbench Architecture Layers'''</center>

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).