UVM实战指南：采用通用验证方法

5星 · 超过95%的资源需积分: 15 51 浏览量更新于2024-07-28 6 收藏 2.49MB PDF 举报

"《实用通用验证方法论（UVM）指南》是一本经过精心校对和重新排版的书籍，作者或编者基于原始影印PDF通过OCR技术转录并纠正了错误。这本书去掉了前言和附录，专注于主要内容，特别是关于UVM的详细解释。书中包含了大量的Visio绘制的图表，清晰度更高，旨在帮助读者更好地理解和应用UVM。本书特别关注了UVM在系统验证中的应用，涵盖了UVM的基本概念、测试平台、环境构建、接口通用验证组件（UVCs）以及对象导向编程的基础知识。" 在深入探讨UVM之前，首先需要理解通用验证方法论（UVM）是什么。UVM是一种基于SystemVerilog语言的业界标准验证方法，它为验证数字设计提供了一种可复用和可扩展的框架。UVM的核心在于其面向对象的设计，这使得它可以适应多语言和多种验证策略。 1. 验证规划与覆盖率驱动验证：在UVM中，验证工作是围绕计划和覆盖率指标进行的。这意味着在验证过程中，设计的每个功能和行为都需要有明确的覆盖目标，以确保全面验证。 2. 多语言和方法学：UVM允许在不同的验证环境中集成多种语言和验证技术，增强了灵活性和兼容性。本书的特色在于它不仅解释了UVM的基本概念，还提供了如何使用这本书的指导，包括如何运行示例和书中的约定。 3. UVM概述： - UVM测试平台和环境：UVM环境是验证设计的核心，它包含了用于模拟设计行为的组件，如代理、序列器、驱动、监视器和收集器。 - 接口UVCs：这些组件处理数据交换，如BFM（总线功能模型）负责与硬件接口交互。 - 测试平台和环境：UVM测试平台包括了所有必要的组件来驱动、监控和评估设计行为。 - 系统和模块UVCs：这些组件用于特定设计层次的验证，例如软件UVCs用于验证软件层面的行为。 - SystemVerilog UVM类库：提供了诸如工厂机制、事务级别建模（TLM）等工具，支持高效、灵活的验证代码编写。 4. 对象导向编程（OOP）基础：作为UVM的基础，OOP是设计和实现UVM组件的关键。书中介绍了OOP的基本概念，包括类、对象和程序的定义，以及在分布式开发环境中的应用。此外，还讨论了关注点分离的原则，这是创建可维护和可扩展的验证代码的关键。《实用通用验证方法论（UVM）指南》是学习和实践UVM的宝贵资源，通过它，读者可以深入了解UVM如何提升系统级验证的效率和质量。无论是对于新手还是经验丰富的验证工程师，都能从中受益。

UVCs to drive traffic for some time while polling the DUT status through the DUT

The repository block on the right illustrates a company UVC repository that can contain internally implemented or

commercial UVCs which can be leveraged by all verification projects.

2.2 Interface UVCs

The interface UVCs standard structure includes the following elements:

2.2.1 Data Items

Data items represent stimulus transactions that are input to the DUT, Examples include networking packets, bus

transactions, and instructions. The fields and attributes of a data item are derived from the data items specification. For

example, the Ethernet protocol specification defines valid values and attributes for an Ethernet data packet. In a typical

test, many data items are generated and sent to the DUT. By intelligently randomizing data item fields using SystemVerilog

constraints, you can create a large number of meaningful tests and maximize coverage.

2.2.2 Driver/Bus Functional Model (BFM)

A driver is an active entity which emulates logic that drives the DUT. A typical driver repeatedly pulls data items

generated by a sequencer (advanced generator) and drives it to the DUT by sampling and driving the DUT signals. For

example, a driver controls the read/write signal, address bus, and data bus for a number of clock cycles to perform a write

transfer. (If you have created a verification environment in the past, you probably have implemented driver functionality.)

2.2.3 Sequencer

A sequencer is an advanced stimulus generator that controls the items provided to the driver for execution. By default,

a sequencer behaves similarly to a simple stimulus generator and returns a random data item upon request from the driver.

This default behavior allows you to add constraints to the data item class in order to control the distribution of randomized

values. Unlike generators that randomize arrays of transactions or one transaction at a time, a sequencer includes many

important built-in features. A partial list of the sequencer’s built-in capabilities includes:

 Ability to react to the current state of the DUT for every data item generated

 Capture of the order between data items in user-defined sequences, which forms a more structured and meaningful

