UVM参考手册：IC验证技术核心指南

需积分: 9 188 浏览量更新于2024-07-09 收藏 4.19MB PDF 举报

"UVM参考手册是半导体行业中进行集成电路（IC）验证的重要参考资料，它基于IEEE Std 1800.2™-2017标准，由IEEE计算机学会的设计自动化标准委员会赞助发布。该手册详细介绍了通用验证方法论语言（UVM）的使用和实现，是工程师们理解和应用UVM的关键工具。" UVM（Universal Verification Methodology，通用验证方法论）是集成电路验证领域的一种标准化方法论，它基于SystemVerilog语言。UVM提供了一套预先构建的、可复用的验证组件和类库，旨在简化验证环境的创建，提高验证效率，并促进团队间的协作。这个参考手册详细阐述了UVM的各种组件、类、接口以及它们如何协同工作来实现高效的验证流程。 1. **UVM基础**：手册首先介绍UVM的基本概念，包括类层次结构、组件模型、事务接口协议（TIP）、消息机制等。这些基础概念帮助读者理解UVM是如何构建验证环境的框架。 2. **验证组件**：UVM的核心是验证组件，如代理（agent）、驱动（driver）、断言（assertion）、监控器（monitor）和环境（enviroment）。手册详细描述了这些组件的职责、它们之间的通信方式，以及如何通过配置和连接来定制验证环境。 3. **类库**：UVM提供了丰富的类库，包括队列、随机化器、覆盖收集器等。手册会解释这些类的使用方法，以及如何扩展和自定义它们以满足特定需求。 4. **配置与连接**：UVM支持动态配置和连接，允许在运行时调整组件的行为。手册会讲述如何使用配置数据库、配置规则和连接机制来控制组件的实例化和交互。 5. **激励发生器**：激励发生器是UVM中的一个重要组成部分，用于生成测试序列。手册会讲解如何定义新的激励类，以及如何使用序列器（sequence）和序列库（sequence library）来管理激励的发生。 6. **覆盖度**：UVM提供了全面的覆盖度支持，包括语句覆盖、条件覆盖、决策覆盖等。手册将指导读者如何设置和收集覆盖点，以评估验证的完整性。 7. **调试和调试工具**：UVM提供了丰富的调试机制，如消息日志、事件跟踪和可视化工具。手册会介绍如何利用这些工具来调试验证环境和发现问题。 8. **最佳实践**：除了技术细节，手册还提供了许多验证的最佳实践，帮助工程师遵循UVM规范，提高代码质量和可维护性。 9. **兼容性和版本管理**：由于UVM标准随着时间不断演进，手册也会讨论不同版本间的差异和向新版本迁移的策略。 10. **案例研究**：手册可能包含一些实际案例，演示如何在具体项目中应用UVM，帮助读者更好地理解和应用理论知识。通过深入学习UVM参考手册，工程师可以掌握验证流程的标准化方法，提高验证的效率和质量，同时也能更好地适应集成电路设计的快速变化和复杂性。

IEEE Std 1800.2-2017

IEEE Standard for Universal Verification Methodology Language Reference Manual

UVM does not require any specific time unit precision for uvm_pkg.

