Verification Horizons Complete Issue:
Verification Horizons Articles:
by Tom Fitzpatrick, Editor and Verification Technologist, Mentor Graphics Corporation
We're finally doing it. My wife and I have been in our house for 13½ years and we're finally redoing our kitchen, which my wife has wanted to do for about 11 years now. This is kind of a big step for us, as those of you who have gone through the exercise can attest, I'm sure. When we had the house built, we chose to limit our budget to keep "expensive" from turning into "exorbitant," and we've been living with formica countertops and a linoleum floor ever since. It's rather exciting seeing the first steps of converting these into granite and hardwood. As you might imagine, I find myself thinking of how this relates to upgrading a verification methodology because I'm sure that, by now, you know that that's how my mind works.
by Andreas Meyer, Verification Technologist, Mentor Graphics Corporation
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.
by Franz Pammer, Infineon
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.
by Alberto Allara, Matteo Barbati, and Fabio Brognara, STMicroelectronic
By now it's a cliché to speak of the rise of digital technology. Follow technology coverage in the media for any length of time and it doesn't take long to note the tacit assumption that nearly anything with an on/off switch will eventually communicate with the world at-large exclusively in strings of 0s and 1s. Of course, as long as the electronics industry is built on harnessing the laws of physics, the importance of analog signals will never go away. Nature speaks in waveforms, not regimented bitstreams. So the challenge, and one that must be repeatedly solved by those building ever more complex semiconductor devices, is how to verify what's happening at the analog-digital interface.
by Shashi Bhutada, Mentor Graphics Corporation
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.
Extracted from the UVM/OVM Online 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.
by Mike Bartley, Founder, TVS and Steve Holloway, Senior Verification Engineer, Dialog Semiconductor
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.
by Darron May, Manager of Verification Analysis Solutions, Mentor Graphics Corporation
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 to our final destination, how bad the traffic is ahead. Verification of SOCs and electronic systems is certainly a little more complex than road navigation. However, the process of planning what you are verifying and then constantly measuring where you are in the process is equally important whether your final destination is a swanky new hotel a few hours away or a successful tape-out by the end of the year.