UVM::uvm_do function about sub-sequence

最新推荐文章于 2025-05-25 13:03:17 发布
原创 最新推荐文章于 2025-05-25 13:03:17 发布 · 396 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

博客探讨了在UVM sequence中使用uvm_do(sub_sequence)时，sub_sequence的pre_body()和post_body()为何不被执行。原因在于uvm_do的实现中call_pre_post参数默认为0，导致这些函数被忽略。这可能导致在sub_sequence中无法执行objection相关操作，因为objection通常在pre/post_body中处理。

关注点1：在sequence中执行uvm_do(sub_sequence,...) 时，sub sequence的pre_body(), post_body() 不会执行， 原因：如果user把objection 的raise/drop放在pre_body/post_body中，而在一个环境中objection不希望出现在很多地方，所以在parent sequence中加入objection机制，sub sequence中pre/post body函数不执行，sub sequence中也不会有objection相关的操作

原因：

下面是sequence的执行function，但是pre_body, post_body是受start() 函数的参数控制的

而uvm_do的实现如下， 对应的call_pre_post参数为0

 

【从零开始学习 UVM】6.2、UVM 激励产生 —— `uvm_do 序列宏解析
努力，加油每一天鸭~
03-31 1865
【从零开始学习 UVM】6.2、UVM 激励产生 —— `uvm_do 序列宏解析
【从零开始学习 UVM】6.4、UVM 激励产生 —— uvm_do 宏详解
努力，加油每一天鸭~
03-31 1554
【从零开始学习 UVM】6.4、UVM 激励产生 —— uvm_do 宏详解
UVM学习笔记--uvm_do宏干了啥？
m0_63492501的博客
04-15 3115
除了uvm_do宏外，uvm_send宏、uvm_rand_send宏、uvm_create宏，其第一个参数都可以是sequence的指针。唯一例外的是start_item与finish_item，这两个任务的参数必须是transaction的指针。此系列一共有8个（do系列和do_on系列各4个），其实这8个系列宏最底层都是uvm_do_on_pri_with这个宏，其他7个都是对他的4个参数做了不同的固化后而形成，先看看他的参数定义。m_sequencer中。的指针，即在哪个sequencer上启动。
max sub_sequence - c
iteye_18468的博客
08-10 155
max sub_sequence  - c     /* problem: there is a sequence of number,could be positive or negative, find out the sub sequence which has max sum, solution: loop the sequence, use max...
[UVM]为什么不建议在body()中使用pre_body()和post_body
元直的博客
04-04 3376
不建议在body()中直接使用pre_body()和post_body()，因为只有通过start()启动sequence时才会调用它们，而常用的uvm_do宏不会触发。替代方案是在sequence中定义body_pre()和body_post()任务，或通过父类body()继承前置任务。此外，start()是uvm_sequence方法，uvm_do_on是宏，不能在uvm_test中使用，顶层virtualsequence应使用start()挂载到virtualsequencer上。
UVM uvm_sequence_library的add_typewide_sequence和add_sequence的区别
W1Z1Q的专栏
03-30 519
本文详细阐述了UVM uvm_sequence_library的add_typewide_sequence和add_sequence的区别
UVM环境复位--stop_sequences()
qq_42779035的博客
04-13 2454
在UVM验证环境中, stop_sequences是一个用于强制终止所有正在运行的 Sequence 的方法，通常用于动态控制激励生成流程。1.通过uvm_config_db传递事件和严格的同步机制，此方案符适用于复杂复位场景和动态测试控制。组件耦合：Driver 和 Sequence 不再直接依赖env，通过标准接口通信。竞争条件：确保 Driver 完成清理后再终止 Sequence。代码健壮性：使用非阻塞操作和事件监听，避免死锁。
UVM同步通信2 - uvm_callback详解
Future Chaser的博客
08-18 458
uvm_callback源码 分析
[UVM]在UVM验证环境中，uvm_reg_cb的详解及案例
元直的博客
05-25 793
摘要：UVM验证环境中，uvm_reg_cb是寄存器模型的关键回调机制，允许在不修改模型代码的情况下扩展功能。文章详细介绍了其六大应用场景：1）寄存器访问日志记录；2）值检查与验证；3）硬件副作用模拟；4）错误注入测试；5）覆盖率收集；6）动态行为调整。重点提供了日志记录、值检查、副作用模拟和错误注入四种场景的完整代码实现，包括回调类定义、注册方法和测试用例。通过实际案例展示了如何利用uvm_reg_cb增强验证能力，同时提示了注册范围、执行顺序等注意事项，为复杂寄存器验证提供了灵活解决方案。（149字）
uvm_sequence_library启动的sequence的一个注意点
W1Z1Q的专栏
04-08 1154
本文分析了放在uvm_sequence_library里启动的子sequence不能将执行代码放大pre_body()/post_body()当中，否则会造成没有被执行到。
UVM基础-sequence系列宏
qq_36955425的博客
06-04 6223
为什么cast会为0？使用重载pre_do，mid_do，和post_do的方法只会把简单的方式复杂化。事实上，这几个宏的底层都是`uvm_rand_send_pri_with，其他宏在其基础上做了参数固化，对于`uvm_rand_send_pri_with的源码分析，逻辑和其他的宏一样，只不过这个宏除了调用start_item和finish_item之外，还需要调用get_sequencer来获取sequencer，因此，这一系列宏需要和uvm_create系列宏配合使用。用的比较少，不过多讨论。
UVM 的sequence 在继承时执行body任务和pre_body任务会影响么？
weixin_40570952的博客
03-19 4338
systemverilog sequence 执行body task
《UVM实战》学习笔记——第六章 sequence机制
qq_42135020的博客
12-04 8517
virtual sequence，仲裁机制，m_sequencer
uvm_do系列宏介绍
热门推荐
m0_61703043的博客
02-23 1万+
uvm_do系列宏介绍
UVM中通过宏启动sequence 的弊端
liuwei848的博客
04-27 969
在UVM中启动sequence的方法主要有两种，一种是start的方法，一种是通过宏，比如`uvm_do。我们推荐在使用UVM的过程中尽量不要使用宏来启动sequence，而是使用start，因为使用宏的方法有一些意想不到的弊端，会给我们带来意想不到的惊喜，一旦出现问题，会给debug调试带来困难。下面我们讲解一下使用宏启动sequence有什么样的弊端。 在UVM中经常有一个顶层virtual ...
UVM常用点（个人）
qq_40571921的博客
05-24 818
1.uvm_do_on用于显式指定那个sequencer发送此transaction。第一个是transaction 指针，第二个是sequencer 指针。 2）使用uvm_do 时，默认的sequencer 就是此sequence 启动时为其指定的sequencer，sequence 将这个sequencer 的指针放在其成员变量m_sequencer 中。等价于： 3.显示UVM树的拓扑结构：uvm_top.print_topology();//应在build_phase之后调用 ...
UVM验证：uvm_do_on_with函数随机化约束问题及解决方案
qq_54649447的博客
12-22 7266
比如：为了增强代码的可读性，我们通常会将顶层和底层的seq变量定义为相同名称，在顶层top_vseq中启动底层sub_seq时，'uvm_do_on_with(sub_seq,{a == a});这个约束是无法生效的。 1、约束不生效的原因 从编译器的角度出发，它不知道两个变量a有什么不同，并且会把它做为sub_seq作用域中的两个相同变量，这就导致约束失效。 2、解决方案 将顶层变量和底层变量定义成不一样的名称，比如：顶层变量定义为a，底层变量定义为rand_a，然后执行’uvm_do_on_with(s
uvm 形式验证_uvm_do系列宏解析
weixin_32836671的博客
12-30 5227
上一篇加法器的UVM验证平台的文章中介绍了两种发送transaction的方法，但是这两种方法其实大同小异，因为uvm_do的这个宏中其实调用了start_item()和finish_item()，下面就详细介绍一下uvm_do系列宏。1、uvm_do系列宏包括：`uvm_do`uvm_do_pri`uvm_do_with`uvm_do_pri_with`uvm_do_on`uv...
incompatible complex type usage,the type of the actal is calss etimer_env_pkg::uvm_analysis_imp_rxport#(class etimer_env_pkg::etimer_transaction.class etimer_env_pkg::etimer_env_refm),while the tupe of the formal is class uvm_pkg::uvm_port_base#(class uvm_pkg::uvm_tlm_if_base#(class svt_ahb_uvm_pkg::svt_ahb_transaction,class svt_ahb_uvm_pkg::svt_ahb_transaction))
最新发布
11-08
<think>我们面对的是一个SystemVerilog UVM环境中的类型不兼容错误。错误信息指出：在实际调用中传递的类型（etimer_env_pkg::uvm_analysis_imp_rxport）与形式参数期望的类型（uvm_pkg::uvm_port_base）不匹配。这两个类型都是参数化的类（模板类），但它们的模板参数不同。 分析错误信息： 实际类型：etimer_env_pkg::uvm_analysis_imp_rxport#(etimer_env_pkg::etimer_transaction.class etimer_env_pkg::etimer_env_refm) 形式类型：uvm_pkg::uvm_port_base#(uvm_pkg::uvm_tlm_if_base#(svt_ahb_uvm_pkg::svt_ahb_transaction, svt_ahb_uvm_pkg::svt_ahb_transaction)) 这里，我们注意到： 1. 实际类型是一个uvm_analysis_imp_rxport，它通常在UVM中用于实现analysis port的imp端，其模板参数是etimer_transaction（传输类型）和etimer_env_refm（实现该imp的组件类型）。 2. 形式类型是一个uvm_port_base，其模板参数是一个uvm_tlm_if_base，而uvm_tlm_if_base本身又用两个svt_ahb_transaction类型参数化。 显然，这两个类型并不相同，而且它们的参数化结构也不一样。因此，直接传递会产生类型不匹配。 解决思路： 1. 检查代码中调用的上下文，确认我们试图将什么传递给什么。根据错误信息，很可能是将etimer_env_pkg中的某个analysis imp端口连接到了期望svt_ahb_transaction类型的TLM端口上。 2. 确保连接的两端具有兼容的类型。在UVM中，端口连接要求两边的端口类型必须是兼容的，即： - 如果一端是`uvm_analysis_port`，那么另一端应该是`uvm_analysis_imp`或者另一个`uvm_analysis_port`（通过端口到端口的连接）。 - 此外，它们所传递的事务类型必须相同。 在这个错误中，实际端口的事务类型是`etimer_transaction`，而形式端口期望的事务类型是`svt_ahb_transaction`（通过`uvm_tlm_if_base`的两个模板参数可以看出，这两个参数分别代表请求和响应类型，但在这里请求和响应都是`svt_ahb_transaction`）。因此，事务类型不匹配。 解决方案： 1. 重新考虑设计：是否应该将etimer_env_pkg中的端口连接到这个期望svt_ahb_transaction的端口？可能设计意图有误。 2. 如果设计正确，那么可能需要一个适配器（adapter）来转换事务类型。即，我们可以在中间加入一个组件，该组件接收`etimer_transaction`，然后将其转换为`svt_ahb_transaction`，再发送到目标端口。 3. 检查两端端口的声明和使用是否正确。特别是，形式参数期望的端口类型是`uvm_port_base`（这是一个基类），但实际上我们可能应该使用更具体的端口类型（如`uvm_analysis_port`）？但是错误信息中给出的形式参数类型是一个参数化的`uvm_port_base`，其参数是特定的TLM接口，这看起来像是某个TLM端口（如`uvm_blocking_put_port`等）的基类。 具体步骤建议： - 首先，定位代码中报错的位置（根据错误信息给出的文件和行号）。 - 检查该行代码中，调用函数或任务时传递的参数（即`this.req`）的类型是否与函数或任务定义的形式参数类型一致。 - 如果确实需要连接两个不同类型的事务，则考虑使用适配器组件： 1. 创建一个新的组件，继承自`uvm_component`，并在其中声明以下端口： - 一个类型为`uvm_analysis_imp_rxport#(etimer_transaction, adapter_component)`的imp端口（用于接收etimer_transaction）。 - 一个类型为`uvm_port_base`所期望类型的端口（例如`uvm_blocking_put_port#(svt_ahb_transaction)`或其他）。 2. 在该组件中实现`write`方法（因为analysis imp需要）或者相应的任务（如果是阻塞操作），在接收到`etimer_transaction`时，将其转换为`svt_ahb_transaction`，然后通过后者的端口发送出去。 3. 在环境中实例化这个适配器，并将原始的连接改为： - etimer_env_pkg的端口连接到适配器的analysis imp端口。 - 适配器的输出端口连接到原来期望`svt_ahb_transaction`的端口。 注意：转换时需要确保事务内容的正确映射。 另外，还需要注意端口的方向和类型是否匹配（例如，analysis端口是广播，而put端口是点对点）。 如果没有设计错误，而是端口声明错误，则需要修改端口声明，使两端的事务类型一致。 由于错误信息中提到了类名包含很长的模板参数，这可能是由于实例化时的参数不一致导致的。因此，请仔细检查相关端口的声明。 总结：这个错误的核心是类型不匹配，解决方法是确保两端端口的事务类型一致，或者通过适配器转换事务类型。 </think>根据您提供的错误信息，实际类型（`etimer_env_pkg::uvm_analysis_imp_rxport`）与形式类型（`uvm_pkg::uvm_port_base`）不兼容的问题源于 SystemVerilog UVM 环境中的类型不匹配。以下是解决方法和步骤： --- ### **错误原因分析** 1. **类型层次不匹配** - 实际类型：`uvm_analysis_imp_rxport`（专用于 `etimer_transaction` 的分析端口实现） - 形式类型：`uvm_port_base`（期望基于 `svt_ahb_transaction` 的 TLM 接口） - 本质是两种不兼容的 UVM 端口类型，且事务对象类型不同（`etimer_transaction` vs `svt_ahb_transaction`）。 2. **模板参数冲突** - `uvm_analysis_imp_rxport` 的模板参数为 `etimer_transaction`，而 `uvm_port_base` 的模板参数为 `uvm_tlm_if_base<svt_ahb_transaction>`，两者无法直接转换[^1][^2]。 --- ### **解决方案** #### 方法 1：统一事务类型（推荐） 在顶层环境（如 `etimer_env`）中显式声明端口类型： ```systemverilog // 修改前：使用 uvm_port_base 声明 uvm_port_base #(uvm_tlm_if_base #(svt_ahb_transaction)) ahb_port; // 修改后：统一为 uvm_analysis_imp uvm_analysis_imp_rxport #(etimer_transaction, etimer_env_refm) rx_port; ``` 确保所有连接（`connect_phase`）使用相同事务类型： ```systemverilog agent.analysis_port.connect(refm.rx_port); // 端口类型均为 etimer_transaction ``` #### 方法 2：使用适配器（Adapter）转换事务类型 若必须连接不同事务对象： 1. 创建事务转换器： ```systemverilog class trans_adapter extends uvm_component; uvm_analysis_imp #(etimer_transaction, trans_adapter) in_port; uvm_analysis_port #(svt_ahb_transaction) out_port; virtual function void write(etimer_transaction t); svt_ahb_transaction ahb_tx = new(); ahb_tx.copy_from_etimer(t); // 自定义转换逻辑 out_port.write(ahb_tx); endfunction endclass ``` 2. 在环境中连接： ```systemverilog trans_adapter adapter = new("adapter", this); env.refm.rx_port.connect(adapter.in_port); // 接收 etimer_transaction adapter.out_port.connect(ahb_monitor.port); // 输出 svt_ahb_transaction ``` #### 方法 3：检查 UVM 端口继承关系 - 确认 `uvm_analysis_imp_rxport` 是否继承自 `uvm_port_base`（通常不直接继承）。 - 若需通用端口接口，改用 `uvm_analysis_port` 或 `uvm_tlm_analysis_fifo` 作为中间层。 --- ### **关键注意事项** 1. **类型一致性** UVM 严格要求端口连接双方： - 相同的端口类型（e.g., `uvm_analysis_port` 只能连 `uvm_analysis_imp`） - 相同的事务类型参数[^1][^2]。 2. **作用域限定** 使用 `etimer_env_pkg::` 和 `svt_ahb_uvm_pkg::` 显式声明类型，避免命名空间冲突。 3. **调试建议** ```systemverilog $display("Actual Type: %s", this.req.get_type_name()); $display("Formal Type: %s", formal_port.get_type_name()); ``` 输出实际与形式类型名，验证类型匹配性。 --- ### **预防措施** - **编码规范**：在 UVM 环境中统一事务对象和端口类型。 - **编译选项**：启用额外类型检查（如 `-sv` 和 `-uvm` 严格模式）。 - **版本兼容**：确保 `svt_ahb_uvm_pkg` 与 UVM 库版本兼容。 通过统一事务类型或添加适配层，可解决此类复杂类型不匹配问题[^1][^2]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值