企业官网建设流程全解析

简介：这是一份聚焦数字集成电路时序验证的静态时序分析（STA）学习资料，面向ASIC、FPGA与IC设计方向的初学者及需要巩固时序基础的工程师，帮助读者理解如何通过约束设定、网表分析与报告解读来定位并优化时序违例。资源为单个PDF文档，压缩包约592KB，内容围绕STA的概念与目的、分析流程、Setup/Hold等时序参数、关键路径与Timing Closure展开，并对比静态时序分析、动态时序分析与形式验证三种方法，同时介绍PrimeTime、SST Velocity、Blast等主流工具的使用场景，延伸至逻辑优化设计与ASIC、FPGA设计流程。文档配有路径示意与公式说明，如T=tCO+tDELAY+tSU及最高频率推导，便于读者把时序路径、时钟到建立时间等抽象概念对应到具体电路，形成从约束到收敛的完整认知。目前已有710人学习下载，适合作为时序分析入门梳理与工程排错思路的参考材料。

1. 静态时序分析：为什么“不跑激励”反而能锁死最坏路径

做数字电路的人都会遇到一个反直觉的结论：仿真跑了几百万个周期全过，静态时序分析却报出一条负 slack 的路径，最后芯片偏偏就在这条路径上出错。这不是工具在吓唬人，而是静态时序分析和功能仿真根本在验证两件不同的事。静态时序分析不需要任何输入向量，它把网表抽象成有向图，沿每一条寄存器到寄存器的路径做最坏情况加法；路径数量随逻辑设计规模指数增长，这件事仿真做不到，在图上做加法却可以。理解这套“不解方程、只算延迟”的机制，是搞懂 ASIC 和 FPGA 时序收敛的前提——教科书上那个T = tCO + tDELAY + tSU，只是这条机制链上最粗的一环。

2. 时序路径的本质：一条同步路径拆成三段延迟

2.1 从时钟沿到时钟沿：tCO、tDELAY、tSU 各管什么

最基础的同步路径模型是：触发器 A 的 Q 端出发，穿过一段组合逻辑，进入触发器 B 的 D 端，A 和 B 的 CK 端接同一个时钟。从 A 的时钟沿有效开始，到 B 能正确捕获数据结束，中间只有三段延迟在起作用。

第一段是 clock-to-Q 延迟tCO，时钟沿到达之后到 Q 端真正翻转到稳定值之间的时间；第二段是组合逻辑传播延迟tDELAY，从 A.Q 到 B.D 上所有门和线的延迟之和；第三段是建立时间tSU，在 B 的捕获时钟沿到来之前，D 端必须已经稳定那么久。三段加起来不能超过一个时钟周期，于是得到 setup 不等式：

T_clk ≥ tCO + tDELAY + tSU

把方向反过来就得到 hold 不等式：

tCO + tDELAY_min ≥ tH

含义是：在 B 的捕获沿到来之后的tH时间内，D 端不能变化，否则 B 可能锁到正在跳变的旧值。注意第二式用的是最小延迟——路径越短、组合逻辑越快，hold 反而越危险。很多刚接触时序分析的人会觉得组合逻辑做得太快也是错，这听起来不合直觉，但它确实是一条硬约束。

提示：hold 违例和时钟频率无关。降频救不了 hold，只能改版。这是流片前必须把 setup 和 hold 两类违例同时清掉的物理原因——setup 还有降频这条退路，hold 没有。

引入时钟偏斜Δt（捕获沿相对发射沿的延迟差）以后，两个不等式会变成带偏斜的形式：

slack_setup = T_clk + Δt - tCO - tDELAY_max - tSU slack_hold = tCO + tDELAY_min - Δt - tH

从这两行能读出很多设计上的东西：正偏斜（捕获沿晚到）对 setup 有利、对 hold 不利；负偏斜反过来。时钟树综合阶段做的 balance 和 useful skew 优化，本质就是在这两个 slack 之间找平衡，牺牲一点 setup 余量去补 hold 的窟窿。

2.2 从网表到有向图：STA 引擎在遍历什么

