1. 时序路径分析到底在解决什么问题

芯片设计到了后端阶段，所有人嘴里都在念叨“时序收敛”“时序违例”“关键路径”。我第一次接触静态时序分析（STA，Static Timing Analysis）的时候，看了几天文档还是一头雾水。后来是某位前辈一句话点醒了我：时序路径分析，本质上是在回答一个问题——数据从一个触发器出发，经过组合逻辑，到达另一个触发器的时候，到底来不来得及？所有的工具、约束、报告，都是围绕这一个问题展开的。

数字芯片里的逻辑电路，靠时钟这个“节拍器”驱动。每个触发器（寄存器）在时钟沿到来时，采样输入端的电平，把数据锁存进去。假设有两个触发器，前一个叫作“发起端”，后一个叫作“捕获端”，数据在这两个触发器之间的传递路径就叫一条“时序路径”。如果数据在捕获端应该被采样的那个时钟沿到来之前到达，并且在时钟沿之后还能保持足够长的时间不乱变，那这条路径就能正常工作；如果数据太晚到了，或者太早变了，结果就是采样到错误数据。前者叫建立时间违例（setup violation），后者叫保持时间违例（hold violation）。

时序路径分析就是把这些路径一条条拉出来，用工具精确计算数据在每一段的延迟，然后跟捕获端触发器的建立时间、保持时间要求做比较，看有没有裕量（slack）。裕量为正，说明路径有余量；裕量为负，说明路径已经“来不及”了，芯片再往下走就是废片。

这项工作在芯片里覆盖面极广。寄存器到寄存器（reg2reg）只是最常见的一类，还有输入端口到寄存器（input2reg）、寄存器到输出端口（reg2output）、输入到输出直通（input2output）等。每一类路径的约束方法不一样，分析的侧重点也不一样。上篇我先把同步逻辑里最核心的建立时间和保持时间讲透，再把约束文件怎么组织、时序报告怎么看、关键路径怎么优化一轮聊完，跨时钟域、时序例外这些内容留在下篇展开。

这篇内容适合刚入行的后端工程师、数字前端工程师，也适合在读研究生第一次接触STA工具时快速建立起全局观。不需要你已经会跑工具，只要懂点数字电路基础，就能跟上节奏。

2. 约束文件是时序分析的“出发点”

时序分析不是芯片里有什么逻辑就分析什么，而是先告诉工具一套“规矩”——时钟长什么样、哪个信号从外面多久进来、哪个信号要多久出去——工具才能基于这些规矩去算路径。这套规矩就是约束文件，业内最常用的格式是SDC（Synopsys Design Constraints）。

2.1 时钟约束：所有路径的时间基准

时钟是时序分析的绝对基准，约束不准确，后面一切计算都是空中楼阁。最基本的时钟约束是下面这两个：

create_clock -name clk -period 10.0 [get_ports clk_in] set_clock_uncertainty -setup 0.2 [get_clocks clk]

create_clock定义了一个名字叫clk的时钟，周期10纳秒，对应100MHz频率，加在端口clk_in上。这条约束等于是告诉工具：所有这个时钟域下的路径，必须在10纳秒的周期内完成“出发→传输→采样”的整个流程。

set_clock_uncertainty算是给分析留的安全余量。实际芯片里时钟沿到达每个触发器的时间点不会绝对整齐，还存在抖动和偏差，所以分析时把要求收紧0.2纳秒，相当于给自己多留了一点缓冲。别小看这0.2，在7nm工艺下，这0.2可能就决定了一条路径能不能收敛。

如果芯片里还有分频时钟，比如从100MHz时钟分频出50MHz的时钟，你得用create_generated_clock把它约束清楚，并且指定它跟源时钟的关系，是几分频、是同相还是反相。很多刚入行的同学在这里翻车，生成的时钟没有正确约束，工具不知道它是父时钟分频出来的，直接把分频点当成了另一条独立的时钟路径，结果全片时序乱套，报告里冒出一堆莫名其妙的违例。

