UVM-IEEE Std.1800.2™-2017：FPGA IC验证最新指南

PDF文件

下载需积分: 35 | 5.88MB | 更新于2024-07-17 | 92 浏览量 | 举报收藏

立即下载

IEEE Std. 1800.2™-2017，全称为《通用验证方法学语言参考手册》，是由设计自动化标准委员会（Design Automation Standards Committee, DAC）的IEEE计算机学会（IEEE Computer Society）所赞助制定的标准。该标准是针对FPGA（Field-Programmable Gate Array）集成电路验证的重要参考资料，适用于2017年发布的版本，旨在提供一套通用的方法论框架，以便于软件和硬件工程师在设计和验证过程中实现更高效、系统化的验证工作。作为UVM（Universal Verification Methodology）的核心文档，IEEE Std. 1800.2™-2017定义了UVM语言的语法规则和架构，以及如何使用UVM进行系统级、模块级和功能级的验证。UVM是一种基于层次结构的验证方法，它将验证任务分解为三个主要部分：环境（Environment）、接口适配器（Interface Adapter）和验证组件（Verification Components），如 sequencers（顺序器）、 Coverage Groups（覆盖组）、composers（合成器）和 monitors（监视器）。此标准的重要内容包括： 1. **UVM架构**：详述了UVM的体系结构，如何组织测试套件，以及各个组成部分之间的协作关系。 2. **环境与配置**：阐述了如何创建和配置环境，模拟系统的行为，并管理全局状态。 3. **接口适配器**：介绍如何编写适配器来连接验证模型与目标设计，使得不同IP核间的交互得以实现。 4. **验证组件**：讲解了如何使用UVM提供的基础类来创建自定义的验证逻辑，如线程驱动的序列化和非序列化操作。 5. **覆盖率和统计**：强调了测试覆盖率的重要性，如何度量和提高代码的覆盖率，确保测试的全面性。 6. **可重复性和可扩展性**：讨论了如何编写可重用的验证模块，以及如何通过组合和扩展这些模块来适应不同的验证场景。 7. **调试和报告**：提供了调试工具和技术，以及如何生成详细的测试报告，帮助开发团队追踪和分析问题。 8. **标准化实践**：推荐了一些最佳实践，包括代码风格、文档编写、版本管理和测试流程的规范化。 9. **版权和授权**：明确指出此标准的版权信息，以及下载和使用时的限制条件。 IEEE Std. 1800.2™-2017是任何从事FPGA IC验证工程师的必备参考资料，它为验证过程提供了清晰的指导，有助于提高验证效率，降低风险，确保产品的质量。对于想要深入了解和实施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: wang kai. Downloaded on January 10,2019 at 05:15:18 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: wang kai. Downloaded on January 10,2019 at 05:15:18 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: wang kai. Downloaded on January 10,2019 at 05:15:18 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: wang kai. Downloaded on January 10,2019 at 05:15:18 UTC from IEEE Xplore. Restrictions apply.

剩余471页未读，继续阅读

paigukai

粉丝: 2

UVM-IEEE Std.1800.2™-2017：FPGA IC验证最新指南

UVM1.1a 验证方法学

uvm v2.0 标准库源代码

1800.2-2017.zip_1800_1800.2_IEEE UVM_ieee 1800 2017_ieee 1800.2-

最新的SV IEEE 1800-2017 和 UVM IEEE 1800.2-2017英文版

SystemVerilog IEEE 1800-2017.pdf

UVM-IEEE-STD-1800-2020 deepl机翻中文版，可对照原版UVM标准快速学习

IEEE 1800.2-2017: UVM语言参考手册

IEEE Std 1800.2-2017：通用验证方法学语言参考手册

IEEE Std 1800.2-2020：UVM通用验证方法学最新标准

IEEE 1800.2-2020 UVM标准修订详解

最新资源