4.3 约束验证：别让工具检查错误的目标

4.3 约束验证：别让工具检查错误的目标

本节摘要：约束错误的表现不是报错，而是安静地查错对象——漏约束让违例消失，错约束让目标偏移。本节给出三件验证工具：check_timing 抓结构完整性、跨域清单核对时钟组、例外审计核对命中数，并给出把三者纳入流程的时机。

别以为约束写完就没事了。约束是最典型的"错误无报警"输入：SDC 语法错误工具会喊，语义错误工具一声不吭——漏定义的时钟让整片路径退出检查，写宽的伪路径把真违例藏进豁免区，错挂的多周期让检查发生在不存在的窗口。报告越漂亮的时候，越要先问一句：工具检查的真是我想让它检查的东西吗？本节的三件验证工具就是回答这句质问的标准流程。

第一件：check_timing 抓结构完整性

check_timing 是约束审计的起点，它枚举所有"处于约束真空"的结构。典型输出如下（逐行带解读）：

check_timing -verbose
Warning : There are 4 register/latch pins with no clock.        ; 无时钟触发器
  → 4 个触发器没有关联到任何时钟：通常是生成时钟漏声明（1.3 的坑），
    这些触发器的全部输入路径都没有被建立保持检查覆盖。
Warning : There are 12 input ports with no input delay.         ; 无输入延迟
  → 12 个输入端口没有 set_input_delay：in2reg 路径的预算缺了外部项，
    工具按零延迟处理，系统性偏乐观。
Warning : There are 3 clocks with no ideal latency or uncertainty. ; 时钟缺不确定度
  → 3 个时钟未设不确定度：预 CTS 阶段的建立账偏乐观 50ps 量级。
Warning : There are 2 endpoints with no output delay.           ; 无输出延迟
  → 对外接口的 reg2out 路径缺少契约数字，签核时属于未定义项。
Info    : Timing exceptions ... 38 constraints                  ; 例外清单
  → 38 条例外：转入第二件与第三件工具核对。
​

这份报告的每一行都对应一类"账本被撕掉一页"的问题。纪律是把它当签核门禁：check_timing 不清零（或每条残留都有书面解释），不进入收敛评估。很多团队把它挂在每次时序更新后的自动流程里，成本为零，收益是杜绝最廉价的一类错误。

第二件：跨域清单核对时钟组

时钟组与伪路径声明的是"意图"，而意图必须与设计的真实拓扑对账。做法是维护一张跨域矩阵：行列都是时钟域，格子里写交互方式（无交互、同步器、异步握手、数据无有效传输）。然后让工具按当前 SDC 报告实际豁免的域对，两者逐格比对。矩阵里有同步器而 SDC 没豁免——多余的假违例，噪声；SDC 豁免了而矩阵里是同步交互——真违例被藏起，危险；两边一致——通过。这张矩阵还是验证人员与后端的共同语言：DFT 插入、低功耗模式切换（第七章）都会改变时钟拓扑，每次变更后矩阵先更新、SDC 再跟随。

时钟组声明还有一个容易漏的角落：同频不同源的域。两个 100MHz 时钟来自不同 PLL，频率相同但相位毫无关系——按域对豁免才能正确处理，按"同频所以同步"的直觉处理会在两个域之间产生一批永远修不掉的"假同频违例"。矩阵法对这类陷阱天然免疫，因为交互方式那一栏会逼你回答"相位关系是什么"。

第三件：例外审计核对命中数

每条例外声明都应在工具里查它的命中清单（report_exceptions 或等价命令）——这条 set_false_path 实际覆盖了几条路径？覆盖的是不是当初申请时的那批？审计要抓三类异常：命中数为零（网表改名导致锚点失效，例外已空转）；命中数暴增（作用域写宽了，豁免扩散到无辜路径）；命中内容变化（网表更新后例外挂到了新的意外路径上）。三类的共同处理是把例外清单纳入版本评审：数量、锚点、原因三要素在每次网表更新后复核一遍。

约束的版本管理

约束是会腐烂的资产：网表改名让例外失效，时钟拓扑变更让生成时钟失配，模式增减让 case_analysis 过期。版本管理的最小实践有三条：SDC 按模块拆分、由模块 owner 维护、顶层只做集成与仲裁——全局单文件在多人项目里必然失控；每次网表发布绑定一个 SDC 标签，报告、网表、约束三者版本可互相追溯；变更日志记录每条修改的原因与评审人，让"为什么这里有一条伪路径"这类问题在半年后仍能找到答案。约束管理的成熟度，直接决定收敛后期是平静收尾还是全员救火。

把验证嵌进流程

三件工具的时机安排：约束初稿完成时跑 check_timing 与跨域矩阵评审——此时修改成本最低；每次综合/布局布线迭代后把 check_timing 与例外审计挂进自动脚本——防网表改名侵蚀；签核门禁时三件全跑并归档输出——签核报告里附上"约束已验证"的证据页。与第二章的门槛公式对照，本节做的事可以概括为：公式保证算得对，验证保证算的是该算的东西。两者缺一，报告的漂亮都只是表象。

一份约束评审的议程模板

评审是把三件工具用出制度感的形式。议程五项，一小时以内：第一项，新变更陈述——本轮 SDC 相对上版的差异清单，逐条说明原因；第二项，check_timing 残留逐条过——残留不为零时每条要给出解释或修复计划；第三项，跨域矩阵变更点——新出现的域对、新加的同步器，豁免清单随之更新；第四项，例外命中抽查——随机抽三条例外核对其命中路径与声明理由是否匹配；第五项，遗留项跟踪——上轮评审的待办逐条销项。会议产物只有一份：带责任人与期限的行动清单。评审的纪律性与三件工具的技术性互为表里，缺了哪一半，约束质量都守不住。

本节要点回顾

• 约束错误无报警：漏约束=少查一类违例，错约束=认真地查错目标，验证必须独立于收敛评估存在。
• check_timing 四类高频残留：无时钟触发器、无输入延迟端口、缺不确定度时钟、无输出延迟端点，每类对应一种被撕掉的账页。
• 跨域矩阵是意图与声明的对账表：行列为时钟域，格子里写交互方式，与 SDC 豁免清单逐格比对。
• 例外审计盯三类异常：命中为零、命中暴增、命中漂移，版本评审三要素是数量、锚点、原因。
• 时机：初稿评审、每次网表迭代自动跑、签核门禁归档，成本近零而回报极高。

约束的"对"被验证过了。但它还只是一定条件下的对——换个电压、温度、工艺批次，延迟账本全部重写。问题链第三站进入正题：第五章 PVT 角点与变异性。