1. 时序路径分析到底在分析什么

做芯片设计，尤其到了数字后端这一层，经常会听到一句话：“时序收不敛，理由千万条；时序不出问题，其实就一条——该到的没到，不该到的到了。”这句话糙理不糙，所有时序路径分析，本质上都在回答两个问题：数据信号在时钟沿到来之前能不能稳定下来？数据信号在时钟沿到来之后能不能保持住？

放在更长远的视角看，时序路径分析是贯穿前端综合、后端布局布线、签核验证全流程的一条主线。前端工程师写出RTL，综合工具负责把RTL映射成门级网表，但它必须确保映射后的电路在目标频率下能在各种工艺角、各种温度电压条件下正常跑起来。后端工程师做布局布线、时钟树综合，每一步都要围绕时序路径做局部优化。签核阶段更是要逐条路径地刨根问底，把所有潜在违例都排查干净。所以无论你是做数字前端、后端、还是定制电路，最终都绕不开时序路径分析这一关。

这篇内容适合的读者面比较宽：在校学生准备数字IC求职面试，工程师刚接触STA想快速建立体系化认知，或者做FPGA开发想理解工具时序报告里那些数字到底怎么算出来的。我会把时序路径分析的核心框架拆开来讲清楚，从寄存器的时序模型一路讲到违例定位的实操经验。

先建立一个基本认知：数字电路里的时序分析，不是拿电路仿真的波形去“看”时序，而是基于标准单元库里的时序模型，用数学方式把每条路径上的延迟累加起来做计算。这种基于延迟计算的分析方式，就是静态时序分析（STA，Static Timing Analysis）。动态仿真要跑几百万个向量的电路，静态时序分析靠一纸约束和一套时序模型就能在几分钟内覆盖全部路径，这也是为什么STA能成为大规模芯片时序签核的主力手段。

1.1 从一个“打拍子”的比喻讲起

想象一组人排队传递卡片，每个人接到卡片后，必须等一个固定的节拍器“嘀”一声，再把卡片传给下一个人。这个节拍器就是时钟，每个负责传递的人就是一个触发器（寄存器）。整个系统能不能稳定运关键看：卡片在节拍器响之前，是不是已经稳稳到了下一个人手里；以及在节拍器响完之后，卡片有没有被下一个人提前碰掉。

放到电路里，“卡片”就是数据信号，“节拍器”就是时钟沿。寄存器在时钟上升沿采样数据，如果数据在上升沿到来之前没有稳定到要求的值，采样结果就可能是一串不确定的毛刺；如果数据在上升沿过后还没稳定够一段时间就变了，同样会导致采样错误。前者对应建立时间（setup time），后者对应保持时间（hold time）。

这里有一个新手容易绕进去的误区：建立时间和保持时间不是“工具定出来的约束”，而是寄存器的物理属性。它们本质上反映了寄存器内部锁存结构对数据稳定窗口的要求。标准单元库里会给出每个触发器的建立时间和保持时间，STA工具把这些参数当作检查条件，去计算数据路径上的延迟是否满足要求。

1.2 数据路径延迟和时钟路径延迟是两个世界

分析一条时序路径时，最重要的一点是要把“数据路径延迟”和“时钟路径延迟”分开理解。

数据路径延迟，指信号从起点寄存器输出端（Q端），经过组合逻辑和互联线，一直到达终点寄存器输入端（D端）的总延迟。它由单元延迟（cell delay）和线延迟（net delay）组成，单元延迟受输入转换时间（slew）和输出负载（load capacitance）影响，线延迟则随工艺节点不同，占比越来越大。

时钟路径延迟，指时钟信号从时钟源出发，经过时钟树上的缓冲器、分频器、门控单元，分别到达起点寄存器和终点寄存器时钟端的延迟。注意，这里有两个终点：起点寄存器的时钟端和终点寄存器的时钟端。很多刚接触STA的人只盯着数据路径，忽略了时钟到达时间的差异，这是导致分析出错的高频原因。

一旦把这两部分拆开，时序计算就变得直观了：数据到达终点D端的时间，等于起点时钟沿的到达时间加上起点时钟到Q端的内部延迟（clock-to-q），再加上数据路径延迟。数据需要到达终点D端的时间，则由终点时钟沿的到达时间减去建立时间得到。两者相减，就是建立时间裕量（setup slack）。保持时间裕量的逻辑类似，但用的是数据相对于时钟沿之后保持的约束来算。

2. 芯片里到底有哪些时序路径