2.2 输入输出延迟：把芯片放到系统里看

一个芯片不是孤立的，它有输入引脚和输出引脚。芯片外部还有别的器件在驱动它、被它驱动，这些器件的时序信息我们看不到，必须通过约束告诉工具。

set_input_delay -max 3.0 -clock clk [get_ports data_in] set_output_delay -max 2.5 -clock clk [get_ports data_out]

set_input_delay说的是：外部数据相对于clk时钟沿已经过了3纳秒才到达芯片引脚，那么芯片内部从引脚到第一个触发器的组合逻辑，剩下的时间就只剩下10 - 3 = 7纳秒（还没考虑不确定性）。set_output_delay意思则相反：芯片输出数据到了引脚后，外面器件采样还需要2.5纳秒的裕量，所以从芯片内最后一个触发器到输出引脚的路径，最多只能用10 - 2.5纳秒。

实际项目里，输入输出延迟的上限和下限都要约束。-max用于算建立时间，-min用于算保持时间。外部器件的时序手册拿过来，数据手册里写的Tco、Tsu、Thd，换算成set_input_delay和set_output_delay，别看它繁琐，这里的误差会直接传导到最终分析结果里。我在实际项目中见过因为输入延迟少算了0.5纳秒，导致某条pin到reg路径的setup违例反复修不掉，最后发现是当初外部器件的时序参数看漏了一行。

2.3 约束不是约束得越紧越安全

有一种误区，觉得约束越紧，芯片越“稳”。实际上不是这么回事。约束紧确实让工具在布局布线时更激进地优化时序，但代价是面积增大、功耗升高、绕线资源紧张，甚至会出现局部区域拥塞。更麻烦的是，约束不合理会让工具把大量资源投入到一条根本没意义的路径上，真正的关键路径反而被冷落了。

我参与过某个项目，某条路径实际上是一个异步信号，设计人员没有把它声明成set_false_path，导致工具把它当成同步路径死命优化，反复优化不过，还牵连了周围一片逻辑的布线。后来加上约束，违例直接清零。所以约束文件要有“一句话一个依据”，每条约束都要能说出来龙去脉，不然后面排查就像大海捞针。

3. 建立时间与保持时间：两条不可碰的红线

数据在两个触发器之间传递，要同时满足两个条件：建立时间要求数据在采样沿之前稳定到达；保持时间要求数据在采样沿之后还能继续稳定一段时间。这两个要求来源于触发器本身的物理特性，跟工艺直接相关。

3.1 建立时间：数据必须“早到”

建立时间违例是时序分析里最经典的问题。你去看时序报告，setup相关的内容占了一大半。一条典型路径的建立时间检查，用下面这个式子概括：

数据到达时间= 发起时钟沿到达发起触发器的时间 + 发起触发器内部延迟(Tco) + 组合逻辑延迟 + 走线延迟

数据需求时间= 捕获时钟沿到达捕获触发器的时间 – 建立时间(Tsu)

计算裕量：

setup slack= 数据需求时间 – 数据到达时间

这个式子看着简单，但有个隐藏概念：从同一时刻出发，发起路径上的时钟沿和捕获路径上的时钟沿，因为时钟树的原因，到达两个触发器的时刻可能不一样。实际计算中，工具会分别算出两个时钟沿的“到达时间”，这里就引入了**时钟偏斜（clock skew）**的概念。

举个例子，时钟周期10纳秒，发起触发器的时钟沿到达时间是0.5纳秒，Tco是0.4纳秒，组合逻辑+走线延迟是6.8纳秒，那么数据到达时间就是0.5+0.4+6.8=7.7纳秒；捕获触发器的时钟沿到达时间是1.2纳秒，建立时间是0.2纳秒，那么数据需求时间就是1.2-0.2=1.0…等等，这里必须注意：这个1.0纳秒要理解成相对时间。因为捕获沿是下一个周期的事件，实际数据需求时间是10+1.2-0.2=11.0纳秒。于是setup slack = 11.0 - 7.7 = 3.3纳秒，正裕量，路径满足建立时间。

