Home

Uncategorized

Cool Things You Can Do With DVE – Part 1
Posted on Sunday, April 3, 2011 - 09:00 by yilani from the site Verification Martial Arts
Yaron Ilani, Apps. Consultant, Synopsys A SystemVerilog test bench could get quite complex. Typical projects today have thousands of lines of code, and the number is constantly on the rise. However, standard base class libraries such as VMM and UVM can help you minimize the amount of code that needs to be rewritten by providing a rich set of macros that substitute long lines of code with a single line. For example, the simple line `vmm_channel(atm_cell) defines a standard VMM channel for an ATM cell with all the necessary fields and methods, all under the hood.
yilani
Posted in
A RAL example with Designware VIP.
Posted on Thursday, March 17, 2011 - 06:48 by S. Varun from the site Verification Martial Arts
I often get asked how best RAL ought to be used with Designware VIP. Since several of these VIPs provide a mechanism to program registers across different DUTs, I felt it would be useful to create an example with Designware AMBA AHB VIP and RAL.
S. Varun
Posted in
Transaction Debugging with Discovery Visualization Environment (DVE) Part-2
Posted on Tuesday, March 8, 2011 - 14:06 by JL Gray from the site Verification Martial Arts
Asif Jafri, Verilab Inc. In my previous blog post, I introduced how to dump waves and how to use $tblog for dynamic data and message recording. If you need more control over scope sensitive transaction debugging, $msglog task is very useful. This blog has been divided into two sections: in the the first section, I talk about how to use $msglog. In the second section, I will discuss how VMM performs transaction recording by calling $msglog from within the VMM library. The call is protected so as not to confuse other simulators or tools. You can use $msglog in any of your code as well.
JL Gray
Posted in
Register Programming using RAL package
Posted on Tuesday, February 15, 2011 - 14:35 by Vidyashankar Ramaswamy from the site Verification Martial Arts
There are many methods available to program (read/write) registers in a design using RAL. 1.    ral_model::read()/write(): This is the old fashion method where you specify the address and the data. No need to know the register by name.               EX:    ral_model.ral.read(status, addr, data, . . .);  2.    ral_model::read_by_name()/write_by_name(): You have to specify the register name and data to execute this method. Here the register name is hard-coded.               EX: ral_model.read_by_name(status, “reg_name”, data, . .
Vidyashankar Ramaswamy
Posted in
Performance appraisal time – Getting the analyzer to give more feedback
Posted on Friday, January 28, 2011 - 21:28 by Amit Sharma from the site Verification Martial Arts
S. Prashanth, Verification & Design Engineer, LSI Logic Performance appraisal time – Getting the analyzer to give more feedback We wanted to use the VMM performance analyzer to analyze the performance of the bus matrix we are verifying.
Amit Sharma
Posted in
Managing coverage grading in complex multicore microprocessor environments
Posted on Wednesday, January 26, 2011 - 14:49 by Shankar Hemmady from the site Verification Martial Arts
Something as simple as coverage grading, which we often take for granted, starts showing its exponential complexity when dealing with cutting-edge designs where quality and timeliness are essential.  An article in EE Times by James Young and Michael Sanders of AMD along with Paul Graykowski and Vernon Lee of Synopsys describes how they created a coverage grading solution, Quickgrade, that scales to meet the complexity of multicore multiprocessor design environments:
Shankar Hemmady
Posted in
Verification in the trenches: Transform your sc_module into a vmm_xactor
Posted on Tuesday, January 18, 2011 - 11:04 by Ambar Sarkar from the site Verification Martial Arts
Dr. Ambar Sarkar, Chief Verification Technologist, Paradigm Works Inc. Say you have SystemC VIP lying around, tried and true. More likely than not, they are BFMs that connect at the signal level to the DUT and have a procedural API supporting transaction level abstraction. What would be the best way to hook these components up with a VMM environment? With VMM now being available in SystemC as well, you really want to make these models look and behave as vmm_xactor derived objects that interact seamlessly across the SystemC/SystemVerilog language boundary.
Ambar Sarkar
Posted in
Channels versus Non-blocking Transport in VMM 1.2
Posted on Monday, January 17, 2011 - 17:57 by John Aynsley from the site Verification Martial Arts
  John Aynsley, CTO, Doulos The original VMM book recommended ways of using the VMM channel to model non-atomic, pipelined, and out-of-order transaction execution. The TLM-2.0 standard addresses the same issues in a very different way. Now that TLM-2.0-like features are part of VMM and the Accellera Verification IP Technical Committee is looking at how to incorporate similar features into UVM, I thought it might be worthwhile to compare and contrast the two approaches.
John Aynsley
Posted in
The VMM TLM Reactive Interface
Posted on Monday, January 10, 2011 - 15:09 by John Aynsley from the site Verification Martial Arts
John Aynsley, CTO, Doulos In an earlier post I showed how to bind a VMM channel to a new-style TLM port using the vmm_connect utility. This is useful if you already have old-style and new-style transactors to be connected together. I have also tried to emphasize that the VMM channel is still the preferred way to write slave transactors that need to work on a transaction while it remains in-flight between producer and consumer. However, the VMM channel mechanism could be regarded as being a bit heavyweight when compared with just passing transactions around using TLM ports and exports.
John Aynsley
Posted in
Transaction Debugging with Discovery Visualization Environment (DVE) Part-1
Posted on Wednesday, January 5, 2011 - 13:20 by JL Gray from the site Verification Martial Arts
Asif Jafri, Verilab The art of verification has evolved dramatically over the last decade. What used to be a very simple verilog testbench which could not possibly cover the vast solution space has evolved into the current monstrosity (Random testbenches) which is a very powerful tool, but the complexity of debug has gone up exponentially.
JL Gray
Posted in
Syndicate content