做过芯片后端的人都知道，时序路径分析是每天睁眼闭眼都绕不开的东西。无论是刚入门的新人，还是干了十年的老工程师，凡是流片前要签核（signoff）的项目，最后都会落到一条条时序路径上。这篇内容我打算分上下两篇来写，上篇先把基础打牢，讲清楚时序路径的分类、建立时间和保持时间的物理含义，以及后端分析里最常用的几个关键参数。下篇再展开时钟树综合、工艺角、片上误差等进阶话题。

这篇内容适合刚接触数字IC设计、在校做ASIC/FPGA项目、或者从嵌入式往芯片后端转行的同学参考。就算你现在只写MCU的C代码、只调LED驱动芯片，理解时序路径对后续调试也有帮助，比如SPI接口上不去频率、DDR读写不稳、时钟偶尔丢一拍，本质上都是时序裕量不足。

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

1.1 时序问题的本质是“数据在规定时间内能不能安全传送”

芯片内部所有逻辑单元都不是独立工作的。一个触发器（Flip-Flop）在时钟上升沿抓取数据，下一个触发器在下一个时钟沿抓取数据，中间这段路径上，数据要穿越组合逻辑门、走线、缓冲器。时序路径分析，就是回答一个问题：数据从源触发器出发，经过中间的所有电路，到达目的触发器时，它的到达时刻是否落在目的触发器允许的窗口内。窗口有两个边界，一个是建立时间要求的数据最晚到达时刻，一个是保持时间要求的数据最早离开时刻。

生活里打个比方就很好理解：这有点像赶高铁。发车前5分钟停止检票，是“建立时间”；开车后你必须已经坐在座位上，是“保持时间”。数据（乘客）如果到得太晚，连检票口都过不去；数据如果换得太快，前一班车还没启动就跳车了，同样出问题。芯片里时序违例（violation），绝大多数就是这两类。

1.2 为什么不用仿真而用静态时序分析

很多刚接触的人会问：不是有功能仿真和门级仿真吗？跑一遍波形不就知道时序对不对了？这就是时序分析领域最经典的误解。

功能仿真用的是理想时钟，或者说时钟沿是瞬时的、对齐的，而且仿真向量只能覆盖你写的那些激励。芯片里寄存器可能有几十万个，组合逻辑路径更是呈指数级膨胀，芯片测试行业在ATE上跑的向量再多，也不可能覆盖所有时序路径。而静态时序分析（STA）不需要输入激励，它把芯片内部的时序路径全部计算一遍，用最差工艺、最低电压、最高温度的“最差条件”去评估每条路径能否满足时序。这种“静态”的意思是输入信号波形是理想化的，只算延迟，不算逻辑功能。

我实际经历过的某个模拟项目，门级仿真跑一万个随机激励都要整整一天，而STA对于同样的设计十几分钟就把所有路径过了一遍。更关键的是，仿真发现不了的隐藏问题，STA能翻出来。所以现在后端signoff流程里，STA的地位几乎等同于法律条文，是流片前必须过的关卡。

1.3 时序路径分析在芯片后端流程中的位置

时序路径分析不是某一步的事情，它贯穿整个数字后端流程。

逻辑综合阶段，工具用线负载模型预估延迟，检查有没有明显时序问题；布局阶段，寄存器放得太远会导致线延迟过大；时钟树综合阶段，要决定时钟怎么到达每个寄存器；布线后期，要实际提取寄生参数，反标到net上重新计算延迟，这就是最精准的signoff时序分析。

我见过很多团队在综合阶段图快把优化力度开得很大，结果布局布线后时序遍地开花，因为综合阶段对布线延迟的预估过于乐观。正确做法是每走完一个大步骤就做一次STA检查，发现问题尽早回改，不要拖到最后。

2. 四种基本时序路径：把整颗芯片拆成可管理的单元

一条时序路径，从起点到终点，在STA工具里被划分为四种基本类型。搞清楚这四类，你看任何时序报告都不会懵。

2.1 寄存器到寄存器路径（reg-to-reg）

这是后端工程师最常面对的路径。起点是源触发器的时钟端，终点是目的触发器的数据输入端。数据在一个时钟沿被源寄存器锁存，经过内部Q端延迟、组合逻辑延迟、线延迟，最终在下一个时钟沿前到达目的寄存器。

数据从源寄存器到目的寄存器的传输周期通常是一个时钟，所以最重要的检查就是“路径总延迟 < 时钟周期”。如果检查不满足，叫建立时间违例。这种路径不需要考虑外部输入输出的时序环境，只需要芯片内部标准单元的延迟库（.lib）和net寄生参数。

