UVM实战指南：2013版

PDF文件

5星 · 超过95%的资源 | 下载需积分: 35 | 11.4MB | 更新于2024-07-24 | 133 浏览量 | 5 评论 | 举报 3 收藏

立即下载

"UVM_CookBook_2013 是一本详细介绍如何使用统一验证方法论（UVM）的指南，由Mentor Graphics的验证方法团队编写。这本书提供了丰富的在线方法学文档，涵盖了UVM的基础到高级应用，旨在帮助工程师理解和实现高效的验证环境。" 在UVM（Universal Verification Methodology）中，以下几个核心知识点是非常关键的： 1. **Testbench Architecture**：UVM测试平台架构是验证过程的核心，它包括了不同的组件、代理和环境来模拟被验证设计（DUT）的行为。测试平台分为不同层次，如块级（Blocklevel）、集成级（IntegrationLevel），这些层次帮助逐步验证DUT的不同部分。 2. **Component**：UVM组件是构建测试平台的基本单元，它们可以是独立的测试序列、监视器、代理或环境。每个组件都有自己的构建、连接、运行和拆除阶段。 3. **Agent**：UVM代理负责在测试平台与DUT之间的数据传输。它包含一个驱动器（Driver）用于生成事务，一个接收器（Sequencer）用于控制事务序列，以及一个监视器（Monitor）用于捕获DUT的响应。 4. **Phasing**：UVM中的阶段模型允许组件按顺序执行操作，如build、connect、start、run和end，确保正确的初始化和同步。 5. **Factory**：UVM工厂机制用于动态创建和实例化组件，允许用户在运行时改变组件类型，提供了强大的可配置性。 6. **SystemVerilog Packages**：UVM库基于SystemVerilog，包含了多种包，如uvm_pkg，提供必要的类、函数和宏，支持UVM组件的创建和交互。 7. **Connections to DUT Interfaces**：连接DUT接口是验证的关键，UVM通过虚拟接口（Virtual Interface）和配置数据库（Config DB）来管理这些连接，确保正确通信。 8. **Parameterized Tests**：参数化的测试类允许根据不同的输入参数实例化多个测试，增加了测试覆盖率。 9. **Configuration**：UVM配置管理涉及组件属性的设置，例如通过Config DB进行配置，可以跨组件层次设置和访问参数。 10. **Bus Functional Models (BFMs)**：BFMs是对总线协议的软件实现，模拟DUT接口的行为，使得测试平台能够与协议兼容。 11. **Protocol Modules**：协议模块是实现特定通信协议的UVM组件，如AHB、AXI等，它们处理协议规则和握手。 12. **Abstract and Concrete Classes**：UVM中的抽象类定义了通用行为，而具体类则实现特定的功能，这种分层设计提高了代码复用和可扩展性。 13. **Configuring a Test Environment**：配置测试环境涉及到组件的实例化、参数设置和连接，通过配置数据库和包可以实现灵活的环境配置。这个UVM CookBook 2013深入探讨了这些概念，并提供了实用的示例和技巧，帮助工程师在实际项目中有效利用UVM进行SoC验证。

Testbench/Build

The first phase of an UVM testbench is the build phase. During this phase the uvm_component classes that make up the

testbench hierarchy are constructed into objects. The construction process works top-down•with each level of the

hierarchy being constructed before the next level is configured and constructed. This approach to construction is referred

to as deferred construction.

The UVM testbench is activated when the run_test() method is called in•an initial block in the top level test module. This

method is an UVM static method, and it takes a string argument that defines the test to be run and constructs it via the

factory. Then the UVM infrastructure starts the build phase by calling the test classes build method.

During the execution of the tests build phase, the testbench component configuration objects are prepared and

assignments to the testbench module interfaces are made to the virtual interface handles in the configuration objects. The

next step is for the configuration objects to be put into the test's configuration table. Finally•the next level of hierarchy is

built.

At the next level of hierarchy, the configuration object prepared by the test is retrieved and further configuration may

