问题现象
在 UART 验证环境中，奇偶校验位（parity）通常不会被定义为 transaction 数据结构的字段，而是在 driver 的 send_to_dut 任务中根据待发送的 data 数组实时计算得出，例如采用偶校验时直接执行 parity = ^(data)，随后将该值赋给接口信号 bus.tx_parity。这种做法的好处是贴合实际硬件行为——真实芯片的奇偶校验本就是发送端在数据发出时动态生成的。
然而，这种做法给故障注入带来了显著挑战。传统的错误注入手段主要依赖修改 transaction 对象中的某些字段，例如将数据位翻转、地址域改写或控制字篡改，然后期望这些修改通过 driver 原样传递到接口。但在上述场景中，无论测试用例如何精心构造 transaction 中的 data，driver 都会在最后一刻按既定算法重新计算 parity，并用计算结果覆盖掉任何人为预置的值。因此，即使测试者试图通过扩展现有序列来模拟“奇偶校验错误”，也会发现实际输出波形上根本看不到预期的错误，所有注错尝试均告无效，导致覆盖率目标中关于奇偶校验异常的测试点无法被有效覆盖。
根本原因分析
这一问题的根源在于验证工程师往往陷入“只关注数据对象”的思维定式，默认认为所有需要验证的故障场景都可以通过对数据包（transaction）的静态改写来完成。这种思维忽略了硬件行为的最终确定点是在时序边界——即 driver 将信号驱动到接口管脚的那个时钟周期。如果错误注入的逻辑不能触及信号赋值那一刻的实时变量，就无法模拟真实的硬件故障条件，例如寄存器位翻转、线路上偶发毛刺、外部干扰导致的逻辑值突变等。
更本质地看，transaction 代表了验证环境中的高层抽象数据，而 driver 负责将抽象数据翻译为底层时序波形。翻译过程中可能存在多种计算、编码、压缩或校验逻辑，这些中间计算结果往往不保留在原始 transaction 中。因此，为了精确注入错误，必须将注入点后移至这些实时计算结果生成之后、信号驱动之前，而不是仅仅停留在数据层。
解决方案
针对上述困境，UVM 提供的 Callback 钩子注入法 是业界标准且优雅的解决途径。具体实现分为三个步骤：
`uvm_do_callbacks(uart_driver, uart_driver_callback, modify_parity(parity, this))
该宏会自动遍历所有已注册到该 driver 实例上的回调对象，并按顺序调用其 modify_parity 方法。若没有任何回调被注册，则宏展开为空操作，对仿真性能零影响。
编写具体回调子类：在测试用例或序列中，派生一个继承自 uart_driver_callback 的类，并重写 modify_parity 任务。在任务内部，测试工程师可以自由实现各种错误注入策略，例如：
-
将 parity 翻转（parity = ~parity）；
-
固定为 0 或 1（parity = 1'b0）；
-
根据当前发包计数或随机条件决定是否注入错误；
-
依据数据内容动态计算特定错误模式。
最后，通过 uvm_callback::add() 将该回调对象注册到目标 driver 实例上，即可激活注错。
关键优势
该方案带来了多重显著收益：
-
彻底解耦：将“故障注入策略”与“硬件驱动机制”完全分离。driver 无需关心何时、如何注错，只需提供钩子点；而测试用例可以独立发展各种复杂的错误注入逻辑，双方互不干扰。
-
无损核心代码：driver 的核心协议时序代码保持纯净、稳定，无需为每一种注错场景增加分支或配置项。所有的异常行为都由回调子类承载，这极大地降低了回归测试中因误改驱动逻辑而引入新 bug 的风险。
-
高度灵活与可扩展：无论未来需要新增何种错误类型（如固定值、毛刺插入、延迟翻转等），都只需添加新的回调子类，无需修改已有代码，符合开闭原则。同时，可以在不同测试用例中注册不同的回调组合，实现错误场景的灵活装配。
-
零开销默认行为：未注册回调时，uvm_do_callbacks 宏几乎不消耗仿真资源，不会影响正常功能仿真的性能。
-
精确控制注入时机：注入发生在计算之后、驱动之前，精准模拟了硬件在最后一级输出缓冲区的瞬时故障，比修改 transaction 的方式更贴近真实物理失效机理，从而提升验证的可信度和覆盖率质量。
综上所述，利用 UVM Callback 机制对硬件实时计算值进行错误注入，是应对“非 Transaction 字段”故障测试的最佳实践。它不仅解决了当前 UART 校验位注入的痛点，更可推广至任何存在动态计算或编码转换的通信协议验证中，为复杂 SoC 验证提供了一种通用的精确注错手段。