STA工具不会把所有逻辑门都拉在一起无差别计算，而是把电路切分成一条条有明确起点和终点的路径，再逐条检查。这种“切分”的合理性来自寄存器的隔离作用：寄存器在一个时钟沿采样数据，到下一个时钟沿再次采样之间，组合逻辑上的信号变化不会跨寄存器扩散。所以每条路径的起点和终点总是落在寄存器的时钟端、输入端、输出端，或者芯片的输入输出引脚上。

标准教科书把时序路径分成四类，实际工作中基本上也都是按这个框架来查违例的。

第一类，寄存器到寄存器路径（reg-to-reg）：起点是上游寄存器的时钟端，终点是下游寄存器的数据端。这是芯片内部最常见的路径，也是STA检查最严格的一类。

第二类，输入端口到寄存器路径（input-to-reg）：从芯片输入引脚开始，经过输入缓冲和组合逻辑，到达第一个寄存器的数据端。这条路径上多了输入引脚的到达时间约束，输入端口的信号什么时候到，是由片外芯片或者系统时序决定的。

第三类，寄存器到输出端口路径（reg-to-output）：从最后一个寄存器时钟端开始，经过组合逻辑到达输出引脚。输出信号什么时候被片外需要，由输出延迟约束来定义。

第四类，输入端口到输出端口路径（input-to-output）：纯组合逻辑直通路径，不经过任何寄存器。如果设计里有这样的路径，需要特别谨慎，因为它在时序上没有任何寄存器的隔离缓冲，任何输入变化都会直接体现在输出上，通常还要额外的IO时序约束来限制。

后端工程师关心得最多的是第一类，因为大部分核心逻辑都在reg-to-reg路径上，时钟树综合的主要优化对象也在这类路径上。

除了按端点分类，STA还会把路径按时钟关系进一步划分：同一时钟域的路径（同沿或者不同沿都能查）、跨时钟域的路径（两个异步时钟之间）、以及异步路径（例如经过异步复位或握手信号的路径）。同源时钟的路径分析最严格，因为起点和终点时钟之间的相位关系是确定的；跨时钟域路径如果同步逻辑设计不当，STA工具会报时序例外，需要设计者逐一确认是不是伪路径（false path）。

2.1 一条路径里藏了多少环节

从微观层面拆开一条reg-to-reg路径，能看到完整的数据流：起点寄存器的时钟端收到时钟沿；时钟沿触发起始寄存器输出更新；数据从Q端出来通过内部逻辑和互联传输；终点寄存器的数据端等到数据；终点寄存器的时钟端在同一周期（或者下一周期）收到时钟沿；终点寄存器检查数据是否满足建立和保持要求。

这里其实涉及两条时钟路径。起点寄存器的时钟到达时间和终点寄存器的时钟到达时间可能不一样，这个差异叫时钟偏斜（clock skew）。偏斜对建立时间和保持时间的影响方向是相反的：终点时钟晚到，对建立时间有利（给数据更多时间准备），但对保持时间不利（数据相对终点时钟沿来说更早消失）；终点时钟早到则刚好相反。

如果听上去有点像“跷跷板”，恭喜你已经抓住了时序分析的核心感觉。后端工程师修时序的时候，有很大一部分精力就是在和数据路径延迟、时钟偏斜以及各种不确定性做博弈。

2.2 为什么说约束是分析的前提

没有约束的STA相当于没有标尺的量测。做时序路径分析之前，必须先把设计的工作条件定义清楚，比如时钟频率、时钟波形、输入到达时间、输出要求时间、以及哪些路径不需要真实检查。

约束主要解决三件事：第一是定义时钟，告诉工具时钟端口在哪里、周期多大、占空比如何，以及时钟树上的插入延迟预期是多少；第二是定义IO时序，告诉工具信号从芯片引脚进来的时候相对时钟沿的到达时间和出去的时候相对时钟沿的要求时间；第三是定义时序例外，明确哪些路径不需要检查、可以使用宽松的周期。

这里必须多说一句：约束质量直接决定时序分析的准确性。约束过松，风险流片后才爆发；约束过严，后端工程师可能要死磕一些实际上不会有问题的路径，徒增功耗和面积。时序路径分析做得好不好，一半在工具，一半在约束。

3. 核心参数与计算逻辑拆解

很多工程师拿到时序报告，第一眼看到setup slack为负就开始紧张，但其实要真正看懂报告，得先把几个核心参数之间的关系理清楚。

3.1 建立时间路径计算：一段完整推导

以最典型的上升沿采样为例，建立时间检查需要验证：数据到达终点寄存器D端的时间，必须早于终点寄存器所需的采样时间到达点。

