2020年UVM验证方法论标准详解：IEEE Std 1800.2-2020

需积分: 23 63 浏览量更新于2024-07-14 收藏 3.91MB PDF 举报

IEEE Standard for UVM-2020，即《通用验证方法论语言参考手册》（IEEE Std 1800.2™-2020），是由IEEE计算机协会的设计自动化标准委员会制定的一份重要文档。这份标准修订自2017年的版本，旨在提升软件和硬件验证过程中的互操作性，并降低使用知识产权（IP）的成本。UVM是一种被广泛应用于电子设计自动化（EDA）行业的软件框架，它为系统级验证提供了统一的标准，使得不同厂商之间的设计验证工具能够协同工作。该标准的核心理念是通过模块化和可扩展的方式来构建验证环境，这包括行为模型（BMs）、系统接口（SIs）、覆盖率工具、环境适配器等关键组件。UVM将验证任务分解为可复用的部分，使得验证工程师可以专注于设计的特定部分，而不是底层实现的细节，从而提高效率并减少错误。在UVM-2020中，着重强调了以下几个方面： 1. **一致性与兼容性**：新标准确保了与先前版本的兼容性，同时引入了必要的更新和改进，以适应快速发展的技术环境。这有助于现有项目的平滑迁移，同时也为未来的技术扩展预留空间。 2. **面向对象编程**：UVM采用面向对象的设计原则，使得模型和组件具有封装性、继承性和多态性，便于维护和扩展。 3. **抽象层次**：UVM提倡分层架构，从高层次的系统级模型到低层次的驱动和检查器，允许验证工程师在不同抽象级别上工作，简化了复杂系统的验证。 4. **测试套件管理**：标准支持测试套件管理和执行，通过提供诸如TestHarness、TestPlan和TestSequence等工具，使得测试的组织和执行更为有序和高效。 5. **IP集成**：UVM帮助设计者更好地整合第三方IP，通过预定义的接口和适配器机制，减少了与外部组件的集成复杂性。 6. **学习资源**：UVM-2020引用了Accellera Systems Initiative的UVM预课程作为重要的学习材料，确保验证团队拥有充足的培训资源。 7. **许可证限制**：尽管这是一个重要的技术资源，但其使用受到限制，仅限于大连理工大学等特定机构下载，且可能涉及版权和使用条款。 IEEE Standard for UVM-2020是电子设计验证领域的一项重要成果，它通过标准化的方法论和工具，促进了验证流程的标准化和高效性，是所有从事该领域工作的专业人员不可或缺的参考资料。

IEEE Std 1800.2-2020

IEEE Standard for Universal Verification Methodology Language Reference Manual

2. Normative references

The following referenced documents are indispensable for the application of this document (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.

4, 5

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.

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.

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: Dalian University of Technology. Downloaded on March 27,2021 at 10:31:39 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1800.2-2020

IEEE Standard for Universal Verification Methodology Language Reference Manual

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: Dalian University of Technology. Downloaded on March 27,2021 at 10:31:39 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1800.2-2020

IEEE Standard for Universal Verification Methodology Language Reference Manual

4. Universal Verification Methodology (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 application programming

interface (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 transaction-level modeling (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 device under test (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: Dalian University of Technology. Downloaded on March 27,2021 at 10:31:39 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1800.2-2020

IEEE Standard for Universal Verification Methodology Language Reference Manual

Policies—Each of UVM’s policy classes performs a specific task for uvm_object–based objects: printing,

comparing, recording, packing, and unpacking (see 5.3). They are implemented separately from uvm_object to

allow for different ways to print, compare, etc., without modifying the object class being utilized; e.g., a user

can simply apply a different printer or compare policy to change how an object is printed or compared. See

Clause 16.

registers and memories in a design under test (DUT)

. See Clause 17.

Macros—UVM provides several macros to help increase user productivity. See Annex B.

Configuration and resources—These classes provide a configuration database, which is used to store and

retrieve both configuration time and run-time properties. See Annex C.

Package scope—This category defines a small list of types, variables, functions, and tasks defined in the

uvm_pkg scope. These items are accessible from any scope that imports the uvm_pkg. See Annex F.

Command line processor—This a general interface to the command line arguments that were provided for the

given simulation. See Annex G.

5. Base classes

5.1 Overview

The UVM base class library defines a set of base classes and utilities that facilitate the design of modular,

scalable, and reusable verification environments. The basic building blocks for all environments are

components and the transactions they use to communicate.

a) uvm_object—All components and transactions derive from uvm_object (see 5.3), which defines an

interface of core class-based operations: create, copy, compare, print, sprint, record, etc. It also defines

interfaces for instance identification (name, type name, unique id, etc.) and random seeding. All

derivatives of uvm_object are factory enabled, unless otherwise specified.

b) uvm_component—The uvm_component class (see 13.1) is the base class for all UVM components.

Components are quasi-static objects that exist throughout simulation. This allows them to establish

structural hierarchy much like modules and program blocks. Components participate in a phased test

flow during the course of simulation. Each phase—build, connect, run, etc.—is defined by a callback

that is executed in precise order. Finally, the uvm_component also defines any configuration,

reporting, transaction recording, and factory interfaces.

c) uvm_transaction—The uvm_transaction (see 5.4) is the root base class for UVM transactions,

which, unlike uvm_components (see 13.1), are transient in nature. It extends uvm_object (see 5.3) to

include a timing and recording interface. Simple transactions can derive directly from

uvm_transaction, while sequence-enabled transactions derive from uvm_sequence_item (see 14.1).

5.2 uvm_void

The uvm_void class is the abstract base class for all UVM classes. It is an abstract class with no data members

or functions. It allows for creation of generic containers of objects, similar to a void pointer in the C

programming language. User classes derived directly from uvm_void inherit none of the UVM functionality,

but such classes may be placed in uvm_void-typed containers along with other UVM objects.

Authorized licensed use limited to: Dalian University of Technology. Downloaded on March 27,2021 at 10:31:39 UTC from IEEE Xplore. Restrictions apply.