3. PrimeTime SI签核流程总览

PrimeTime SI(以下简称 PT-SI)的串扰签核不是“跑一次 crosstalk 命令”这么简单,它是一条由库、寄生参数、时序约束、串扰分析、报告检查五个环节串联起来的完整数据链。任何一个环节的输入不完整或语义错误,都会在最终报告里表现为“看似有违例、实则不可信”的结果。理解这条链的输入输出关系,比记住某条命令更重要。

下面这张图给出 PT-SI 签核的整体数据流:左侧是四类输入(工艺库、寄生参数、时序约束、设计网表),中间是 PT-SI 内部的处理阶段,右侧是报告与判定。图中同时标注了每个阶段最常见的失败点,便于对照排查。

输入层 工艺库 / 单元库 .db / .lib(含 CCS) 寄生参数 SPEF / DSPF 时序约束 SDC(时钟/IO/例外) 设计网表 Verilog / .db PT-SI 处理阶段 ① 库准备与链接 link_design / read_db ② 寄生参数反标 read_parasitics ③ 约束加载与检查 read_sdc / check_timing ④ 串扰分析 update_timing -crosstalk ⑤ 报告与检查 report_timing / report_si 输出与判定 链接报告 unresolved / black box 反标覆盖率 annotated / total nets 约束完整性 unconstrained paths 串扰违例 delta delay / glitch 签核结论 PASS / FAIL / 待修 常见失败点 • 库版本与网表不匹配 • 缺失 CCS 噪声模型 • link 后出现 unresolved • SPEF 与网表 net 名不一致 • 反标率低于 95% • 缺少耦合电容信息 • 时钟定义缺失或重叠 • 未设 false path / multicycle • IO 约束不完整 • 未开启 crosstalk 分析 • 噪声阈值设置不当 • 分析窗口未覆盖 • 只看 WNS 忽略 delta • 未区分真实/虚假违例 • 报告未保存版本基线

阶段一:库准备与链接

PT-SI 的起点是让工具“认识”设计。需要读入工艺库(.db 或 .lib)和设计网表,执行 link_design 完成链接。这一步的关键不是命令本身,而是链接后的检查:用 report_design 或 check_design 确认没有 unresolved reference、没有 black box、没有重复模块定义。如果库版本与网表综合时使用的版本不一致,单元功能可能对得上,但噪声模型(noise model)和 CCS 时序模型可能缺失,导致后续串扰分析直接跳过某些单元。

一个容易被忽略的细节是:PT-SI 做串扰分析需要单元库中包含噪声容限(noise margin)和 CCS 驱动/接收模型。如果库只提供了 NLDM 模型,工具会退化为较保守的估算,或者在某些版本中直接报 warning 并跳过该单元的串扰计算。因此库准备阶段应确认:report_lib 中能看到 ccs_noise_model 或 noise_margin 相关属性。

阶段二:寄生参数反标

寄生参数通常来自 StarRC 或 Quantus 提取的 SPEF 文件。用 read_parasitics 读入后,必须检查反标覆盖率。PT-SI 提供 report_annotated_parasitics 命令,输出每个 net 的 annotated / total 比例。工程实践中,反标率低于 95% 就需要排查:是 SPEF 中的 net 名与网表不一致(常见于层次化设计中的转义字符或 bus 命名差异),还是提取时只输出了部分 corner。

串扰分析对寄生参数的要求比普通时序分析更高:它不仅需要每根 net 的对地电容,还需要 net 之间的耦合电容(coupling capacitance)。如果 SPEF 中缺少耦合电容段,PT-SI 会认为该 net 没有串扰影响,报告看起来“干净”,但实际上是漏报。检查方法是查看 SPEF 中是否有 *CAP 段带耦合节点,或在 PT-SI 中用 report_si 查看耦合网络数量。

阶段三:时序约束加载与检查

SDC 约束决定了 PT-SI 在哪些路径上做时序比较,也决定了串扰分析的“受害者”和“攻击者”如何被识别。读入 SDC 后,必须执行 check_timing,重点关注:unconstrained endpoints、no clock、generated clock 未定义、false path 覆盖不全。串扰分析中,如果某条路径没有被约束覆盖,它不会出现在时序报告里,也就不会被签核。

另一个关键点是时钟定义。串扰引起的 delta delay 会改变路径的建立/保持关系,如果时钟本身定义有重叠或不确定性设置过松,delta delay 可能被掩盖。建议在串扰分析前先跑一次无串扰的时序分析,记录 baseline WNS/TNS,作为后续对比的参照。

阶段四:串扰分析

PT-SI 中开启串扰分析的核心命令是 update_timing -crosstalk(不同版本可能略有差异)。执行后,工具会计算每根 victim net 上的 delta delay,包括上升沿和下降沿两个方向。这里需要理解一个方向约定:delta delay 为正表示串扰使 victim 跳变变慢(延迟增加),为负表示变快(延迟减小)。建立时间检查关注正 delta,保持时间检查关注负 delta。

串扰分析的计算量远大于普通时序分析,因为它需要遍历耦合网络并迭代求解。实际项目中通常先做一次全芯片分析,再对违例路径做增量分析。如果运行时间过长,可以先用 set_si_analysis 相关选项限制分析范围,但签核阶段必须做全芯片覆盖。

阶段五:报告检查与签核判定

串扰分析完成后,用 report_timing 查看带 delta delay 的路径报告,用 report_si 或 report_noise 查看串扰专项报告。判定时不能只看 WNS 数值,还要区分:

  • 真实违例:delta delay 导致 setup 或 hold 实际不满足,需要修。
  • 虚假违例:路径被 false path 覆盖但工具未识别,或攻击者与受害者不会同时翻转。
  • 噪声违例:glitch 幅度超过接收端噪声容限,即使时序满足也可能导致功能错误。

签核报告应保存完整的版本基线:库版本、SPEF 文件、SDC 版本、PT-SI 版本、分析选项。缺少任何一项,后续复现或对比都会失去意义。

流程闭环检查:在跑完 PT-SI 后,建议按以下顺序确认——link 无 unresolved → 反标率 ≥ 95% → check_timing 无 unconstrained → crosstalk 分析已开启 → 报告同时包含 delta delay 和 noise 两类结果。任何一步不满足,后续报告都不应作为签核依据。
常见误区:把 PT-SI 当成“跑一次就出结果”的工具。实际上,串扰签核的可信度高度依赖前四步的输入质量。反标率不足、约束缺失、库模型不全,都会让最终报告产生“假通过”或“假违例”。建议在项目早期就建立输入检查清单,而不是等到签核前才排查。