极客工场

Appearance

共 2,235 字预计阅读约 7 分钟

Verilator WAITCONST 常量等待：常真无意义与常假死等的修复 ​

更新时间：2026-10-31。FAQ 速查页，属于 EDA 报错排查系列。Verilator WAITCONST 常量等待 指向 wait 后面的条件已经是常量，进程无法靠这个表达式等待真实状态变化。它与时序控制是否启用有关，也与验证进程的同步意图有关；声明生命周期类问题可对照 Verilator IMPLICITSTATIC 静态声明。

首屏答案：wait (1'b1) 的条件永远成立，只会立即继续，不构成任何同步；wait (1'b0) 永远不满足，当前进程会停在这里。需要等待握手时，把常量换成会变化的 valid、ready、done 等有效条件；不需要同步时，直接删掉常真等待。不要只关闭 WAITCONST，更不能把常假当成可用的延时语句。

本文要回答的问题 ​

  • WAITCONST 定位的是 wait 语句还是整个进程？
  • 常真等待为什么无意义，常假等待又为什么会死等？
  • 为什么 Verilator 5.020 实测只给常真版本报警？
  • 怎样改为事件或有效条件，并用同一命令复跑？

处理这类告警要同时看「工具报没报」和「语义对不对」。下面的四层漏斗把两者分开：先定位常量，再判断进程原本要不要同步，最后才改条件并复验。

WAITCONST 处理：常量条件必须回到同步意图

第三层不是机械地给所有 wait 换一个信号。若这里本来就该顺序执行，常真等待应删除；若这里确实要跨进程协调，才引入真实条件。第四层也不能替代第二层，因为实测中的常假版本没有告警，却照样不会让后续语句执行。

一、Verilator WAITCONST 常量等待的报错现场 ​

最小复现把两种情况拆开，避免第一条告警中断后掩盖第二条命令的结果。常真文件只有下面这个进程：

