IEEE 1800.2-2020标准：UVM通用验证方法论参考手册

verification

IEEE

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

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

30元优惠券

"IEEE_Standard_for_UVM-2020.pdf" 本文将详细解析《IEEE Standard for Universal Verification Methodology Language Reference Manual》2020版本，也即UVM IEEE标准2020年更新。该标准由IEEE计算机学会的设计自动化标准委员会开发，主要目的是提高验证方法的互操作性，降低在新项目中使用知识产权（IP）的成本。 UVM（Universal Verification Methodology）是一种基于SystemVerilog的行业标准验证方法论，旨在为系统级验证提供一个可复用、可扩展和可定制的框架。2020版是对2017版的修订，通常会包含对之前版本的错误修正、功能增强以及对技术发展的适应。 1. **UVM核心组件** UVM的核心组件包括类库，如Agent、Sequence、SequenceItem、Scoreboard、Environment等，这些组件构建了验证环境的基础结构。例如： - **Agent**：负责管理数据传输，包括驱动、监视器和事务接口。 - **Sequence**：定义了在验证过程中发送到DUT（Design Under Test）的事务序列。 - **SequenceItem**：代表单个事务，是Sequence的操作对象。 - **Scoreboard**：用于比较模型预期的结果与实际观测到的行为，以评估设计的正确性。 - **Environment**：包含了验证环境的所有组件，定义了验证环境的结构和行为。 2. **UVM的复用性和扩展性** UVM通过提供一组预定义的类和方法，使得用户可以快速搭建验证环境，而不必从头开始编写代码。同时，UVM的设计允许用户根据需要扩展或修改其基础结构，以适应特定的设计验证需求。 3. **面向对象编程** UVM利用SystemVerilog的面向对象特性，如继承、多态和封装，实现高效灵活的验证代码。用户可以通过继承UVM基类并重写或扩展方法来创建自定义组件。 4. **事件和通信机制** UVM使用事件和消息传递机制协调验证组件之间的交互。例如，sequences通过请求（reqeust）和响应（response）机制与driver进行通信，而monitor则通过分析总线信号来收集数据。 5. **覆盖度** UVM提供了内置的覆盖度支持，允许用户定义和跟踪设计的关键行为覆盖率指标，从而帮助确认验证的完整性。 6. **可配置性** UVM的可配置性使得用户可以在不修改代码的情况下，通过配置参数调整验证环境的行为。这极大地提高了代码的复用性。 7. **标准化** 作为IEEE标准，UVM确保了不同团队和公司之间的工具兼容性和验证流程一致性，降低了合作和迁移成本。 IEEE Std 1800.2-2020为SoC（System on Chip）验证提供了一个强大且统一的框架，它不仅简化了验证过程，还促进了验证团队之间的协作和效率提升。对于任何从事系统级验证的工程师来说，理解和掌握UVM都是必不可少的技能。

资源详情

资源推荐

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: East China Normal University. Downloaded on April 03,2021 at 11:06:26 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: East China Normal University. Downloaded on April 03,2021 at 11:06:26 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: East China Normal University. Downloaded on April 03,2021 at 11:06:26 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: East China Normal University. Downloaded on April 03,2021 at 11:06:26 UTC from IEEE Xplore. Restrictions apply.

剩余457页未读，继续阅读

小破同学

粉丝: 7768
资源: 4

IEEE 1800.2-2020标准：UVM通用验证方法论参考手册

IEEE Standard for UVM-2020.pdf

IEEE_Standard_for_UVM-2020_redline.pdf

uvm-1.1.zip_IC验证_IC验证资料_UVM_uvm 1.1d_uvm平台

svt_uvm_pkg::*是什么库

uvm_config_db#(virtual svt_axi_if)::set(uvm_root::get(), "uvm_test_top.env.amba_system_env.axi_system[0]", "vif", axi_if);

将shell的uvm_warning=$(grep "UVM_WARNING :" sim.log | sed 's/[^0-9]//g') uvm_error=$(grep "UVM_ERROR :" sim.log | sed 's/[^0-9]//g') uvm_fatal=$(grep "UVM_FATAL :" sim.log | sed 's/[^0-9]//g')翻译成python

UVM-Info的结构

ieee 1800.2-2020

tv_proc.uvm_meth_db.cfg_reg_using_tv

grep $fn /hpc1/users/verification/EMS/UVM/uvm_rtl_ems_ad1/all_param_table.f --max-count=1 | sed "s/\s//g"

uvm-1.1a.tar.gz

uvm_reg_access_virt_seq和uvm_reg_bit_bash_seq的区别

uvm的top.sv中为什么有了uvm_pkg::*还要写svt_uvm_pkg::*

uvm_seq_item_pull_port

写一个python，在文件夹中搜索所有.log结尾的文件，统计UVM_ERROR、UVM_WARNING、UVM_FATAL、Testcase FAIL

最新资源

uvm的top.sv中为什么有了uvm_pkg::还要写svt_uvm_pkg::