先说数据到达时间，也就是arrival time。它包含三部分：

• 时钟从时钟根节点到起点寄存器的时钟端延迟，记为launch clock path delay；
• 起点寄存器的内部延迟，即时钟有效沿到数据输出有效的延迟，记为clk-to-q delay；
• 从起点寄存器Q端到终点寄存器D端的组合逻辑和互联延迟。

用公式表达：数据到达时间 = launch clock path delay + clk-to-q + data path delay。

再说数据要求时间，也就是required time。建立时间检查用下一个时钟沿做参考（对于单周期路径）：要求时间 = capture clock path delay + 时钟周期 - 建立时间 - 时钟不确定性。

这里的时钟不确定性和时钟偏斜不一样。偏斜是实际时钟树造成的到达时间差，不确定性则是STA工具在计算时人为预留的余量，用来覆盖时钟抖动、时钟源延迟误差、以及片上偏差等因素。后端集成时钟树之前，偏斜的大小也是用不确定性的形式来约束的。

建立时间裕量 = 要求时间 - 到达时间。这个值大于0，表示时序有富余；小于0，表示建立时间违例。注意，人脑直观里“数据来得越早越好”，所以setup slack为正意味着数据到达比要求时间早一些，没有问题。

3.2 保持时间路径计算：容易被忽视的暗坑

保持时间检查的逻辑是：数据在终点寄存器时钟沿到来之后，还要稳定至少一个保持时间那么长。发送时钟沿和捕获时钟沿其实是同一个沿（对同周期检查保持时间时），所以计算时不需要单独加一个时钟周期。

数据到达时间 = launch clock path delay + clk-to-q + data path delay（这和上面一样）。但这一次，数据要求时间 = capture clock path delay + 保持时间 + 时钟不确定性。注意，保持时间的公式里没有时钟周期，而且时钟不确定性是加在要求时间里的，方向与建立时间相反，因为它让数据要求时间更晚，让保持检查更严格。

保持时间裕量 = 数据到达时间 - 数据要求时间。保持违例意味着数据消失得太早，即数据路径太短，很可能是因为寄存器之间只有极少的组合逻辑，甚至直接连在一起，数据在时钟沿之后很快就变化了。修保持时间的基本手法是插延迟，比如在路径上插入buffer或者增加负载。

我见过不少刚入行的工程师只盯着建立时间，忘记了保持时间检查的存在，结果在高速接口或者寄存器密集排布的设计里被hold违例打得措手不及。做时序路径分析，必须始终同时记住两条检查公式，一个看数据到得早不早，一个看数据走得晚不晚。

3.3 共同路径悲观消除（CPPR）与片上偏差

在先进工艺下，同一时钟源到达起点寄存器和终点寄存器的公共路径上，延迟偏差是相关的。如果STA工具按最悲观方式把各段延迟最大偏差直接叠加，会造成不必要的过度悲观。为此引入了共同路径悲观消除（CPPR，也叫CRPR）。工具在计算时会对比起点和终点时钟路径的公共部分，把这一段上的悲观偏差扣除掉。

这个细节看起来学术，实际后端工程中非常关键。一个小规模设计里CPPR生效可能只有几十皮秒，但在时钟树长、分支多的大芯片里，这个值动辄几百皮秒。工程师排查setup违例时，如果看到报告里CPPR contribution这一栏数值很大，需要重点核查时钟树结构是否合理，而不是急着去插buffer或者替换cell。因为此时真正的瓶颈可能在时钟偏斜和公共路径结构上。

OCV（片上偏差）也是一个绕不开的术语。简单说：同一块芯片上，不同位置的晶体管、互联线的延迟特性会有制造偏差，低温低压下某些路径更快，高温高压下某些路径更慢。STA工具通过设置derating因子来模拟这种偏差，在建立时间分析时把数据路径延迟放大、把时钟路径延迟缩小，让检查更悲观；在保持时间分析时则反过来。理解了OCV的悲观原则，就理解了很多signoff报告里为什么setup和hold同时存在“冗余”和“风险”。

4. 实操过程：从约束配置到报告解读

纸上谈兵讲公式永远不够，下面我用一套实际工作流来展示时序路径分析是怎么跑起来的。具体工具有很多，但思路是通用的，我以主流STA工具的操作习惯为参考。

4.1 约束准备：先给设计一把“尺子”

第一步是建立约束文件，也就是常说的SDC（Synopsys Design Constraints）。其中最基础的是时钟定义。用一条虚拟时钟或者真实时钟端口来创建时钟：

create_clock -name clk_core -period 2.000 [get_ports clk_in]

