UVM入门指南：覆盖驱动验证与TLM详解

需积分: 34 178 浏览量更新于2024-07-22 收藏 1.16MB PDF 举报

UVM（Universal Verification Methodology）是IC验证领域中的一个关键工具，它提供了一种结构化和模块化的测试方法，以实现覆盖率驱动的验证(Coverage-Driven Verification，CDV)。UVM的学习文档旨在帮助读者理解和应用UVM在设计验证过程中的角色。首先，UVM用户指南概述了UVM的核心概念，包括： 1. **简介**：介绍UVM的基本理念和目标，它是如何作为测试benchmarks和验证环境之间的桥梁，促进组件间的协作。 1.1 **UVM入门**： - **覆盖率驱动验证**：强调UVM通过自顶向下或自底向上的方式，确保设计的所有重要功能和路径都被测试覆盖。 - **测试台与环境**：讲解UVM如何组织和管理测试环境，包括数据交互的各个角色，如Driver（行为模型，BFM）、Sequencer（顺序器）、Monitor（监视器）和Agent（代理）。 1.2 **验证组件概述**： - **数据项（交易）**：数据单元，用于封装和传递测试用例中的操作。 - **Driver（行为模型）**：负责生成和发送交易，模拟真实世界的行为。 - **Sequencer**：生成交易序列并控制执行流程。 - **Monitor**：检查交易是否符合预期结果。 - **Agent**：更通用的角色，可以同时包含Driver和Monitor的功能。 - **环境**：全局上下文，协调所有组件的活动。 1.3 **UVM类库**：UVM提供了一系列预定义的类和接口，支持组件的创建、配置和管理。 1.4 **其他UVM设施**： - **UVM工厂**：简化组件实例化和管理的过程。 - **Transaction-Level Modeling (TLM)**：UVM的基础通信机制，包括TLM-1和TLM-2.0版本，以及它们的实施细节和组件连接方式。 2. **交易级别建模(TLM)**：深入讲解TLM，涉及交易的概念、通信机制、阻塞与非阻塞通信、组件间连接、封装和层次关系、分析通信、通用载荷等核心接口和特性。这份文档不仅适合新手学习UVM的基础知识，也对已有经验的验证工程师提供实用指导，帮助他们在实际项目中高效地运用UVM进行IC设计的验证工作。通过理解并遵循UVM的最佳实践，开发者能够确保其设计的可靠性，并在复杂的设计环境中实现有效的测试覆盖。

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页未读，继续阅读

drwang119

粉丝: 0
资源: 3

UVM入门指南：覆盖驱动验证与TLM详解

学习UVM验证方法学的必读文档：UVM IEEE标准文档

UVM学习指南与代码分析教程

UVM学习资料：从入门到进阶的全面指南

UVM学习文档,资源包括了UVM入门文档

UVM学习实验

UVM学习视频

uvm 学习指南

UVM IEEE标准文档

UVM学习资料合集.rar

uvm1.2学习资料.zip

最新资源