UVM 1.1用户指南：IC验证全面解析

需积分: 5 71 浏览量更新于2024-07-09 1 收藏 1.2MB PDF 举报

"uvm_users_guide_1.1.pdf - 全面介绍IC验证的资料，包含验证架构、环境搭建及SystemVerilog和UVM的详细内容。由Accellera、Cadence、Mentor Graphics和Synopsys等公司联合发布，基于Apache 2.0许可证授权。" 本文档是Universal Verification Methodology (UVM) 1.1用户指南，旨在为集成电路（IC）验证提供一套全面的方法论。UVM是一个基于SystemVerilog的开源验证库和方法学，它提供了一套标准化的组件和机制，用于创建高效的验证环境。一、UVM基础 UVM的核心在于其组件化和可重用性。它包括各种预定义的类，如sequencer、agent、monitor、controller和virtual sequence等，这些类为验证工程师提供了构建验证环境的基础模块。通过组合和定制这些组件，可以快速搭建出符合特定需求的验证环境。二、验证架构 1. **验证环境**：UVM的验证环境由不同的组件组成，如DUT（设计单元）接口、代理（agent）、监控器（monitor）和测试平台（testbench）。代理负责与DUT的交互，监控器则监控DUT的行为，而测试平台包含控制器和序列器，用于生成和调度激励。 2. **类层次结构**：UVM的类层次结构允许用户自定义继承自基类的组件，以便扩展功能或实现特定行为。三、SystemVerilog和UVM的关系 SystemVerilog是一种强大的硬件描述和验证语言，UVM就是建立在SystemVerilog的基础上，利用其面向对象的特性来实现验证方法学。SystemVerilog提供的事件、任务、函数、接口和类等机制，使得UVM能够灵活地处理验证过程中的并行性和通信问题。四、UVM组件 1. **Sequencer**：控制激励生成，协调虚拟序列（virtual sequences）的执行。 2. **Agent**：封装了DUT的接口，处理输入/输出信号，并提供了连接到监控器和控制器的机制。 3. **Monitor**：观察DUT的行为，记录和报告感兴趣的事件。 4. **Controller**：处理不同组件间的交互，根据需要响应事件或改变验证流程。 5. **Virtual Sequence**：可以看作是高级的测试序列，允许异步和并行的激励生成。五、教育和实践尽管UVM提供了丰富的工具和指导，但理解并有效应用它需要深入的教育、实践经验以及专业判断。用户应根据具体项目情况选择合适的组件和方法，并不断调整验证策略以确保充分覆盖设计的功能。六、许可证和法律事项本指南遵循Apache Software Foundation的Apache License 2.0，这意味着代码可以自由使用、修改和分发，但需遵守许可证条款。用户在使用UVM时，应了解并遵守相关的版权和法律要求。 "uvm_users_guide_1.1.pdf"是一个宝贵的资源，对于理解并掌握IC验证的UVM方法学至关重要。它不仅提供了详细的理论知识，还涵盖了实际应用的方方面面，是IC验证工程师的重要参考材料。

8 UVM 1.1 User’s Guide May 18, 2011

The UVM Class Library provides a built-in central factory that allows:

— Controlling object allocation in the entire environment or for specific objects.

— Modifying stimulus data items as well as infrastructure components (for example, a driver).

Using the UVM built-in factory reduces the effort of creating an advanced factory or implementing factory

methods in class definitions. It facilitates reuse and adjustment of predefined verification IP in the end-

user’s environment. One of the biggest advantages of the factory is that it is transparent to the test writer and

reduces the object-oriented expertise required from both developers and users.

1.4.2 Transaction-Level Modeling (TLM)

UVM components communicate via standard TLM interfaces, which improves reuse. Using a

SystemVerilog implementation of TLM in UVM, a component may communicate via its interface to any

other component that implements that interface. Each TLM interface consists of one or more methods used

to transport data. TLM specifies the required behavior (semantic) of each method, but does not define their