如果组合逻辑延迟从6.8增加到9.9，setup slack就变成负数了。工具报告里看到的那样，slack为负的就是违例路径。

3.2 保持时间：数据不能“早变”

保持时间违例很多人到了后端才真正理解，它在物理上特别反直觉。保持时间检查的是采样沿过后，数据不能立刻变化。它的公式也很清爽：

数据保持时间= 数据到达时间（相对于采样沿）

数据需求保持时间= 捕获时钟沿到达时间 + 保持时间要求(Thd)

hold slack= 数据到达时间 – 数据需求时间

注意这里的数据到达时间是同一条路径的同一个沿计算出来的，不像setup那样经历了完整周期。也就是说，保持时间关注的是“采样沿之后数据还能撑多久”。数据延迟太小，反而会破坏保持时间。

所以修保持时间违例的思路，和建立时间完全相反：建立时间不够，要缩短路径延迟；保持时间不够，要增加路径延迟。怎么加？常见做法就是往路径上插入缓冲器（buffer），让数据晚一点到达。你看后端工程师在时序收敛阶段，经常一个缓冲器一个缓冲器地插，就是在修hold。

但这里有个很折磨人的矛盾：你插入缓冲器修hold违例，数据到达时间变晚，setup裕量就会下降。每条路径既查setup又查hold，你改完hold发现setup又红了，改回去setup好了hold又崩了，这就是时序工程师日常的拉锯战。真实的工程里，修hold通常是在setup收敛之后统一做的，而且优先在时钟偏斜小的地方插buffer，尽量降低对setup的影响。

3.3 时钟偏斜：一把双刃剑

时钟偏斜对setup和hold的影响方向是反的。如果捕获时钟沿比发起时钟沿晚到（正向偏斜），捕获时钟给了数据更多时间，setup裕量变大，但采样沿过后捕获时钟还没到，hold检查变得更严格，很容易hold违例。如果捕获时钟沿比发起时钟早到（负向偏斜），则刚好相反。

这也是为什么时钟树综合（CTS）阶段要求在触发器之间做平衡，不是“大家同一时刻收到时钟”，而是“每个收发对的时钟偏斜在允许范围内”。做CTS的工程师有一阵最怕的就是clock skew过大的路由，动不动就要手动插延迟单元去调整。一个经验法则是：在300MHz以上的设计中，时钟偏斜超过周期的3%就要引起警觉；超过5%基本就是违例的元凶了。

4. 关键路径的定位：学会读时序报告

工具跑完时序分析，会输出一份文本报告。很多人拿到几千行的报告不知道从哪看起。实际上，一条路径的报告就一页多，核心信息就那几个字段。

4.1 一条时序报告的解剖

拿一条setup检查报告为例，结构大致是这样：

• 顶部写明检查类型是setup，时钟是哪个，起点单元是哪个，终点单元是哪个。这两行信息最重要，你要第一时间知道是“谁到谁”的路径出了事。
• 然后一大段按时间正序列出的数据到达路径，从发起时钟沿开始，一层层经过各单元，每一步都标注了单元类型、引脚、延迟值。这一串就是数据“跑”过的路线。
• 接着是数据需求时间，会列出捕获时钟沿和相关约束。
• 最后算出slack值。

看报告有个技巧：不要从第一行读到最后一行的延迟累加，而是先确认路径类型。如果是输入引脚到寄存器，你要去看输入延迟约束和引脚到寄存器的组合逻辑，到底哪个占了大头；如果是寄存器到寄存器，那重点找组合逻辑级数最深的那一段。工具报告里每一行延迟值，把数据到达路径上的延迟一列列加起来，那些延迟数值特别均匀的，往往说明逻辑级数太长；那些某一跳特别大的，说明是走线绕远了。