这段约束定义了core时钟周期2ns，也就是500MHz，时钟端口是clk_in。没有这个时钟定义，STA工具连最基本的路径检查都做不了。

紧接着要设置时钟的不确定性和转换时间约束：

set_clock_uncertainty -setup 0.050 [get_clocks clk_core] set_clock_uncertainty -hold 0.050 [get_clocks clk_core] set_clock_transition -rise 0.050 [get_clocks clk_core] set_clock_transition -fall 0.050 [get_clocks clk_core]

时钟不确定性的大小很有讲究。芯片设计早期，时钟树还没长出来，需要给0.2ns左右的偏斜预算；等时钟树综合完成后，这个值可以收紧到0.05ns甚至更低。如果从头到尾都用一个很悲观的不确定性，综合工具就会把大量面积浪费在冗余逻辑上。

输入输出约束也不能漏：

set_input_delay -clock clk_core -max 0.400 [get_ports data_in] set_output_delay -clock clk_core -max 0.300 [get_ports data_out]

input delay表示数据引脚相对于时钟沿晚到400ps，output delay则告诉工具输出引脚的数据需要在下一个时钟沿之前提前300ps到达。这些约束的来源是芯片规格或者系统级时序预算，不能随便拍脑袋填。填得太多，内部逻辑会无谓地快；填得太少，芯片在实际系统里可能跑不到目标频率。

4.2 用STA工具跑一次完整时序检查

约束齐了，接下来是工具流程。引用设计网表、约束库和工艺库之后，第一步通常做编译和时钟树传播前的初步检查；时钟树综合完成后，再用带真实时钟树延迟的网表做最终时序收敛检查。

跑时序分析的核心命令通常长这样：

set target_library [list typical.db worst.db best.db] read_verilog top_netlist.v link_design read_sdc top_constraints.sdc update_timing -full report_timing -from [get_pins u_reg_a/CK] -to [get_pins u_reg_b/D] -delay_type max -path full

关键点在report_timing这条命令：-delay_type max查建立时间，-delay_type min查保持时间。-path full表示要把时钟路径、数据路径完整展示出来。如果只看summarized路径，很多关键细节会被折叠掉，不利于排查问题。

4.3 怎么读一条具体的时序报告

下面我用一个典型setup路径报告来演示读法。真实工具输出格式各有不同，但核心指标是一致的：

Startpoint: u_reg_a (rising edge-triggered flip-flop clocked by clk_core) Endpoint: u_reg_b (rising edge-triggered flip-flop clocked by clk_core) Check: setup Path Group: clk_core Path Type: max Clock Clock arrival time required time slack clk_core 1.200 2.035 0.835

先看arrival time和required time两个数。arrival time是数据到达终点D端的时间，内部细分为launch clock路径延迟、clk-to-q、组合逻辑延迟等；required time是捕获时钟路径延迟加时钟周期减建立时间减不确定性的结果。如果slack为正，说明有富余；如果slack为负，就要往上看各分段的贡献，找出延迟最大的逻辑级。

一般来说，一个setup违例的路径上，数据路径延迟和逻辑级数是最先要查的。如果看到一条路径横跨了十几级组合逻辑，且每级延迟都不小，那修起来的主要方向就是削减逻辑深度，而不是去调时钟偏斜。反过来，如果逻辑级数不多但slack很紧张，就要分析是不是线延迟太大、单元驱动强度不够，或者是clock skew和CPPR的贡献占比过高。

工具还提供按端点分组的汇总报告：

report_timing -group clk_core

这个报告能快速列出当前设计里用户关心的时序分组里，最差路径对应的端点都是哪些。工程师拿到这份列表后，一般会按违例严重程度从高到低逐个分析，先问三个问题：这条路径的逻辑级数是否合理？这条路径的布局是否跨了过大的物理距离？这条路径是不是虚假的时序例外没设对？

5. 常见问题与排查技巧实录

5.1 最典型的误判场景

“我发现setup违例，立刻换了一堆高驱动cell，结果failure反而更严重了。”这个问题我听过很多次。高驱动cell本身延迟确实变小了，但它的输入电容变大，连带加重了上一级cell的输出负载，上一级延迟升高。这是一组连锁反应，不能只看局部。正确做法是先看完整路径每一级的延迟分布，定位真正“卡脖子”的那一两级，再决定是换cell还是调整逻辑结构。

另一个高频场景是：报告显示hold check出现了大量违例，但数据路径明明很长。这时候要警惕是不是时钟偏斜造成的。如果终点寄存器时钟比起点寄存器早到非常多，即使数据路径整体延迟不短，保持时间也可能会违例。修保持时间时不能盲目往数据路径上插buffer，把握不准的时候先看时钟树结构，优先把局部偏斜降下来。