实际做STA时，reg-to-reg路径的数量占全部路径的99%以上。芯片内部绝大多数逻辑，都是这种“寄存器吃数据、组合逻辑算数据、寄存器再吃”的流水结构。对reg-to-reg路径优化，手段通常是插缓冲器、调整逻辑级数、调寄存器位置。

2.2 输入端到寄存器路径（input-to-reg）

这种路径的起点是芯片的输入引脚，终点是内部某个触发器的数据输入。换句话说，数据从芯片外部进入，经过IO pad、ESD保护电路、组合逻辑，在内部寄存器被采样。

这条路径的难点在于外部信号是芯片自己不能控制的，它什么时候变化、延迟多大，取决于上游芯片或系统的接口时序。所以STA工具要求设计者用输入延迟约束（set_input_delay）告诉工具：信号相对于时钟沿，最晚/最早什么时候到。

之前在调一块接口芯片时，本端寄存器始终抓不到稳定的数据，后面查出是上游芯片输出到数据线的延迟被低估了。这类教训很常见。外部世界不会等你的时钟，只会按它自己的节奏发数据，所以input-to-reg路径分析，约束的准确性直接决定分析结果的可靠性。

2.3 寄存器到输出端路径（reg-to-output）

源是寄存器，终点是芯片的输出引脚。数据从寄存器Q端出发，经过组合逻辑和输出IO，最后离开芯片，被下游芯片采样。

检查这条路径时，要考虑片外负载。输出引脚还要驱动外部电容，这部分延迟由set_load约束决定。很多芯片输出上升沿偏慢、信号质量差，就是因为输出级驱动能力不足，而STA里表现为reg-to-output路径延迟过大。

如果你在写FPGA或MCU外设，肯定见过GPIO输出翻转速度太慢的问题，本质上就是这条路径的延迟控制。芯片内部主动，片外被动，但外部负载是你必须认账的。

2.4 输入端到输出端路径（input-to-output）

起点是输入引脚，终点是输出引脚，它是一条完全的组合逻辑路径，中间没有任何寄存器。这种路径也常被叫作“穿通路径”（combinational path），数据从外部进入，经过逻辑电路，直接从另一个引脚出去。

对这条路径，没有时钟沿采样，所以它只受外部时序环境的约束。工具检查的重点是延迟是否满足外部的set_input_delay和set_output_delay。很多接口协议里，只要求组合逻辑延迟在一个区间内，比如地址译码、按键消抖电路、模拟开关控制，这类路径在纯数字芯片里不算多，但在数模混合芯片或者带IO复用功能的芯片里很常见。

下表把这四种路径的核心特征放在一起，方便对照记忆：

3. 建立时间与保持时间：芯片逻辑的“生死线”

STA工具判断路径是否违例，靠的是两个时间参数。它们都是触发器本身的物理特性，由制造工艺决定，写在标准单元库里。

3.1 建立时间：采到的数据必须“先到一步”

在时钟上升沿到来之前，数据输入必须在触发器的数据引脚上保持稳定一段最短时间，这个最短时间就是建立时间，记作Tsetup。为什么会需要这段时间？触发器内部有一个采样环路，它需要时间把输入电平传送到内部锁存节点，时钟沿到来时才能正确判定当前电平是0还是1。如果数据到得太晚，内部节点还没稳定，输出的值可能就是亚稳态——既不像0也不像1，可能要过很长时间才真正落到某个值，后面所有逻辑都会因此出错。

用我们赶高铁的例子：建立时间就是检票口的关闸时间，数据至少提前这个量到达。设计上，建立时间的余量可以这样理解：数据到达时间如果比要求的最晚时间晚，哪怕晚了一点点，这条路径就建立时间违例，芯片在实际工作温度或电压稍差时可能出问题。

建立时间违例解决方法很直观：要么让信号走得更快（减少组合逻辑级数、调整布局），要么让时钟来得更晚（但时钟树不能随意动），要么降频。芯片后端大部分时间都在折腾这三件事。

3.2 保持时间：数据不能“闪了就跑”

时钟沿到来之后，数据输入还必须继续保持稳定一段最短时间，这个最短时间就是保持时间，记作Thold。原理上，时钟沿打断触发器的采样窗口，输入信号在沿后如果立刻翻转，内部环路可能还没锁住旧值就已经收到新值，结果就会把两个值混合起来输出。