我处理过一个典型的reg2reg setup违例，报告里其他单元的延迟都在30~50皮秒之间，唯独某一层走线延迟报了0.8纳秒。查到最后是布局阶段某条线跨了半个芯片的宽度，导致数据绕了大远路。走线延迟占比过高，很多时候是布局拥塞或者逻辑摆放位置不合理的信号。

4.2 优化关键路径的常用手段

一旦锁定了关键路径，优化策略按代价从低到高排列大概有这几种：

第一种是调整逻辑结构。看RTL代码里是不是出现了过深的组合逻辑链。比如一个路径上串了六七个逻辑门，能不能通过提前计算、重用中间结果等方式把链拆短。这种方法面积几乎不增加、功耗影响也很小，是最理想的手段。但问题是你通常不能随意动RTL，因为功能可能已经冻结了。

第二种是工具层面的逻辑优化。在综合和布局阶段，用optimize_design这类命令调整优化策略，或者给工具设置更高的优化等级。这种方法不需要动前端代码，能改善10%~20%的性能，但越到后段效果越有限，因为工具能优化的空间其实在综合阶段就被决定了。

第三种是寄存器重定时（retiming）。把组合逻辑的延迟分布重新调整，把部分逻辑从某级寄存器前搬到后，或者反过来，不影响总体功能，但能降低某条路径的延迟。这个方法效果好，但需要工具支持，而且可能会改变可观测性，对后端的验证压力也有影响。

第四种是时钟偏斜调整。在允许范围内故意让捕获时钟晚到一点，变相给数据多争取时间。这是后端时序工程师最后的“润滑剂”，但副作用就是hold条件变差了，往往需要配合插buffer来同时修hold。

实际操作中我个人的习惯是：先把所有setup违例路径按slack值排序，从最差的那条开始，先分析是逻辑深度问题还是走线问题。逻辑深度问题优先找RTL看能不能微调，走线问题优先看能不能通过布局疏散和pin assignment优化。优化完一条，重新跑一轮，看有没有新的路径冒出来冒头，因为时序收敛就是“按倒葫芦浮起瓢”的过程。

4.3 别被“假路径”绑架

有一种情况，你会花好几天修一条永远修不完的路径，结果最后发现它根本不需要修。比如两个异步时钟域之间的路径，或者某些功能模式下不会激活的路径，这些路径在约束里应该声明成set_false_path。再比如一条路径数据实际需要两个周期才能到达，但工具默认按一个周期检查，这类该用set_multicycle_path的场景，如果不做例外约束，工具会按最严格情况给你报违例。

下篇我会把set_false_path、set_multicycle_path、set_case_analysis这些时序例外好好展开。这里先提一句：遇到看起来无法收敛的违例，先问一句“约束对不对”。很多所谓关键路径，其实是“错误约束下的人造关键路径”。我在某项目上见过一条路径，设计者把本该是组合逻辑的输出错误地约束成了寄存器，导致工具报出来一条寄存器到寄存器的长路径，整整改了三天才发现根因是建模方式的问题。

5. 常见时序违例排查思路和实操实录

时序分析这个活儿，难的不是看懂报告，而是在一堆纷繁复杂的数据里迅速锁定真正的问题根源。这里整理几个最常见的违例场景和排查经验，这些是我实际项目里反复踩过的坑，比任何文档都值钱。

5.1 场景一：莫名出现的hold违例集中爆发

项目在时序收敛后期，突然冒出来成片的hold违例，而且集中在某个时钟域的边界。第一反应不应该是去插buffer，而是先查这个时钟域的时钟约束。

