SDC约束签核22项自查清单：时钟、IO、时序例外、CDC与物理环境五组逐项过

更新时间：2026-10-29。本文是「集成电路大类 · 芯片设计」入门层（beginner）的一篇清单文。时序分析的基本概念（建立/保持、slack 怎么算）见 STA 静态时序分析入门，create_clock 报告字段怎么读见 OpenSTA create_clock 报告解读。那两篇回答「时序分析是什么、报告怎么看」，本篇回答一个更工程化的问题：约束文件写完了，签核（sign-off）之前到底该自查什么。22 项检查点按五组编排，每项给「检查点 → 怎么判 → 常见错误后果」三件套，签核前对着过一遍即可。

本文要回答的问题

• SDC 签核自查应该按什么顺序分组，22 项各自检查什么？
• 每项检查看报告的哪个字段、跑什么命令就能判定？
• 漏掉某一项最常见的后果是什么——是漏约束（路径不被分析）还是过度约束（工具白优化）？

先看五组的全貌，再逐组展开：

读这张卡抓住分组逻辑：五组的顺序就是依赖顺序——时钟是所有约束的锚点，IO 约束挂在时钟上，时序例外引用时钟域，物理环境参数最后叠加；前一组有漏，后面所有组都建立在错误前提上。所以自查必须从第 1 项顺着做到第 22 项，不要跳。

一、时钟定义（第 1-5 项）

时钟是 SDC 的地基，这一组漏任何一项，下游时序分析全是空中楼阁。

#	检查点	怎么判	常见错误后果
1	每个输入端口时钟都有 create_clock	report_clocks 列出的时钟与设计时钟端口一一对应	整片寄存器无约束，时序报告「全绿」假象
2	时钟周期/波形与真实频率一致	对照设计规格书核 report_clocks 的 period 字段	约束过松放过违例，过紧白耗面积功耗
3	分频/倍频时钟用 create_generated_clock	查时钟树输出端是否只有主时钟、无生成时钟定义	生成时钟域路径按主时钟分析，结果完全错误
4	时钟名唯一且可读	report_clocks 无重名、无自动生成的 clk_1 类无名时钟	后续例外约束引用错对象
5	同相/异步关系用 set_clock_groups 声明	report_clock_groups 输出与 CDC 文档一致	异步路径被当同步路径分析，报出海量假违例

第 1 项是最常见的入门级事故：设计有三个时钟端口，约束只写了两个，第三个时钟域的所有路径根本不进 STA 分析，报告上一片 clean，签核完上板就翻车。判定的捷径是对比 report_clocks 数量和设计里实际时钟源数量，不等必有鬼。第 5 项的假违例问题见 CDC 报告分诊 里的同类讨论。

二、IO 约束（第 6-9 项）

没有 IO 约束，工具不知道芯片外部世界长什么样，接口路径等于没分析。

#	检查点	怎么判	常见错误后果
6	所有输入端口有 set_input_delay	check_timing 报告 unconstrained endpoints 为 0	输入路径不参与建立/保持检查
7	所有输出端口有 set_output_delay	同上，输出端点 0 悬空	输出路径时序无人担保
8	IO delay 相对正确的时钟（-clock）	抽查几个端口的 delay 约束引用时钟与接口协议一致	delay 挂错时钟，接口时序算错量级
9	驱动/负载模型（set_driving_cell / set_load）与真实板级一致	对照板级方案核驱动单元与负载电容	IO 转换时间失真，接口时序偏乐观

第 8 项的坑在于「约束存在但挂错对象」：set_input_delay -clock 写的是内部时钟而非接口的虚拟时钟，数值上看着都有，语义上全错。签核时抽查几个关键接口（DDR、SPI、RGMII）逐条核对这个字段，比全量机器检查更能抓到真问题。第 6、7 两项合并用一条 check_timing 就能判：报告末尾的 unconstrained endpoints 必须是 0，任何非零值都意味着有端口漏了 delay 约束——这条命令应当固化进签核脚本，而不是靠人肉翻约束文件。第 9 项常被当成「可有可无」：不设 set_load 时工具按默认负载估算输出 transition，数值往往偏小，接口时序因此偏乐观，上板后才发现建立时间不够。

这一组还有个使用上的建议：IO 约束的数值不要手抄规格书，要让约束文件里出现的是「板级时序预算表里能查到的那一项」，并在注释里写明出处。半年后换人维护时，没人记得 1.2ns 是哪来的，出错就从这里开始。

三、时序例外（第 10-14 项）

