Verilator PROCASSWIRE：wire 被过程赋值的定位与修复

更新时间：2026-10-30。FAQ 速查页，属于 Verilator PROCASSWIRE 所在的 EDA 报错排查系列。这个诊断的核心是线网声明与过程赋值不兼容：wire 适合由 assign、模块端口等结构持续驱动，不能作为 always 或 initial 块里的赋值左值。它与驱动数量无关，即使全模块只有一处赋值也会报错。

首屏答案：若信号只是组合连接，保留 wire 并把过程块改成 assign；若确实需要过程逻辑，Verilog 改用 reg，SystemVerilog 改用 logic。修改后按原语言模式复跑，不要仅用 -Wno-PROCASSWIRE 隐藏问题。

本文要回答的问题

完整 PROCASSWIRE 报错指向声明还是赋值语句？
为什么单独一次 always @* 赋值也不能驱动 wire？
连续赋值、reg、logic 三种修复应怎样选择？
如何确认修复后 lint 真正通过，而非仅关闭诊断？

排查时先沿行号找到左值，再反查声明和全部驱动，最后依据设计意图修改。不要看到 wire 就一律换成 reg：纯连线场景这样改虽然可能通过，却偏离了最小修复原则。

这张图把「设计意图」放在改代码之前。wire 与 reg 不是可以随意互换的关键字：前者描述连接，后者描述 Verilog 过程变量；选错修复路径会把一个简单的类型问题扩散成驱动方式重构。

一、Verilator PROCASSWIRE 完整报错与最小复现

下面的一级组合模块把输入 a 经内部信号 q 接到输出 y。q 声明为 wire，却在 always @* 中被阻塞赋值，因此 lint 不需要 testbench 就能稳定复现。

verilog

module broken (
    input  wire a,
    output wire y
);
    wire q;

    always @* begin
        q = a;
    end

    assign y = q;
endmodule

运行 bash run.sh，脚本以 Verilog 2005 模式检查 broken，再分别验证三个修复版本。终端卡包含工具版本、完整诊断、每次 lint 的退出码和最终 PASS。

关键行是 %Error-PROCASSWIRE，位置 broken.v:8:9 对准过程赋值左值 q。本次 broken 退出码为 1，三个 fixed 均为 0。always 使用 @* 只解决组合敏感列表问题，并不会把 wire 自动变成可过程赋值的变量。

二、根因：wire 是线网，不是过程变量

PROCASSWIRE 可理解为 procedural assignment to wire，即「对 wire 进行过程赋值」。Verilog 的线网由外部驱动源持续决定取值；过程块则在执行到赋值语句时修改变量。两种机制不能混在同一个左值上。

声明与驱动组合	是否符合本文语言模式	适用意图
`wire q` + `assign q = a`	符合 Verilog 2005	组合连接、持续驱动
`reg q` + `always @* q = a`	符合 Verilog 2005	组合过程逻辑
`logic q` + `always_comb q = a`	符合 SystemVerilog 2017	带语言检查的组合过程逻辑
`wire q` + `always @* q = a`	不符合，触发 PROCASSWIRE	声明与赋值机制错配

reg 名称容易误导：它并不保证综合出触发器，组合 always @* 中的 reg 仍可生成组合逻辑。反过来，wire 也不等于「可综合的普通信号」，它不能承担过程存储语义。

同一规则也适用于 initial。例如测试代码写 wire reset; initial reset = 1'b0;，仍然是在过程中驱动线网；应把 reset 声明为变量，或改用合适的连续驱动结构。不能因为它只执行一次、没有时钟，就把 initial 当成例外。对于双向总线，也不能简单把所有 inout wire 换成变量：高阻态和多源连接需要按总线协议重新梳理，本文的一级单向组合模块不覆盖那种场景。

红色节点是报错入口，蓝色表示定位，橙色是两条修复路径，绿色表示复验。图中两条路径都保留单一驱动，只是让声明类型与赋值机制重新匹配；若反查时发现多个过程块同时写 q，还需另行解决多驱动问题。

三、排查清单：先收集声明和驱动，再动代码

报错只给出当前赋值位置，声明可能位于端口列表、头文件或宏展开代码中。可用下面的搜索拼出信号 q 的声明与全部驱动：

bash

rg -n '\b(wire|reg|logic)\s+q\b|\bassign\s+q\b|\bq\s*(<=|=)' .
rg -n '1364|1800|language|\.sv\b|\.v\b' Makefile '*.f'

拿到结果后逐项核对：

左值是否确为线网：包括显式 wire、默认线网端口以及 tri 等等价线网声明。
赋值属于哪种过程结构：always、always_comb、always_ff 和 initial 都要求变量左值。
是否还有第二个驱动源：修复类型不会自动解决多驱动；不要遗漏其他 assign 或过程块。
语言模式是否明确：Verilog 2005 用 reg 表达过程变量，SystemVerilog 推荐 logic，不要靠改扩展名碰运气。
原逻辑语义是否保留：组合块使用阻塞赋值；时序块继续使用非阻塞赋值，不能为消错改变时钟语义。