比如时钟源定义是create_clock -name clk -period 10.0 [get_ports clk_in]，但这个信号进了芯片又做了分频。分频路径上的约束如果没写对，工具计算分频时钟沿的偏斜方式就跟实际不符。有一个项目里，我用create_generated_clock声明了分频关系，但漏了-master_clock选项，工具就把分频时钟独立看待了，两个时钟域之间出现了一条跨时钟域保持违例，全部集中在分频点附近。

排查方法很简单，把工具的时钟报告调出来，看时钟树的分支偏斜和约束关系，逐一核对时钟与父时钟的关系是否正确。这类问题修约束比修网表快得多。

5.2 场景二：setup路径组合逻辑不长但延迟爆炸

报告里逻辑级数只有四五级，不是特别深的组合逻辑，但setup slack就是负得离谱。这种时候要重点关注两种可能。

第一种是走线绕路。布局时周围的宏单元（memory、PLL、模拟IP）把通道挤掉了，数据线被迫绕了一个巨大的U形，延迟飙升。这种情况去floorplan里看实际物理位置，基本一目了然。处理办法通常是调整宏单元位置、增加绕线通道，或者给工具指令设置区域约束。

第二种是信号上有巨大的负载。某个信号不止驱动一条路径，而是扇出了好几条路径，驱动强度跟不上，延迟自然就大了。可以在报告里看到终点单元的输入转换时间（transition time）异常偏大。处理方法是在约束中增大驱动强度，或者在版图中插入驱动单元，把大扇出拆分成多级。

5.3 场景三：跨模块边界路径总是违例

在顶层集成时，两个子模块之间的路径时序经常出问题，因为综合时每个模块是单独收敛的，内部时钟树和边界延迟没有被全局统一优化。这种问题不能靠修子模块内部来解决，核心思路是在顶层约束里把模块间的输入输出延迟设置正确。

尤其要注意一点：模块内部综合时的时钟树和顶层集成后的时钟树不一样，所有子模块内部的延迟数据，到顶层要重新计算。所以模块级综合时不要过度优化内部时序，留足裕量，顶层做收敛时才游刃有余。

5.4 防坑小技巧：先查约束，再查路径，最后查物理

这是我做时序收敛多年养成的习惯，顺序不能乱。

第一步，检查约束。把SDC里跟这条路径相关的时钟、延迟、例外全部调出来，一条条对，看是不是约束本身有错误。约30%的违例是约束问题，这一块排查成本最低、收益最高。

第二步，检查路径逻辑。如果约束没问题，那就看报告里的路径本身：起点、终点、经过的单元链、组合逻辑级数、各段延迟分布，判断是逻辑结构问题还是负载问题。

第三步，检查物理。逻辑和约束都没毛病，就要进版图界面看实际走线和单元摆放。拥塞、绕路、宏单元挡道、upstream驱动不足，这些只从文本报告里看不出来，必须在物理视图里确认。

这套流程走下来，绝大多数问题都能定位。走保险的路，不要上来就一顿插buffer，那是最后一个手段，不是第一手段。

6. 上篇就写到这里，下篇聊什么

把同步时序这条主线聊透，上篇的任务就完成了。建立时间、保持时间、时钟约束、关键路径优化，这些概念是学习后面所有内容的基石，建议动手跑一遍工具，自己造一条简单路径，故意把约束改紧，看看报告里slack怎么变化，比读十篇教程都管用。

我在实际做时序分析的过程中，最深的一点体会是：时序分析看起来是工具在做计算，实际上是工程师在做判断。同一个报告，新手看到的是数据，老手看到的是一个决策树——这条路径该不该修、该用什么手段修、修完会不会让别的地方恶化。这种判断力，只能靠大量看报告、大量跟真实违例打交道练出来。

下篇我会讲跨时钟域（CDC）路径的约束与分析、时序例外（false path、multicycle path、case analysis）的完整用法，以及多模式多角度的时序收敛流程。这些都是上篇概念的延伸，等到写完了，你会发现自己对“时序”这两个字的理解会再上一个台阶。