3. 时序报告解读基础
时序签核的第一步不是修，而是读。Tempus 输出的标准时序报告里，每一行都对应一条真实的时序路径，而理解这些行的关键，是先把 setup/hold、slack、arrival、required、clock path、data path 这六个概念串成一条完整的因果链。本章不追求覆盖报告的所有字段，而是聚焦于"看到一行报告，能判断它为什么违例、违例发生在哪一段"。
一、setup 与 hold：两种检查，两种约束方向
数字电路中的时序检查本质上只有两类。setup（建立时间）检查的是数据能否在捕获时钟沿到来之前足够早地稳定下来；hold（保持时间）检查的是数据在捕获时钟沿之后能否保持足够久，不被同一沿过早冲掉。两者方向相反：setup 违例意味着数据到得太晚，hold 违例意味着数据到得太早。
在 Tempus 报告中，setup 检查通常写作 setup 或 max_delay，hold 检查写作 hold 或 min_delay。一个容易混淆的点是：setup 分析走的是最慢路径（max），hold 分析走的是最快路径（min）。因此同一条物理路径，在 setup 和 hold 两种分析模式下可能得到完全不同的结论，这不是矛盾，而是分析模式不同。
二、arrival 与 required：一条路径的两个端点
要理解 slack，必须先理解 arrival 和 required 这两个量。
arrival time（到达时间）是数据实际到达捕获触发器 D 端的时间。它从发射触发器的时钟沿出发，经过发射时钟路径、组合逻辑、互连线，最终到达捕获端。arrival 是"数据实际走了多久"。
required time（要求时间）是数据最晚（setup）或最早（hold）必须到达的时间。它由捕获时钟沿、捕获时钟路径延迟以及触发器的 setup/hold 时间共同决定。required 是"数据被允许的最晚/最早边界"。
slack 就是两者的差：
setup slack = required_time - arrival_time
hold slack = arrival_time - required_time注意两个公式的减数顺序不同。setup 中 required 在后、arrival 在前，slack 为正表示数据比要求更早到，安全；hold 中 arrival 在后、required 在前，slack 为正表示数据比要求更晚到，安全。slack 为负即违例，负得越多越严重。
三、clock path 与 data path：违例到底出在哪一段
一条完整时序路径可以拆成四段：发射时钟路径（launch clock path）、数据路径（data path）、捕获时钟路径（capture clock path），以及触发器自身的 setup/hold 约束。Tempus 报告会把这几段分别列出，这正是定位问题的关键。
如果 slack 为负，需要判断是 arrival 太大还是 required 太小。arrival 大，通常意味着数据路径太长（组合逻辑级数多、线延迟大）或发射时钟路径偏慢；required 小，通常意味着捕获时钟路径偏慢或时钟不确定性（uncertainty）设置偏大。反过来，hold 违例常见于数据路径太短、时钟偏斜（skew）方向不利，或捕获时钟路径比发射时钟路径快太多。
下面这张图把一条 setup 路径的四段结构和 slack 的构成关系画在一起，便于对照报告逐段阅读。
四、读懂 Tempus 标准报告的一行
Tempus 的 report_timing 输出通常包含路径起点、终点、路径类型、各段延迟、arrival、required 和 slack。下面是一段典型的 setup 报告片段（示例数据，用于说明字段含义）：
Path 1: setup check
Startpoint: u_reg_a/Q (rising edge-triggered flip-flop)
Endpoint: u_reg_b/D (rising edge-triggered flip-flop)
Path Group: clk
Path Type: max
Point Incr Path
------------------------------------------------------
clock clk (rise edge) 0.000 0.000
u_reg_a/CK (FF) 0.120 0.120 r
u_reg_a/Q (FF) 0.250 0.370 r
u_comb1/Z (NAND2) 0.180 0.550 r
u_comb2/Z (NOR2) 0.220 0.770 f
u_reg_b/D (FF) 0.000 0.770 f
------------------------------------------------------
data arrival time 0.770
clock clk (rise edge) 1.000 1.000
clock uncertainty -0.050 0.950
u_reg_b/CK (FF) 0.100 1.050 r
library setup time -0.080 0.970
------------------------------------------------------
data required time 0.970
slack (MET) 0.200逐段读：data arrival time = 0.770 是数据从发射沿到捕获端 D 的实际累计延迟；data required time = 0.970 是捕获沿（1.000）减去 uncertainty（0.050）、加上捕获时钟路径延迟（0.100）、再减去 setup 时间（0.080）后的结果。两者相减得 slack = 0.200，为正，报告标注 MET。
如果 slack 变成 −0.150，说明 required 比 arrival 小了 0.150。此时应回到路径明细里看：是 u_comb2/Z 的 0.220 太大，还是 u_reg_b/CK 的 0.100 偏小，抑或 uncertainty 的 0.050 设置过紧。不同原因对应完全不同的修复手段——前者加缓冲或改逻辑，后者查时钟树或约束。
五、hold 报告的读法差异
hold 报告的字段结构与 setup 相同，但方向相反。hold 的 required time 通常等于捕获沿加上捕获时钟路径延迟，再加上 hold 时间；arrival 仍是从发射沿算起的数据到达时间。slack = arrival − required，为正表示数据没有来得太早。
一个常见误区是把 setup 的 slack 公式套到 hold 上。记住：setup 关心"晚"，hold 关心"早"；setup 用 required − arrival，hold 用 arrival − required。两者符号约定不同，但"正为安全、负为违例"是一致的。