implementation. Classes inheriting a TLM interface must provide an implementation that meets the

specified semantic. Thus, one component may be connected at the transaction level to others that are

implemented at multiple levels of abstraction. The common semantics of TLM communication permit

components to be swapped in and out without affecting the rest of the environment.

May 18, 2011 UVM 1.1 User’s Guide 9

2. Transaction-Level Modeling (TLM)

2.1 Overview

One of the keys to verification productivity is to think about the problem at a level of abstraction that makes

sense. When verifying a DUT that handles packets flowing back and forth, or processes instructions, or

performs other types of functionality, you must create a verification environment that supports the

appropriate abstraction level. While the actual interface to the DUT ultimately is represented by signal-level

activity, experience has shown that it is necessary to manage most of the verification tasks, such as

generating stimulus and collecting coverage data, at the transaction level, which is the natural way engineers

tend to think of the activity of a system.

UVM provides a set of transaction-level communication interfaces and channels that you can use to connect

components at the transaction level. The use of TLM interfaces isolates each component from changes in

other components throughout the environment. When coupled with the phased, flexible build infrastructure

in UVM, TLM promotes reuse by allowing any component to be swapped for another, as long as they have

the same interfaces. This concept also allows UVM verification environments to be assembled with a

transaction-level model of the DUT, and the environment to be reused as the design is refined to RTL. All

that is required is to replace the transaction-level model with a thin layer of compatible components to

convert between the transaction-level activity and the pin-level activity at the DUT.

The well-defined semantics of TLM interfaces between components also provide the ideal platform for

implementing mixed-language verification environments. In addition, TLM provides the basis for easily

encapsulating components into reusable components, called verification components, to maximize reuse and

minimize the time and effort required to build a verification environment.

This chapter discusses the essential elements of transaction-level communication in UVM, and illustrates

the mechanics of how to assemble transaction-level components into a verification environment. Later in

this document we will discuss additional concerns in order to address a wider set of verification issues. For

now, it is important to understand these foundational concepts first.

2.2 TLM, TLM-1, and TLM-2.0

TLM, transaction-level modeling, is a modeling style for building highly abstract models of components and

systems. It relies on transactions (see Section 2.3,

Basics), objects that contain arbitrary, protocol-specific

data to abstractly represent lower-level activity. In practice, TLM refers to a family of abstraction levels

beginning with cycle-accurate modeling, the most abstract level, and extending upwards in abstraction as far

as the eye can see. Common transaction-level abstractions today include: cycle-accurate, approximately-

timed, loosely-timed, untimed, and token-level.

The acronym TLM also refers to a system of code elements used to create transaction-level models. TLM-1

and TLM-2.0 are two TLM modeling systems which have been developed as industry standards for building

transaction-level models. Both were built in SystemC and standardized within the TLM Working Group of

the Open SystemC Initiative (OSCI). TLM-1 achieved standardization in 2005 and TLM-2.0 became a

standard in 2009.

TLM-1 and TLM-2.0 share a common heritage and many of the same people who developed TLM-1 also

worked on TLM-2.0. Otherwise, they are quite different things. TLM-1 is a message passing system.

Interfaces are either untimed or rely on the target for timing. None of the interfaces provide for explicit

timing annotations. TLM-2.0, while still enabling transfer of data and synchronization between independent

processes, is mainly designed for high performance modeling of memory-mapped bus-based systems. A

subset of both these facilities has been implemented in SystemVerilog and is available as part of UVM.

10 UVM 1.1 User’s Guide May 18, 2011

2.2.1 TLM-1 Implementation

The following subsections specify how TLM-1 is to be implemented in SystemVerilog.

— Section 2.4,

Encapsulation and Hierarchy

— Section 2.5, Analysis Communication

2.2.2 TLM-2.0 Implementation

The following subsections specify how TLM-2.0 is to be implemented in SystemVerilog.

— Section 2.6,

Generic Payload

— Section 2.7, Core Interfaces and Ports

— Section 2.8, Blocking Transport

