四个宏，四种态度
在 UVM 验证环境中，我们几乎每天都要用到报告宏：uvm_info、uvm_warning、uvm_error、uvm_fatal。它们是我们观察平台运行状态、报告异常、终止仿真的主要手段。uvm_info被用得最多，因为它是打印调试信息的主要工具；但另外三个宏同样重要，它们代表了不同严重级别的问题处理方式。然而，很多人并不清楚何时该用哪个宏，甚至滥用uvm_fatal导致调试困难，或者错误地用uvm_info报告严重错误而错过问题。
重点：报告宏是验证平台的“语言”，正确使用它们，既能高效调试，又能确保错误不被遗漏；错误使用，则可能掩盖问题或制造噪音。
四个宏的定义与区别
宏的基本格式
四个宏都接受类似参数，但略有差异：
uvm_info(ID, MSG, VERBOSITY, [FNAME], [LINE])uvm_warning(ID, MSG, [FNAME], [LINE])uvm_error(ID, MSG, [FNAME], [LINE])uvm_fatal(ID, MSG, [FNAME], [LINE])
其中：
- ID：消息标识符，用于分类和过滤。建议使用有意义的字符串，如
"DRV"、"SB"、"CFG"。 - MSG：消息内容，通常使用
$sformatf格式化。 - VERBOSITY（仅
uvm_info）：冗余度级别，决定消息是否显示。 - FNAME, LINE：可选，通常由宏自动填充，也可以手动指定。
重点：uvm_info是唯一的带冗余度参数的宏，其余三个宏始终显示，不受 verbosity 阈值影响（但可能受其他过滤条件影响）。
四个宏的语义与行为
| 宏 | 严重级别 | 默认行为 |
|---|---|---|
uvm_info | UVM_INFO | 打印信息，继续仿真 |
uvm_warning | UVM_WARNING | 打印警告，继续仿真 |
uvm_error | UVM_ERROR | 打印错误，错误计数器加 1，继续仿真 |
uvm_fatal | UVM_FATAL | 打印致命错误，立即终止仿真 |
uvm_info：用于报告正常但值得注意的信息，例如“收到一笔事务”、“配置完成”等。冗余度控制显示与否。uvm_warning：用于报告潜在问题或非预期但可恢复的情况，例如“未找到接口句柄，使用默认值”、“数据延迟超时但未失败”。不终止仿真，但应在日志中关注。uvm_error：用于报告实际错误，例如“数据不匹配”、“协议违规”。每调用一次，错误计数器加 1。错误计数器累计到一定阈值（默认 0 表示不限制，但有些仿真器可配置退出阈值），最终可能导致仿真结束。uvm_fatal：用于报告致命错误，表示平台无法继续运行，例如“虚拟接口未设置”、“关键组件创建失败”。调用后立即终止仿真，不执行后续代码。
重点：uvm_fatal是“立即终止”，不会等待其他组件完成；uvm_error是“记录错误但继续”，适合在比对失败时报告，以便收集多个错误。
严重级别覆盖与行为定制
UVM 允许通过set_report_severity_override将某个严重级别提升或降低。例如，可以将UVM_WARNING提升为UVM_ERROR，让所有 warning 也计入错误计数。也可以通过set_report_severity_action修改uvm_error的行为，例如增加UVM_EXIT动作，使得第一个 error 就终止仿真。
// 将 warning 提升为 error set_report_severity_override(UVM_WARNING, UVM_ERROR); // 让 error 立即退出 set_report_severity_action(UVM_ERROR, UVM_DISPLAY | UVM_COUNT | UVM_EXIT);如何正确使用
class my_driver extends uvm_driver #(my_trx); `uvm_component_utils(my_driver) virtual task run_phase(uvm_phase phase); my_trx req; forever begin seq_item_port.get_next_item(req); `uvm_info(get_type_name(), $sformatf("Received trx: addr=%0h data=%0h", req.addr, req.data), UVM_HIGH) if (req.addr >= 'h1000_0000) begin `uvm_warning("DRV", $sformatf("Address %0h is in reserved range", req.addr)) end if (req.data == 'hDEAD_BEEF) begin `uvm_error("DRV", "Unexpected data pattern DEAD_BEEF detected") end if (!vif) begin `uvm_fatal("NOVIF", "Virtual interface is null, cannot continue") end vif.drive(req); seq_item_port.item_done(); end endtask endclass示例解析：
uvm_info使用get_type_name()作为 ID，打印接收到的 transaction，冗余度UVM_HIGH。uvm_warning用于地址超出预期范围的警告。uvm_error用于数据模式异常，但不终止仿真。uvm_fatal用于接口缺失，直接终止。
何时用哪个宏
- Scoreboard 数据不匹配：使用
uvm_error。因为一次不匹配不代表整个测试失败，可能还有更多错误需要报告，连续报告有助于定位问题。 - 平台配置错误（如 virtual interface 未设置、寄存器模型获取失败、override 无效）：使用
uvm_fatal。这些是致命问题，继续运行只会产生无意义的结果或崩溃。 - 调试信息（如 driver 收到事务、状态机跳转、配置成功）：使用
uvm_info，并设置合适的冗余度。 - 非致命异常（如响应超时但重试成功、非法但可忽略的输入）：使用
uvm_warning。
重点：严重级别要匹配问题的实际影响。滥用uvm_fatal会让你在调试时无法收集完整信息；滥用uvm_info则会淹没真正的错误。
报告宏使用中的常见错误
uvm_fatal滥用导致调试困难
有些人一遇到问题就使用uvm_fatal，结果仿真立即停止，无法看到后续更多的错误或状态，增加了调试难度。除非环境无法继续运行，否则优先使用uvm_error，并在测试结束后统一分析。uvm_error计数没看
仿真结束时，UVM 会报告错误总数。但很多工程师不检查最终的错误计数，导致有 error 但测试仍标记为通过。必须在回归脚本中检查错误计数，或设置错误阈值退出。ID 拼写错或不一致
如果 ID 拼写错误，消息过滤和统计会失效。例如，你想屏蔽某个 ID 的消息，但 ID 写错，屏蔽无效。使用宏定义或枚举来管理 ID，或至少保持 ID 简短、一致。verbosity参数位置错uvm_info的第三个参数是 verbosity，如果忘记或位置错误（例如把消息放在第三个参数），会导致消息不显示或行为异常。始终检查宏的参数顺序：ID, MSG, VERBOSITY。大量
uvm_info拖慢仿真
在高速事务处理中，如果每条事务都打印uvm_info，即使冗余度阈值较高，宏的字符串格式化也会消耗时间。在性能敏感路径中，尽量使用低冗余度或条件编译，避免不必要的消息构造。
经验总结：报告有节制，info 必带 ID，error 必带上下文
报告宏使用原则：
uvm_info必带有意义的 ID，例如模块名_组件名，方便按 ID 过滤。uvm_error必须包含足够的上下文，例如期望值、实际值、地址、事务 ID，否则难以定位。- 报告要有节制：不要打印冗余的 info，也不要忽略 warning。在关键路径上使用
UVM_HIGH或UVM_DEBUG，常规运行使用UVM_LOW或UVM_MEDIUM。 - 测试结束时，检查错误计数，并在脚本中强制失败。
- 在环境初始化阶段，统一配置严重级别和动作，例如将 warning 提升为 error，让 error 计数达到一定数量后退出。
记住：报告宏是你的“眼睛”和“嘴巴”。正确使用它们，你才能看清平台运行状态，及时发现问题。掌握这四个宏，你的验证平台将更加健壮和可调试。