保持时间发生在同一个时钟沿上，它不关心时钟周期多长，只看时钟沿附近数据有没有变化。因此保持时间检查通常不是靠降频解决的，降频对保持时间一点帮助都没有。真正能解决的办法是让路径上加延迟，比如在数据路径上插入延迟缓冲器，让数据更晚到达，或者对时钟树做特殊处理。

我做过的某个低功耗项目里，芯片在不同电压域之间做电源门控，唤醒瞬间有些寄存器数据错乱，最后发现是唤醒路径上某几个触发器保持时间裕量不足，时钟先到、数据后到，结果采到了上一个状态的值。这种问题在快速翻转的低功耗模块中非常容易爆发。

3.3 时序裕量计算：正slack和负slack到底意味着什么

有了建立时间和保持时间的概念，就可以看STA报告里最核心的数字：时序裕量，常被称为Slack。

建立时间检查的裕量公式长期被各种资料写成不同形式，但核心意思都一样。它关心的是：数据到达目的寄存器的时间，比“时钟到达时间 + Tsetup”是早还是晚。如果数据到达时间早于最晚允许时间，余下的差额就是正的建立时间裕量；如果晚于，裕量就是负值，就是建立时间违例。

保持时间检查的裕量则是：数据到达目的寄存器的时间，比“时钟到达时间 + Thold”是早还是晚。保持时间要求数据不能太早到达，在时钟沿之后至少要稳定Thold这么久。所以数据到达越晚，保持时间裕量越好；数据到达越早，保持时间裕量越差。

正slack代表路径还有余量，但要记住它不能太小，长期工作温度漂移、老化、电压纹波都会吃掉一部分余量。负slack则意味着芯片在当前约束下必然时序违规，流程上通常是不给流片的。

另外还要提醒一个新的常见误区：有些工具报告的slack单位是纳秒，有些是皮秒，看报告前先弄清单位。我见过有人把-0.05的slack看成是5ps的违例，其实是50ps，完全不同的处理思路。

4. 时钟不是一根直线：偏斜与延迟组成的物理现实

很多在小芯片上做嵌入式的人，比如用STM32或ESP32调外设时，很难理解为什么芯片后端要把时钟树单独拿出来讲。原因是，真实芯片里的时钟信号是经过很多级缓冲器才到达每个寄存器的，每一条时钟路径的长度、驱动、负载都不完全相同，所以时钟到达每个寄存器的时间并不一致。

4.1 时钟偏斜：为什么两颗寄存器“看”到的时钟不一样

同一个时钟源，到达寄存器A的时间是t1，到达寄存器B的时间是t2，它们之间的差值就是时钟偏斜（clock skew）。如果把数据从A穿到B，时钟先到B、后到A，B采到的数据是上一拍的，建立时间裕量增加，保持时间裕量减少；反过来，时钟先到A、后到B，B就有更长的等待时间来采新数据，建立时间裕量减少，保持时间裕量增加。

既然skew会改变时序裕量，能不能故意把skew做成“有利”方向来解决时序问题？思路可行，但实际操作中非常危险。时钟树不平衡会导致功能逻辑对工作条件敏感，某颗芯片在这个温度正常、下一颗在那个电压下就崩，而且这种问题极难定位。我参与过的项目里，有过一次为了救一条关键路径的建立时间，把时钟偏斜往一个方向推了几十ps，结果强势地牺牲了另一条保持时间路径，最后在测试机台上爆出随机读写错误，又花了两周改回来。所以规范做法永远是让skew尽量小，靠数据路径本身解决问题。

4.2 发射路径、捕获路径与数据路径的延迟构成

从STA的角度拆解一条reg-to-reg路径，纵向看有三个延迟段。

第一段是发射时钟路径延迟（launch clock latency）：时钟从源头到源寄存器时钟端的延迟。第二段是数据路径延迟（data path delay）：源寄存器内部时钟端到数据输出Q的延迟，加上组合逻辑延迟和线延迟。第三段是捕获时钟路径延迟（capture clock latency）：时钟从源头到目的寄存器时钟端的延迟，再考虑目的寄存器的建立时间要求。

因此，建立时间检查关心的等式就是：发射时钟延迟+数据路径延迟，要早于捕获时钟延迟 - 建立时间。这个式子理解透了，你会明白为什么后端流程把时钟树放在布局之后、布线之前来做——因为时钟延迟本身也是需要被控制的对象。

4.3 工艺角对时序分析的影响

芯片制造是一个物理过程，工艺偏差、电压波动、温度漂移是常态。同样的路径，同一片晶圆上不同位置的晶体管快慢都不同。STA分析不能只看一个条件，而要在多个工艺角（corner）下分别检查。

