OVM/OVM методология/Layered Organization of Testbenches
Глава 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.
Figure 1-7 OVM Testbench Architecture Layers
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).
Figure 1-9 A Master and a Slave
1.4.3 Analysis Components
Analysis components receive information about what’s going on in the testbench and use that information to make some determination about the correctness or completeness of the test. Two common kinds of analysis components are scoreboards and coverage collectors.
Scoreboard
Scoreboards are used to determine correctness of the DUT, to answer does-it-work questions. Scoreboards tap off information going into and out of the DUT and determine if the DUT is responding correctly to its stimulus.
Coverage Collector
Coverage collectors count things. They tap into streams of transactions and count the transactions or various aspects of the transactions. The purpose is to determine verification completeness by answering are-wedone questions. The particular things that a coverage collector counts depends on the design and the specifics of the test. Common things that coverage collectors count include: raw transactions, transactions that occur in a particular segment of address space, and protocol errors. The list is limitless.
Coverage collectors can also perform computations as part of a completeness check. For example, a coverage collector might keep a running mean and standard deviation of data being tracked. Or it might keep a ratio of errors to good transactions.
1.4.4 Controller
Controllers form the main thread of a test and orchestrate the activity. Typically, controllers receive information from scoreboards and coverage collectors and send information to environment components.
For example, a controller might start a stimulus generator running and then wait for a signal from a coverage collector to notify it when the test is complete. The controller, in turn, stops the stimulus generator. More elaborate variations on this theme are possible. In an example of a possible configuration, a controller supplies a stimulus generator with an initial set of constraints and starts the stimulus generator running. When a particular ratio of packet types is achieved, the coverage collector signals the controller. Rather than stopping the stimulus generator, the controller may send it a new set of constraints.
1.5 Two Domains
We can view the set of components in a testbench as belonging to two separate domains. The operational domain is the set of components, including the DUT, that operate the DUT. These are the stimulus generators, bus functional models (BFM), and similar components that generate stimulus and provide responses that drive the simulation. The DUT, responder, and driver transactions—along with the environment components that directly feed or respond to drivers and responders—comprise the operational domain. The rest of the testbench components—monitor transactors, scoreboards, coverage collectors, and controller—comprise the analysis domain. These are the components that collect information from the operational domain.
Data must be moved from the operational domain to the analysis domain in a way that does not interfere with the operation of the DUT and preserves event timing. This is accomplished with a special communication interface called an analysis port. Analysis ports are a special kind of transaction port in which a publisher broadcasts data to one or more subscribers. The publisher signals all the subscribers when it has new data ready.
One of the key features of analysis ports is that they have a single interface
function, write(). Analysis FIFOs, the channels used to connect analysis
ports to analysis components, are unbounded. This guarantees that the
publisher doesn’t block and that it deposits its data into the analysis FIFO in
precisely the same delta cycle in which it was generated. Chapter 7 discusses
analysis ports and analysis FIFOs in more detail.
Figure 1-10 Connection between Operational and Analysis Domains
Generally, the operational and analysis domains are connected by analysis ports and control and configuration interfaces. Analysis ports tap off data concerning the operation of the DUT. These data might include bus transactions, communication packets, and status information (success or failure of specific operations). The components in the analysis domain analyze the data and make decisions. The results of those decisions can be communicated to the operational domain via the control and configuration interfaces. Control and configuration interfaces can be used to start and stop stimulus generators, change constraints, modify error rates, or manipulate other parameters affecting how the testbench operates.
