4. 时序报告解读与关键路径定位

在 Agilex 器件上完成综合与布局布线后，Quartus Prime 的 Timing Analyzer（基于 SDC 约束的静态时序分析引擎）会给出完整的时序报告。真正决定收敛效率的，不是"跑一次报告"，而是能否从成百上千条路径中快速读出违例类型、判断违例性质，并定位到具体的瓶颈模块。本节围绕建立时间（Setup）、保持时间（Hold）、恢复时间（Recovery）与移除时间（Removal）四类违例，说明报告的读法与关键路径的定位方法。

一、四类违例的物理含义与判据

建立时间检查的是数据到达时间（Data Arrival）是否早于数据需求时间（Data Required）。在 SDC 中，需求时间由时钟周期、时钟不确定性（Clock Uncertainty）、建立时间裕量（Setup Relationship）共同决定。报告中的 Slack 为负即违例，其数值等于 Required − Arrival。Agilex 的 Hyper-Register、可配置时钟树和大量流水级使得建立违例往往集中在跨时钟域或长组合逻辑链上。

保持时间检查的是数据在捕获沿之后是否保持足够稳定，即 Arrival 是否晚于 Required（保持需求通常为 0 加保持时间）。保持违例的典型成因是数据路径过短、时钟偏斜（Skew）过大或同一时钟沿下数据几乎"贴着"捕获沿到达。恢复/移除时间针对异步复位或置位信号：恢复时间要求复位释放不能太靠近时钟有效沿，移除时间要求复位有效不能太靠近时钟有效沿。这两类违例常出现在复位同步器、异步 FIFO 的复位路径上。

四类违例的判据可统一记为：Slack = Required − Arrival。Setup/Recovery 关注"数据/复位释放是否来得太晚"，Hold/Removal 关注"数据/复位有效是否来得太早"。Slack 为负即违例，负值越大越严重。

二、报告结构与关键字段

在 Timing Analyzer 中，常用报告包括 Report Setup Summary、Report Hold Summary、Report Recovery Summary、Report Removal Summary，以及针对单条路径的 Report Timing。摘要报告给出每个时钟域的最差 Slack、违例路径数（TNS、WNS、NVP）。其中 WNS（Worst Negative Slack）是最差负裕量，TNS（Total Negative Slack）是所有违例路径负裕量之和，NVP 是违例路径条数。三者结合才能判断问题的"深度"与"广度"：WNS 很小但 NVP 很大，说明是普遍性紧张；WNS 很大但 NVP 很少，说明是个别长路径。

展开单条路径后，报告分为 Source、Destination、Launch Clock、Latch Clock、Data Path、Clock Path、Clock Uncertainty 等段落。Data Path 中的每一行给出元件类型、位置（如 LAB_CLK、FF、LUT）、延迟值（IC、Cell、RC 等）。Clock Path 则给出时钟从源到发射/捕获寄存器的延迟，用于计算 Skew。定位瓶颈时，应重点看 Data Path 中延迟占比最大的几级，以及 Clock Path 中是否存在异常大的插入延迟。

三、关键路径定位流程

定位关键路径不是"看最差的一条"，而是按"时钟域 → 路径类型 → 瓶颈模块 → 具体元件"逐层收敛。建议按以下顺序操作：

  1. 先看 Setup/Hold Summary，确认违例集中在哪个时钟域、哪类检查。
  2. 用 Report Timing 指定该时钟域，按 Slack 升序排列，取前 10～20 条路径。
  3. 观察这些路径的 Source 与 Destination，判断是否集中在同一模块或同一总线。
  4. 展开最差路径，查看 Data Path 中延迟最大的 3～5 级，记录其元件与位置。
  5. 回到 RTL 或网表，确认该逻辑是否可流水化、是否可复制寄存器、是否可调整约束。

例如，某 Agilex 工程在 400 MHz 时钟域下报告 WNS = −0.42 ns，NVP = 37。展开路径后发现 Source 为 u_dsp/u_mac/acc_reg[7]，Destination 为 u_dsp/u_mac/acc_reg[8]，Data Path 中一级 DSP 累加器到下一级寄存器的组合逻辑延迟达 1.9 ns，占整条路径的 62%。这说明瓶颈在 DSP 累加链的进位逻辑，而非布线。此时可考虑插入一级流水寄存器或改用 DSP 内部流水模式。

Agilex 时序报告解读与关键路径定位 报告层级 Summary 摘要 WNS / TNS / NVP Report Timing 按 Slack 排序取前 N 条 路径展开 Data Path / Clock Path 瓶颈模块 Source / Destination 聚类 具体元件 延迟最大 3～5 级 关键路径时序示意（Setup 检查） Launch FF acc_reg[7] 组合逻辑 DSP 累加进位链 1.9 ns (62%) Capture FF acc_reg[8] Launch Clock Latch Clock Clock Tree (Skew) Launch Edge Capture Edge Data Arrival Data Required Slack = −0.42 ns WNS = −0.42 ns ｜ NVP = 37 ｜ 瓶颈：DSP 累加进位链

四、从报告到修复的对应关系

读出违例后，修复手段与违例类型强相关。建立违例的常见处理包括：在长组合链中插入流水寄存器、对高扇出信号做寄存器复制、降低时钟不确定性（改善 PLL 配置或时钟树约束）、对跨时钟域路径改用同步器并设置 set_clock_groups 或 set_false_path。保持违例则相反，通常需要增加数据路径延迟（插入缓冲）、减小时钟偏斜、或对过短路径设置 set_max_delay 与 set_min_delay 约束。恢复/移除违例多通过复位同步器、调整复位释放时序或对复位路径设置 set_false_path 来处理。

需要特别注意的是，Agilex 的 Hyper-Register 和可配置 DSP 模块会显著改变路径延迟分布。若报告显示某条路径的 Cell Delay 远大于 IC Delay，说明瓶颈在逻辑级数而非布线；反之若 IC Delay 占比高，则应优先考虑布局约束或区域约束（LogicLock）。在 Report Timing 中勾选 Show Routing 可以区分这两类延迟。

定位关键路径时，建议同时打开 Chip Planner 查看路径的物理位置。若 Source 与 Destination 分处不同 SLD 区域，IC Delay 会明显偏大，此时调整布局约束往往比改 RTL 更有效。

五、实操检查清单

检查项观察位置判断依据
违例类型Setup/Hold/Recovery/Removal Summary确认是建立、保持还是复位类违例
严重程度WNS / TNS / NVPWNS 大且 NVP 少 → 个别长路径；NVP 大 → 普遍紧张
时钟域Summary 中的 Clock 列定位到具体时钟域，缩小排查范围
路径聚类Report Timing 的 Source/Destination是否集中在同一模块或总线
延迟构成Data Path 的 Cell vs ICCell 大 → 逻辑级数多；IC 大 → 布局问题
时钟偏斜Clock Path 的插入延迟差Skew 过大需检查时钟树约束

掌握上述读法与定位流程后，面对 Agilex 工程中动辄数万条时序路径，就能在几分钟内锁定真正的瓶颈，而不是被摘要报告中的数字牵着走。下一阶段的工作，是把定位结果转化为具体的 RTL 修改或约束调整，并再次运行 Timing Analyzer 验证收敛效果。

← 上一章 📖 返回目录 下一章 →