STA 不做任何逻辑仿真，它做的是一次图遍历。网表里的每个管脚是一个节点，每条连接是一条边。边分两类：单元弧（cell arc）和线网弧（net arc）。单元弧的延迟来自工艺库中的二维查表，输入是上一级的输出转换时间（slew）和本级输出负载；线网弧的延迟来自 RC 寄生参数提取，早期阶段可能用 fanout 估算。

引擎分两遍走。正序遍历时，从每个起点（输入端口、寄存器 CK/Q 对）出发，沿拓扑序把每条弧的延迟累加，得到每个节点的最晚到达时间。反序遍历时，从每个终点（寄存器 D 端、输出端口）的 required time 出发，往回逐级减去延迟，得到每个节点的要求时间。最后每个终点的slack = required - arrival，取所有路径里 slack 最小的那条，就是所谓的 critical path。

这套机制的复杂度大致和节点数成线性关系。一个上千万门的设计里，寄存器到寄存器的路径可能有几十万条，但它们不是一条条枚举出来的——正反两遍遍历就把所有路径的极值一次性算完了。这就是“静态”两个字的真正落脚点：不迭代、不需要激励，只看延迟极值。

2.3 仿真为什么覆盖不了所有路径，而 STA 可以

功能仿真的覆盖率受限于两个维度：输入空间和状态空间。一个 n 输入组合逻辑有 2 的 n 次方种组合，即使你有 90% 的代码覆盖率，也可能漏掉真正触发最长延时链的那组数据。更麻烦的是，某些路径的最坏延迟依赖特定输入跳变顺序——比如加法器的进位链，只有在特定进位传播模式下才达到最长延迟。

STA 完全绕开了这个问题：它不管输入是什么，只问这条路径上所有可能延迟的最大值能不能塞进一个周期。代价也是有的——它证明的是“在所有输入下都不会违例”，而不是“在哪些输入下会违例”，所以它对某些实际上永远不激活的路径也会报警，后面讲 false path 时会展开。

3. 时序约束怎么变成数学：一行 SDC 在工具里被翻译成了什么

3.1 create_clock 定义了时间原点

时序分析必须有一个时间参考。默认情况下，工具把时钟当成“理想时钟”：0 时刻，所有接到这个时钟的触发器 CK 端同时收到跳变。这一行约束写进去：

# 声明一个周期 10ns、占空比 50% 的时钟 # 第一个沿在 0 时刻上升，第二个沿在 5ns 下降 create_clock -name sys_clk -period 10.0 -waveform {0.0 5.0} [get_ports clk]

工具把sys_clk传播到所有与之相连的寄存器 CK 端，并把所有到达时间和要求时间挂到这个时间轴上。周期 10ns 意味着 setup 检查里T_clk取 10ns。如果路径从正沿触发寄存器出发、到负沿触发寄存器终止，那么实际的 setup 周期就是 5ns，报告里会单独列出一个半周期检查项。

这里最容易踩的坑是：时钟定义写错不会报语法错误。把 100MHz 写成-period 100（把频率当成周期了），所有路径立刻变得余量巨大，工具一句话不吭。约束不是代码，工具没有能力判断你写的是不是物理真值。

3.2 set_input_delay / set_output_delay：把芯片边界折进模型

STA 分析只覆盖芯片内部，但数据是从外面来的、也要走到外面去。输入输出延迟就是用来把外部时序折合到芯片端口上的：

# 外部器件从时钟沿到数据到达本芯片端口的最大/最小延迟 set_input_delay -clock sys_clk -max 2.0 -min 0.5 [get_ports data_in] # 下游器件对数据到达本芯片输出端口的时间要求 set_output_delay -clock sys_clk -max 3.0 -min 1.0 [get_ports data_out]

-max用来算 setup，-min用来算 hold。如果不写这两条，工具默认端口是理想边界，边界上的路径 slack 会非常好看，但实际板子上会挂——这是很多新手第一次 tape-out 后最血泪的一课。

3.3 ideal clock 与 propagated clock：同一版网表为什么两次结果对不上

