Verification Horizons Complete Issue:
Verification Horizons Articles:
by Tom Fitzpatrick, Editor and Verification Technologist, Mentor Graphics Corporation
Our featured articles in this issue introduce two new UVM initiatives that we think you'll find useful. Both are intended to extend UVM accessibility to new groups of users. The first article, "Introducing UVM Connect," by my friend and colleague Adam Erickson, gives an introductory look at our open-source UVM Connect library, which provides TLM1 and TLM2 connectivity and object passing between SystemC and SystemVerilog models and components, as well as a UVM Command API for accessing and controlling UVM simulation from SystemC (or C or C++). The library makes it possible to use UVM in a mixed-language environment in which the strengths of each language can be applied to the problem as needed. 
by Adam Erickson, Verification Technologist, Mentor Graphics Corporation
So what does this new capability allow you to do? UVM Connect enables the following use models, all designed to maximize IP reuse: Abstraction Refinement— Reuse your SystemC architectural models as reference models in UVM verification. Reuse your stimulus generation agents in SystemVerilog to verify models in SystemC. Expansion of VIP Inventory—More off-the-shelf VIP is available when you are no longer confined to VIP written in one language. Increase IP reuse! To properly verify large SoC systems, verification environments are becoming more of an integration problem than a design problem. Leveraging language strengths—Each language has its strengths. You can leverage SV's powerful constraint solvers and UVM's sequences to provide random stimulus to your SC architectural models. You can leverage SC's speed and capacity for verification of untimed or loosely timed system-level environments. Access to SV UVM from SC—The UVM Command API provides a bridge between SC and UVM simulation in SV. With this API you can wait for and control UVM phase transitions, set and get configuration, issue UVM-style reports, set factory type and instance overrides, and more.
by Darron May, Manager of Verification Analysis Solutions, Mentor Graphics Corporation
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.
by Suresh Babu P., Chakravarthi M.G., Test and Verification Solutions India Pvt. Ltd.
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.
by Roger Sabbagh, Product Marketing Manager Design Verification & Harry Foster, Chief Verification Scientist, Mentor Graphics
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.
by Ray Salemi, Senior Verification Consultant, Mentor Graphics
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.
by Ashish Aggarwal, Verification Technologist and Ravindra K. Aneja, Verification Technology Manager, Mentor Graphics
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, and effective management of coverage closure.
