iverilog 端口符号位强转：signed 连接 unsigned 后的负数排查

更新时间：2026-10-30。属于 EDA 报错排查系列。iverilog 端口符号位强转与 iverilog 端口位宽不匹配不同：位宽可以完全相同，问题只出在同一批比特被按有符号数还是无符号数解释。

首屏答案：无符号 8'hff 直接接到 input signed [7:0] 时，本机 Icarus Verilog 13.0 编译、运行都退出 0，端口位型仍是 ff，但按 signed 十进制显示为 -1，小于零的比较结果为 1。若模块协议本来就要求有符号输入，应在连接处显式写 $signed(raw_code)，再用断言同时核对位型与解释结果；不要等待一个并不存在的报错。

本文要回答的问题

• unsigned 信号连接 signed 端口后，比特真的被改了吗？
• 为什么 255 会在端口内按 -1 参与比较？
• 编译和仿真都退出 0 时，怎样暴露这类静默数值问题？
• 显式 $signed 修复了什么，又不能修复什么？

两栏的输出数值相同，差别不是显式转换会把 -1 改回 255，而是第二种写法把有符号协议写清楚，并用可失败的检查固定下来。若设计本意是无符号 255，真正该改的是端口声明或运算语义，而不是添加强转。

一、完整实测：iverilog 端口符号位强转没有诊断

实验模块只有一个 8 位 signed 输入 code 和输出 negative，组合逻辑为 negative = (code < 0)。测试平台把无符号寄存器 raw_code 置为 8'hff，直接连接到该端口，再分别按十六进制、无符号十进制和 signed 十进制打印。相同输入随后通过显式 $signed(raw_code) 再跑一次。

日志没有夹在编译命令后的 warning 或 error。bad compile exit=0、bad run exit=0 只说明仿真顺利执行；紧接着的三行才是问题证据：原始值是 raw_unsigned=255，端口是 port_signed=-1，negative=1。因此不能用“编译器没报错”推导“数值解释符合预期”。

修复用例同样得到 port_signed=-1，但这次三条断言分别检查端口位型等于 8'hff、signed 值等于 -8'sd1、比较输出等于 1。最终的 PASS 来自这些检查，而不是来自退出码本身。

二、根因：翻转的是数值解释，不是 0xff 的比特

8'hff 的八位全是 1。在无符号解释下，它等于 255；在 8 位二进制补码 signed 解释下，它等于 -1。端口连接没有把这八位取反，日志里的 raw=0xff 与 port=0xff 已直接证明这一点。发生变化的是端口声明提供给表达式和格式化输出的符号属性。

模块内部的 code < 0 因而按有符号负数处理，negative 为 1。这个问题常出现在寄存器原始字段、总线切片或存储器输出接入温度、偏移量等有符号模块时：上层只关心八位数据，下层却把最高位当符号位。若随后拿它做阈值比较、数组索引或算术缩放，影响会继续传播。

红色路径表示容易被漏掉的隐式解释，橙色是明确协议的修复动作，绿色是复验。两条路径到达相同的 -1 并不矛盾：实验目标是让有符号行为显式且可验证，而不是把一种解释强行改成另一种。

观察项	unsigned 原始信号	signed 端口	排查含义
十六进制位型	ff	ff	没有比特翻转
十进制显示	255	-1	符号属性改变数值解释
小于零比较	不成立	成立，输出 1	下游控制流可能改变
进程退出码	编译 0、运行 0	编译 0、运行 0	必须增加语义断言

三、排查清单：沿端口边界核对符号与预期值

遇到“数据发出去是 255，模块里却成了 -1”时，按下面顺序检查：