综合阶段时钟树还没生成，STA 只能用理想时钟分析；P&R 之后有了真实的时钟树布线和寄生参数，打开set_propagated_clock分析，时钟树里每一级 buffer 的延迟和偏斜都会进入计算。两次分析结果因此出现差异。

这个差异的方向值得记住：真实时钟树的 skew 一般对 setup 有利、对 hold 不利。如果你在综合阶段看着 ideal clock 下的正 slack 就签核了，等于给 hold 留了一个虚假的安全余量。正确的做法是：综合阶段的时序结果只用来指导优化，最终签核必须用 P&R 之后带 SDF 反标的 propagated clock 分析。

4. 关键路径与 timing closure：负 slack 的物理含义

4.1 slack 是减法，但它背后是两个物理时间的差

slack = required - arrival这个减法里，required 是“数据最晚能什么时候到”，arrival 是“数据实际最早什么时候到”。负 slack 意味着数据比要求晚到了若干皮秒。工具报告里的格式大致是这样：

Startpoint: u_reg_a/Q (rising edge-triggered flip-flop clocked by sys_clk) Endpoint: u_reg_b/D (rising edge-triggered flip-flop clocked by sys_clk) Path Type: max Path Group: sys_clk Point Incr Path ------------------------------------------------------ clock sys_clk (rise edge) 0.000 0.000 u_reg_a/CK -> u_reg_a/Q 0.120 0.120 u_comb/u_and1/Z 0.340 0.460 ... data arrival time 9.860 clock sys_clk (rise edge) 10.000 10.000 u_reg_b/D setup requirement -0.180 9.820 slack (VIOLATED) -0.040

从这一段能读出三个层次的信息：哪条路径、每一级延迟贡献了多少、以及负 slack 的具体数值。timing closure 的过程就是反复打开这个报告，找到关键路径上占延迟最大的几级，换驱动更强的单元、重构逻辑、或者把组合逻辑切开，一轮一轮地把 slack 推到正数。

4.2 false path 与 multicycle path：约束里的后悔药

工具只会按你给的模型做最坏情况加法，它没有功能意识。如果一条路径在所有正常输入下都不会被激活——比如只用来做上电初始化的路径、跨异步时钟域的握手机制、或者测试模式下才打开的扫描通路——你就得用set_false_path告诉工具跳过它，否则它会占着报告的首位，把真正的违例遮在后面。

# 异步时钟域之间的路径，功能上不同时被激活 set_false_path -from [get_clocks clk_slow] -to [get_clocks clk_fast] # 测试模式下才使用的扫描路径 set_false_path -from [get_ports scan_en] -through [get_pins u_mux/scan_in]

用对了能去掉大量虚假违例，用错了会把真实违例藏起来，一直藏到芯片上板。set_multicycle_path同理，它表达的是“这条路径允许多个周期才稳定一次”，常见于慢速外设寄存器的采样路径。关键是：每一条都要有功能上的证明，不能凭“看起来不像会用到”就随手写成 false path。

4.3 pipeline 和 retiming：把延迟搬走，而不是消掉

关键路径 slack 为负时，可选手段通常只有三类：降低组合逻辑延迟（换单元、重构逻辑、加大驱动），降低时钟频率，或者把组合逻辑切成几段、中间插入寄存器——也就是 pipeline。

pipeline 不减少总延迟，它只是把一段长逻辑拆成两段短逻辑，让每一段都能在一个周期内完成。代价是吞吐延迟增加、面积增加、控制逻辑变复杂（数据需要在新的流水级上对齐）。retiming 则是把已有寄存器沿路径前移或后移，重新划分组合逻辑和寄存器的边界，同样不改变总延迟，只是让各段更均衡。

这两种方法都要求你先知道真正的瓶颈路径在哪。而“真正”的意思是：打开report_timing -max_paths看到的，是工具按你写的约束算出来的最短路径，如果约束错了，pipeline 可能插错位置，chip 回来照样违例。

5. 避坑与排查：报告看着全过了，芯片为什么还会挂

5.1 现象：所有路径 slack 都是正的，芯片上板却锁不住

现象：签核报告里 setup/hold 全部为正值，最差 slack 还有几百皮秒余量，芯片上板后却在特定温度下间歇性出错。