如果错误落在 output wire y 上，修复原则相同：连续驱动就保留线网端口；过程驱动则按语言改为 output reg y 或 output logic y。修改端口类型不会改变方向和位宽，但仍应检查上层例化是否引入额外驱动。

常见处理	为什么不充分	正确动作
只删除 `@*`	改变敏感列表，类型错配仍在	先决定保留连续驱动还是过程驱动
把所有 wire 批量替换为 reg	可能破坏端口连接和其他持续驱动	只修改报错左值，并逐处复跑
同时保留 assign 与 always	从类型错误变成潜在多驱动	一个信号只保留预期驱动源
全局关闭 PROCASSWIRE	其他工具仍可能拒绝同一代码	修复声明或赋值方式后复验

还要区分「当前文件不再报错」与「工程语义正确」。如果过程块本来包含不完整分支，改成 reg 后可能继续出现锁存器推断等诊断；那说明类型问题已解除，应继续处理新的具体问题，而不是退回 wire 或关闭全部告警。

四、三种修复与复跑结果

纯组合连接的最小修复是删掉过程块，保留 wire，改为连续赋值：

diff

-    always @* begin
-        q = a;
-    end
+    assign q = a;

若代码后续要在 case、条件分支等过程结构里计算 q，Verilog 2005 应把声明改为 reg，过程块原样保留：

verilog

reg q;
always @* begin
    q = a;
end
assign y = q;

SystemVerilog 工程可使用 logic，并用 always_comb 明确组合意图。本实验直接驱动输出，避免再保留无必要的内部信号：

systemverilog

module fixed_logic (
    input  logic a,
    output logic y
);
    always_comb begin
        y = a;
    end
endmodule

三种写法分别复跑，均没有 PROCASSWIRE 或其他告警。下面的原始摘录保留了命令对应的退出码与脚本核对结果：

exp-log

=== fixed-assign ===
$ verilator --lint-only -Wall --language 1364-2005 fixed_assign.v
fixed-assign exit=0

=== fixed-reg ===
$ verilator --lint-only -Wall --language 1364-2005 fixed_reg.v
fixed-reg exit=0

=== fixed-logic ===
$ verilator --lint-only -Wall --language 1800-2017 fixed_logic.sv
fixed-logic exit=0

PASS: PROCASSWIRE reproduced; all three fixes exited 0

完整 broken 诊断原文为 %Error-PROCASSWIRE: broken.v:8:9: Procedural assignment to wire, perhaps intended var (IEEE 1800-2017 6.5): 'q'。其中 perhaps intended var 只是修复提示，不代表所有场景都必须改变量；本例的连续赋值修复同样合法。-Wno-PROCASSWIRE 只会隐藏诊断，不会改变赋值语义，不宜作为跨工具工程的首选处理。

复跑还应保持命令中的 --lint-only -Wall 和语言选项不变，确保前后差异来自源码而非检查强度变化。实际工程若有行为仿真或等价性检查，也应在 lint 通过后继续执行；本文证明的是三个最小模块的静态检查通过，不把这一点扩大为任意设计的时序或功能等价结论。

实验环境

机器/系统：Linux 容器环境（Docker 镜像 geek-eda:0.2）
工具版本：Verilator 5.020 2024-01-01 rev (Debian 5.020-1)
日期：2026-10-30
完整命令：bash run.sh；脚本执行 verilator --lint-only -Wall --language 1364-2005 broken.v，随后以 1364-2005 检查 fixed_assign.v、fixed_reg.v，以 1800-2017 检查 fixed_logic.sv，并逐项核对预期退出码。

代码获取

最小复现、三种修复、复跑脚本与原始日志位于公开仓 https://github.com/derekzhuo/geek-doc.cn/tree/main/experiments/ts-verilator-warn-procasswire。进入目录执行 bash run.sh 或 make run，即可复现 PROCASSWIRE 并验证全部修复。

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

本篇处理声明类型与赋值方式错配。若修改后仍存在多个驱动源，应转到 Verilator PROCASSWIRE 修复后的 MULTIDRIVEN 排查；若组合逻辑进一步形成环路，则参考 UNOPTFLAT 组合环排查。这些诊断的判据不同，不要互相替代。

总结

Verilator PROCASSWIRE 表示 wire 被 always 或 initial 过程赋值，根因是线网声明与驱动机制不匹配，而非赋值次数过多。纯组合连接保留 wire 改用 assign；过程逻辑在 Verilog 中改用 reg，在 SystemVerilog 中使用 logic。沿左值反查声明和全部驱动，按原语言模式复跑并确认退出码为 0，才算真正解决 Verilator PROCASSWIRE。

入门

进阶

专家

Verilator PROCASSWIRE：wire 被过程赋值的定位与修复 ​

本文要回答的问题 ​

一、Verilator PROCASSWIRE 完整报错与最小复现 ​

二、根因：wire 是线网，不是过程变量 ​

三、排查清单：先收集声明和驱动，再动代码 ​

四、三种修复与复跑结果 ​

实验环境 ​

代码获取 ​

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

总结 ​