典型场景有几种：慢工艺、低电压、高温下，晶体管驱动变慢、线延迟变大，建立时间最容易违例，这就是setup分析的主要条件；快工艺、高电压、低温下，晶体管翻转很快，数据到达过早，保持时间最容易违例，对应hold分析。

我在做好几个节点的项目时，signoff通常要跑三个以上的corner。每个corner下每条路径重新计算延迟，再交叉检查setup和hold。不要觉得麻烦，多一个corner多一份安心。很多返工就是因为只检查了典型条件，结果低温快角下hold崩了。

这里顺便说一句，SST、RAM、IO这类单元因为翻转特性不同，延迟对电压和温度的反应跟普通逻辑单元还不太一样，所以做STA时千万不能把一个库的corner映射想当然地套到另一类单元上。这是容易翻车的地方。

5. 一份SDC约束和一张报告：实操阶段的三个起步手段

前面讲了原理，现在落到实操。刚接触STA的人，面对工具界面和一堆文件会手足无措。这里我分享一套相对稳妥的起步顺序，也是我当时摸索了很久才总结出来的。

5.1 先读懂SDC约束里的时钟定义

时序路径的起点，就是时钟约束。SDC文件里最常见的两行代码是：

create_clock -period 10.000 -name clk [get_ports clk] set_clock_uncertainty 0.200 [get_clocks clk]

第一行定义了一个周期为10ns、名字叫clk的时钟端口。第二行设置了时钟不确定性（uncertainty），你可以把它理解为时钟本身抖动、PLL输出波动、片上差异等各种非理想因素的余量。这200ps不是白给的，实际做signoff时还要根据时钟源特性换算。

很多新手看到代码套进去跑完，slack也过了，但忘了检查时钟是不是被工具自动识别为理想时钟，结果后面对不上。建议拿到工程第一步，先看时钟树综合报告，确认每个时钟都定义正确、没有悬空的端点。

5.2 看时序报告的五个关键字段

STA报告格式各工具略有不同，核心字段是一致的。我通常按下面顺序依次看：

• Path Group：代表这条路径属于哪个时钟域或哪个约束组，多时钟设计要先分清楚。
• Path Type：标记是max（setup）还是min（hold）检查。
• Incr：每一段的增量延迟，这是定位瓶颈在哪里的关键，看是线延迟大还是逻辑延迟大。
• Path Delay：累计延迟，也是这条路径从头到尾的总延迟。
• Required Time：目的端允许的最晚到达时间，与Arrival Time做差就是slack。

举例说什么叫在线延迟大。某条路径slack是-0.3ns，看报告发现有一段的线延迟占了总延迟的70%，明显是布局阶段两个寄存器离太远，或者中间经过了一个拥塞的布线区域。这种问题靠逻辑优化解决不了，必须回布局阶段挪位置。

5.3 一个典型的建立时间违例定位过程

举个我处理过的简化案例。有一个模块，时钟频率要求200MHz，也就是周期5ns。综合后STA报告显示某条关键路径建立时间违例0.15ns。看Incr各段，发现组合逻辑延迟是3.2ns，数据路径中有一个三输入与门和一个多路选择器级联，逻辑级数高达11级，每级约有0.25ns延迟。另一条路径只有7级，延迟2.1ns。

问题就很清楚了：这条路径的寄存器被布局工具放到了角落，导致布线很长，而且逻辑门逻辑级数偏多。处理方式不是硬插缓冲器（那只会增加延迟），而是调整这两个寄存器的相对位置，把路径缩短；同时把级联逻辑重新综合，优化掉冗余的与门。改完之后延迟降到2.5ns，slack转正0.35ns，整个过程三天完成。

5.4 上篇小结：现在你应该掌握的框架性认识

做时序路径分析，千万不要上来就对着工具乱点。先把四个路径类型刻在脑子里，再理解建立时间和保持时间的不同本质，最后知道偏斜和延迟是怎么影响裕量的。这样无论你拿到什么报告，都能定位到问题到底出在数据路径、时钟路径还是约束本身。

这部分内容我写得比较基础，因为时序路径分析的书再厚，真正的功夫还是在动手跑case、不断对报告的过程中打磨出来的。下一篇我计划写时钟树综合的实践细节、多时钟域同步路径的处理，以及保持时间违例在布局布线后的常见修复手段。如果你在自己的芯片项目里遇到类似问题，欢迎对照这篇内容的思路去排查。我个人还有个小习惯：每次修完一条路径都会在报告里顺手记一笔“为什么这么改”，等回看时这些记录比任何文档都有用。