原因：签核用的是 ideal clock，时钟树插入延迟和偏斜没有进入计算；同时工艺角只跑了 typical，没有覆盖 SS/FF 等最坏角。典型角下的正余量在慢角下可能直接翻负。

解决：把 propagated clock 打开，用 SDF 反标真实时钟树；把签核角扩展到工艺库定义的所有必需角，至少覆盖 SS（setup）和 FF（hold）两端。

5.2 现象：同一版网表两次 STA 结果对不上

现象：同一个设计、同一版网表，换台机器跑两次，关键路径的 slack 差了 20ps 以上。

原因：两次用的工艺库版本或操作条件不一致；或者约束文件加载顺序不同，后加载的约束悄悄覆盖了前面的时钟定义。

解决：把库文件和约束文件的绝对路径写死在签核脚本里，加上校验和比对；每次签核前先 dump 一遍report_clocks，确认工具内部真正能看到哪些时钟。

5.3 现象：跨时钟域路径从报告里消失了

现象：一个从快时钟域到慢时钟域的同步器路径，在report_timing里完全找不到。

原因：之前的某版约束里有一条set_false_path -from [all_clocks] -to [all_clocks]之类的批处理命令，把整片跨域路径全吞掉了。

解决：约束文件要按模块分段审查，禁止使用all_clocks这种全局通配的 false path。跨时钟域路径要单独列出来，能用同步器加异步 FIFO 解决的，就在功能层面解决，而不是让工具假装它不存在。

5.4 现象：边界电路的 I/O 时序看起来完美无缺

现象：输入端口到第一个寄存器的 setup 路径 slack 常年是正数，端口处的数据建立时间在板上实测却明显不足。

原因：没有写set_input_delay/set_output_delay，工具把端口当成理想边界，外部器件延迟根本没有进入模型。

解决：按接口协议的时序参数补齐输入输出延迟，-max/-min分别对应 setup 和 hold 检查。更稳妥的做法是直接从接口数据手册里把外部器件的 tCO、tSU 折进去。

5.5 现象：max_transition 违例一直亮红灯没人管

现象：report_constraint里大量max_transition违例，但report_timing的 slack 全部通过。

原因：过渡时间超标时，查表延迟会超出库模型的有效区间，工具只能按边界值外推，算出来的延迟本身就不准。所以 transition 违例不一定直接体现在 slack 里，但它会让 slack 的可信度归零。

解决：把max_transition和max_capacitance当成硬约束清掉；实在无法清干净的，换用更强的驱动单元或者插入 buffer 分级驱动。

6. 设计取舍：STA、仿真和形式验证各自守的边界在哪

这三种方法从来不是互相替代的关系，它们守的是不同的问题空间。

STA 的位置很清楚：它负责回答“延迟是否在规格内”，它不负责回答“功能对不对”。所以签核流程里两者的顺序是：功能仿真先确认设计逻辑正确，STA 再确认所有实现路径满足时序。这个顺序反过来没有意义——一条时序全部通过但逻辑错误的电路，只是错得很准时。

FPGA 和 ASIC 在这条链上的侧重点也不同。FPGA 的布线资源是固定的，延迟模型相对简单，时序分析结果和实际行为的一致性比较高；ASIC 的寄生参数依赖版图和工艺角，同一版网表在不同提取模型下算出来的 slack 可能有十几皮秒的差异。所以 ASIC 的 STA 要跑多角、要留 margin，FPGA 的 STA 则更多是在确认综合和 P&R 的约束有没有写对。

第一次带一个跨时钟域的设计流片时，我把所有异步路径都标成了 false path，报告一片绿色，芯片回来以后跨域传输的数据偶尔采样到跳变中间，变成一个亚稳态问题。那次复盘之后我给自己定了个规矩：每一条set_false_path后面都必须跟一行注释，写清楚为什么这条路径在功能上永远不会被激活，写不出来的就不允许加。从那以后我每次审约束都强制走一遍这个检查，哪怕报告再好看，也先把这些注释逐条读一遍再签字。希望这些经验帮你少走一段弯路。

本文还有配套的精品资源，点击获取