FloTHERM is powerful 3D computational fluid dynamics (CFD) software that predicts airflow and heat transfer in and around electronic equipment, from components and boards up to complete systems. Learn More →

Accellera’s Universal Verification Methodology (UVM)-The Real Story

Once upon a time, there were three verification methodologies. One was too hard. It was based on a language that only one vendor supported and, while it had some good ideas, the language and lack of multi-vendor support limited its use. One was too closed (and wasn’t all that easy, either). It was based on SystemVerilog, a standard language that almost everyone supported, but its vendor tried to keep customers locked in and competitors locked out. And one methodology, based on Mentor Graphics’ vision that a methodology should be made from an open base class library that all of the “Big-3” EDA vendors could support, was just right

Using SystemVerilog Packages in Real Verification Projects

This paper details some of the key features and frustrations of using the package construct in SystemVerilog. The package construct is compared to similar features in other languages such as the identically named construct in VHDL and namespaces in C++. Valuable lessons learned over the course of multiple projects in the development of verification environments are described, and the paper makes recommendations for basic DOs and DONTs for SystemVerilog package use. The theme of code reusability is always important, and tips on how packages can be used to achieve this are discussed.

Users of languages such as VERA, which does not have the package construct, are more accustomed to using include files, which provide some but not all the features packages provide. The paper discusses why the continuance of this approach, while possible in SystemVerilog, is not recommended and why the package construct is superior.

Finally, the paper discusses how SystemVerilog allows packages and classes to be mixed in interesting ways not seen in other languages.

Time to Adopt Formal Property Checking

There are three reasons the time is right for formal property checking, even for design teams whose project schedules are measured in months instead of years. First, the technology has matured. Second, standards now exist to express interesting functional properties. And third, formal property checking is well-suited to today’s problem domain.

Multi-Method Verification of SoC Designs in an OVM Testbench

The demand for smarter, more powerful consumer electronics devices is increasing the complexity and integration of underlying SoC designs. This, in turn, is making it harder to build a comprehensive test environment. The availability of the Open Verification Methodology (OVM) [1] has helped to at least partially ease the burden on verification engineers. Based on the IEEE 1800 SystemVerilog standard and fully open, the OVM is non-vendor-specific and works with multiple languages and simulators. OVM provides a library of base classes as building blocks for creating modular and reusable verification environments that support a constrained random stimulus generation methodology. With OVM, verification IPs (VIP) can be developed with a well defined structure to help make them simple to use and re-use. Such VIPs are already available to target common interfaces, such as AHB, AXI3 and AXI4 in the AMBA family

Reusable Sequences Boost Verification Productivity and Reduce Time to Market for PCIe

Today’s design process is increasingly dynamic due to smaller manufacturing process technologies and the corresponding higher gate counts. The tough economic climate also exacerbates matters for verification engineers, who are driven to meet increasingly ambitious time-to-market demands. One major source of help is efficient and reusable stimulus, especially for use in random or constrained random verification. OVM sequences enables a user to develop such stimuli across a range of design activities. Based on OVM sequences, the sequences in PCIe Multi-View Verification Component (MVC) help verify the PCIe design in a simple yet elegant manner. (Mentor Graphics Questa MVCs allow a verification team to connect to any level of abstraction, from system to gates.

This paper describes how incorporating multi-abstraction-level BFM in PCIe verification intellectual property (VIP) can yield a host of benefits, including faster, more flexible verification and easier debugging. (One specific example that is discussed: how a transaction GUI that links a top-level parent to its wire-level child is generally far superior to a more traditional GUI when it comes to locating bugs.) By providing methodology-based sequences, PCIe VIP speeds verification by helping to structure primary and secondary test sequences. Also discussed: how the combination of PCIe VIP based on coverage-driven methodology and protocol-capturing XML plans can boost verification completeness.

Accelerated Debug - A Case Study

Debugging is one of the most painful and time consuming tasks within the design and verification cycle. Day in and day out, engineers trace signals in the design, stare at waveforms, and analyze lines of code in order to understand why failures occur. In today’s advanced design environments, debugging is one of the few tasks that has not changed for decades. As result it has been reported that debug is the fastest growing verification component and now takes as much as 52% of the total verification effort [1]. This article introduces, OnPoint, the first and only automated debugging tool that analyzes failures and returns the source of errors with no user guidance. Through a case study we illustrate how Questa and OnPoint can accelerate the verification and debugging of assertions.

Verification of a Complex IP Using OVM and Questa - from Testplan Creation to Verification Success

For flexibility and reuse concerns, PSI-Electronics verification flow has been developed using open and standard solutions. XML was chosen some years ago to describe plans, as it is easily processed to generate documentation for a lot of tools like Microsoft Office or OpenOffice or parsed to extract suitable information. The verification plan is captured as XML files. For the first time the design features and properties are listed and grouped by functionality to build the verification plan. In a second time, testcases and functional coverage are added and will allow the verification engineer to measure completeness of his work.

Agile Transformation in Functional Verification, Part 1

The potential for agile methods in IC development is large. Though agile philosophy suggests the benefits of an agile approach are most profound when applied across an entire team, reality often dictates that new techniques and approaches are proven on a smaller scale before being released for team wide application.

This article is the first in a two part series that describes how a functional verification team may benefit from and employ agile planning and development techniques while paving the way for use in RTL design and ultimately, team wide adoption.

Simulation-Based FlexRayTM Conformance Testing - an OVM Success Story

This article presents a case study on how the Open Verification Methodology (OVM) was successfully applied to implement a SystemVerilog simulationbased conformance test environment for next generation FlexRay™ 3.0 Communications System controllers.

Complex application requirements and a need to run conformance tests on multiple vendor simulators, including Mentor’s Questa, with reliable, repeatable and identical results provided the design team with specific challenges. The OVM helped meet these challenges and proved that OVM has achieved its goal to “facilitate true SystemVerilog interoperability”.

Making OVM Easier for HDL Users

There is currently much discussion concerning the use of constrained random verification techniques with the SystemVerilog language and the OVM and UVM methodologies. The debate is largely the province of experts, of verification professionals who eat, sleep and breathe functional verification every day of their lives. This particular article has been written with a different kind of engineer in mind. Do you use Verilog or VHDL for ASIC or FPGA design, writing RTL code and block-level test benches? Are you still playing catch-up with the latest functional verification techniques? Then this article is for you.

Hardware emulators, like Mentor Graphics’ Veloce, are widely used to debug SoCs that include one or more processors. Although hardware designers are the traditional target for emulators, software developers are increasingly using hardware emulation for early firmware, kernel and driver development. The traditional connection of a software debugger to an emulator is done with a debug probe connected to the JTAG port of the design, but this solution is slow because of the serial nature of the JTAG protocol. This article explores the use of ARM’s VSTREAM co-emulation transactor connected to a Veloce hardware emulator, to accelerate the connection from the debugger to the hardware target.

Verification Horizons

We have created the Verification Horizons newsletter to provide concepts, values, methodologies and examples to assist with the understanding of what advanced functional verification technologies can do and how to most effectively apply them. Verification Horizons