4. 时序检查宏：uvm_info与时间戳打印、uvm_warning/uvm_error的时序上下文、`uvm_fatal在死锁检测中的应用

各位同学，今天我们来聊聊UVM里那些跟时序检查打交道的宏。说实话，很多新手觉得这些宏不就是打印信息嘛，有啥好讲的？嗯，我当年也这么想，直到有一次在项目中，一个隐蔽的时序bug让我熬了三个通宵。从那以后，我对这些宏的看法彻底变了。

你想想看，验证环境跑起来，成千上万条信息刷刷刷地过。如果没有好的时序标记，你根本不知道哪条消息是在哪个时间点发出的。这就像看监控录像，没有时间戳，你永远找不到关键帧。

uvm_info：不只是打印，更是时间戳的艺术

uvm_info 是我们最常用的宏。但很多人只用它的基本功能：

uvm_info("MY_ID", "data is ready", UVM_LOW)

这样写，信息是打出来了，但缺少关键的时序上下文。我个人习惯，在关键节点一定要加上仿真时间：

uvm_info("MY_ID", $sformatf("time=%0t, data is ready", $time), UVM_LOW)

为什么这么做？因为 $time 返回的是当前仿真时间，单位取决于你的timescale。我曾经在调试一个AXI总线协议时，发现数据总在某个固定时间点出错。就是因为每条 uvm_info 都带了时间戳，我才能快速定位到问题窗口。

还有一个容易被忽略的点——uvm_info 的冗余度级别。很多人从头到尾都用 UVM_LOW，结果log文件大得吓人。我建议这样分层：

• UVM_LOW：只打印关键状态变化，比如事务开始/结束、错误发生
• UVM_MEDIUM：打印正常流程中的中间步骤
• UVM_HIGH：打印所有细节，包括内部变量值、临时状态

调试时设成 UVM_HIGH，回归测试时设成 UVM_LOW。这样既不会漏信息，也不会被海量log淹没。

uvm_warning / uvm_error：时序上下文才是灵魂

说完了 uvm_info，咱们来看看 uvm_warning 和 uvm_error。这两个宏的区别大家都知道——warning不终止仿真，error会。但我想强调的是：时序上下文比错误本身更重要。

举个例子，你在监测一个握手协议：

if (valid && !ready) begin
  uvm_error("HANDSHAKE", "valid asserted but ready is low")
end

这样写够吗？不够。你只告诉我有问题，但没告诉我这个问题发生在哪个时钟周期、前后状态是什么。我建议这样：

if (valid && !ready) begin
  uvm_error("HANDSHAKE", $sformatf(
    "time=%0t, cycle=%0d, valid=%b, ready=%b, prev_valid=%b, prev_ready=%b",
    $time, cycle_cnt, valid, ready, prev_valid, prev_ready
  ))
end

你看，多了时间、周期号、前后状态。拿到这个error，你基本不用再看波形就能猜到问题在哪。

说到 uvm_warning，我个人的用法是：warning 用来标记那些“可能有问题，但我不确定”的情况。比如：

• 时序裕量接近边界值
• 某个信号在非预期时间翻转
• 配置参数超出推荐范围

这些warning不会让仿真停，但会提醒你：嘿，这里有点不对劲，回头检查一下。

`uvm_fatal：死锁检测的终极武器

最后聊聊 uvm_fatal。这个宏一调用，仿真立刻终止。听起来很暴力，但用好了，它是死锁检测的利器。

什么是死锁？说白了就是两个或多个模块互相等待，谁都不往前走。比如：

• driver等sequence发item，sequence等driver回response
• monitor等valid信号，DUT等monitor采样完成
• scoreboard等两个通道的数据都到齐，但其中一个通道永远不来

这些死锁在仿真里表现为什么？——仿真时间不动了，或者一直在某个循环里打转。如果没有 uvm_fatal，你可能要等很久才发现仿真卡住了。

我的做法是：在关键等待点加超时检测。比如：

fork
  begin
    // 正常等待
    @(posedge vif.ready);
    uvm_info("TIMEOUT", "ready received", UVM_MEDIUM)
  end
  begin
    // 超时检测
    #1000;
    `uvm_fatal("TIMEOUT", $sformatf(
      "Deadlock detected! Waiting for ready at time=%0t", $time
    ))
  end
join_any
disable fork;

这段代码的意思是：等ready信号，但最多等1000个时间单位。超时了，就报fatal并终止仿真。这样，死锁一发生，你立刻就知道，而不是等仿真跑完才发现log里全是重复信息。

我记得有一次，一个同事在调试一个复杂的DMA控制器。仿真跑了两个小时，结果发现log里最后几万行全是同一个warning。原来是一个握手信号永远没拉高，导致整个环境死锁了。如果他在那个握手点加了 uvm_fatal 超时检测，两分钟就能发现问题，而不是等两个小时。

嗯，这里要注意：uvm_fatal 不要滥用。只在那些“如果这里卡住，整个环境就废了”的关键路径上加。否则，一些临时性的延迟也会触发fatal，反而干扰调试。

小结一下

这三个宏，各有各的用处：

说白了，这些宏就是你的“眼睛”。没有它们，你根本看不到仿真环境里发生了什么。但光有眼睛还不够，你得让它们“看”到正确的东西——也就是带上时序上下文。

最后送大家一句话：好的log，是调试成功的一半。花点心思在信息打印上，后面调试能省十倍的时间。