4.2 静态时序分析：读时序报告

4.2 静态时序分析：读时序报告

本节摘要：静态时序分析（STA）是 FPGA 工具按约束对每一条时序路径做"体检"的工序——不需要仿真波形，纯静态计算所有路径的建立与保持时间余量。本节教你读懂时序报告的结构（slack、WNS、TNS、关键路径），区分建立时间违例与保持时间违例，并掌握定位与修复违例的基本章法。

一句行话背后的行业默契

硬件团队里流传一句行话："WNS 是红的，周末就别想休息了。"WNS（Worst Negative Slack，最差负余量）是时序报告里最重要的数字——它表示全芯片最坏一条路径还差多少纳秒才能满足约束。WNS 为正，全芯片时序通过；WNS 为负，表示存在违例，这条路径就是不满足约束的最差路径。工程上约定俗成用"红"表示违例、"绿"表示满足，所以"看 WNS 是红是绿"成了判断一次实现成败的第一反应。

为什么静态时序分析能"不跑波形就知道结果"？因为路径延迟是可以静态计算的：每根布线有固定延迟、每个逻辑单元有固定延迟，工具把"起点触发器 → 组合逻辑 → 终点触发器"的延迟累加，和约束要求的时钟周期一比，就有结论。它不验证功能，只验证"时间够不够"——这是 STA 与仿真互补分工的关键。

建立时间与保持时间

任何寄存器都有两个硬性时间要求：

• 建立时间（Setup Time）：时钟沿到来之前，输入数据必须提前稳定的最短时间。违例意味着"数据来得太晚"，在时钟沿采到的可能是上一拍的值——结果是功能随机错乱。
• 保持时间（Hold Time）：时钟沿到来之后，输入数据必须保持稳定的最短时间。违例意味着"数据变得太快"，同样导致采样错误。

它们分别对应两条检查：建立时间检查关心数据最晚什么时候到（路径太长、时钟太快会违例），保持时间检查关心数据最早什么时候变（路径太短、时钟偏斜大大会违例）。工程上建立时间违例占绝大多数，保持时间违例多出现在跨时钟域或复位释放场景。

时序路径与余量示意

这张图的公式建议抄下来：建立余量 slack = 时钟周期 − 数据到达时间 − 建立时间。slack 为正是余量，为负就是欠账——欠得越多，路径越急。

读报告的三个层次

一份完整的 STA 报告信息量很大，按"由粗到细"三个层次读：

第一层：全局数字。看 WNS（最差负余量）和 TNS（负余量总和）。WNS 决定"过不过"，TNS 告诉你违例是"一根独苗"还是"一片荒芜"。WNS 负一点点而 TNS 很小 → 单条关键路径，好修；WNS 负得不多但 TNS 很大 → 系统性问题（约束或布局），别在单条路径上使劲。

第二层：关键路径清单。报告会列出最差的若干条路径，每条给出起点、终点、路径延迟分解。先看路径延迟分解里哪一段占比最大——组合逻辑延迟？布线延迟？扇出太大？段与段的比例直接告诉你修法：组合段长 → 切流水线；布线段长 → 改布局或管脚；扇出大 → 寄存器复制。

第三层：单条路径细节。展开到每个节点的到达时间，确认修法是否生效。

下面模拟一段报告关键路径（示意，字段按真实报告简化）：

Timing Path (Max Delay Path)   — 建立时间检查
Startpoint:  proc_inst/reg_data[7]  (rising edge of clk_200m)
Endpoint:    fir_inst/acc_reg[15]   (rising edge of clk_200m)
Path Group:  clk_200m
Path Type:   Max (Setup)

Slack (MET):     0.512 ns
  Source Clock:  clk_200m  at 0.000 ns
  Data Path Delay: 4.488 ns
    Logic Delay:    2.960 ns
    Route Delay:    1.528 ns
  Destination Clock: clk_200m at 5.000 ns

Analysis: slack = 5.000 - 4.488 = 0.512 ns  (MET = 满足)
​

模拟一份违例版（关键字段），对比着看：

Slack (VIOLATED): -0.784 ns
  Data Path Delay: 5.784 ns
    Logic Delay:    4.460 ns   ← 组合逻辑占了 77%
    Route Delay:    1.324 ns
​

组合逻辑占 77%——这是典型的"组合链太长"，修法首选在关键路径中间切一级流水（把组合逻辑分成两半，各用一拍）。第 2 章你写的 a * b 如果没打拍，在这里就会现形。

修复违例的决策顺序

拿到违例，按这个顺序尝试，别一上来就动代码：

1. 先查约束：时钟约束写对了吗？周期换算对不对？PLL 配置对吗？约束错导致的假违例，改代码就是白忙。
2. 再查布局：重跑一次实现（启发式随机性可能解决）；或调整管脚约束、区域约束。
3. 最后动代码：组合链切流水（加一级寄存器）、逻辑复制降扇出、关键路径上的大逻辑（乘法、大 case）挪到 DSP 或查表化。

问题：报告中 MET 和 VIOLATED 是怎么判的

问：时序报告里每条路径标注的 MET（满足）和 VIOLATED（违例）是怎么算出来的？答：核心就是 4.2 那个公式——slack = 时钟周期 − 数据到达时间 − 建立时间。slack 为正标 MET，为负标 VIOLATED。注意两点：slack 是"全路径"的余量，不是某一级的延迟，所以只看路径总延迟不够，要看延迟分解（组合/布线/扇出各占多少）才能判断修法；报告分建立和保持两组，同一路径在两个检查组里各有 slack，别只看建立组就下结论。

⚠️ 常见坑：保持时间违例（尤其复位释放和跨时钟域）用切流水线是修不好的——保持违例的修复方向是"加延迟"（插缓冲）或改时钟偏斜，工具通常有自动修复，但前提是约束里声明了相关时钟关系。别把两类违例的修法搞混。

本节要点回顾

• STA 不跑波形：静态累加路径延迟与约束比较，验证"时间够不够"，不是验证功能。
• 两类违例两类修法：建立违例→缩短路径；保持违例→加延迟，别混。
• 三层次读报告：全局数字（WNS/TNS）→ 关键路径 → 单条细节，由粗到细。
• 按延迟分解定修法：组合段长切流水、布线段长调布局、扇出大做复制。
• 修违例先查约束：假违例比真违例更常见，约束错了改代码是浪费。

下一步进入 4.3：同一时钟域的问题能用 STA 查，跨时钟域的隐患却藏在 STA 盲区里——亚稳态与 CDC 处理登场。