— Section 2.9, Nonblocking Transport

— Section 2.10, Sockets

— Section 2.11, Time

— Section 2.12, Use Models

2.3 Basics

Before you can fully understand how to model verification at the transaction level, you must understand

what a transaction is.

2.3.1 Transactions

In UVM, a transaction is a class object, uvm_transaction (extended from uvm_object), that

includes whatever information is needed to model a unit of communication between two components. In the

most basic example, a simple bus protocol transaction would be modeled as follows:

class simple_trans extends uvm_transaction;

rand data_t data;

rand addr_t addr;

rand enum {WRITE,READ} kind;

constraint c1 { addr < 16’h2000; }

...

endclass

The transaction object includes variables, constraints, and other fields and methods necessary for generating

and operating on the transaction. Obviously, there is often more than just this information that is required to

fully specify a bus transaction. The amount and detail of the information encapsulated in a transaction is an

indication of the abstraction level of the model. For example, the simple_trans transaction above could

be extended to include more information, such as the number of wait states to inject, the size of the transfer,

or any number of other properties. The transaction could also be extended to include additional constraints.

It is also possible to define higher-level transactions that include some number of lower-level transactions.

Transactions can thus be composed, decomposed, extended, layered, and otherwise manipulated to model

whatever communication is necessary at any level of abstraction.

12 UVM 1.1 User’s Guide May 18, 2011

NOTE—The semantics of the put operation are defined by TLM. In this case, the put() call in the producer will

block until the consumer’s put implementation is complete. Other than that, the operation of producer is completely

independent of the put implementation (uvm_put_imp). In fact, consumer could be replaced by another component

that also implements put and producer will continue to work in exactly the same way. The modularity provided by

TLM fosters an environment in which components may be easily reused since the interfaces are well defined.

The converse operation to put is get. Consider Figure 6.

Figure 6—Consumer gets from Producer

In this case, the consumer requests transactions from the producer via its get port:

class get_consumer extends uvm_component;

uvm_blocking_get_port #(simple_trans) get_port;

function new( string name, uvm_component parent);

get_port = new(“get_port”, this);

...

endfunction

virtual task run();

simple_trans t;

for(int i = 0; i < N; i++) begin

// Generate t.

get_port.get(t);

end

endtask

The get() implementation is supplied by the producer.

class get_producer extends uvm_component;

uvm_blocking_get_imp #(simple_trans, get_producer) get_export;

...

task get(output simple_trans t);

simple_trans tmp = new();

// Assign values to tmp.

t = tmp;

endtask

endclass

As with put() above, the get_consumer’s get() call will block until the get_producer’s method

completes. In TLM terms, put() and get() are blocking methods.

NOTE—In both these examples, there is a single process running, with control passing from the port to the export and

back again. The direction of data flow (from producer to consumer) is the same in both examples.

2.3.4 Communicating between Processes

In the basic put example above, the consumer will be active only when its put() method is called. In

many cases, it may be necessary for components to operate independently, where the producer is creating

transactions in one process while the consumer needs to operate on those transactions in another. UVM

get_

producer

get_

consume

剩余197页未读，继续阅读

争做乖乖五好少年

粉丝: 0
资源: 1

UVM 1.1用户指南：IC验证全面解析

uvm_user_guide 1.0

uvm user guide

uvmgen_userguide.pdf

uvm_ref_flow_1.1.tar.gz_UVM_full_ovm_uvm_ref_flow

uvm_users_guide_1.1(学习uvm必备，可添加注释)

uvm_users_guide_1.2.zip_UVM手册_site:www.pudn.com_uvm user guide 1

UVM_Golden_Reference_Guide.rar_Golden_Practical UVM_UVM_UVM refe

UVM_learning.rar_UVM code_UVM guide_UVM pdf_UVM reference_uvm入门

pcie_test_suite_svt_uvm_user_guide.pdf

UVM1.1_labs_lossqet_UVM1.1_uvm验证book_UVM_uvm代码_

最新资源