systemverilog
module waitconst_bad;
  initial begin
    wait (1'b1);
    $display("constant true resumed");
  end
endmodule

常假文件结构相同，只把条件换成 1'b0。wait 属于时序控制，所以本次 lint 命令显式带 --timing，并用 -Wall 保持完整告警检查：

bash
verilator --lint-only --timing -Wall waitconst_bad.sv
verilator --lint-only --timing -Wall waitconst_false.sv

下面是三个文件依次检查的结果，包含两个常量版本和后面的修复版本：

WAITCONST 常真告警、常假静默与修复复跑

告警箭头落在 1'b1 上，而不是 $display 上，说明问题就是这个条件不具备等待价值。-Wall 下该告警使常真版本退出码变为 1。紧随其后的常假版本退出码却是 0，且没有 WAITCONST；这不是常假写法安全，而是这次工具检查没有覆盖到它的语义风险。修复版最后以 0 退出，脚本给出 PASS。

二、常真与常假为什么都不该留 ​

wait (expression) 是电平敏感等待：表达式当前为真就立即继续，否则挂起进程，等表达式因变量变化而重新求值。常量没有「因变量变化」这一步，所以两种极值都失去同步能力。

写法当前进程行为实际风险合适处理
wait (1'b1)不等待，直接执行后续语句给读者造成已有同步的错觉无需同步就删除；需要则换真实条件
wait (1'b0)永远停在当前语句后续动作不可达，验证流程可能 incomplete找出本应等待的事件或完成条件
wait (valid)valid 为 0 时挂起，为 1 时继续条件 already 为真时不会额外等一拍用于等待有效电平，并确认由谁驱动

常真不等于「等一个时间单位」。它既不会让仿真时间前进，也不会主动让出一次确定的时钟边沿；需要延时或时钟同步，应使用明确的 #delay 或 @(posedge clk)。常假也不能当作「永久关闭进程」的推荐写法，它会把本意藏在一条看似等待的语句里。

还要区分「永久阻塞」和「整个仿真一定永不结束」。若其他进程也结束且没有未来事件，模拟器可能直接结束；但只要讨论这个进程本身，wait (1'b0) 后面的语句就不会执行。因此不能凭仿真最终退出，反推这条等待曾经满足。

三、修复为会变化的有效条件 ​

本例的意图是消费者等待生产者先后给出开始、完成状态。修复版用 start 和 done 替代常量，生产者负责改变它们：

systemverilog
module waitconst_fixed;
  bit start;
  bit done;

  initial begin
    #1 start = 1'b1;
    #1 done = 1'b1;
  end

  initial begin
    wait (start);
    $display("start event observed");
    wait (done);
    $display("done event observed");
  end
endmodule

这里 bit 的初值为 0，第二个进程能否继续取决于第一个进程的赋值。wait (start) 若在进入时已经看到 1，会立即通过；若仍为 0，则等它变成 1。这与常量版本的根本差别是条件拥有可观察的状态变化。--lint-only 只验证静态检查，不执行这两条显示语句，所以本文结论仅限告警消失与语法、时序控制检查通过。

exp-log
$ verilator --lint-only --timing -Wall waitconst_false.sv
constant_false_exit_code: 0
$ verilator --lint-only --timing -Wall waitconst_fixed.sv
fixed_exit_code: 0
PASS: constant true warns; constant false is silent; event conditions are clean

摘录同时保留了常假和修复版的零退出码。两者数值相同，含义却不同：前者是静默通过但仍死等，后者是条件已改为真实信号且静态检查干净。复跑时应连同源码语义一起评审，不能只收集退出码。

四、评审与预防清单 ​

实际评审还要区分「条件有效」与「事务完成」。wait (valid) 只说明有效电平已经出现；如果数据只能在时钟边沿采样，进程仍需在合适的 @(posedge clk) 上读取，并检查 ready 等握手信号。把常量换成一个永不悬置的信号名只是第一步，生产者、消费者和采样时刻必须构成完整协议。

常量条件也不一定总以醒目的 0、1 出现。固定参数参与的条件、被错误写死的比较表达式，都可能让等待失去变化来源。代码评审时应追问「谁会改变这个条件、最晚何时改变、复位时是什么值」，并给验证进程设置可诊断的超时；超时信息应带上正在等待的信号名，而不是只报告仿真停滞。

  • 搜索测试平台中的 wait (0)、wait (1) 及其位宽写法，确认它们不是遗留的临时桩代码。
  • 需要等电平用 wait (valid)；需要等边沿用 @(posedge valid)。后者可能错过已经发生的边沿，二者不可随意互换。
  • 等待跨进程条件时，确认另一端确实会驱动它，并考虑复位期间条件是否可能一直保持不成立。
  • 不用 /* verilator lint_off WAITCONST */ 消音。隐藏告警不会给常量增加状态变化，也不会让常假等待恢复可达。
  • 修复后用相同的 --timing -Wall 参数复跑；常假这类静默情况还要补进程完成检查或超时保护。

实验环境 ​

  • 机器/系统：macOS 主机运行 Docker，容器为 Ubuntu 24.04.5 LTS。
  • 工具版本：Verilator 5.020 2024-01-01 rev (Debian 5.020-1)，镜像 geek-eda:0.2。
  • 日期：2026-10-31。
  • 完整命令：docker run --rm -v "$PWD:/work" -w /work geek-eda:0.2 bash run.sh；脚本分别执行 verilator --lint-only --timing -Wall waitconst_bad.sv、waitconst_false.sv 与 waitconst_fixed.sv，记录三次退出码并核对 WAITCONST 数量。

代码获取 ​

常真版、常假版、修复版、复跑脚本与使用说明位于公开仓 https://github.com/derekzhuo/geek-doc.cn/tree/main/experiments/ts-verilator-warn-waitconst。进入该目录后运行 bash run.sh，可看到常真版本报 WAITCONST、常假版本静默通过，以及事件条件版本的零退出码和最终 PASS。

这一篇在知识体系里的位置 ​

本篇处理的是 SystemVerilog 进程同步中的常量条件。缺少驱动会看 Verilator UNDRIVEN 排查，例程变量生命周期问题看 Verilator IMPLICITSTATIC 静态声明。几类问题共同提醒读者：lint 通过只是静态检查结论，仍要确认信号驱动、等待可达性和进程语义。

总结 ​

Verilator WAITCONST 常量等待 的核心是 wait 条件没有变化来源。常真会立即通过，并未建立同步；常假会永久阻塞当前进程，即使 Verilator 5.020 实测未报警也不能保留。需要同步时改为真实有效条件，不需要时删除常真等待。本次容器实测中，常真版退出码为 1，常假版为 0 但语义仍死等，改用 start、done 后同一 --timing -Wall 检查退出码为 0 并输出 PASS。