【UVM基础】是否只能在build_phase中执行实例化动作的探究（以及为什么建议在UVM中，先配置再实例化）

于 2025-03-19 23:55:30 发布
阅读量70 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： 数字IC验证百宝箱 文章标签： 经验分享 面试 数字IC 芯片验证 SV
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/MoorePlus/article/details/146384322

答案是否定的。 除了在build_phase中执行实例化的动作，其实还可以在new函数中执行实例化的动作。

如可以在my_agent的new函数中实例化driver和monitor：

function new(string name, uvm_component parent);
	super.new(name, parent);
	if (is_active == UVM_ACTIVE
了解本专栏 订阅专栏 解锁全文
【UVM基础】常用的三个phase作用：build_phase/connect_phase/run_phase
悟已往之不谏 知来者之可追
02-21 4702
常用的三个phase：build_phase/connect_phase/run_phase
UVM对象实例化及覆盖的几种方法
沧月九流的博客
05-19 3206
UVM对象实例化的方法有多种，以下以object为例： 1）第一种：直接利用new函数进行实例化 trans t1; t1 = new("t1");//利用new函数进行实例化 2）第二种：uvm_component_registry中提供的方法type_id::create，此种方法也是最常使用的方法 trans t2; t2 = trans::type_id::create("t2",this); 3）第三种：uvm_factory中提供的方法creat_object_by_type trans t
UVM-实例调试
ICJJ的博客
03-28 1240
搭建一个简单平台 每个类都有类继承声明 每个类都有注册声明 使用component注册：test，env，scoreboard，agent，driver，monitor 使用object注册：sequence，sequence_item 每个类有new构造器 Makefile all： compile simulation compile： <tab>vcs -sverilog -ntb_opts uvm -timescale=1ns/1ns +define+UVM_NO_DPI &lt
Xcode 应用程序构建阶段（Build Phases）分析（1）
热门推荐
harbinxxh的专栏
09-12 1万+
在Xcode编译一个应用程序需要几个步骤，也称为构建阶段（Build Phases），有如下几个build phase，如下图所示： 1) 编译源文件（Compile Sources） 这个阶段编译所有的源文件；默认情况下，项目中添加任何一个源文件，也将添加到编译列表中。 2) 连接二进制文件和库（Link Binary With Libraries） 在完成源文件的编译之后，连接框架
Xcode 应用程序构建阶段（Build Phases）分析
u012808173的专栏
12-07 1981
在Xcode编译一个应用程序需要几个步骤，也称为构建阶段（Build Phases），有如下几个build phase，如下图所示： 1) 编译源文件（Compile Sources） 这个阶段编译所有的源文件；默认情况下，项目中添加任何一个源文件，也将添加到编译列表中。 2) 连接二进制文件和库（Link Binary With Libraries） 在完成源文件
4.1 学习UVM中的“build_phase“，将其应用到具体案例分为几步？
啄缘之间的博客
02-17 1249
在具体的验证项目中，是 UVM 验证环境初始化的核心阶段，用于构建组件树形结构和配置参数传递。Test：顶层测试用例，配置全局参数。Env：验证环境容器，集成所有子组件（Agent、Scoreboard 等）。Agent：代理组件，管理 Driver、Monitor 和 Sequencer。：具体功能组件，与 DUT 交互。：数据检查和覆盖率收集组件。
UVM_PHASE的执行顺序
m0_69999886的博客
06-06 4714
uvm phase的执行顺序
UVM(六）
buzhiquxiang的博客
04-15 831
UVM callback 如何改变driver的行为？ （1）使用UVM的factory机制和override机制实现（过多的扩展可能会引起继承关系层次出现混乱，应该从哪个类进行扩展？） call back(回调） function or task（回调函数） 在一个对象中使用，在另一个对象中定义 如何使用UVM callback 1、将UVM callback 方法内嵌入组件中 2、...
【UVM基础】UVM 的 build_phase 执行顺序
悟已往之不谏 知来者之可追
02-16 1282
UVM build_phase 执行顺序
Systemverilog+UVM搭建SOC
03-23
svUVM搭建利用Systemverilog+UVM搭建SOC及ASIC的RTL验证环境
UVM学习笔记--build_phase的执行顺序
wonder_coole的博客
05-10 1万+
理解UVM build_phase的执行顺序很重要 虽然明白build_phase的执行顺序是由上往下，由根节点到叶子节点，但具体细节还是不清楚，如是在同级的所有节点都先创建完成，在开始下一级节点的创建？还是某个节点一下所有节点都创建完，在创建兄弟节点及其子节点呢？ 我做了个试验，在每个component的new函数结尾会打印tag是 [new_call]的信息， 在每个build_phase函数...
UVM phase
踩坑记录
09-05 512
uvm phase
如何实例化uvm_object
weixin_44303034的博客
03-27 1254
uvm_object类是所有UVM数据以及层次结构的基类，其主要的角色是定义一系列的方法，比如一些公共的操作：create(), copy(), compare(), print(), record()等。 其中的 create() 与 get_type_name() 虚方法被简单实现，不再是纯虚方法。但在扩展类中如果需要使用与这两种方法的相关方法时必须实现这两种方法。1. 层次结构uvm_obj...
UVM学习笔记记录Day3
weixin_44357763的博客
11-17 807
function new、build_phase和main_phase、virtual、uvm_tset_top、宏的分号
UVM入门与进阶学习笔记3——phase机制
weixin_41979380的博客
01-22 2492
传统硬件设计模型在仿真开始前已完成例化和连接；而SV软件部分，类的例化需要在仿真开始后完成。虽然类的例化通过调用构建函数new()实现，但仅通过new()函数无法解决一个重要问题——验证环境层次化时需要保证例化的先后关系，以及在确立各个组件均完成例化后的连接。且如果需要实现高级功能，如顶层到底层的配置时，也无法在底层组件例化之前提前完成配置逻辑。 因此UVM引入phase机制，通过该机制可以清晰地将UVM仿真的阶段层次化。不单单是对各个phase的先后顺序，处于同一phase中的层次化组件之间的phase也
UVM-实验2
weixin_48510351的博客
11-11 1570
sv环境转换到uvm环境中时，有一些重要的改变发生。
UVM实战笔记（二）
weixin_44590534的博客
09-17 2982
UVM第二章，搭建一个简单的测试平台
《UVM实战卷Ⅰ》学习笔记 第二章 一个简单的UVM验证平台(2)
ICLC的博客
10-15 802
写在前面:为了避免文章过长,引起阅读疲劳,会将有些章节分开写 2.3 1.什么是基于信号级的操作?什么是基于transaction的操作? transaction是个抽象的概念,我们可以结合代码来理解,先看不同driver中什么是信号级再看什么是transaction.需求是:满足一般物理协议,以帧或者包传递数据.解决是:引入transaction 信号级 task my_driver::main_phase(uvm_phase phase); phase.raise_objection(
UVM中build_phase为什么是自上向下的执行顺序
最新发布
08-06
<think>首先，用户的问题是关于UVM框架中build_phase的执行顺序。用户问：“UVM框架中build_phase的执行顺序为何是自上向下”，意思是“为什么UVM框架中build_phase的执行顺序是自上而下”。 我需要参考提供的引用内容来回答这个问题。引用中包含了关于UVM Phase机制的信息。 从引用[1]：UVM Phase的核心作用包括流程标准化、执行顺序控制、同步机制和层次化执行。它提到“确保组件按正确顺序创建、连接和运行（如先创建父组件，再创建子组件）”。 引用[2]：描述了UVM内phase的执行顺序，但没有具体提到build_phase的顺序。 引用[3]：明确指出“实际上除了build_phase、final_phase和run_phase，其他phase的执行顺序均为自底向上”，并说“build_phase的执行顺序为自顶向下”。在引用[3]中，它说：“实际上除了build_phase、final_phase和run_phase，其他phase的执行顺序均为自底向上”，然后给出了connect_phase的自底向上例子，但build_phase是自顶向下的。 引用[4]：提到“build_phase在new函数之后main_phase之前运行”，并说“build_phase主要完成实例化工作”，但build_phase本身不自动实例化，需要依靠new函数或create。 引用[5]：解释了phase机制的意义，提到“在SV中对象例化通过new()来实现，但是简单的new无法解决的一个重要问题就是验证环境在实现层次化时如何保证例化的先后关系”，以及“UVM在验证环境构建时引入了phase机制，通过该机制我们可以很清晰的将UVM仿真阶段层次化。这里的层次化，不仅仅是指各个phase的先后执行顺序，处于同一phase中的层次化组件之间的phase也有先后关系。” 所以，关键点是：build_phase的执行顺序是自上而下的，即从父组件到子组件。 原因：这是因为在构建验证环境时，需要先创建父组件，然后再创建子组件。这样，父组件可以在子组件被创建之前进行配置或设置，确保子组件在创建时可以使用父组件的配置信息。 例如，在build_phase中，父组件先执行，它可以设置一些配置对象或参数，然后子组件在执行build_phase时，可以访问这些配置。 在引用[5]中，它解释了为什么需要这种顺序：为了解决验证环境层次化构建中的例化先后关系和配置问题。 因此，回答用户的问题： - build_phase的执行顺序是自上而下的（从父组件到子组件）。 - 原因：为了确保父组件先于子组件构建，这样父组件可以配置子组件所需的资源或参数，保证环境的一致性和正确性。 现在，关于回答结构： - 使用中文回答。 - 结构清晰，逐步解决问题。 - 行内数学表达式用$...$格式，但这里可能不需要数学，因为UVM是硬件验证相关。 - 独立公式用$$...$$，但同样可能不需要。 - 在回答中引用的段落末尾添加引用标识，例如[^1]。 - 生成相关问题。 回答结构： 1. 直接回答问题：解释build_phase的执行顺序。 2. 解释原因：基于引用内容。 3. 添加引用标识。 4. 最后生成相关问题。 生成相关问题： - 基于主题，生成2-3个相关问题。 例如： 1. build_phase与其他phase（如connect_phase）的执行顺序有何不同？ 2. 在build_phase中常见的任务是什么？ 3. 如何优化build_phase的实现？ 最终回答： - 先确认build_phase的顺序。 - 解释原因。 - 引用相关部分。</think>### UVM框架中build_phase的执行顺序及其原因 在UVM（Universal Verification Methodology）框架中，`build_phase` 的执行顺序是 **自上向下（top-down）** 的，即从验证环境的顶层组件（如 `uvm_test` 或 `uvm_env`）开始，逐级向下执行到子组件（如 `uvm_agent`、`uvm_driver` 等）。这种顺序是UVM Phase机制的核心设计之一，确保了验证环境的正确初始化和配置。以下我将逐步解释执行顺序和原因，结合UVM的机制设计。 #### 1. **build_phase的执行顺序** - **自上向下的流程**：在 `build_phase` 中，UVM执行引擎首先调用父组件的 `build_phase` 方法，然后递归调用其子组件的 `build_phase`。例如： - 顶层测试（`uvm_test_top`）的 `build_phase` 最先执行。 - 然后是环境组件（`env`）的 `build_phase`。 - 接着是代理组件（如 `i_agt` 或 `o_agt`）的 `build_phase`。 - 最后是叶子组件（如 `driver`、`monitor`）的 `build_phase`。 - 这种顺序确保了父组件在子组件之前被构建。 - **与其他phase的对比**：值得注意的是，`build_phase` 是少数自上向下执行的phase之一。例如： - `connect_phase` 的执行顺序是 **自底向上（bottom-up）**（即从叶子组件到父组件）[^3]。 - `final_phase` 和 `run_phase` 也有特定顺序，但 `build_phase` 的独特顺序是为了解决环境构建的依赖问题。 这种自上向下的顺序不是随意的，而是UVM设计哲学的一部分，下面解释原因。 #### 2. **执行顺序的原因** `build_phase` 的自上向下顺序主要源于验证环境构建的层次化需求，确保父组件能先于子组件完成初始化和配置。具体原因包括： - **解决配置依赖问题**： - 在验证环境中，父组件（如 `uvm_env`）通常负责定义和设置配置对象（例如，通过 `uvm_config_db` 设置参数）。如果子组件（如 `uvm_driver`）先执行 `build_phase`，它们可能无法访问父组件的配置，导致运行时错误。 - 自上向下顺序允许父组件在子组件创建之前完成配置。例如，父组件可以在其 `build_phase` 中设置时钟频率或协议参数，子组件在后续执行时直接使用这些配置[^5]。 - **确保组件创建的正确性**： - UVM组件的实例化（通过 `new()` 或 `create` 方法）发生在 `build_phase` 中。父组件需要先被创建，才能正确创建和引用子组件（如通过 `uvm_component` 的层次结构）。如果顺序颠倒（自底向上），父组件可能无法在子组件创建时提供必要的资源或句柄，导致连接错误[^4][^5]。 - 引用[5]明确指出：传统的SystemVerilog（SV）方法无法保证层次化组件的例化顺序，UVM的phase机制通过标准化顺序解决了这个问题。 - **支持验证平台的可扩展性和迁移**： - 自上向下顺序使验证环境更容易扩展。例如，添加新组件时，父组件可以在 `build_phase` 中动态调整子组件的类型或数量，而无需修改子组件代码。这也有助于从其他验证平台迁移到UVM，因为顺序提供了清晰的构建流程[^4][^5]。 总之，`build_phase` 的自上向下顺序是UVM确保验证环境可靠性和一致性的关键机制。它避免了配置和创建阶段的竞争条件，使得验证平台在仿真开始前（如 `run_phase`）就处于稳定状态。 #### 3. **实际影响与最佳实践** - **常见任务**：在 `build_phase` 中，开发者通常执行组件实例化、配置设置和资源分配。例如： ```systemverilog function void my_env::build_phase(uvm_phase phase); super.build_phase(phase); // 父组件先设置配置 uvm_config_db#(int)::set(this, "i_agt", "config_value", 100); // 然后创建子组件 i_agt = my_agent::type_id::create("i_agt", this); endfunction ``` - **错误避免**：如果顺序被错误处理（如子组件在父组件之前访问配置），可能导致空指针或配置未定义错误。因此，UVM强制执行此顺序。 通过以上分析，您可以看到 `build_phase` 的自上向下设计是UVM Phase机制的智慧之处，它解决了验证环境构建中的根本问题[^1][^5]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

MoorePlus

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值