All UVM methods that operate on values of type time, such as uvm_printer::print_time (see 16.2.3.11

are subject to the time scaling defined in IEEE Std 1800™.

1.3.6 Random stability

Any APIs that result in user code being executed are not guaranteed to be random stable. All other APIs are

guaranteed to be random stable, unless otherwise specified.

Authorized licensed use limited to: BEIJING UNIVERSITY OF TECHNOLOGY. Downloaded on April 20,2020 at 08:26:58 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1800.2-2017

IEEE Standard for Universal Verification Methodology Language Reference Manual

2. Normative references

The following referenced documents are indispensable for the application of this standard (i.e., they must be

understood and used, so each referenced document is cited in text and its relationship to this document is

explained). For dated references, only the edition cited applies. For undated references, the latest edition of

the referenced document (including any amendments or corrigenda) applies.

IEEE Std 1800™, IEEE Standard for SystemVerilog—Unified Hardware Design, Specification, and

Verification Language.

3. Definitions, acronyms, and abbreviations

For the purposes of this document, the following terms and definitions apply. The IEEE Standards

Dictionary Online should be consulted for terms not defined in this clause.

3.1 Definitions

agent: An abstract container used to emulate and verify device under test (DUT) devices; agents encapsulate

a driver, sequencer, and monitor.

blocking: An interface where tasks block execution until they complete. See also: non-blocking.

component: A piece of verification intellectual property (VIP) that provides functionality and interfaces.

consumer: A verification component that receives transactions from another component.

driver: A component responsible for executing or otherwise processing transactions, usually interacting

with the device under test (DUT) to do so.

environment: The container object that defines the testbench topology.

export: A transaction level modeling (TLM) interface that provides an implementation of methods used for

communication. Used in Universal Verification Methodology (UVM) to connect to a port.

factory method: A classic software design pattern used to create generic code by deferring, until run time,

the exact specification of the object to be created.

hook: A method that enables users to customize certain behaviors of a component.

generator: A verification component that provides transactions to another component. Also referred to as a

producer.

monitor: A passive entity that samples device under test (DUT) signals, but does not drive them.

non-blocking: A call that returns immediately. See also: blocking.

policy: A collection of settings used to apply an operation to a class.

IEEE publications are available from the Institute of Electrical and Electronics Engineers (http://standards.ieee.org/).

The IEEE standards or products referred to in Clause 2 are trademarks owned by the Institute of Electrical and Electronics Engineers,

Incorporated.

IEEE Standards Dictionary Online is available at: http://ieeexplore.ieee.org/.

Authorized licensed use limited to: BEIJING UNIVERSITY OF TECHNOLOGY. Downloaded on April 20,2020 at 08:26:58 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1800.2-2017

IEEE Standard for Universal Verification Methodology Language Reference Manual

port: A transaction level modeling (TLM) interface that defines the set of methods used for communication.

Used in Universal Verification Methodology (UVM) to connect to an export.

proxy: A class functioning as an interface to another component or class.

request: A transaction that provides information to initiate the processing of a particular operation.

response: A transaction that provides information about the completion or status of a particular operation.

scoreboard: The mechanism used to dynamically predict the response of the design and check the observed

response against the predicted response. Usually, refers to the entire dynamic response-checking structure.

sequence: A Universal Verification Methodology (UVM) object that procedurally defines a set of

transactions to be executed and/or controls the execution of other sequences.

sequencer: An advanced stimulus generator that executes sequences that define the transactions provided

to the driver for execution.

singleton: A design pattern where the creation of the class only has one instance of that class.

test: Specific customization of an environment to exercise required functionality of the device under test

(DUT).

testbench: The structural definition of a set of verification components used to verify a device under test

(DUT). Also referred to as a verification environment.

transaction: A class instance that encapsulates information used to communicate between two or more

components.

user: Someone that uses the Universal Verification Methodology (UVM) base class library (BCL).

NOTE—In this standard, user uses the classes, functions, methods, or macros defined herein.

3.2 Acronyms and abbreviations

API application programming interface

BCL base class library

DPI direct programming interface

DUT device under test

EDA electronic design automation

FIFO first-in, first-out

HDL hardware description language

IP intellectual property

RTL register transfer level

TLM transaction level modeling

UVM Universal Verification Methodology

VIP verification intellectual property

Notes in text, tables, and figures are given for information only and do not contain requirements needed to implement the standard.

Authorized licensed use limited to: BEIJING UNIVERSITY OF TECHNOLOGY. Downloaded on April 20,2020 at 08:26:58 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1800.2-2017

IEEE Standard for Universal Verification Methodology Language Reference Manual

4. UVM class reference

The UVM base class library provides the building blocks needed to quickly develop well constructed and

reusable verification components and test environments in SystemVerilog. All UVM API should maintain

random stability.

The UVM classes and utilities are divided into the following categories pertaining to their role or function.

The subsequent clauses of this standard give a more detailed overview of each category—and the classes

that comprise them.

Base—The basic building blocks for all environments are components, which do the actual work,

transactions, which convey information between components, and ports, which provide the interfaces used

to convey transactions. The UVM’s core base classes provide these building blocks. See Clause 5

Reporting—The reporting classes provide a facility for issuing reports (messages) with consistent

formatting and configurable side effects, such as logging to a file or exiting simulation. Reports can also

filter out messages based on their verbosity, unique ID, or severity. See Clause 6

Recording—The recording classes provide a facility to record transactions into a database using a consistent

API. Users can configure what gets sent to the back-end database, without knowing exactly how the

connection to that database is established. See Clause 7

Factory—As the name implies, the UVM factory is used to manufacture (create) UVM objects and

components. A factory can be configured to produce an object of a given type on a global or instance basis.

Factories allow dynamically configurable component hierarchies and object substitutions without having to

modify their code or break encapsulation. See Clause 8

Phasing—This category defines the phasing capability provided by UVM. See Clause 9

Synchronization—These event and barrier synchronization classes can be used for process synchronization.

See Clause 10

Containers—These classes are type parameterized data structures that provide queue and pool services. The

class-based queue and pool types allow for efficient sharing of the data structures compared with their

SystemVerilog built-in counterparts. See Clause 11

UVM TLM—The UVM TLM library defines several abstract, transaction-level interfaces and the ports and

exports that facilitate their use. Each UVM TLM interface consists of one or more methods used to transport

data, typically whole transactions (objects) at a time. Component designs that use UVM TLM ports and

exports to communicate are inherently more reusable, interoperable, and modular. See Clause 12

Components—Components form the foundation of UVM. They encapsulate the behavior of drivers,

scoreboards, and other objects in a testbench. The UVM base class library provides a set of predefined

component types, all derived directly or indirectly from uvm_component. See Clause 13

Sequences—Sequences encapsulate user-defined procedures that generate multiple

uvm_sequence_item-based transactions (see 14.1

). Such sequences can be reused, extended, randomized,

and combined sequentially and hierarchically in interesting ways to produce realistic stimulus to a DUT. See

Clause 14

Sequencers—The sequencer serves as an arbiter for controlling transaction flow from multiple stimulus

generators. More specifically, the sequencer controls the flow of uvm_sequence_item-based transactions

(see 14.1

) generated by one or more uvm_sequence #(REQ,RSP)-based sequences (see 14.3). See

Clause 15

Authorized licensed use limited to: BEIJING UNIVERSITY OF TECHNOLOGY. Downloaded on April 20,2020 at 08:26:58 UTC from IEEE Xplore. Restrictions apply.