Open Verification Methodology: Why Now?
By Pete Johnson, Cadence Design Systems
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.
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
- nQrux® Root of Trust IP
- AXI to UCIe Bridge IP
- UCIe 2.x Controller IP
- SWI3S (SoundWire I3S Interface) Peripheral Controller Core IP
- OpenTitan-based RISC-V Secure Element
Related Articles
- SIMT-Aware Lockstep Verification and Functional-Coverage Closure Methodology for an Open-Source RISC-V GPGPU: A UVM 1.2 Environment
- Managing an Adaptive Verification Environment with the Open Verification Methodology
- Efficient methodology for verification of Dynamic Frequency Scaling of clocks in SoC
- Metric Driven Verification of Reconfigurable Memory Controller IPs Using UVM Methodology for Improved Verification Effectiveness and Reusability
Latest Articles
- A Secure dToF LiDAR SoC with Dual-Domain Fingerprinting and Event-Driven AFE Circuit Achieving Sensor-Level Attack Resilience
- ZTA-Q: an Open-source RISC-V Platform for Accurate Quantized CNN Inference
- Automated Pre-Silicon Verification of High-Speed DDR5 and LPDDR5/6 Memory Controllers: Closed-Loop Timing, Mode Register, and PHY Synchronization in UVM
- U-Sonic: An Open-Source 8-Channel Ultrasound Transmit IP in a 130 nm RISC-V SoC
- S-ALSA: Co-Design of Adiabatic Logic-based Sensing and Balanced Bit-Cells for Secure and Energy-Efficient MRAM