uvm_callback机制学习总结
在初学uvm和看很多VIP的源码时，总是谈callback色变，一直觉着这是个高级特性，不好理解，但随着项目中对callback的使用越来越多，callback机制的面纱逐步落下，也渐渐体会到了这种机制的妙用，因此有必要在这里总结一下。
什么是callback机制？
callback（回调）机制并非uvm独有，它是一种设计模式，核心思想是在特定的操作或任务之前或之后插入回调函数。Callback早期使用于C语言。
“Callback” 这个英文单词本身，直接借用了传统电信领域的“电话回呼（Call back）”业务。
- 传统场景： 你打电话给客服咨询一个复杂问题，客服查资料需要半小时。你不可能拿着听筒傻等半小时（这叫阻塞/同步）。于是你告诉客服：“你先查，查到了打我这个电话（留下一串号码，即注册回调）。” 客服查完后拨通你的电话（触发回调）。
- 计算机科学家发现，这种非阻塞的、事件驱动的通信方式，与软件设计中传递函数地址的行为完美契合，因而正式将其命名为 Callback。
而在硬件验证领域，随着芯片集成度暴增，验证语言需要更高的抽象。原本在软件领域用来解耦的 Callback 机制，被高级验证语言（如 Vera、Specman e，以及后来的 SystemVerilog/UVM）吸收，演变成了验证环境中不可或缺的错误注入（Error Injection）和动态行为定制的标准工具。
systemverilog或者uvm中 callback机制到底实现了什么功能？
在 SystemVerilog 和 UVM 中，Callback（回调）机制的核心本质是“在不修改原有组件源码的前提下，动态向其内部注入或串改行为”。
它不仅是一个编程技巧，更是解决“通用验证组件（如 VIP）的固化”与“具体测试用例（Testcase）的千变万化”之间矛盾的终极武器。
callback既保证了验证平台的通用性，也实现了验证平台的扩展性，
具体来说，它在验证中主要实现了以下四大核心功能：
1. 动态错误注入（Error Injection）—— 最核心的应用
在验证芯片时，我们不仅要测试它在正常协议下的表现，更要测试它遇到异常、协议违规、丢包时能否正确恢复（鲁棒性测试）。
- 痛点： 你的 AXI Driver 是从 Synopsys 买来的 VIP，或者是组里前辈写好的通用标准组件，源码是加密的或者不允许你直接修改。你无法进到 Driver 源码里去改 WVALID 的拉高时机。
- Callback 的解法： Driver 内部通常在发送数据前留有 Callback 钩子（Hook）。你可以通过 Callback 注入一段代码：“如果当前是第 100 个包，强行将它的 CRC 校验位翻转” 或者 “随机延迟 3 个周期再拉高有效信号”。
2. 彻底的解耦与组件重用（Reusability）
Callback 实现了真正的开闭原则（Open-Closed Principle）：对扩展开放，对修改关闭。
- 没有 Callback 时： 如果项目 A 的环境和项目 B 的环境只有 5% 的行为差异（比如项目 B 的数据包需要多加一个自定义的 Header），你可能不得不把项目 A 的 Monitor 复制一份改名为 monitor_project_b。这导致代码冗余，后续维护灾难。
- 有了 Callback 时： Monitor 保持纯净和通用。项目 B 只需要写一个 Callback 类（里面包含添加 Header 的逻辑），在 Test 层挂载到通用的 Monitor 上即可。同一个 Monitor 组件可以在多个项目中无缝复用。
3. 动态的测试行为定制（Runtime Flexibility）
UVM 的 Factory 机制（工厂模式）也可以用来替换组件（Override），但 Factory 是静态且粗暴的替换——你必须在 build_phase 开始前就决定好用组件 B 替换组件 A，并且是一整块组件的替换。
而 Callback 实现了运行时的动态控制（Runtime Control）：
- 按需开关： 你可以在 run_phase 运行到一半时（比如仿真到了 100us 之后），动态地把某个 Callback 挂载（Append）上去开始注入错误，等测试完了，再动态地把它卸载（Delete）掉。
- 多重叠加： 你可以对同一个 Driver 挂载多个不同的 Callback。比如 Callback A 负责“统计发送总数”，Callback B 负责“随机延迟”。它们会像流水线一样串联执行（Callback Queue），而 Factory 替换是无法叠加的。
4. 事务级（Transaction-level）的监控与数据拦截
除了修改行为，Callback 还可以单纯用来做“旁路监听”。
例如，在不改动 Scoreboard（记分板）或 Monitor 内部连线（TLM Port）的情况下，你想单独拉出一个分支来把所有的 Transaction 记录到本地的文本文件中，或者同步给一个外部的 C++ 参考模型（Reference Model）。你完全可以通过在 Monitor 的 write 或 sample 位置注册一个 Callback 来实现这种数据的“拦截与旁路输出”。（在AXI总线项目中，就通过callback，来实现对trans生命状态的监控）
Q&A：callback为什么又叫钩子函数？
“钩子函数（Hook Function）” 其实是 Callback（回调函数）在特定应用场景下的一个形象化称呼。在技术本质上，它们俩是一回事：都是一段先定义、后执行的代码地址。但之所以被称为“钩子”，是因为它在工程上提供了一种极具画面感的隐喻。
想象一条工厂的自动化流水线（代表程序的主循环或核心骨干流程）。物品在传送带上依次前进，这个流程是固定的、封装好的，你无法轻易暂停或拆卸它。
但是，工程师在传送带的某些特定位置（比如“质检点”、“包装点”）预留了几个物理挂钩（Hooks）。
当你（开发者）有特殊需求时（比如：当苹果走过来时，给它贴个标签），你就写好一段“贴标签”的代码，然后挂到这个特定的钩子上。
当流水线运行到这个位置时，系统发现钩子上有东西，就会停下来把你的代码执行完（给苹果贴标），然后再继续往前走。
因为它的作用就像是在一条原本连续的执行流中，硬生生“钩出”一个时间节点来执行你的自定义代码，所以被称为“钩子”。
纯systemverilog验证环境中是如何实现callback的？
在不使用UVM的情况下，SystemVerilog原生支持通过抽象类（virtual class）和继承来实现回调机制。以下是具体方法：
核心原理
在SystemVerilog中，回调机制基于面向对象的多态性（polymorphism）实现：
- 定义一个虚方法（virtual method）的基类作为回调接口
- 用户派生子类并重载（override）这些虚方法
- 组件在适当位置调用这些虚方法
具体实现方式
1. 使用抽象类定义回调接口
// 定义回调基类（抽象接口） virtual class Driver_cbs; // 虚方法，默认空实现 virtual task pre_send(Driver drv); // 默认不做任何事 endtask virtual task post_send(Driver drv); // 默认不做任何事 endtask endclass : Driver_cbs2. 在驱动类中集成回调
class Driver; // 回调队列（存储多个回调对象） Driver_cbs cbs[$]; task send(); // 发送前执行所有回调 foreach (cbs[i]) begin cbs[i].pre_send(this); end // 实际的驱动逻辑 // ... // 发送后执行所有回调 foreach (cbs[i]) begin cbs[i].post_send(this); end endtask : send // 注册回调对象 function void add_callback(Driver_cbs cb); cbs.push_back(cb); endfunction : add_callback endclass : Driver3. 使用者扩展回调类
// 扩展回调类，实现具体行为 class Driver_cbs_drop extends Driver_cbs; virtual task pre_send(Driver drv); // 自定义行为：随机丢弃某些数据包 bit drop; std::randomize(drop) with {drop dist {1:=1, 0:=9};}; if (drop) begin drv.drop_packet = 1; $display("Callback: Dropping packet"); end endtask : pre_send endclass : Driver_cbs_drop // 另一个扩展：插入错误数据 class Driver_cbs_error extends Driver_cbs; virtual task post_send(Driver drv); // 在发送后修改数据模拟错误 $display("Callback: Injecting error"); endtask : post_send endclass : Driver_cbs_error4. 在测试中注册并使用
class Test; Driver drv; Driver_cbs_drop drop_cb; Driver_cbs_error error_cb; function new(); drv = new(); drop_cb = new(); error_cb = new(); // 注册回调 drv.add_callback(drop_cb); // 添加丢弃回调 drv.add_callback(error_cb); // 添加错误注入回调 endfunction task run(); repeat(100) begin drv.send(); // 发送时自动调用已注册的回调 end endtask : run endclass : Test总结
在不使用UVM的情况下，SystemVerilog通过以下方式实现回调：
1. 划（定义规范）
使用 virtual class 划分好统一的接口规范，声明好各种虚方法（如 pre_send、post_send）。这个基类不实现具体逻辑，只负责给底层组件定义可以引用的句柄类型。
2. 留（预留钩子）
在底层通用组件（如 driver）内部：
- 声明一个基类类型的队列（my_driver_callback cbs[$]）。
- 在核心业务流的特定时机，通过遍历队列（foreach）来调用这些虚方法。
- 提供一个注册函数（register_cb）作为外部代码注入的通道。
3. 改（编写逻辑）
在不触动底层组件源码的前提下，编写一个具体的派生类继承自该基类。在子类中重写（override）虚方法，将你真正想要的定制逻辑（如错误注入、Debug 打印）写在里面。
4. 挂（动态绑定）
在顶层测试用例（test）中，实例化子类得到真正的对象，然后调用底层组件的注册函数，把子类对象挂载（塞进）到底层组件的基类队列中。
UVM验证环境中是如何实现callback的？ ⭐⭐⭐
在 UVM（Universal Verification Methodology）中，Callback 机制的底层逻辑与前面讲的纯 SystemVerilog（多态+队列）是一样的，但 UVM 对其进行了高度的工程化封装。
UVM 提供了一套标准的基类、宏和全局管理器（uvm_callbacks 居中调度），使得不需要自己去写队列和 foreach 遍历，并且支持通过字符串在全局动态管理 Callback。
UVM验证环境中实现callback机制遵循开发者和使用者两个角色分工的流程。
核心组件
UVM callback机制涉及以下几个关键类和宏：
- uvm_callback：用户自定义回调类的基类
- uvm_callbacks #(T,CB)：用于管理回调注册、删除和迭代的类
- uvm_register_cb宏：注册回调基类与组件的关联
- uvm_do_callbacks宏：在组件特定位置调用回调方法
开发者需要做的（组件开发者）
1. 定义回调基类
从uvm_callback派生，声明虚方法作为回调接口。
注意，这里定义的是回调基类，这个是用来写在固化的验证环境中的，所有的回调基类都必须从uvm_callback类扩展。
回调基类中必须定义一些虚方法，virtual function或者virtual task。一般来说，这些虚方法是空的，具体实现由使用者对该回调基类进行继承，并重写这些虚方法。
// 文件: dadd_driver.sv typedef class dadd_driver; class driver_callback extends uvm_callback; `uvm_object_utils(driver_callback) function new(string name = "driver_callback"); super.new("name"); endfunction : new // 定义虚方法（回调接口），默认空实现 virtual task pre_send(dadd_driver drv); endtask : pre_send endclass : driver_callback2. 在组件中注册回调类型
使用uvm_register_cb宏将回调类与组件类关联。
`uvm_register_cb(T, CB) 这个宏应该在 预留了 Callback 接口的组件（Component）类的类定义内部、类名声明之后、任何成员方法之外 调用。通常，最标准、最常见的位置是紧跟在组件的 `uvm_component_utils(T) 宏的下一行。
class dadd_driver extends uvm_driver; `uvm_component_utils(dadd_driver) // 注册回调类型：将driver_callback与dadd_driver关联 `uvm_register_cb(dadd_driver, driver_callback) function new(string name, uvm_component parent); super.new(name, parent); endfunction : new // ... endclass : dadd_driver3. 在适当位置嵌入回调调用点
使用uvm_do_callbacks宏在组件的关键位置调用回调方法。
task dadd_driver :: main_phase(uvm_phase phase); @(posedge vif.clk); forever begin seq_item_port.get_next_item(req); // 在发送前调用回调 `uvm_do_callbacks(dadd_driver, driver_callback, pre_send(this)) if(req.data_en) begin vif.mcb.dadd_in_en <= req.data_en; vif.mcb.dadd_in <= req.data; vif.mcb.dadd_in_addr <= req.addr; end else begin vif.mcb.dadd_in_en <= 0; vif.mcb.dadd_in <= 0; vif.mcb.dadd_in_addr <= 0; end @(posedge vif.clk); vif.mcb.dadd_in_en <= 0; vif.mcb.dadd_in <= 0; vif.mcb.dadd_in_addr <= 0; seq_item_port.item_done(); end endtask: main_phase使用者需要做的（验证工程师）
1. 扩展回调基类，重载回调方法
从开发者定义的回调基类派生新类，重载需要的虚方法。
class dadd_driver_callback extends driver_callback; `uvm_object_utils(dadd_driver_callback) function new(string name = "dadd_driver_callback"); super.new("name"); endfunction : new // 重载回调方法 virtual task pre_send(dadd_driver drv); int val; std::randomize(val) with { val inside {[0:9]};}; if(val < 3) begin drv.req.data = 32'h5a5a; // 修改数据包内容 end endtask : pre_send endclass : dadd_driver_callback2. 将回调实例添加到目标组件
使用uvm_callbacks #(T,CB)::add()函数注册回调实例。
class dadd_callback_test extends uvm_test; `uvm_component_utils(dadd_callback_test) dadd_environment env; dadd_driver_callback drv_cb; function void build_phase(uvm_phase phase); super.build_phase(phase); env = dadd_environment :: type_id :: create("env", this); endfunction : build_phase function void connect_phase(uvm_phase phase); drv_cb = dadd_driver_callback :: type_id :: create("drv_cb"); // 将回调实例添加到env.iagt.drv组件 uvm_callbacks #(dadd_driver, dadd_driver_callback) :: add(env.iagt.drv, drv_cb); // 显示已注册的回调信息（可选） uvm_callbacks #(dadd_driver, dadd_driver_callback) :: display(); endfunction : connect_phase endclass : dadd_callback_test回调执行流程
当组件运行到嵌入uvm_do_callbacks的位置时，执行流程如下：
- 组件调用uvm_do_callbacks宏
- UVM遍历与该组件实例关联的所有已注册回调对象
- 按注册顺序执行每个回调对象的指定方法（如pre_send）
- 继续执行组件原有的代码
附录A：uvm中用户直接接触的与callback相关的类和宏的解析
仔细看uvm_callback.svh这个文件，会发现这个文件定义了不止uvm_callback这一个类。而是定义了8个类。
- uvm_typeid_base
- uvm_typeid
- uvm_callbacks_base
- uvm_typed_callbacks
- uvm_callbacks （通过宏调用该类的静态方法）
- uvm_derived_callbacks
- uvm_callback_iter
- uvm_callback （回调基类从此类扩展）
而macros/uvm_callback_defines.svh文件中，定义了非常多的宏，用来封装上述class中方法的调用。 这两个文件是整个uvm_callback机制运转的核心。而uvm通过封装，使得用户在使用callback时，只需要和几个简单的类打交道，按照固定的流程去执行命令就可以。 而和底层核心原理实现的复杂类，uvm并没有暴露给用户，初衷也是不想让用户接触。
从上面实现uvm_callback的步骤来看，无论是开发者还是使用者，直接接触到的类，只有两个。整个 UVM 的回调机制其实就是围绕 回调对象 ( uvm_callback ) 和 回调管理器 ( uvm_callbacks#(T,CB) 及其父类) 展开的。
因此，在附录A中，将会只针对用户接触的相关类和宏定义进行拆解。而附录B中，会针对其他的底层类进一步探索callback机制实现的底层原理。
用户直接接触的相关类和宏定义：
- uvm_callback：用户自定义回调类的基类
- uvm_callbacks #(T,CB)：用于管理回调注册、删除和迭代的类
- uvm_register_cb宏：注册回调基类与组件的关联
- uvm_do_callbacks宏：在组件特定位置调用回调方法
uvm_callback基类
uvm_callback继承自uvm_object，本身没有什么特别之处
回调的禁用与开启（callback_mode() ）
这个函数 callback_mode 是 uvm_callback 类提供的一个开关/控制接口。它的主要作用是：动态地启用（Enable）或禁用（Disable）某个特定的 Callback 实例，或者查询它当前是否处于激活状态。它的设计理念完全模仿了 SystemVerilog 原生自带的 rand_mode() 和 constraint_mode()。
在uvm_callback中，默认是m_enabled=1，默认这个callback_mode()函数是不调用的。所以默认情况下，都是开启的。
1. 查询状态（默认不传参，即 on = -1）
如果你不传任何参数调用它：cb.callback_mode();
- 行为：代码会走到第 1392 行的 else 分支，打印出当前的使能状态。
- 返回值：返回该 Callback 实例更新前/当前的开关状态（m_enabled 的值，1 代表启用，0 代表禁用）。
2. 关闭这个 Callback（传入 on = 0）
- 调用方式：cb.callback_mode(0);
- 行为：代码第 1397 行判断成立，将内部的控制变量 m_enabled 设为 0。
- 效果：这个特定的 Callback 实例被“静音”了。此后，即便组件中触发了 `uvm_do_callbacks，这个实例里的回调方法也不会被执行。
3. 开启这个 Callback（传入 on = 1）
- 调用方式：cb.callback_mode(1);
- 行为：代码第 1401 行判断成立，将 m_enabled 设为 1。
- 效果：重新激活这个 Callback 实例，使其恢复正常工作。
实际应用场景（为什么需要它？）
在复杂的验证环境中，这个函数非常有用，尤其是做动态测试（Dynamic Testing）或阶段性错误注入时。
场景：定向错误注入控制
假设你写了一个 error_cb 实例用于给总线注入“随机单bit错”。你想让这个错误注入只在特定的仿真阶段发生，而不是贯穿全过程：
1. 仿真开始（Reset & 配置阶段）：你不希望有错误干扰初始化。
my_error_cb.callback_mode(0); // 暂时关闭它2. 仿真中途（正常业务流量阶段）：开始测试 DUT 的纠错能力。
#100us; my_error_cb.callback_mode(1); // 动态开启，开始注入错误3. 仿真尾声（Drain Phase / 扫尾阶段）：需要清空 DUT 内部的数据，不希望再有新错误进去。
#500us; my_error_cb.callback_mode(0); // 再次关闭Q&A：这个callback_mode函数，如果传入0，m_enbalbed=0，但是在这个赋值之前，已经先执行了callback_mode = m_enabled，此时m_enalbed还是1啊
假设当前 Callback 是开启的（m_enabled = 1），你调用了 cb.callback_mode(0)：
- 第 1396 行：callback_mode = m_enabled;
- 此时 m_enabled 确实是 1。所以函数的预备返回值被设置成了 1。
- 第 1398 行：m_enabled = 0;
- 这时候，内部的 m_enabled 正式被改写成了 0（关闭成功）。
- 第 1405 行：endfunction
- 函数执行完毕，吐出刚才存好的返回值 1。
这种设计是为了实现一个经典的功能：返回对象的“历史状态”（Previous State）。
当你想把开关关掉（传入 0）时，UVM 不仅帮你关掉了，还顺便通过返回值告诉你：“在你关掉我之前，我原来是开着的（返回 1）”。
这种“返回旧值”的设计，在写测试平台时可以非常优雅地做状态恢复。
比如你想临时关闭一下这个 Callback，执行完某段代码后，再恢复它原本的状态（因为你不知道它原本是开着的还是关着的）：
bit bit_old_status; // 1. 关闭 Callback 的同时，记录它原本的状态 bit_old_status = cb.callback_mode(0); // 2. 执行一些不希望被 Callback 干扰的代码 ... // 3. 事情办完了，原样恢复它 cb.callback_mode(bit_old_status);状态指示函数is_enabled()
这个函数，是一个状态指示函数，用来查看某个callback类，是否开启了callback模式。
Q&A：回调基类定义的虚方法中，必须是空的吗？
不必须。 它可以是完全空的，也可以包含默认的、通用的业务逻辑，甚至可以做成一个纯虚方法（Pure Virtual Method）强制子类必须重写。
具体怎么写，完全取决于你希望这个“默认行为”是什么。在实际项目开发中，虚方法的实现通常有以下三种策略：
1. 空实现（最常见）
如果你希望在默认情况下，组件（如 Driver）不需要任何额外的动作，只有在特定测试用例需要时才注入行为，那就写成空的。
2. 带默认业务逻辑的实现（进阶玩法）
如果你希望这个基类自带一些通用的公共功能（比如打日志、计数、基本的合法性检查），你完全可以把这些通用代码写在基类的虚方法里。
3. 纯虚方法实现（强制约束）
如果你作为平台架构师，写了一个专门用于“外部打印数据”的 Callback 基类，你希望逼着后续写 Testcase 的新人必须自己去实现具体的打印格式，不实现就让它编译报错。这时候可以使用 pure virtual：
`uvm_register_cb宏
`uvm_register_cb宏，本质是调用了 uvm_callbacks 类中的静态函数 m_register_pair()
该宏调用时，需要传入两个参数，分别是两个类的类名（注意不是句柄名）
1. 第一个参数 T（Target Component）
- 代表什么：目标组件（Component）的类名。
- 作用：指定这个 Callback 机制要绑定到哪一个具体的 UVM 组件（比如具体的 Driver、Monitor 或 Scoreboard）上。
2. 第二个参数 CB（Callback Base Class）
- 代表什么：回调基类的类名。
- 作用：指定允许贴到上述组件 T 上的 Callback 类型。这个类本身必须是继承自 uvm_callback 的。
- 注意回调基类，必须继承自uvm_callback，可以是uvm_callback的子类，也可以是孙子类，只要是从uvm_callback类继承的就行
当你调用 `uvm_register_cb(my_driver, my_driver_callback) 时，这个宏会利用参数在组件类内部静态地做两件事：
- 生成一个唯一的静态变量：变量名叫 m_register_cb_my_driver_callback。由于是静态的（static），它会在仿真最开始的编译/阐述阶段自动初始化。
- 在全局登记这对“CP”：通过调用 uvm_callbacks#(my_driver, my_driver_callback)::m_register_pair("my_driver", "my_driver_callback")，正式在 UVM 底层数据库中把这两个类注册为合法的配对关系。
具体m_register_pair的解析详见附录B
Q&A：`uvm_register_cb宏应该在哪里调用？
`uvm_register_cb(T, CB) 这个宏应该在 预留了 Callback 接口的组件（Component）类的类定义内部、类名声明之后、任何成员方法之外 调用。
通常，最标准、最常见的位置是紧跟在组件的 `uvm_component_utils(T) 宏的下一行。
⚠️ 避坑指南（常见错误）
- 错误 1：误放在 initial 块或 build_phase 内部
- 后果：编译报错。因为它是一个宏展开后包含静态声明的语句，不能放进任何 function/task 或过程块内部。
- 错误 2：误放在类定义的外面（比如 endclass 之后）
- 后果：编译报错。它必须属于组件类的成员作用域内。
- 错误 3：Test 派生类需要重复注册吗？
- 答案：不需要。如果你在 my_driver 里注册了，后续你写了一个 class extended_driver extends my_driver，子类会自动继承这个 Callback 通道，不需要（也不应该）在子类里重新调用 uvm_register_cb。
`uvm_do_callbacks宏
`uvm_do_callbacks宏的参数有三个
第一个是要调用callback函数的执行组件类的类名（不是句柄名）
第二个是实现callback函数的类的类名（不是句柄名）
第三个是要执行的callback函数的类的callback方法
对uvm_callback原理的最形象解释
UVM 的 Callback 就像是一个按“键-值”对（Key-Value）存放的储物柜。
三行关键代码 参数必须保持一致
附录B：UVM中底层callback的实现原理
uvm_callbacks#(T,CB)::m_register_pair(`"T`",`"CB`");