2.4 违例报告逐行解读：slack 是怎么算出来的
2.4 违例报告逐行解读：slack 是怎么算出来的
本节摘要：违例报告不是一堆需要"看懂大概"的日志，而是 2.1 公式的逐行展开。本节解剖一份完整的建立违例报告：启动时钟路径在哪里结算、数据路径如何累加、required time 怎么组装、slack 的减法发生在哪一行，并给出读报告时的四个防误读要点。
凌晨的签核室里，一份报告摊在屏幕上，最上面一行写着 slack 为负。问题链走到第四站：违例怎么报。多数人扫一眼 slack 数字就开始改电路，这正是很多收敛工作低效的起点——报告的每一行都在告诉你这个数字的来历，逐行读完，修复方向往往自己浮现。本节的任务是让每个数字都能对上出处。
一、报告的骨架：五段结构
一份标准建立检查报告由五段组成：头部的起点终点信息、路径类型声明、逐行累加的点表（Point / Incr / Path）、到达与要求两行汇总、最后的 slack 结论。先看完整报告，再逐行拆：
**************************************** Report : timing Path Type : max ; 建立账（慢延迟） **************************************** Startpoint: u_cpu/u_ex/alShiftOut_reg[3] ; 起点：启动触发器的时钟端 (rising edge-triggered flip-flop clocked by clk) Endpoint: u_l2/u_ctrl/cmpDone_reg/REGEN ; 终点：捕获触发器的使能数据端 (rising edge-triggered flip-flop clocked by clk) Path Group: clk ; 路径所属时钟组 Path Type: max Point Incr Path ------------------------------------------------------------- clock clk (rise edge) 0.000 0.000 ; 启动沿名义位置 clock network delay (ideal) 0.000 0.000 ; 预 CTS 阶段时钟树为 0 u_cpu/u_ex/alShiftOut_reg[3]/CK D 0.000 0.000 r ; 到达启动 CLK 引脚 u_cpu/u_ex/alShiftOut_reg[3]/Q 0.098 0.098 f ; CLK 到 Q，输出下降沿 u_ex/u_shift32/Y 0.121 0.219 f ; 组合单元弧 u_ex/u_cmp15/Y 0.086 0.305 r ; 组合单元弧（翻转为升） net2157 (wire) 0.044 0.349 r ; 互连弧 u_l2/u_ctrl/cmpDone_reg/REGEN 0.000 0.349 r ; 到达终点数据引脚 data arrival time 0.349 ; 到达时间结算 clock clk (rise edge) 0.500 0.500 ; 捕获沿名义位置 clock network delay (ideal) 0.000 0.500 ; 捕获侧时钟树 u_l2/u_ctrl/cmpDone_reg/CK 0.000 0.500 r ; 到达捕获 CLK 引脚 library setup time 0.031 0.531 ; 减去建立时间 data required time 0.531 ; 要求时间结算 ----------------------------------------------------------------- data required time 0.531 data arrival time 0.349 ----------------------------------------------------------------- slack (MET) 0.182 ; 0.531 − 0.349
二、逐行对上公式
把报告逐段对应到 2.1 的公式。到达时间一侧：clock rise edge 0.000 是启动沿名义位置；clock network delay 是启动时钟路径（布线后显示真实时钟树延迟）；CK 到 Q 的 0.098 是启动触发器的输出弧，注意它同时标了翻转极性 f——下降沿输出对下一级延迟的影响不同，这是查表时的重要索引。中间的 u_ex/u_shift32/Y、net2157 等行分别是单元弧与互连弧，Incr 列就是 1.2 说的"账本上每一行"。要求时间一侧：捕获沿 0.500 是周期；捕获侧 clock network delay 之下的 library setup time 0.031，是捕获触发器对数据的要求；如果约束设了不确定度，这里还会有一行 clock uncertainty 直接参与加减；如果时序 derogating（第五章 OCV）生效，两侧还会出现 derate 折扣行。最后一行是减法本身：required 减 arrival，括号里 MET 或 VIOLATED 给出裁决。
保持报告的结构一模一样，差别有三处：Path Type 显示 min；捕获沿与本拍同沿（capture edge 显示与 launch 相同的时刻 0.000）；library 一行换成 hold time，且出现在到达时间的下方做减法方向相反的运算。读保持报告时只需盯三行：最短的 CLK 到 Q、最短的数据路径、要求侧的 hold 加不确定度。
图：报告行与公式项的对应关系
三、四个防误读要点
第一个误读：把负 slack 直接当频率缺口。slack 为 −0.1ns 不等于"芯片只能跑到目标的 80%"，频率上限要看关键路径的（到达 + 要求侧固定项）反推，而且全芯片频率由最差路径决定，与其他路径无关。第二个误读：只看最差一条。单条 WNS（worst negative slack）之外，还要看 TNS（全部负 slack 之和）与违例端点数——一条 −0.05 和一百条 −0.05 是两种完全不同的工程问题，前者可能一个 buffer 解决，后者暗示系统性问题（约束、角或全局布局）。第三个误读：忽略 min/max 模式。报告若标了 Path Type: min，这是保持账，降频无用，修复方向完全不同。第四个误读：把 ideal clock 阶段的数字当签核结论——clock network delay (ideal) 表明时钟树还不存在，偏斜还没发生，此阶段保持违例没有意义（时钟树综合后才是真账）。
工具输出可以按需加字段：让报告显示各点的 transition（翻转率）、fanout、slack 贡献等，例如在 report_checks 里打开 -fields 选项带上 transition、capacitance、input_pins。定位瓶颈时这些字段比 slack 本身更有用——6.3 的瓶颈分析就建立在这些字段上。
本节要点回顾
- 报告五段结构：头部信息、路径类型、点表累加、到达与要求两行、slack 裁决，任何一段都能对上 2.1 的公式项。
- Incr 列即账本行：单元弧、互连弧、时钟树延迟各占一行，翻转极性（r/f）标注在行尾。
- 保持报告三处不同：Path Type 为 min、同沿比较、hold 要求方向相反。
- WNS、TNS、违例端点数三个指标合用才能判断违例的规模与性质。
- ideal clock 阶段的保持数字没有意义，时钟树综合之后保持账才算数。
至此问题链第一站完成：门槛公式（2.1）、护栏检查（2.2）、特殊角色（2.3）、报告解读（2.4）全部就位。下一站进入延迟的物理来源——报告里那 0.098ns 的 CLK 到 Q、那 0.044ns 的线延迟，究竟是被什么决定的。