OVM Base Class Library
The OVM provides all the building blocks needed to construct a suitable test environment (Figure 1). Components may be encapsulated and instantiated hierarchically and are controlled through an extendable set of phases to initialize, run, and complete each test. These phases are defined in the base class library but can be extended to meet specific project needs.
The OVM components communicate via standard TLM interfaces, which improves reuse. The TLM Standard, originally developed by OSCI, defines a standard set of interface methods to define communication semantics but separates the interfaces from their implementations. Using a SystemVerilog implementation of TLM in the OVM, a component may communicate via its interface to any other component that implements that interface. Thus, one component may be connected at the transaction level to others implemented at multiple levels of abstraction. The common semantics of TLM communication permit
components to be swapped in and out without affecting the rest of the environment.
To facilitate debug, results checking, and overall consistency, the OVM includes a standard set of methods for reporting messages to stdout and/or to one or more text files. Messages may be controlled using verbosity or other customizable filters on an individual or hierarchical basis. Standard severity levels (INFO, WARNING, ERROR, FATAL) are supported.
OVM users also have access to advanced automation to simplify environment creation. Macros dramatically reduce coding and improve readability. Alternatively, users can access the same capabilities through function calls.
The OVM uniquely provides three forms of configuration to decouple the "test" from the "testbench". The testbench is the complete topology for the specific components needed to perform verification, while the test becomes a straightforward configuration of that topology. These three forms of configuration are all available at run time as follows:
- The test may choose from a set of precompiled environments
- The chosen environment and the components therein may be configured to modify their behavior and/or layout
- Stimulus sequences may be added or modified on-the-fly to exercise different scenarios
The key benefit of this unique configuration capability is that the test writer is able to modify the behavior of the underlying environment without having to modify or extend the code.
The OVM provides class support for building hierarchical sequences, making it easy to specify complex layered stimulus scenarios. By defining sequences as objects, the OVM separates the test behavior from the testbench structure, allowing greater modularity and reuse of stimulus scenarios. At any level of abstraction, sequences enable a simple test writer interface, including built-in semantics for controlling the randomization of transactions.
Simple Test Writer Interface
The OVM sequences are written at the transaction level, independent of the underlying testbench infrastructure. The test writer simply specifies procedurally the type of transaction to be generated, along with an optional set of constraints and the transaction is automatically randomized and sent to the driver. In addition, sequences may call subsequences or may spawn parallel sequences (Figure 2). New tests are created simply by specifying new sequences, which can be executed via simple configuration calls from the test without modifying the underlying environment.