5.2 时序违例修复思路的优先级

后端修时序有一套不成文的优先级：

• 第一优先，检查约束和时序例外是否合理。时钟定义错了、误设了false path、或者把异步信号当成同步路径查了，会出现假违例。假违例修得越多越错。
• 第二优先，检查物理实现是否合理。模块距离太长、布局拥塞严重、单元堆叠混乱，线延迟会失控。
• 第三优先，优化逻辑结构。综合时插入流水级、并行化逻辑、重定时逻辑，从根源上削减路径延迟。
• 第四优先，做单元和线网层面的微调：换VT等级、增大驱动、调整buffer位置、合理插入延迟单元修hold。

很多跨时钟域信号同时报了setup和hold违例，但真实场景下这类路径往往根本不需要检查。我遇到过一个项目，某个IP的异步接口信号没有在马鞍约束中正确声明为false path，导致后端工程师花了一整周去修“假违例”，修到最狠的时候把这条路径的寄存器都搬了一遍，后来发现是约束漏了一个set_false_path。这个教训让我养成了习惯：先看约束，再谈修时序。

5.3 排查工具之外的工具

除了STA工具，有四类手段我建议流程中一定要配合用：形式化验证工具确认约束与网表功能一致性；功耗分析工具确认修时序时增加的buffer没有引发过度功耗；EM/IR压降工具确认高压降区域没有加剧时序迕例；以及最朴素的逻辑图解分析——把关键路径高亮在版图上，直观看到路径绕了多远、跨了几次sink扩散区。

这些工具配合下来，基本可以区分“真违例”和“仿真噪声”。没有项目能保证第一次迭代就全绿，但有了体系化的排查流程，每一次迭代的效率会显著不一样。

5.4 实测下来有用的三个细节

第一个细节，修hold的时候不要一根路径一根路径去插buffer。工具支持auto hold fixing，它会自动批量插入延迟单元。但前提是约束里定义了合理的hold uncertainty和clock uncertainty，否则工具会留下潜在风险或者修得过狠。

第二个细节，分析时序报告时，眼睛不要只盯着负slack的路径，还要看near-critical路径，也就是slack小但还为正的路径。这类路径在工艺偏差、电压波动下有可能会在signoff阶段变成违例。前后端项目里我习惯把slack小于0.05ns的路径全部拉出来“过一遍脑子”，防止迭代后出现新的违例山头。

第三个细节，关于报告里delay breakdown中net delay占比。如果发现某条高频路径上线延迟占了总延迟的60%以上，光换cell基本无解，大概率需要回到布局阶段做局部floorplan优化。把关键单元摆近一点，线网短了，延迟自然降下来，这种改善是换cell给不了的。

5.5 常见问题速查表

6. 时序路径分析的工程化经验

最后想聊聊工程层面的体会。时序路径分析看着是一个技术动作，但真正做好它需要的是系统思维。它不仅仅是一个工具脚本、一份约束、一次性报告，而是设计流程里不断循环、不断收敛的闭环。

我在实际项目中用过一个笨但有效的办法：把一个模块里所有关键路径（critical path）导出来，手工在版图上画一遍走向。画多了，会逐渐建立一种直觉——什么样的布局会产生什么样的延迟分布，哪些区域容易成为时序瓶颈，约束里哪条设置会让工具产生不合理的行为。这种直觉说不清道不明，但它在快速定位问题时比任何工具脚本都管用。

另外一条很现实的经验是：时序路径分析最好从项目的早期就开始介入，而不是等到后端实现结束再来看signoff报告。前端做架构设计的时候，如果没有做粗略的时序预算和路径评估，等到综合完之后才发现顶层模块间时序路径太长，只能被迫改架构或者降频，代价就大了。给后续留出做时序收敛的余量，比拿工具去死磕一条已经不太健康的路径要聪明得多。

修时序是一个没有最好只有更好的过程。你永远不会知道一条路径能不能再压掉几十皮秒，直到你尝试过换一种布局、换一组单元、甚至调整一条时钟树分支的位置。保持“所有参数都可以被质疑”的心态，会让你在这种极其冗长的收敛过程里不至于过早崩溃。

芯片时序路径分析（上）我们把路径分类、参数计算和STA实操主流程讲完了。后面的内容里，我会接着展开跨时钟域分析、时序例外处理的细节，以及如何在先进工艺节点下应对越来越复杂的时序收敛场景。