1. 同时打印位型和 signed 值：只看十六进制会漏掉符号解释，只看十进制又容易误以为比特被改。格式可参考 $display("port=0x%02h signed=%0d", code, code)。
2. 核对连接两端声明：重点看模块定义中的 input signed，不要只看测试平台或上游寄存器。位宽相同不代表数值类型相同。
3. 定位第一次语义变化：在原始信号、端口内部、比较输出各设一个观察点，确认问题是在端口边界还是后续算术表达式中发生。
4. 先问协议应该是什么：如果该字段表示有符号偏移，-1 是正确结果；如果表示数量或地址，255 才可能正确。不能仅凭“出现负数”就判工具错误。
5. 让回归能失败：对关键位型、十进制解释和分支结果使用 !== 与 $fatal(1, ...)。只检查 vvp 退出码，无法识别本次静默问题。

还要检查表达式中的扩展与混用。本实验刻意保持两端都是 8 位，以隔离符号因素；若位宽也不同，截断或扩展会叠加进来，应改看 iverilog 数值截断排查 的方法，把两个问题拆开验证。

建议把最小复现保持在单个模块和单个测试平台内，并选取 00、7f、80、ff 这类能区分符号边界的值。只测正数时，signed 与 unsigned 的十进制结果一致，回归很容易长期假绿；加入最高位为 1 的输入，才能覆盖符号解释差异。对真实总线字段，还应把期望值写成协议注释，避免维护者仅凭变量名猜测。

四、修复代码：显式 signed 转换并复跑 PASS

这里的设计契约就是“ff 表示 -1”。因此保留 signed 端口，在实例化边界写 $signed(raw_code)，明确告诉维护者此处需要按有符号数解释：

signed_decoder dut (
    .code($signed(raw_code)),
    .negative(negative)
);

if (dut.code !== 8'hff)
    $fatal(1, "FAIL: signed conversion changed the bit pattern");
if ($signed(dut.code) !== -8'sd1)
    $fatal(1, "FAIL: 0xff was not interpreted as -1");
if (negative !== 1'b1)
    $fatal(1, "FAIL: signed comparison did not select negative");

$display("PASS: explicit signed port keeps 0xff and evaluates -1");

$signed 不会把八位全 1 改成别的位型，它的作用是给出 signed 解释。断言使用四态不等的 !==，避免未知位被宽松比较漏掉；任何一项不符合契约都会以非零状态终止。复跑输出如下：

fixed raw=0xff raw_unsigned=255
fixed port=0xff port_signed=-1
fixed negative=1
PASS: explicit signed port keeps 0xff and evaluates -1
fixed.sv:34: $finish called at 1000 (1ps)
fixed run exit=0
PASS: implicit result observed and explicit signed conversion verified

如果业务契约其实是无符号 255，则不应照抄这份修复。应移除端口上的 signed，并审查模块内部所有比较和算术表达式；显式 $signed 只会更坚定地选择 -1，不能替代接口语义设计。

实验环境

• 机器/系统：macOS 26.5.2，x86_64。
• 工具版本：Icarus Verilog 13.0 (stable) (v13_0)。
• 日期：2026-10-30。
• 完整命令：bash run.sh；脚本执行 iverilog -g2012 -s tb -o bad_simv bad.sv、vvp bad_simv、iverilog -g2012 -s tb -o fixed_simv fixed.sv、vvp fixed_simv，标准输出与标准错误合并记录。两次编译、两次运行及脚本最终退出码均为 0。

代码获取

两份测试平台、复跑脚本和完整记录位于公开仓 https://github.com/derekzhuo/geek-doc.cn/tree/main/experiments/ts-iverilog-port-coercion-signed。进入目录执行 bash run.sh，即可复现隐式 signed 端口解释并运行修复版断言。

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

本篇处理位宽不变、符号解释变化的端口连接问题。位宽不一致时继续看 iverilog 端口位宽不匹配，数据被截断或扩展时看 iverilog 数值截断排查。返回 EDA 报错排查系列 可按编译诊断、运行值和协议断言继续分诊。

总结

iverilog 端口符号位强转的关键不是比特翻转，而是同一 8'hff 从无符号 255 变为 signed -1 的解释；本机两次编译和运行均退出 0，负数比较已经变为 1。确认接口协议后，用 $signed 明确有符号意图，并用位型、数值和分支断言复跑到 PASS；若预期本是 255，则应修改 signed 声明，而不是增加强转。