UVM1.1用户指南：系统验证方法学

需积分: 0 131 浏览量更新于2024-06-21 收藏 1.66MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"UVM1.1用户指南是关于Universal Verification Methodology (UVM)的详细文档，由Accellera、Cadence Design Systems、Mentor Graphics和Synopsys等公司联合发布。该指南旨在为电子设计自动化领域的验证提供一种通用的方法学。UVM是基于SystemVerilog的，用于半导体集成电路验证的开源框架。此资源涵盖了UVM1.1版本的使用方法，包括版权信息和Apache 2.0许可证条款。" UVM（Universal Verification Methodology）是一种广泛采用的系统Verilog验证方法学，它为数字设计验证提供了标准化的组件库、架构和指导原则。UVM的核心目标是提高验证效率，通过复用和可配置的验证组件来加速验证流程。 1. **UVM组件库**：UVM包含一组预定义的验证组件，如代理（agent）、序列器（sequencer）、驱动（driver）、监视器（monitor）和环境（environment）。这些组件可以灵活组合，以适应不同的验证需求。例如，代理负责在模拟器和硬件模型之间的通信，序列器控制测试序列的生成，而驱动则将这些序列转化为实际的激励。 2. **类层次结构**：UVM采用面向对象的设计，基于类的继承和多态性。这使得用户能够轻松地扩展和定制现有的组件，以满足特定项目的需求。 3. **事件和消息机制**：UVM通过事件和消息传递机制促进了组件间的通信。这些机制确保了异步操作的正确同步，并允许数据在验证环境中高效流动。 4. **覆盖率**：UVM内置了覆盖收集器，支持多种类型的覆盖率指标，如代码覆盖、功能覆盖和约束覆盖，帮助验证团队度量验证进度和完整性。 5. **配置和连接**：UVM提供了一套配置机制，使得组件可以自动连接并根据需求进行配置。这降低了环境搭建的复杂性，提高了重用性。 6. **随机化和约束**：UVM支持使用SystemVerilog的随机化和约束来生成测试数据。这有助于创建更丰富、更复杂的测试序列，从而更好地暴露设计中的错误。 7. **可扩展性**：UVM的设计考虑了可扩展性，允许用户添加自定义组件和功能，同时保持与标准UVM组件的兼容性。 8. **Apache 2.0许可证**：UVM1.1遵循Apache Software Foundation的Apache License 2.0，这意味着源代码可以免费使用、修改和分发，但需遵守一定的条款，如保留原始版权信息。 9. **专业判断和教育**：虽然UVM1.1用户指南提供了具体的验证任务指南，但实际应用时需要结合教育、经验和专业判断，因为不是所有指南内容都适用于所有情况。 UVM1.1用户指南是半导体行业验证工程师的重要参考资料，它提供了一个强大且灵活的验证框架，以提升验证质量和效率。通过深入理解和应用该方法学，工程师们能够构建出更为高效和可靠的验证环境。

资源详情

资源推荐

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.

可以对事务进行组合、分解、扩展、分层，并以其他方式

进行操作，以对任何抽象级别所需的任何通信进行建模。

May 18, 2011 UVM 1.1 User’s Guide 11

2.3.2 Transaction-Level Communication

Transaction-level interfaces define a set of methods that use transaction objects as arguments. A TLM port

defines the set of methods (the application programming interface (API)) to be used for a particular

connection, while a TLM export supplies the implementation of those methods. Connecting a port to an

export allows the implementation to be executed when the port method is called.

2.3.3 Basic TLM Communication

The most basic transaction-level operation allows one component to put a transaction to another. Consider

Figure 5

Figure 5—Simple Producer/Consumer

The square box on the producer indicates a port and the circle on the consumer indicates the export. The

producer generates transactions and sends them out its put_port:

class producer extends uvm_component;

uvm_blocking_put_port #(simple_trans) put_port; // 1 parameter

function new( string name, uvm_component parent);

put_port = new(“put_port”, this);

...

endfunction

virtual task run();

simple_trans t;

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

// Generate t.

put_port.put(t);

end

endtask

NOTE—The uvm_*_port is parameterized by the transaction type that will be communicated. This may either be

specified directly or it may be a parameter of the parent component.

The actual implementation of the put() call is supplied by the consumer.

class consumer extends uvm_component;

uvm_blocking_put_imp #(simple_trans, consumer) put_export; // 2 parameters

...

task put(simple_trans t);

case(t.kind)

READ: // Do read.

WRITE: // Do write.

endcase

endtask

endclass

NOTE—The uvm_*_imp takes two parameters: the type of the transaction and the type of the object that declares the

method implementation.

oducer

事务级接口定义了一组使用事务对象作为参数的方法。

TLM的port定义用于特定连接的一组方法(应用程序编程接口(API))，

而TLM的export提供这些方法的实现。

将

port

连接到

export

允

许在调用端口方法时执行该实现

事务的类型和声明方法实现的对象的类型。

发送请求（request）的端口为port（发起者 intiator），中间接收请求的端口为export，

最后实现的端口为imp（实现者 target）

按照transaction的流向，我们又可以将两个对象分为producer和consumer。区分它们的方法是，数据从哪里产生，它

就属于producer，而数据流向了哪里，它就属于consumer

producer(产生数据)因此需要调用put方法，所以是port

consumer(消耗数据）因此需要实现put方法，所以是imp

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

put操作的语义由TLM定义。在这种情况下，生产者中的put()调用将阻塞，直到消费者的put实现完成。除此之外，

producer的操作完全独立于put实现(uvm_put_imp)。事实上，消费者可以被另一个同样实现put的组件所取代，而生产

者将继续以完全相同的方式工作。TLM提供的模块化促进了一种环境，在这种环境中，由于接口定义良好，组件可以很

容易地重用。

剩余197页未读，继续阅读

weixin_51100707

粉丝: 1
资源: 3

UVM1.1用户指南：系统验证方法学

uvm2sadfasdfgddssddsas

无人机图像目标检测.zip

数据结构《数据结构》经典算法代码.zip

Microsoft Remote Desktop for mac

Axelrod-1.10.0-py2.py3-none-any.whl.zip

支持易码支付的聚合支付最新破解去后门源码.zip

基于JSP的图书管理系统.zip

Axelrod-1.17.1-py2.py3-none-any.whl.zip

基于yolov8的西红柿缺陷检测系统python源码+onnx模型+评估指标曲线+精美GUI界面.zip

基于Spring Boot框架的OA管理系统.zip

基于Spring Boot框架的微信课程学习系统.zip

IMG_20240905_192349.jpg

Avanza-0.0.11-py3-none-any.whl.zip

基于C++实现的Linux的 Shell 程序+项目开发文档，实现基本的命令执行功能，支持 I/O 重定向和管道操作

使用OpenCV部署yolov5-pose目标检测+人体姿态估计，包含C++和Python两个版本的程序

byoc框架中代码生成部分文档

2024-2030东南亚与中国废旧轮胎回收（热裂解部分）市场现状及未来发展趋势 Sample wyl.pdf

wireshark-4.2.4

yolov4-tiny版本的目标检测及可视化界面设计.zip

资源数据 (2qssxcx

最新资源