stimulus pattern

 Enabling time modeling in reusable scenarios

 Support for declarative and procedural constraints for the same scenario

 System-level synchronization and control of multiple interfaces

2.2.4 Monitor

A monitor is a passive entity that samples DUT signals but does not drive them. Monitors collect coverage information

and perform checking. Even though reusable drivers and sequencers drive bus traffic, they are not used for coverage and

checking—monitors are used instead. A monitor performs the following functions:

 Collects transactions (data items). A monitor extracts signal information from a bus and translates the information

into a transaction that can be made available to other components and to the test writer. Note that this activity might

be performed by a collector component that is described below.

 Extracts events. The monitor detects the availability of information (such as a transaction), structures the data, and

emits an event to notify other components of the availability of the transaction. A monitor also captures status

information so it is available to other components and to the test writer.

 Performs checking and coverage

 Checking typically consists of protocol and data checkers to verify that the DUT output meets the protocol

specification.

 Coverage is also collected in the monitor.

 Optionally prints trace information

Note We recommend splitting the monitor activity into signal- and transaction-level activities. This is done by splitting

the monitor class into a low-level collector class and a high-level monitor that does transaction-level coverage and

checking. See more information about the collector in “Collector” on page 17.

On a protocol-by-protocol basis, an environment can instantiate a separate monitor per device (for example, a monitor per

master or slave in an AHB bus), or a single bus monitor. A bus monitor handles all the signals and transactions on a bus,

while an agent monitor handles only signals and transactions relevant to a specific device.

Typically, drivers and monitors are built as separate entities (even though they may use the same signals) so they can work

independently of each other. However, you can reuse code that is common between a driver and a monitor to save time.

Note To enable an agent to operate passively when only the monitor is present, do not make monitors depend on drivers

for information.

2.2.5 Collector

In use models such as transaction-level modeling or acceleration, the signal-level activity is abstracted away completely, or

placed into the accelerator box. In addition, advanced protocols include transaction-level state machines, which need to be

checked and covered. When driving stimuli, the UVM enforces a good separation between the transaction level (sequencer)

and the signal-level activity (driver). The collector enables a similar separation for the monitoring path. The collector is also

a passive entity. It follows the specific protocol in order to collect bits and bytes and form transactions. An analysis port is

used to send the collected transaction to the monitor, where coverage and checking are performed. While not mandatory,

We recommend that you dedicate the monitoring path to a monitor and a collector. Figure 2-2, Monitor-Collector

Interaction, demonstrates the interaction between the monitor and the collector.

Note UVM 1.0 EA does not currently include a separate collector class.

Monitor

Collector

TLM:uvm_analysis_imp

Data transfer

TLM:uvm_analysis_port

Figure 2-2 Monitor-Collector Interaction

2.2.6 Agents

Sequencers, drivers, monitors, and collectors can be reused independently, but this requires the environment

integrator to learn the names, roles, configuration, and hookup of each of these entities. To reduce the amount of work

and knowledge required by the test writer, UVM recommends that environment developers create a more abstract

container called an agent.

Agents can emulate and verify DUT devices. They encapsulate a driver, sequencer, monitor, and collector (when

applicable). UVCs can contain more than one agent. Some agents are proactive (for example, master or transmit agents)

and initiate transactions to the DUT, while other agents (slave or receive agents) react to transaction requests. Agents

should be configurable so that they can be either active or passive. Active agents emulate devices and drive transactions

according to test directives. Passive agents only monitor DUT activity.

2.2.7 The Environment

The environment (env) is the top-level component of the UVC. It contains one or more agents, as well as other

components such as a bus monitor. The env contains configuration properties that enable you to customize the topology

and behavior to make it reusable. For example, active agents can be changed into passive agents when the verification

environment is reused for system verification.

Figure 2-3, Typical Interface UVC, illustrates the structure of a reusable verification environment. Notice that a

UVM-compliant UVC may contain an environment-level monitor. This bus-level monitor performs checking and coverage

for activities that are not necessarily related to a single agent. An agents monitors can leverage data and events collected

by the global monitor.

Monitor

Collector

uvm_driver

Sequencer

Driver

Config

Master Agent

Bus Monitor

checks

coverage

Config

name

has...

Monitor

Collector

uvm_driver

Sequencer

Driver

Config

Slave Agent

UVM Environment

DUT

