Doulos - UVM Golden Reference Guide-Doulos Ltd. (2013).pdf-资料库

qq_43360393-12012738-4744302543340084252.pdf-第1页.png

第1页 / 共316页

qq_43360393-12012738-4744302543340084252.pdf-第2页.png

第2页 / 共316页

qq_43360393-12012738-4744302543340084252.pdf-第3页.png

第3页 / 共316页

qq_43360393-12012738-4744302543340084252.pdf-第4页.png

第4页 / 共316页

qq_43360393-12012738-4744302543340084252.pdf-第5页.png

第5页 / 共316页

qq_43360393-12012738-4744302543340084252.pdf-第6页.png

第6页 / 共316页

qq_43360393-12012738-4744302543340084252.pdf-第7页.png

第7页 / 共316页

qq_43360393-12012738-4744302543340084252.pdf-第8页.png

第8页 / 共316页

UVM GOLDTN RËTËRËNCT GUIDË A concise guide to the Universal Verification Methodology UVMl'"*w &oouLos

UVM Golden Reference Guide Second Edition, December 201 3 Copyright@2013 by Doulos Ltd. All rights reserved. The information contained herein is the property of Doulos Ltd and is supplied without liability for errors or omissions. No part may be used, stored, transmitted or reproduced in any form or medium without the written permission of Doulos Ltd. Doulos@ is a registered trademark of Doulos Ltd. UVM is licensed under the Apache Software Foundation's þache License, Version 2.0, January 2004. The full license ¡s available at http://www.apache.org/licenses/ Al other tradernarks are acknowledged as the property of their respective holders. First publ¡shed by Doulos 201 1 Doulos Church Hatch 22 Market Place Ringwood Hampshire BH24 IAW UK Tel +44 (0) 1425471223 rax +44 (0) 1425 471573 Email: info(Adoulos.com Doulos 2055 Gateway Place Suite 220 San Jose c495110 USA +1-888-GO DOULOS +1408-762-2246 ¡nfo.usa@doulos.com Web: http://www.doulos.com

Gontents Secfion Preface Page 4

Preface The UVM Golden Reference Guide is a compact reference guide to the Universal Verif icatio n Methodology for SystemVeri log. The intention of the guide is to provide a handy reference. lt does not offer a complete, formal description of all UVM classes and class members. lnstead it offers answers to the questions most often asked during the practical application of UVM in a corvenient and concise reference format. lt is hoped that this guide will help you understand and use UVM more effectively. This guide is not intended as a substitute for a full training course and will probably be of most use to those who have received some training. Also it is not a replacement for the official UVM Class Reference, which forms part of the UVM and is available from www.accellera.org. The UVM Golden Reference Guide was developed to add value to the Doulos range of training courses and to embody the krnwledge gained through Doulos methodology and consulti ng activities. For more information about these, please visit the web-site www.doulos.com. You will find a set of UVM tuûorials at www.doulos.com/knowhow. For those needing full scope training in UVM, see the UVM Adopter Class from Doulos.

Using This Guide The UVM Golden Reference Guide comprises a Brief lntroduction to UVM, information on Finding What You Need in This Guide, the Alphabetical Reference section and an lndex. This guide assumes knowledge of SystemVerilog and testbench automation. lt is not necessary to know the full SystemVerilog language to understand the UVM classes, but you do need to understand object-oriented programming in SystemVerilog. You will find some tutorials at http://www.doulos.com/knowhow. Oroanization The main body of this guide is organized alphabetically into sections and each section is indexed by a key term, which appears prominently at the top of each page. Often you can find the information you want by flicking through the guide looking for the appropriate key term. lf that fails, there is a full index at the back. Except in the index, the alphabetical ordering ignores the prefix uvm_. So you will find Field Macros between the articles uvm_f actory and uvm_heartbeat. Finding What You Need in This Guide on page I contains a thematic index to the sections in the alphabetical reference. The lndex Bold index entries have corresponding pages in the main body of the guide. The remaining index entries are followed by a list of appropriate page references in the alphabetical reference sections. Methods and Members Most sections document the methods and members of UVM classes. Not all public members and methods are included; we have tried to concentrate on those that you may want to use when using the UVM. For details on all the members and methods, please refer to the official UVM Class Reference and the actual UVM source code.

