Formality 位宽与类型不匹配：端口位宽、有符号比较与常数截断速查

更新时间：2026-10-23。FAQ 速查页，属于 EDA 工具排错系列。Formality（fm_shell）做形式等价比对时，对「位宽与类型」远比仿真器敏感：仿真里一次隐式截断顶多埋个功能 bug，FM 里 reference 与 implementation 两端端口位宽对不上，轻则 Warning 刷屏、重则 compare 直接 mismatch。特征是报错本身写得明明白白——哪个端口、两边各多少位——难的是判断该改哪一端、还是该统一命名风格。如果读入阶段就语法报错，先看 Formality 语法解析报错；模块名都对不上则转 Formality 模块未找到。

本文要回答的问题

• 报 Port 'xxx' width mismatch，reference 8 位、implementation 9 位，改哪边？
• 总线在一边展开成 data_7_ 风格、另一边是 data[7] 风格，算同一个端口吗？
• 报 implicit truncation 的 Warning 要不要管，还是直接 waive？
• 常数 assign out = 255; 没写位宽，FM 会怎么处理？
• signed 和 unsigned 信号比较，为什么 compare 结果和仿真不一致？
• 同一个模块两个实例位宽不同，是 parameter 传错了吗？

一、报错原文与现象

Warning: Port 'dout' width mismatch: reference 'top' has 8 bits, implementation 'top' has 9 bits (FMT-048)
Warning: Bus 'data' naming style differs: reference uses 'data_%d', implementation uses 'data[%d]' (FMT-052)
Warning: Implicit width truncation at ./rtl/alu.v:64: 33-bit expression assigned to 32-bit signal (VER-318)
Warning: Constant '255' has no explicit width; defaulting to 32 bits (VER-284)
Warning: Signed/unsigned comparison mismatch at ./rtl/cmp.v:41 (VER-351)
Warning: Instance 'u_mac0' port 'coef' width 16 differs from instance 'u_mac1' width 12: parameter values differ (FMT-061)

这些 Warning 的共同点是不阻断读入，所以很容易被一把 suppress_message 全 waive 掉——这是最大的坑。端口位宽不一致的端口在 compare 阶段会被标记为不完全可比，最终结果不可靠；隐式截断在仿真里可能只是「高位丢掉没事」，但 FM 的布尔等价检查是按实际位展开的，两边截断位置不同就是实打实的 mismatch。处置原则：位宽类 Warning 一条条过，确认每一条是「可解释的设计事实」还是「真笔误」，只 waive 前者。

二、可能原因总览

现象特征	可能原因	处置
同名端口两边位宽差 1-2 位	实现侧插了溢出/进位位或补了符号位	确认是设计意图后用 guide/约束对齐，笔误则改 RTL
总线命名 _%d vs [%d]	综合工具总线展开风格与 RTL 不一致	set hdlin_bus_naming_style 统一两边风格
implicit truncation 指向加法/乘法表达式	表达式位宽比左值宽，高位被丢	显式扩展左值或显式截取，消除隐式语义
常数未指定位宽按 32 位展开	assign a = 255; 这类裸常数	写成 8'd255 显式位宽，两端一致
signed/unsigned 比较 Warning	一端声明 signed、另一端无符号	统一声明或显式 $signed/$unsigned 转换
同模块两实例位宽不同	parameter 传参不一致或默认值漂移	核对两边 parameter override，统一参数表
读入无 Warning 但 compare mismatch	位宽差被上游 waiver 掩盖	撤 waiver 重读，按上面逐条过筛

三、排查决策图

位宽类问题的排查顺序建议「先端口、再命名、后表达式」——端口位宽不一致是硬伤，直接决定可比性；总线命名风格是「假不一致」，改个开关就消失；表达式截断、常数位宽、符号比较这三类是 RTL 语义层问题，需要回到代码里逐处确认。下面这张图把主线串起来：红色是入口现象与真根因，蓝色是排查动作，绿色是确认通过的汇合点，橙色是修复动作，紫色是收尾防复发。

