Open Verification Methodology: Why Now?
April 01, 2008 -- edadesignline.com
Cadence and Mentor Graphics recently announced and shipped the Open Verification Methodology (OVM). This initiative focuses on providing a single, open, and interoperable SystemVerilog-based methodology and supporting class library. But why introduce a new methodology now? With at least three other SystemVerilog methodologies already available, why add another to the mix?
The simple answer is that goal of the OVM is to reduce the number of methodologies available, thereby improving the productivity of SystemVerilog users, including designers, verification engineers, VIP providers, and even EDA vendors. In order to achieve this, OVM must be completely open, enable full interoperability, provide advanced functionality, and offer a long-term growth path.
The SystemVerilog Language Race is Over
When SystemVerilog was standardized over four years ago, users liked the idea of a single language with constructs to handle not just design, but verification as well. As simulation vendors started implementing these features, customers started using them and asking for others. This trend continued for several years, as customers pushed vendors to support the language constructs they needed. But what happened along the way was a shift from needing language constructs to a requirement to build a reusable verification environment. Customers realized that the important factor was how they built the environment, not which language constructs were involved.
Fast forward to today when we see that most of the testbench language constructs have been implemented in simulation tools. In order to deliver on the original promise of SystemVerilog, what is needed is the ability to create modular verification environments that can use verification IP (VIP) components that have been created somewhere else - either on another project within the company or by an external source such as a partner or a VIP supplier.
To read the full article, click here
Related Semiconductor IP
- DDR5 MRDIMM PHY and Controller
- RVA23, Multi-cluster, Hypervisor and Android
- HBM4E PHY and controller
- 64 bit RISC-V Multicore Processor with 2048-bit VLEN and AMM
- NPU IP Core for Mobile
Related White Papers
- Reusable Test-Case Methodology for SoC Verification
- Managing an Adaptive Verification Environment with the Open Verification Methodology
- Mixed Signal Design & Verification Methodology for Complex SoCs
- Efficient methodology for verification of Dynamic Frequency Scaling of clocks in SoC
Latest White Papers
- QiMeng: Fully Automated Hardware and Software Design for Processor Chip
- RISC-V source class riscv_asm_program_gen, the brain behind assembly instruction generator
- Concealable physical unclonable functions using vertical NAND flash memory
- Ramping Up Open-Source RISC-V Cores: Assessing the Energy Efficiency of Superscalar, Out-of-Order Execution
- Transition Fixes in 3nm Multi-Voltage SoC Design