A Brief Introduction to uvM Background Various verification methodologies have emerged in recent years. One of the first notable ones was the ¿ Reuse Methodology for verification lP using the e language. This defines an architecture for verification components together with a set of naming and coding recommendations to support reuse across multiple projects. The architecture of eRM and some of its concepts (e.9. sequences) were used to create the Cadence Universal Reuse Methodology (URM), for SystemVerilog. The SystemC TLM-I and TLM-2.0 libraries define a transport layer for transaction level models. Mentor Graphics' Advanced Verification Methodology (AVM) used SystemVerilog equivalents of the TLM-1 ports, channels and interfaces to communicate between verification components. Support for TLM- 2.0 was introduced in UVM. The Verification Methodology Manual (VMM) was co-authored by Synopsys and ARM and enables the creation of robust, reusable and scalable verification erviro nments usi ng SystemVeri log. URM and AVM were joined together to form the Open Verification Methodology (OVM). OVM combines the classes from AVM and URM. lt is backwards compatible with both. UVM was developed by Accellera in collaboration with Cadence, Mentor Graphics and Synopsys. Version 1.0 and, subsequently, version 1.'l were released in2011, although an early access version (UVM f .OEA) was made available in 2010. UVM is based on OVM 2.1.1 and adds a Register Layer based on the Register Abstraction Layer (RAL) from VMM and TLM-2.0 interfaces, based on the SystemC standard. UVM versions 1.1a through 1.1c provide bug fixes with only a few minor changes. lransaction-level Modelinq Transactionlevel modeling (TLM) involves communication using function calls, with a transaction being the data structure passed to or from a function as an argument or a return value. Transaction level modeling is a means of accelerating simulation by abstracting the way communication is modeled. Whereas an HDL simulator models communication by having a separate event for each pin wiggle, a transaction level model works by replacing a bunch of related pin wiggles by a single transaction. Obvious examples would be a bus read or bus write. 6 Copyriglìt @2013 by DoulosLtd. All r¡!¡hts ßwed.

uvM UVM is implemented entirely in SystemVerilog so it should work on any simulator that supports the full IEEE 1800-2009 standard. The UVM source code can be downloaded from the UVM web site. There is also an active user forum on this site that any registered user can freely participate in. UVM Glass Hierarchy Data Register Layer Structuro The main UVM classes form a hierarchy as shown here. The uvm object class is the base class for all other UVM classes. User defined transaction classes should be derived from uvm_seguence_item. TLM channels such as uvm_ttm_fifo are derived from urrm_report_object so include the ability to print their state. There are also implementations of the SystemC TLM-1 and TLM-2.0 interface classes (not shown here) that are inherited by TLM channels. The uvm_component class, which also derives from uvm_report_object, is for user-defined verification components. lt has a run phase task that is automatically invoked at the start of a simulation. Base classes for common verification components such as environments, agents, drivers and monitors are also provided. Copyr¡ght@ 20'13 by OoulosLld. Allr¡ghts resfled. 7

Finding What You Need in This Guide This section highlights the major areas of concern when creating or modifying a UVM verification environment, and indicates the most important classes that you will need to use for each of these areas. Classes and UVM features highlighted in bold have their own articles in the Alphabetical Reference section of this Guide. Designing Transaction Data UVM verification environments are built using fransacfion level modeling. Stimulus, responses and other information flowing around the testbench are, as far as possible, stored as transactions - objects carryirg a high-level, fairly abstract representiation of the data. Because these objects are designed as SystemVerilog classes, they can all be derived from a common base class, usually uvm_sequence_item. When designing classes derived from th¡s, you not only add data members ard methods to model the data itself, but also overload various base class methods so that each data object knows howto do a standard set of operations such as copying or printing itself. Greatinq Problem.Specific Testbench Gomponents The core of a testbench is the set of testbench components that will manipulate the transaction data. Some of these components need a direct connection to signals in HDL modules representing the device-undertest (DUT) and its supporting structures. Other components operate at a higher level of abstraction and work only with transaction data. All the components you create should be represented by classes derived from uvm_component. Components need to pass data to and from other components. ln UVM this is achieved by providing the components with suitable ports and exports (TLM-1 ) or sockets (TLM-2.0) through which they can communicate with one anotåer, (Note that all the standard components described below use TLM-I interfaces; TLM-2.0 interfaces are provided for communication between SystemVerilog and SystemC components that have TLM-2.0 interfaces.) Components never need to know about neighboring components to which they are connected; instead, components send and receive data by means of calls to methods in their ports. The set of methods implemented by ports is known as the TLM-I Interfaces (uvm_tlm_if in TLM-2.0). This is the fundamental principle of transaction level modeling: one component calls a TLM interface method in its porf and, thanks to the connection mechanism, the corresponding method is automatically called in a different component's exporf. I Copyright@2013 by Douloe Ltd. Allrþhts reswêd.

资料库

Doulos - UVM Golden Reference Guide-Doulos Ltd. (2013).pdf

相关推荐

开发技术

热门标签

最新资料