FEB 2012—Volume 8, ISSUE 1
“Our kitchen renovation is nearly complete... Just as with verification, the key is to have a plan,... take as many contingencies into account as you can,... and... be able to handle constrainedrandom stimulus.”
Tom Fitzpatrick, Editor and Verification Technologist
February 2012 Issue Articles
- Introducing UVM Connect
- UVM Express
- Automation Management
- Partners' Corner
- Using Formal Technology to Improve Coverage Results
- Consultants' Corner
- A Methodology for Advanced Block-Level Verification
Introducing UVM Connect
This article introduces Mentor’s new open-source UVM Connect (UVMC) library, now available for download at verificationacademy.com. UVMC provides TLM1 and TLM2 connectivity and object passing between SystemC and SystemVerilog models and components. It also provides a UVM Command API for accessing and controlling UVM simulation from SystemC (or C or C++).
This article is extracted from the UVM/OVM Online Methodology Cookbook found on verificationacademy. com. This is the Overview article, which introduces UVM Express. Other articles are also included in the Cookbook that go into more detail on each of the steps in applying UVM Express to your verification environment.
UVM Express is a collection of techniques, coding styles and UVM usages that are designed to increase the productivity of functional verification. The techniques include raising the abstraction level of tests, writing tests using BFM function and task calls, adding functional coverage, and adding constrained-random stimulus generation.
Increasing demand for high quality IP and SoC designs and ever shortening design cycles puts pressure on IP and SoC houses to leverage automation as much as possible throughout the entire electronic design and verification processes. This is indeed widely seen in the verification space, where verification engineers have to contend with tasks such as coverage closure, bug hunting, smoke and soak testing, all of which are done through running lots of regressions. How automation is applied to a verification process can have a massive impact (positive and negative) on overall productivity of that process. Regression systems are often heavily scripted, often developed and understood by one or two individuals or maybe a small handful of people within larger organizations. Large amounts of historical baggage are carried over from project to project, sometimes the majority of users don’t even know why they have to run a particular script; it just works until of course it doesn’t.
Test and Verification Solutions (TVS) uses Questa Verification Management (Questa VM) for both project management and verification sign off for its asureVIP development program. Questa VM can manage verification data, process and tools with features such as testplan tracking, trend analysis, results analysis and run management. TVS has benefitted specifically from Questa VRM (Verification Run Manager), which automates regression runs and monitors coverage status. These features are useful in helping us identify a bug during a regression run, immediately starting the debug process and subsequently easily monitoring project status.
Using Formal Technology to Improve Coverage Results
Debugging continues to be one of the biggest bottlenecks in today’s design flow. Yet, when discussing the topic of debugging among project teams, the first thought that comes to mind for most engineers is related to the process of finding bugs in architectural and RTL models, as well as verification code and test. However, debugging touches all processes within a design flow—including the painful task of coverage closure. In fact, one of the most frustrating aspects of debugging is tracking down a particular coverage item that has not been hit only to learn that the coverage item is unreachable. In this article we explore the debugging aspect of coverage closure; with a focus on the unique ability of formal technology to automatically generate simulation exclusion files to improve coverage results while reducing the amount of time wasted trying to hit unreachable states.
We verification test bench designers are happy sausage makers, merrily turning out complex and powerful verification environments. To us, object-oriented programming environments not only greatly enhance our productivity, but they make us feel smarter. Who doesn’t like to throw around words such as extend, factory, and, of course, polymorphism. It’s good for the ego and the soul.
However, our test writing coworkers, the ones who will use our environment to drive stimulus into the DUT, look upon object oriented programming as a horrible goo, that some people need to touch to make the sausages, but that they would rather ignore. When you tell these folks, “Just extend the basic test class, and override the environment in the factory”, they look at you as if you had asked them to plunge their hands into a bowl of freshly ground pork.
A Methodology for Advanced Block-Level Verification
This paper outlines the process for advanced verification methods at the block level. Design and verification issues can be divided into four major categories, each of which we briefly address in this paper:
- RTL development
- Verification of standard protocol interfaces
- End-to-end verification using a simulation-based environment
- Effective management of coverage closure