NOV 2011—Volume 7, ISSUE 3
“I find myself thinking of how this (kitchen upgrade) relates to upgrading a verification methodology because I’m sure that, by now, you know that that’s how my mind works.”
Tom Fitzpatrick, Editor and Verification Technologist
November 2011 Issue Articles
- Graph-Based IP Verification
- Use Scripting Language to Define Powerful Test Cases
- Mixed Analog-Digital Verification with QVM and Questa
- Polymorphic Interfaces
- UVM/OVM Methodology Cookbook
- Partners' Corner with TVS
- Are You Driving in the Dark with Faulty Headlights?
Graph-Based IP Verification
The use of graph-based verification methods for block designs has been shown to provide a significant time and cost reduction when compared to more traditional constrained random techniques. By filling the random constraint space in a controlled random fashion, the full set of constraints can be filled significantly faster than a random constraint solver will. Possibly more importantly, the ability to describe a graph in canonical form is likely to be easier to modify and maintain over the life of an IP block than constraint statements. Combining graphs with a UVM environment, it is possible to extend block-level verification components into a SoC-level test environment with little additional verification development.
Use Scripting Language to Define Powerful Test Cases
This article focuses on providing a methodology to make the process of writing test cases easier for verifying mixed analog digital designs. It explains the advantage of using a scripting language together with a Hardware Description Language (HDL) environment.
It shows a way to give the HDL engineers the possibility to use constrained randomized test cases without having too much knowledge about the implemented testbench.
Two possible scenarios for defining your test cases will be demonstrated. One can be used for the traditional VHDL testbench and another for the SystemVerilog (SV) Open Verification Methodology (OVM) environment. For both cases a scripting language will be used to write test cases. At the end you will understand that with the mentioned methodology also design engineers will fully benefit of verifying their design.
Please note that within this article Tool command language (TCL) is used as scripting language. The reason for using TCL is, that Questasim is controlled by TCL and also has some more built in TCL commands included. Nevertheless this approach can be used with any scripts which are supported by your simulation environment.
Mixed Analog-Digital Verification with QVM and Questa
- Verify IP for a R/W channel to be integrated into a STMicroelectronics hard disk component (an SoC)
- Build a verification process from reusable steps
- Focus on integration into the larger SoC, not just on the IP
- Make maximum use of standards, start with OVM
- Start writing verification components as soon as design work in RTL is underway
- Use Mentor Graphics Questa ADMS tool for analog accuracy and easy integration into digital verification flow
The SystemVerilog language is increasing in adoption for advanced verification techniques. This enables the creation of dynamic test environments using SystemVerilog classes among other things. The SystemVerilog virtual interface has been the primary method for connecting class-based SystemVerilog testbenches with a VHDL or Verilog DUT, but this construct has certain limitations, especially when the interface is parameterized. In this article we will discuss some of these limitations and demonstrate an alternative approach called as the Polymorphic Interface. The recommended approach can also work generically wherever one uses virtual interfaces and not just parameterized interfaces.
For the SystemVerilog testbench, we will use OVM infrastructure, but this same discussion applies to UVM testbenches. This article assumes SystemVerilog OVM/ UVM class and interface syntactical understanding.
UVM/OVM Methodology Cookbook
Many protocols have a hierarchical definition. For example, PCI express, USB 3.0, and MIPI LLI all have a Transaction Layer, a Transport Layer, and a Physical Layer. Sometimes we want to create a protocol independent layer on top of a standard protocol so that we can create protocol independent verification components ( for example TLM 2.0 GP over AMBA AHB ). All these cases require that we deconstruct sequence items of the higher level protocol into sequence items of the lower level protocol in order to stimulate the bus and that we reconstruct higher level sequence items from the lower level sequence items in the analysis datapath.
Partners' Corner with TVS
OVM has gained a lot of momentum in the market to become the dominant verification “methodology” and the indications are that UVM will gain even greater adoption. OVM is built around SystemVerilog and provide libraries that allow the user to build advanced verification test benches more quickly. There is extensive documentation, training and support for how to best develop such test benches and to encourage test bench re-use. However, there is less advice on how to adapt your verification processes on your project to best use OVM and even less advice on how to do this for company wide adoption.
In this article we discuss the experiences of the authors of a company-wide adoption of OVM. We consider the original motivations for that adoption and the expected benefits, and the actual results achieved and problems that have been overcome. The aim of the article is to give advice to other companies considering adopting OVM.
Are You Driving in the Dark with Faulty Headlights?
If your car’s headlights were faulty, would you even think about leaving home in the dark bound for a distant destination to which you’ve never been? Even if you were armed with a map, a detailed set of instructions and a good flashlight, the blackness on the other side of your windshield would still make it difficult to navigate. And even with reliable headlights and maps, you’ll invariably still encounter obstacles and detours.
These hassles are nowadays mitigated somewhat by car navigation systems that tell us where we are, how far we have travelled and, so we can consider alternate routes and estimate how long it will take to get