take place. Before the configuration object is used to guide the configuration and conditional construction of the next

level of hierarchy it could be modified by that level of hierarchy. This conditional construction affects the topology or

hierarchical structure of the testbench.

The build phase works top-down and so the process is repeated for each successive level of the testbench hierarchy until

the bottom of the hierarchical tree is reached.

Testbench/Build

Assigning Virtual Interfaces From The Configuration Space

Before the UVM run_test() method is called, the links to the signals on the top level I/O boundary of the DUT should

have been made by connecting them to SystemVerilog interfaces and then a handle to each interface should have been

assigned to a virtual interface handle which is passed in to the test using uvm_config_db::set. See the article on virtual

interfaces for more information on this topic.

In the test's build method, these virtual interface references need to be assigned to the virtual interface handles inside the

relevant component configuration objects. Then, individual components access the virtual interface handle inside their

configuration object in order to drive or monitor DUT signals. In order to keep components modular and reusable,

drivers and monitors should not get their virtual interface pointers directly from the configuration space, only from their

configuration object. The test class is the correct place to ensure that the virtual interfaces are assigned to the right

verification components via their configuration objects.

The following code shows how the SPI testbench example uses the uvm_config_db::get method to make virtual interface

assignments to the virtual interface handle in the apb_agents configuration object:

// The build method from before, adding the apb agent virtual interface assignment

// Build the env, create the env configuration

// including any sub configurations and assigning virtual interfaces

function void spi_test_base::build_phase( uvm_phase phase );

// Create env configuration object

m_env_cfg = spi_env_config::type_id::create("m_env_cfg");

// Call function to configure the env

configure_env(m_env_cfg);

// Create apb agent configuration object

m_apb_cfg = apb_agent_config::type_id::create("m_apb_cfg");

// Call function to configure the apb_agent

configure_apb_agent(m_apb_cfg);

// Adding the apb virtual interface:

if( !uvm_config_db #( virtual apb3_if )::get(this, "" , "APB_vif",m_apb_cfg.APB) ) `uvm_error(...)

// More to follow

endfunction: build_phase

Nesting Sub-Component Configuration Objects

Configuration objects are passed to sub-components via the UVM component configuration space from the test. They

can be passed individually, using the path argument in the uvm_config_db::set method to control which components can

access the objects. However a common requirement is that intermediate components also need to do some local

configuration.

Therefore, an effective way to approach the passing of configuration objects through a testbench hierarchy is to nest the

configuration objects inside each other in a way that reflects the hierarchy itself. At each intermediate level in the

testbench, the configuration object for that level is unpacked and then its sub-configuration objects are re-configured (if

necessary) and then passed to the relevant components using uvm_config_db::set.

Following the SPI block level envrionment example, each of the agents will have a separate configuration object. The

envs configuration object will have a handle for each of the agents configuration object. In the test, all of the

configuration objects will be constructed and configured from the test case viewpoint, then the agent configuration object

剩余600页未读，继续阅读

资源评论

宏馨

2025.05.30

2013版本可能稍显陈旧，但基础概念依然有效。

艾闻

2025.05.19

UVM_CookBook_2013是一本关于UVM使用方法的实用指南。

莫少儒

2025.03.31

文档对于验证领域专业人士是宝贵的资源。

经年哲思

2025.02.20

适合初学者快速入门UVM。😂

思想假

2025.01.08

内容覆盖SV UVM，值得系统学习者关注。

haohao

粉丝: 5

UVM实战指南：2013版

uvm cookbook

UVMcookbook，user guide

uvm-cookbook-sequences-guide-verification-academy

UVM_Cookbook

Flex_CookBook_读书笔记(精品)

uvm-cookbook-ssss

uvm-cookbook2019.pdf

uvm-cookbook-complete-verification-academy

UVM-cookbook-complete-verification-academy.pdf

uvm-cookbook-registers-guide-verification-academy

最新资源