A methodology is hard to define and hard to grasp. At its most basic, a methodology is little more than a set of guidelines or rules for accomplishing some task. On this basis, "Grab the stick end of a mop and use the other end to wet down the entire floor,"
perhaps qualifies as a methodology for cleaning up muddy footprints.
This single guideline is not really sufficient; a user of this methodology might spend six months mopping the same spot before moving on. More details are clearly needed, such as descriptions of mop motions (spiral, back-and-forth, up-and-back) that will accomplish the intended cleaning task.
If the mopping methodology requires the use of a specific type of mop or soap, the methodology should include a specification. Most importantly, the methodology must be open
to allow multiple vendors to supply the mop, soap, and other complementary materials meeting the relevant specifications.
This analogy may be all wet, but any attempt to define a methodology for functional verification has the same challenges. An overly simplistic methodology that lacks details can easily result in a user wasting time and resources. In the worst case, it may take more time to follow a poor methodology than to try to accomplish the verification task without one. Further, a verification methodology that requires specific libraries should, at a minimum, define the requirements for these components.
The verification task is much easier if the methodology is provided as part of a package that includes the appropriate documentation along with any required libraries. Full, open disclosure of the libraries allows users to see all details, enables customization if needed, and fosters associated vendor solutions. An open verification methodology supports multiple tools from multiple vendors and is freely available to any interested vendors, users, or standardization organizations.
This all seems to make perfect sense, yet until a few weeks ago no truly open verification methodology existed. The announcement of the appropriately named Open Verification Methodology (OVM) by Cadence and Mentor has completely changed the landscape for functional verification. There are several important differences between previous methodologies, some claiming to be open, and OVM.
For a start, OVM is based entirely on the IEEE 1800 SystemVerilog standard. Some previous methodologies have relied on vendor-specific extensions to SystemVerilog or used the Accellera 3.1a version that the IEEE standard supplanted. Any tool that supports standard IEEE SystemVerilog will be able to run any commercial verification IP (VIP), custom verification components, and testbenches developed using OVM.
Further, Cadence and Mentor have ensured that OVM-compliant verification code will run on their respective simulation platforms. Major VIP vendors have already committed to making their products available in OVM-compliant form. This enables a plug-and-play level of verification interoperability across multiple simulators unprecedented in EDA. OVM is the first object-oriented, reuse-driven verification methodology to be proactively architected and tested for support across multiple vendors' tools.
OVM is truly open; all documentation for the methodology and the SystemVerilog library source code will soon be available on a community Web site. Anyone wishing to access the methodology, even competitors of the two originating companies, will be able to download the documentation, library source code, and examples showing how to build an OVM-compliant verification environment. The only requirement is click-through acceptance of a widely used open-source license agreement (Apache 2.0).
Source code is essential for users to run on additional EDA tools. Source also makes it easy for additional EDA vendors and VIP suppliers to add support for OVM. In contrast, some verification methodologies have not provided source code at all in order to prevent competitors from running the libraries, or have provided source only under onerous license terms that restrict users' ability to perform their verification tasks.
Of the previous methodologies that have claimed to be open, only OVM truly is. Only OVM provides open source libraries and documentation under the Apache license, validated on multiple leading simulators. It is precisely the combination of openness and multi-vendor support, built entirely on top of the IEEE SystemVerilog language standard, that makes OVM unique and compelling. A truly open standard for functional verification is long overdue, and OVM fits the bill.