Migrating Ethernet VIP to OVM Is a Cinch
By Rahul V. Shah, Director, ASIC Engineering Division, Sibridge Technologies
rahulv.shah@sibridgetech.com

The Advanced Verification Methodology (AVM) was instrumental in delivering SystemVerilog to the masses. This was partly due to its open, interoperable format. In addition, it supplied models, instructions, and support that allowed verification and design engineers alike to take advantage of advanced verification technologies, including objectoriented programming, without having to be verification language experts. Today, the openness and benefits of the AVM have been expanded into the Open Verification Methodology (OVM). It is our good fortune that the transition from AVM to OVM is an easy one and can be made without any modification to existing code.

Even when standalone VIP is fully verified to be good, integration at the chip level is not a trivial task. Many VIP developers have not thought about the issues users face when they are using VIP at the chip level. Thus, VIP usage at the chip level should be a high priority as more and more VIP is moving from verification at the module level toward creating interesting scenarios at the chip level.

An open source, standard-based methodology is the foundation for this bridge, allowing the knowledge-base gained at one level to be ported to another. Such a methodology begins with a standard verification language, such as SystemVerilog. Standard languages allow designs, models, and verification components to be easily moved from one tool to another and allow the same verification environment to be used for both block and chip level verification.

Instead of just creating a pure reference model, SystemVerilog allows the development of VIP in a new way that supports the creation of scenarios that capture bugs and the forwarding of language features to the user where it can help them. This SystemVerilog VIP is also easy to configure for non-language experts: critical in today’s crunch-time status quo where engineers are frequently asked to wear more than one hat. Consequently, designers as well as verification experts will use VIP.

If SystemVerilog is the brick of the bridge, methodology is the mortar. An open source, pure SystemVerilog methodology is needed that both facilitates the adoption and use of SystemVerilog and encourages reuse of all the fruits of the verification effort. Initially, the AVM provided the fullest support of SystemVerilog and delivered leading verification technologies. The AVM’s emphasis on reusable components encourages a scalable solution that allows VIP to successfully move between block and chip level verification, and ultimately between functional verification
and post-silicon validation.

Figutr1:Sibridge Ethernet OVM compliant VIP block diagram.

Recently, the AVM was extended, along with the universal verification methodology (URM), into the OVM. The OVM assures the continuity of a standard, interoperable verification methodology into the future. It delivers an enormous benefit for both VIP providers and verification engineers developing testbenches, offering established interoperability mechanisms for VIP, transaction-level and RTL models as well as integration with other languages commonly used in production flows. It establishes a common methodology and a class library that runs on any simulator that supports the SystemVerilog standard.

The OVM methodology classes define unique capabilities for blockto- system VIP reuse and layered sequences. The OVM provides the TLM-based infrastructure for building modular, reusable verification components that communicate through well-defined transaction-level interfaces. This is critical for the bridging of functional verification and post-silicon validation. Its class library allows users to create sequential constrained-random stimulus, collect and analyze functional coverage information, and include assertions as first-class members of the configurable testbench environment. The OVM open library gives the flexibility to make VIP that can be synchronized with other environmental components in a verification environment, whether those components are in C, are encrypted, or in some other language.