静态时序分析实战：从SDC约束、slack计算到关键路径签核

简介这份PDF资料围绕静态时序分析STA与逻辑设计展开面向数字集成电路设计初学者、ASIC/FPGA 方向的学生与工程人员帮助读者建立从时序约束概念到 timing closure 的完整认知框架。内容涉及时序约束中 Setup、Hold 时间的含义与 Clock-to-Output、tMET 等参数的关系静态时序分析流程中的网表生成、分析执行与报告解读以及建立时间与保持时间违例的成因和关键路径定位思路同时简要介绍 PrimeTime、SST Velocity、Blast 等主流 STA 工具与动态时序分析、形式验证等方法的差异并延伸至流水线、重定时等逻辑优化手段。资源包内仅含1个PDF文件大小约592KB篇幅紧凑适合作为时序分析入门梳理或面试前复习的提纲式读物。目前已有710人浏览学习可作为理解 STA 基本概念与术语体系的轻量参考资料。1. 从一张时序报告说起这份 STA 讲义解决的到底是哪类问题很多人第一次做时序签核流程是先运行一遍工具看见一屏 slack 数字然后才开始猜哪个数才算合格。真正容易出问题的地方通常不在工具会不会用而在于能否用一条T tCO tDELAY tSU把报告里那一行数字还原回具体电路。《静态时序分析与逻辑设计》这份 PDF 采用的是另一种讲法先把建立时间、保持时间、时钟到输出延迟这几个参数固定下来再讲时序约束怎么写、关键路径怎么找、timing closure 怎么收。它适合已经能画时序图、但对“约束为什么这么写”没底的人也适合从 FPGA 逻辑设计转向 ASIC 签核、需要补齐流程概念的工程师。静态时序分析不是跑一次报告就结束而是一套从约束到报告再到优化的闭环这份材料把闭环的每一段都落到了具体参数上。2. 时序路径的两个不等式T tCO tDELAY tSU 怎么落到网表上在同步电路里几乎所有时序问题最终都会被化简成两个不等式一个管“数据来得够不够早”一个管“数据走得够不够慢”。前者是建立时间检查后者是保持时间检查。这两个式子在教材上只有一行落到真实网表上却要牵扯库单元延迟、互连延迟、时钟树偏斜和工作条件。这一章把公式拆开拆到能拿到单个路径上逐个数字对得上的程度。2.1 把 tCO、tDELAY、tSU 三个量固定住一条从触发器 A 到触发器 B 的路径延迟由三段组成。tCO是 A 的时钟沿到 Q 端输出稳定所花的时间这个值不在网表里而在标准单元库或器件手册的时序表里并且分 min/typ/max 三档。tDELAY是 A 的 Q 到 B 的 D 之间那段组合逻辑加互连的延迟由综合与布局布线决定同样分档。tSU是 B 的 D 端数据必须在时钟沿之前稳定的时间窗口方向与 tCO 相反属于“必须提前量”。把这三点串起来就得到单周期路径的周期下限时钟周期必须大于等于tCO(max) tDELAY(max) tSU再扣掉时钟不确定度。这里最容易被忽略的是 max 与 min 的选择建立时间检查走最大延迟最慢那条路保持时间检查走最小延迟最快那条路。同一份网表两次检查用的根本不是同一组数字这一点如果没建立直觉后面看报告会一直觉得工具在乱算。参数数据来源建立检查取值保持检查取值典型量级示例工艺tCO库单元时序表maxmin0.08 ~ 0.20 nstDELAY综合/布线后的 SDF 或寄生参数maxmin0.1 ~ 数 nstSU库单元时序表max—0.02 ~ 0.10 nstH库单元时序表—max0.01 ~ 0.05 ns时钟不确定度约束文件给定加到 required 上扣减加到 required 上扣减0.05 ~ 0.20 ns提示表格里的量级只是示意实际值必须以手上那套库的.lib或器件手册为准。拿别人的数字套自己的工艺是最常见的翻车起点。有了这三段就能回答一个很实际的问题这颗芯片或这块板子最高能跑到多少频率。把f 1/T代进去T 取下限得到的就是理论频率上限。注意这个上限只对单周期路径成立多周期路径、跨时钟域路径、带使能的路径都不能直接套用。2.2 slack 的加减法arrival 与 required 到底谁减谁工具报告里那三列数字本质是两个时间点的比较。arrival time是数据实际到达 D 端的时刻从发射时钟沿算起等于发射沿时刻加上tCO tDELAY。required time是数据最晚必须到达的时刻从捕获时钟沿倒推等于捕获沿时刻减去tSU和时钟不确定度。两个一减就是 slackslack required - arrival正数表示还有余量负数表示已经违例。手算一遍比看十遍报告有用。下面这段脚本把一条路径的 setup slack 算出来用来和工具输出对齐# 单条 setup 路径的 slack 手算用于对照工具报告 tco 0.12 # 触发器 clock-to-Q取库中 max 档 tdelay 0.85 # 组合逻辑 互连延迟取 max 档含布线 tsu 0.08 # 目的触发器 setup time取 max 档 tclk 2.00 # 时钟周期对应 500 MHz uncertainty 0.15 # 时钟不确定度jitter skew 预留 arrival tco tdelay # 数据实际到达时刻 required tclk - tsu - uncertainty # 数据最晚允许到达时刻 slack required - arrival print(farrival{arrival:.3f} required{required:.3f} slack{slack:.3f}) # arrival0.970 required1.770 slack0.800 - 正余量这条路径不是瓶颈这段脚本里最值得琢磨的是uncertainty这一项。它不是工艺参数而是设计者主动留出的安全垫通常会涵盖时钟抖动、时钟树偏斜预估、以及 OCV 降额。留多少没有统一答案我一般的做法是先把时钟树综合前的偏斜预估放进去时钟树做完之后再用实际偏斜回填把多余的部分收回去否则后期会被过大的余量拖住白白多做一堆没必要的优化。对 hold 检查加减法方向反过来arrival tCO(min) tDELAY(min)required tH两者相差slack arrival - required。同样是正数合格但含义变成“数据不能来得太早”。2.3 保持时间为什么和频率无关初学者常有的误会是hold 违例降频就能救。实际上把周期从 2 ns 拉到 4 nshold 的 slack 一点都不会变。原因在检查的两个沿setup 检查比较的是“这个沿发射、下个沿捕获”两个沿之间隔着一整个周期周期变长余量变大hold 检查比较的是“同一个沿发射、同一个沿捕获”路径两端的时钟沿是同一个时刻周期长短根本没进公式。所以 hold 违例的修复手段只有三种在数据路径上插延迟buf 或延迟单元、缩短时钟到捕获触发器的偏斜、换驱动更弱的单元让 min 延迟变大。这三种手段都在改路径本身跟频率无关。反过来setup 违例的修复空间就宽得多降频、砍组合逻辑级数、加流水、改约束随便挑。维度setup 检查hold 检查发射沿 / 捕获沿不同沿隔一个周期同一沿用的延迟档位maxmin与频率的关系周期越紧越容易违例无关修复手段降频、减逻辑级数、加流水、松约束插延迟、调偏斜、换弱驱动高发 corner慢 corner低压高温快 corner高压低温表格最后一行是签核时的第二个高发点hold 违例经常只在快 corner 冒出来如果只跑一个慢 corner 就下结论说时序干净流片回来大概率会遇到问题。2.4 时钟不确定度和工作条件余量不能混着留约束文件里能影响 slack 的余量项有好几个clock uncertainty、clock latencysource 与 network 分开、以及各类 derate 系数。它们不是同义反复压的也不是同一个东西。uncertainty 压的是“我不确定时钟沿什么时候来”latency 补的是“时钟从端口到触发器实际走了多久”derate 则是对延迟值做悲观放大。实践中常见的错误是把所有悲观都塞进 uncertainty。这么做 slack 会集体变负然后开始盲目优化最后发现优化完还是负的因为负的根源是约束里的常数项。我一般的分配是uncertainty 只放抖动和偏斜预估通常 0.1 ns 上下OCV 通过 derate 表达早路径和晚路径分开设latency 在时钟树综合之后用提取出的实际值覆盖预估。这三项各走各的通道出了问题才能定位到具体是哪一项在起作用。3. 约束到报告的四步链路一份能跑的最小 SDC 与报告读法工具跑起来不难难的是让它算的东西和你脑子里想的是同一件事。这一步的差距全在约束上约束写漏一条报告会给你一个漂亮的假绿约束写重一条你会花两周去优化一条本来就不需要的路径。下面按“约束 → 网表与库 → 报告 → 路径分组”这个顺序把链路走一遍。3.1 时序约束一份能跑的最小 SDC 骨架一份能真正跑出有意义结果的约束文件最少要覆盖四类信息时钟定义、输入延迟、输出延迟、驱动与负载。缺任何一类工具都会用默认值兜底而默认值往往是把端口当成理想环境报告自然好看。# 最小可跑的 SDC 骨架时钟 - 不确定性 - 端口延迟 - 驱动/负载 # 1) 主时钟周期 2.0 ns占空比 50%上升沿在 0、下降沿在 1.0 create_clock -name clk_core -period 2.0 -waveform {0 1.0} [get_ports clk] # 2) 时钟不确定度与转换时间setup 留 0.15hold 留 0.05 set_clock_uncertainty -setup 0.15 [get_clocks clk_core] set_clock_uncertainty -hold 0.05 [get_clocks clk_core] set_clock_transition 0.10 [get_clocks clk_core] # 3) 输入延迟上游器件的 tCO 板级走线max/min 分别给 set_input_delay -clock clk_core -max 0.60 [remove_from_collection [all_inputs] [get_ports clk]] set_input_delay -clock clk_core -min 0.20 [remove_from_collection [all_inputs] [get_ports clk]] # 4) 输出延迟下游器件的 tSU/tHmax 对应 setup、min 对应 hold set_output_delay -clock clk_core -max 0.45 [remove_from_collection [all_outputs] [get_ports clk]] set_output_delay -clock clk_core -min 0.10 [remove_from_collection [all_outputs] [get_ports clk]] # 5) 驱动能力与负载不写这两行端口延迟算出来偏乐观 set_driving_cell -lib_cell BUF_X2 -pin Z [remove_from_collection [all_inputs] [get_ports clk]] set_load 0.05 [all_outputs]逐段解释一下。create_clock的-waveform决定上升沿与下降沿位置如果设计里同时用到双沿这里写错会让一半路径的检查沿错位报告全错但看起来很正常。set_clock_uncertainty分 setup/hold 两条是因为两个检查的悲观程度本来就不该一样。set_input_delay和set_output_delay里的 max/min 不是随便写的max 参与 setup、min 参与 hold少写一条 min输入侧的所有 hold 检查就等于没做。set_driving_cell和set_load是最容易被跳过、又最容易造成假绿的两行。前者告诉工具输入端有多强的驱动后者告诉工具输出端挂了多少电容。不写这两行工具按理想驱动和零负载算延迟偏小slack 偏大报告漂亮但没意义。注意端口列表里一定要把时钟端口排除掉否则时钟会被当成普通数据端口加输入延迟时钟路径的检查会全部失效。3.2 网表与库的匹配别让工具在错的单元上算延迟约束写完下一步是把网表和库对起来。这一步出问题的表现很有特征工具能跑完报告也能出但延迟数字明显不合常理比如一个反相器算出 3 ns。原因通常是网表里的单元名在库里找不到工具悄悄替换成默认单元或者直接跳过。# 网表与库一致性检查抽出网表里用到的单元名逐个到库里核对 grep -oE ^[[:space:]]*[A-Za-z_][A-Za-z0-9_]* netlist.v \ | tr -d | sort -u cells_in_netlist.txt # 从 .lib 里抽出所有 cell 定义名 grep -oE cell[[:space:]]*\([[:space:]]*[A-Za-z0-9_] slow.lib \ | sed -E s/cell[[:space:]]*\([[:space:]]*// | sort -u cells_in_lib.txt # 差集出现在网表但库里没有的单元就是隐患清单 comm -23 cells_in_netlist.txt cells_in_lib.txt这段脚本的思路很直接网表里出现的单元名集合减去库里定义的单元名集合剩下的就是“工具认识网表、但不认识这个单元”的部分。实际项目里这个差集通常不会为空因为网表里混着电源单元、填充单元、物理only单元这些本来就没有时序模型。所以真正要看的是差集里有没有带时序的单元比如触发器、锁存器、时钟门控单元。这几类如果缺库工具会给出完全错误的路径延迟。除了单元名还有两项必须核对工作条件corner和库版本。网表是某个 corner 下综合出来的STA 却拿另一个 corner 的库去算两边的延迟模型对不上结果没有参考价值。我一般的做法是在脚本开头把 corner 名字打印出来跑之前肉眼确认一遍比事后翻日志省事得多。3.3 报告三列怎么读一份真实报告的拆解报告里真正需要的只有三列起点时刻、到达时刻、余量。其余信息都是辅助定位。下面是一段典型的建立时间报告结构各工具字段名有差异语义一致Startpoint: u_core/u_ff0 (rising edge-triggered flip-flop clocked by clk_core) Endpoint: u_core/u_ff1 (rising edge-triggered flip-flop clocked by clk_core) Path Group: clk_core Path Type: max Point Incr Path --------------------------------------------------------- clock clk_core (rise edge) 0.000 0.000 u_ff0/CK 0.000 0.000 u_ff0/Q 0.120 0.120 - tCO u_core/u_and0/Z 0.310 0.430 - 组合逻辑 u_core/u_and1/Z 0.280 0.710 u_ff1/D 0.000 0.710 - arrival --------------------------------------------------------- data arrival time 0.710 clock clk_core (rise edge) 2.000 2.000 clock uncertainty -0.150 1.850 u_ff1/setup -0.080 1.770 - required --------------------------------------------------------- data required time 1.770 slack (MET) 1.060读这份报告的顺序是先看 Path Group 和 Path Type确认这是不是你想检查的那组路径再看 arrival 那一行是 tCO 加了几段组合逻辑最后看 required 那一行的三个减项。三段组合逻辑一共贡献 0.59 ns占了整条路径延迟的大头如果要优化目标很明确——把 and0 和 and1 合并或者拆到两级流水里。真正需要警惕的是相反的情况报告显示 slack 很大但路径上的组合逻辑段数明显偏少。这说明这条路径根本没被走通工具是在一段不完整的路径上算出的余量。判断方法是看 startpoint 和 endpoint 是不是都在设计内部只要有一端落在端口上就要回头检查 3.1 里的输入输出延迟有没有覆盖到。3.4 路径分组与报告生成把上千条路径收敛成几条一颗稍大的设计时序路径动辄几十万条全打印出来没人看。收敛的办法是分组按时钟域分、按路径类型分、按 slack 阈值筛。分组之后每组只保留最差的那几条问题就集中了。# 按时钟域分组只抓违例路径每组保留最差的 5 条 set clk_list [all_clocks] foreach clk $clk_list { set grp [get_path_group -of_clocks $clk] # -slack_lesser_than 0 只留违例-nworst 控制每端点条数 report_timing -path_group $grp \ -delay_type max \ -max_paths 5 \ -nworst 1 \ -slack_lesser_than 0 \ ./rpt/${clk}_setup.rpt }-slack_lesser_than 0是关键参数它把所有合格路径过滤掉只留下需要动手的。-nworst 1表示每个端点只报最差的一条避免同一端点因为多条输入路径重复刷屏。-max_paths 5控制总量。三个参数配合能把一个时钟域的报告压到一页以内。生成完报告不要急着看先做一次覆盖率检查约束里定义的时钟数量、端口加了延迟的数量、以及设计里实际存在的时钟数量三者应该对得上。对不上说明有约束没覆盖到报告是残缺的。4. FPGA 与 ASIC 的边界同一套 STA 方法两套参数要重算方法在两边是通用的参数几乎全要重算。从 FPGA 转过来的人最容易犯的错是把 FPGA 上那套“时序报告全绿就完事”的习惯直接搬到 ASIC 上。两边的延迟构成、可用资源、签核标准差得很远同一个设计在两边的瓶颈路径经常不是同一条。4.1 工具档位对照签核级 STA 与内置时序分析器项目正文里提到的几款 EDA 工具按能力可以分成两档签核级 STA 工具和 FPGA 厂商自带的时序分析器。两档的定位完全不同混用会出问题。维度签核级 STA 工具FPGA 内置时序分析器输入门级网表 标准单元库 寄生参数布局布线后的器件网表 器件时序模型约束方式SDC 全量约束需自行编写与校验部分自动生成时钟由工具识别延迟模型库单元 提取的互连 RC器件内部固定模型按行列位置查表多 corner 支持完整可批量扫有限通常按速度等级给定典型使用阶段综合后、布局布线后、签核前综合后预估、布局布线后确认常见误用约束漏项导致假绿把预估结果当签核结果表格里最后一行值得展开。FPGA 侧的分析器在布局布线前给的是估算值估算用的互连模型和最终布线结果能差出不少尤其在高利用率设计上。把估算报告当签核结论上板之后才发现问题这种属于典型的流程坑。4.2 跨时钟域、伪路径、多周期三个高发误用点约束里最危险的不是写错是写得太“宽松”。三条命令能让报告瞬间全绿也能让真实问题全部消失。# 危险区这三条命令都能让报告变绿用错就是掩盖问题 # 1) 跨时钟域只对真正的异步跨越生效且必须配合同步器 set_false_path -from [get_clocks clk_a] -to [get_clocks clk_b] # 2) 多周期只有逻辑上真的允许 N 拍才写setup 和 hold 要成对给 set_multicycle_path 2 -setup -from [get_pins u_ff0/Q] -to [get_pins u_ff1/D] set_multicycle_path 1 -hold -from [get_pins u_ff0/Q] -to [get_pins u_ff1/D] # 3) 逻辑互斥需要配合 design rule 检查否则会被综合优化掉 set_case_analysis 0 [get_ports test_mode]第一条set_false_path的正确用法是跨越的双方确实属于异步时钟域且路径上已经有同步器两级触发器或异步 FIFO。如果只是“不想看到这条违例”就加 false_path等于把真实的数据路径从检查里删掉上板后表现为极低概率的功能错误极难复现。第二条的多周期约束setup 和 hold 必须成对。只给 setup 不给 hold工具会把 hold 检查的捕获沿也往后推一个周期导致 hold 检查完全失效。这是我在实际项目里见过最多的约束错误没有之一。第三条set_case_analysis在测试模式下很有用但它会把相关路径直接剪掉如果这条路径在功能模式下是活的等于漏检。4.3 从 FPGA 迁到 ASIC 要重算的四个量同一份 RTL从 FPGA 换到 ASIC下面四个量必须重新评估不能沿用旧数字。第一个是单元延迟模型。FPGA 的查找表和进位链延迟是固定的ASIC 的标准单元延迟随驱动强度、输入转换时间、输出负载连续变化同一种逻辑功能在不同驱动下能差好几倍。第二个是互连延迟占比。FPGA 的布线资源是固定的延迟相对可预测ASIC 的互连延迟由实际走线长度和层决定在先进工艺下占比经常超过单元延迟本身。这意味着 ASIC 上优化单元延迟的收益可能远小于预期。第三个是时钟树。FPGA 的时钟走专用网络偏斜很小ASIC 需要自己插入时钟树偏斜、功耗、拥塞都要自己平衡时钟树综合前后的时序差别很大。第四个是工作条件 corner 的数量。FPGA 通常按速度等级给一组参数ASIC 要覆盖多个工艺角、多个电压温度组合每个组合都要单独签核。签核报告的数量是 FPGA 的数倍。5. 避坑与排查五条时序签核里翻过的车时序这块的坑有个共同特征犯的时候毫无感觉发现的时候已经烧掉一周。下面五条都是按“现象 → 原因 → 解决”记下来的每条对应一个很具体的信号。5.1 报告全绿但上板跑飞端口约束漏了一整片现象STA 报告 setup 和 hold 全部为正最差余量还有 0.3 ns但板子跑起来功能偶发错误换个批次又好了。原因只约束了内部时钟域之间的路径输入输出端口一条延迟都没加。工具把端口当成理想环境外部器件的 tCO 和板级走线延迟完全没进检查。内部路径确实没问题问题出在芯片边界上而边界根本没被检查。解决在约束末尾加一段覆盖率自检统计端口总数与已加延迟的端口数两者不等就中断流程。另外把外部器件的 tCO、tSU、tH 和板级走线延迟整理成一张表直接从表里取值不靠记忆。# 端口约束覆盖率自检数量对不上直接报错退出 set all_ports [remove_from_collection [all_inputs] [get_ports clk]] set constrained [get_ports -filter input_delay ! {}] if {[llength $all_ports] ! [llength $constrained]} { puts ERROR: [expr {[llength $all_ports] - [llength $constrained]}] 个输入端口缺少 input_delay exit 1 }5.2 约束写对了 slack 还是负的库和网表来自不同 corner现象约束逐条核对过和上一版工程一模一样但这一版跑出来一片负 slack最差的 -1.2 ns。把约束回退到上一版结果还是负的。原因网表是慢 corner 下综合出来的STA 却加载了快 corner 的库。两边的延迟模型对不上工具算出来的路径延迟比实际偏大slack 自然全线告负。这种情况很隐蔽因为工具不会报错只会安静地按加载的库算。解决在脚本开头把库路径、corner 名称、网表版本三者一起打印到日志首行跑完先看这一行。更进一步的做法是把 corner 名称写进库文件名让加载错库的行为在路径上就暴露出来。5.3 关键路径越优化越多拆散的组合逻辑被布线延迟反噬现象针对一条违例路径做逻辑重构把 6 级组合压到 3 级综合报告显示单元延迟降了 40%但布局布线后这条路径的 slack 反而更差了。原因级数减少意味着每级的扇出和驱动要求变高综合出来的单元尺寸变大布局时被推得更开互连延迟上升。在互连占主导的工艺节点上单元延迟的收益被布线延迟吃干净还倒贴。解决判断该不该动一条路径先看报告里单元延迟与互连延迟的比例。互连占比超过一半就不要在逻辑级数上做文章改用寄存器打拍pipeline把长路径切断让每一段的物理距离缩短。这个判断在布局布线前的报告里看不到必须用带寄生参数的版本。5.4 保持时间只在快 corner 违例只跑了一个慢 corner现象慢 corner 下 hold 全部通过签核前顺手补跑了一个快 corner冒出一批 hold 违例最差的 -0.15 ns。原因hold 检查用的是最小延迟路径工艺越快、电压越高、温度越低单元延迟越小数据越容易提前到达。只跑慢 corner等于只检查了 setup 的最坏情况hold 的最坏情况完全没覆盖。解决签核脚本里把 corner 列表写成显式数组setup 扫慢角、hold 扫快角两组结果分开汇总。任何一组缺失就判定签核不完整。这条现在已经是我的固定动作不再靠记忆。5.5 报告里整组路径消失一条 false_path 把它们全剪了现象某个时钟域下的路径在报告里一条都找不到既没有违例也没有合格路径像是这个域根本不存在。原因约束文件里有一条范围过宽的set_false_path用了-from [get_clocks clk_a]这种粗粒度写法把该时钟域下所有路径连同真实的同步路径一起剪掉了。工具不会提示“你剪掉了 N 条路径”只会安静地不检查。解决所有set_false_path必须写到具体路径或具体引脚禁止用时钟到时钟的粗粒度写法除非确认整对时钟域完全异步。另外在报告生成后统计每个 path group 的路径条数某组为 0 就回头查约束。这个检查很土但救过我两次。6. 关键路径之后的收口pipeline 与 retiming 什么时候值得动找到关键路径只是开始真正决定项目周期的是“改哪里”和“改到什么程度停手”。我的判断顺序是先看这条路径是不是真的需要优化再看能不能靠约束澄清最后才动 RTL 结构。第一步永远是确认这条路径在功能上必须单周期完成。带多周期语义的路径比如乘法器的后级、状态机的慢速分支如果被当成单周期在优化投入的每一分力气都是浪费。确认的方式是回到 RTL 看数据依赖性不是看报告。确认必须单周期之后才轮到三个手段手段适用场景代价见效速度逻辑重构合并/提取公因式组合级数多但每级很浅改动小可能引入新路径快综合即可验证插入流水级pipeline路径跨越多个模块物理距离长增加一拍延迟接口时序要改中需重新验证功能寄存器重定时retiming组合逻辑夹在寄存器之间前后负载不均工具自动搬移调试信息变差慢需多轮迭代收敛逻辑重构的收益上限通常在 20% 到 30%再往上就很难因为剩下的延迟主要是互连。插入流水级的收益最大但会改变接口时序凡是跟外部器件对接的路径都不能随便加这一点如果没提前跟系统侧对齐后期返工代价很高。寄存器重定时在数据通路上效果好在控制逻辑上经常把可读性搞没调试时找不到信号我一般只在对性能极度敏感的数据通路上开。还有一个容易被忽略的收口动作优化完之后重新跑一遍完整签核不要只看被优化那条路径的新 slack。逻辑重构和流水级插入都会改变布局周边路径的延迟跟着变经常出现“修好一条、坏了两条”的情况。全量重跑一次的成本远低于上板之后定位一个偶发错误的成本。从那以后我每次拿到一份新网表都强制先跑一遍端口约束覆盖率检查和 corner 完整性检查两项都过了才允许自己去看 slack 数字。这个习惯看着笨但它把“报告好看”和“时序真的干净”这两件事分开了。希望帮到你。本文还有配套的精品资源点击获取