Master Agent Slave Agent

bus

Figure 2-3 Typical Interface UVC

The environment class (

uvm_env

) is designed to provide a flexible, reusable, and extendable verification component.

The main function of the environment class is to model behavior by generating constrained-random traffic, monitoring

DUT responses, checking the validity of the protocol activity, and collecting coverage. You can use derivation to specialize

the existing classes to their specific protocol. This book describes the process and infrastructure that UVM provides to

replace existing component behavior with IP-specific behavior.

2.2.8 Testbench

A testbench is an environment that instantiates the rest of the reusable verification components. Interface, system,

and SW environments are instantiated, configured, and connected in a testbench component. If the next generation of a

device uses exactly the same interfaces of an existing device, the testbench can be re-applied and reused. But usually the

testbench is specific to the DUT and to the project, and is typically not reused in vertical reuse scenarios. Refer to Figure

2-1 to see the integration of multiple UVCs in a UVM testbench.

2.3 System and Module UVCs

As already discussed, an interface UVC captures protocol-related verification aspects. But where would you place a

device-specific set of verification aspects? For example, where would you place end-to-end coverage of multiple interfaces?

Or a DUT-specific checker? For these purposes, a module UVC is needed. A module UVC is an environment that contains

verification logic for a specific module or subsystem. It assists in verifying this subsystem, as it is vertically reused in a larger

environment.

A system UVC makes use of interface, module, and software UVCs (UVCs that can dynamically control software

execution). A system UVC might not contain its own agents, in which case it merely instantiates other UVCs and connects

them to create a larger verification environment. System UVCs are targeted at system verification—for example, a CPU,

bridge, or a cell phone. Relatively small system UVCs sometimes are called module UVCs. A system UVC typically makes use

of other UVCs, including:

 Interface UVCs for connecting to the system interfaces

 Other module or system UVCs, which are subsystems or modules of the current system being verified

 Any system UVC can he reused in a larger system verification environment. The system UVC architecture is similar to

the interface UVC architecture and contains:

 A collector for signals that connect to the DUT.

 A monitor that is fed by the collector and other interface UVCs’monitors. Virtual (multiple channel) sequencers

connected to the sequencers of the interface and subsystem UVCs. While interface UVC sequencers control a single

interface, a virtual sequencer controls multiple sequencers and orchestrates the system-level scenario. Its sequence

library defines multiple-channel sequences, which simultaneously control all of the system interfaces.

 A scoreboard—an untimed reference model that allows end to end checking. The scoreboard receives input from the

interface UVCs and compares the DUT responses to the testbench prediction for the same input. We recommend

using a scoreboard in the system UVC.

 An address map and register files. Most systems use memory and registers, which can be modeled using a register

package. With UVM, you will have a pointer to the register database address map and register files.

2.3.1 Software UVCs

Verification poses requirements such as How can you ensure that an interrupt occurred while visiting all the software

states? Or, How can you steer the simulation to visit this specific HW/SW corner cases? SW UVCs arc- elegant solutions for

requirements such as these.

A SW UVC expands the coverage-driven verification (CDV) capabilities of a testbench to control and monitor software.

The software UVC provides run-time control to the execution of driver routines. It can control the type, time, and

parameters of routine calls, and can collect desired coverage for software state variables. Virtual sequences can be used to

seamlessly control HW interfaces and SW execution. Coverage monitors can collect coverage for HW, SW and their

associations.

Note We do not cover SW UVCs in this book, if you are interested in additional information regarding these, please

contact a Cadence representative.

Figure 2-4, Typical System-Level UVM Testbench, shows how interface, module, and system UVCs can be reused to

compose a specific verification environment, including HW/SW co-verification. Later in this book we cover the details of

how to develop this type of environment.

剩余198页未读，继续阅读

oscillator

粉丝: 1

UVM实战指南：采用通用验证方法

Java实用编码挑战：pratical1.2b深入解析

BIOMOD教程：建模与分析指南

.NET代码生成实践与Visual Studio插件开发

Modeling Transient Flows-A Pratical Guide.pdf

Book_A_Pratical_Guide_to_AB_Testing

matlab a pratical introduction to programming and problem solving.pdf

Optimize Quality for Business Outcomes,a Pratical approach to software testing

TCP/IP sockets in java pratical guide for programmers second edition

A Practical Guide to TPM 2.0

芯片制造 Microchip Fabrication A Practical Guide to Semiconductor Processing

最新资源