读这张图抓住一条主线：第一步蓝色判别节点按 Warning 的指向分流——指端口、指总线命名、指表达式三条路互斥，一次只走一条；「核对两边设计意图」是唯一需要人介入判断的节点，其余全是机械动作。绿色「重读无 Warning 通过」是所有支线的汇合点，任何修复后立刻重读验证，不要攒一批一起改——Warning 行号和位宽数字一变，原有的 waiver 清单就全部失效。

四、逐条排查展开

端口位宽不一致：先问「多出来的位是什么」。 reference 8 位、implementation 9 位这种差一位的场景，九成是综合或后端插了溢出位、符号扩展位，或者实现侧顶层把 {carry, sum} 打平成一个端口。判别方法：打开两边网表看那个端口的实际驱动——多位是常数 0、符号位复制，还是真实逻辑。是设计意图就在 FM 脚本里用 set_guide 或端口约束声明对齐关系；是笔误（比如 RTL 端口宽度抄错）直接改 RTL，别用 waiver 糊过去。同模块两实例位宽不同（FMT-061）则是 parameter 问题：核对两边的 defparam 或 #(...) override，常见于一个实例手改了参数、另一个用默认值。

总线命名风格：一个开关消除的假不一致。 RTL 里写 data[7:0]，综合网表展开成 data_7_、data_6_……，两边 read 进来后 FM 认成两组不同端口：

# 读入前统一总线命名风格，两边都设
set hdlin_bus_naming_style "%s[%d]"

风格字符串必须 reference 与 implementation 两侧一致，且要在 read 之前设置，读完再改无效。如果网表来自第三方、命名不可控，用 change_names 类流程先把网表名字洗一遍再进 FM。

隐式截断：把隐式语义写成显式。 VER-318 指向的表达式（如 a + b 结果 33 位赋给 32 位信号）在仿真里悄悄丢高位，FM 里则是两端截断位置必须一致才可比。修法二选一，关键是显式：

// 方案一：扩展左值，保留进位
wire [32:0] sum_full = a + b;
// 方案二：显式截取，声明丢弃高位是意图
wire [31:0] sum = (a + b) & 32'hFFFF_FFFF;

常数与符号：两个小习惯挡掉一半 Warning。 裸常数 assign out = 255; 按 32 位展开，与 8 位左值之间又是一次隐式截断——写成 8'd255 从源头消除。signed/unsigned 混比（VER-351）在 FM 里按位展开后可能与仿真的数值语义不同，统一两端声明，或在比较处显式 $signed(a) >= b，让意图落在代码里而不是读者脑子里。

五、预防与纪律

• 位宽 Warning 零 waiver 起步：项目初期一条不 waive，每条都给出「设计意图」书面结论；后期增量 waiver 必须带注释说明理由。
• 总线命名风格写进模板脚本：hdlin_bus_naming_style 与综合流程约定同源，新项目从模板继承，不靠人记。
• RTL 编码规范禁裸常数与隐式截断：常数必带位宽、截断必显式，用 verilator --lint-only -Wall 在入库前挡住。
• parameter 清单集中维护：参数化模块的 override 值从公共配置生成，reference 与 implementation 同源，防实例位宽漂移。
• waiver 清单随脚本入库、进 CI 评审：任何新增 waiver 在 code review 里单独过一眼，防止「为消 Warning 而 waive」掩盖真位宽 bug。

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

本篇是 EDA 排错速查簇中「读入语义层」节点的 Formality 篇，覆盖位宽与类型不匹配；读入连语法都过不去时先看 Formality 语法解析报错；模块、引用层面对不上时转 Formality 模块未找到；位宽对齐之后 compare 仍 mismatch 的信号层问题，见 Formality 未定义符号。

一句话总结

Formality 位宽类型不匹配按「端口 → 命名 → 表达式」三层排查：端口位宽不一致先核对两边设计意图再决定改 RTL 还是加约束，总线命名风格不同用 hdlin_bus_naming_style 在读入前统一，隐式截断、裸常数、signed/unsigned 混比这三类回 RTL 写显式位宽与类型转换；铁律是位宽类 Warning 零 waiver 起步、逐条给结论，根治靠编码规范禁隐式语义、parameter 与 waiver 清单集中入库进 CI，让位宽问题从「waive 掉看运气」变成每条可解释、可回归的机械活。