OVM Datasheet - Open Verification Methodology (OVM)
Open Verification Methodology (OVM)The Open Verification Methodology (OVM) provides the first open, interoperable SystemVerilog verification methodology in the industry. The OVM provides a library of base classes that allow users to create modular, reusable verification environments in which components talk to each other via standard transaction-level modeling (TLM) interfaces. It also enables intra- and inter-company reuse through a common methodology and classes for virtual sequences and block-to-system reuse. As a joint development initiative between Mentor Graphics® and Cadence® Design Systems, the OVM is supported on multiple verification platforms making it the de facto standard methodology that is ideally suited to both novice and expert verification engineers. Download PDF Version of OVM Datasheet Download PDF Version of OVM Datasheet (Japanese) Built on the success of the Advanced Verification Methodology (AVM) from Mentor Graphics and the Universal Reuse Methodology (URM) from Cadence, the OVM brings the combined power of these two leading companies together to deliver on the promise of SystemVerilog. The OVM offers established interoperability mechanisms for verification IP (VIP), transaction-level and RTL models, and full integration with other languages commonly used in production flows. Benefits
|
|
|
| Figure 1: The OVM object hierarchy |
OVM Base Class LibraryVerification InfrastructureThe 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. Transaction-Level ModelingThe 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 OVM MessagingTo 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 AutomationOVM 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. Flexible ConfigurationThe 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 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. Sequential StimulusThe 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 InterfaceThe 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. |
|
|
| Figure 2: Hierarchical sequences |
Sophisticated Virtual SequencesThe OVM sequences can also be layered hierarchically to build and maintain sophisticated protocols as well as a library of tests. Virtual sequences may be used to coordinate the execution of multiple sequences on different interfaces, allowing more sophisticated tests to exercise more complex corner cases of the design under test (DUT). While sequences provide the stimulus, scoreboards monitor the results. The OVM implements scoreboards using configurable classes, making them easy to build and maintain. System Level VerificationThe use of TLM interfaces in the OVM naturally leads to the development of verification environments at the transaction level. This facilitates the early development of testbenches against SystemCTM models prior to RTL coding. The modularity and reuse provided in the OVM allows these system-level models to be refined down to RTL while still exposing the same TLM interfaces to the test environment. The original SystemC model can also be incorporated back into the environment as a golden model to help verify that the RTL behaves correctly. At a higher level, the OVM architecture facilitates the development of protocol-level golden VIP for plug-and-play reuse. These OVM components encapsulate all of the functionality needed to verify a particular protocol or interface, including generating protocol-level stimulus, signal-level behavior and checking, and functional coverage. The built-in architectural management capabilities then enable the VIP built for block-level verification to be encapsulated and reconfigured for system-level verification without modifying the code in the VIP (Figure 3). |
|
|
| Figure 3: Verification IP |
The OVM WorldEcosystemThe OVM inherits the well-established Cadence and Mentor verification ecosystems. This ensures that OVM users have multiple sources for training, VIP, and verification services. SupportThe OVM is jointly supported by both Mentor Graphics and Learning MoreCadence and Mentor Graphics have jointly created the OVM World http://www.ovmworld.org. At this site you can find the OVM download, including source code, examples, and documentation. You can also find additional information such as a white paper, events calendar, and the OVM partner links. Copyright (C) 2008 Mentor Graphics Corporation and Cadence Design Systems, Inc. All company or product names are the registered trademarks or trademarks of their respective owners. |