例外约束是双刃剑：写对了砍噪音，写错了把真违例一起豁免掉。false path 滥用后果 专门讲过一类事故，这一组是它的清单化展开。

#	检查点	怎么判	常见错误后果
10	每条 false path 有设计理由注释	逐条 review，答不出「为什么这条路径不用分析」	真违例被误豁免
11	false path 用 -from/-to 精确限定，不用通配符扫一片	grep 约束文件里的 * 通配	一片路径被连带豁免，违例漏网
12	multicycle 的 N 值与握手协议拍数一致	对照协议时序图核 set_multicycle_path 的 N	多拍路径按单拍检查报假违例，或反之放过真违例
13	multicycle 成对设置 setup 和 hold	检查是否只有 setup 没有 -hold	保持时间检查错位一拍
14	set_max_delay 不与 clock 约束冲突	比较 max_delay 值与时钟周期关系	约束互相打架，工具按谁算都不对

第 13 项是经典漏项：set_multicycle_path 2 -setup 写了，配套的 -hold 忘写，hold 检查默认仍按 setup 的拍数偏移，结果是对一个本不存在的要求做检查。记住口诀：setup 移几拍，hold 跟着补。

四、跨时钟域约束（第 15-18 项）

#	检查点	怎么判	常见错误后果
15	异步时钟对在 set_clock_groups -asynchronous 中	report_clock_interaction 里异步对显示为 false	异步路径产生海量无意义违例
16	同步器链（两拍/三拍）路径被正确豁免或 max_delay 约束	抽查同步器路径的约束类型	同步器被做不必要的时序优化反而破坏 MTBF 假设
17	时钟交互报告无意外 timed 路径	report_clock_interaction 全表 review	隐藏的跨域路径漏分析
18	数据总线跨域有格雷码/FIFO 等结构佐证	对照 CDC 检查工具报告核约束	多比特总线直接豁免，亚稳态风险残留

第 17 项的 report_clock_interaction 是最被低估的一张表：它把「哪些时钟域之间有被分析的路径」一览无余，任何意料之外的 timed 交叉格都是约束漏洞的指针。第 16 项要反过来理解：同步器路径不是「不用管」，而是「要按特殊方式管」——要么显式 false path 交给 CDC 工具做结构性检查，要么用 set_max_delay -datapath_only 限定最大延迟，保证同步器级间布线足够近；完全不加约束，布局布线工具可能把两级同步触发器拉到芯片两端，亚稳态恢复时间被布线延迟吃掉。第 18 项强调「豁免要有结构佐证」：多比特数据总线跨域不是打个 false path 就完事，必须能指出对应的握手电路、格雷码计数器或异步 FIFO 实例，否则豁免的就是一条真实的亚稳态通道。

五、物理与环境（第 19-22 项）

#	检查点	怎么判	常见错误后果
19	set_timing_derate 与签核 corner 要求一致	对照工艺厂 sign-off 文档核 derate 数值	裕量计算与代工要求脱节
20	set_clock_uncertainty 覆盖抖动+偏差预算	核 uncertainty 与 PLL 抖动指标+时钟树偏差之和	上板实测频率到不了签核频率
21	输入 transition（set_input_transition）有上限	查输入端口转换时间约束存在	慢 transition 传播进内部，时序偏乐观
22	多 corner 约束全部加载并各自通过	确认 setup 查 ss/tt、hold 查 ff 等各角报告	只签一个 corner，极端工艺角翻车

这一组的共性是「约束值不是设计拍脑袋，而是来自外部文档」——derate 来自工艺厂、uncertainty 来自 PLL 手册、transition 来自板级仿真。自查时每项都要能指出数值出处，指不出来就是隐患。

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

• 上游概念：STA 静态时序分析入门（建立/保持与 slack 的基础）；
• 报告解读：OpenSTA create_clock 报告解读（第 1-5 项依赖的报告字段逐个讲）；
• 例外深挖：false path 滥用后果（第 10-11 项的事故案例）；
• 横向延伸：时序分析 与 芯片设计流程（约束在整流程中的位置）。

总结

SDC 签核自查按「时钟 → IO → 例外 → CDC → 物理环境」五组 22 项顺序过：时钟组防漏约束（路径不分析的假绿），IO 组防悬空端点，例外组防通配符滥用遮蔽真违例，CDC 组防异步路径被误当同步分析，物理组防约束与签核 corner 脱节；每项的判定都落到具体报告字段（report_clocks / check_timing / report_clock_interaction）上，自查不是背书而是逐字段核对。