4. 时序报告解读：如何读懂Setup/Hold报告、关键路径分析、WNS与TNS
时序报告，说白了就是STA工具给你的一张「成绩单」。
我刚入行那会儿，看到几百页的时序报告就头大。后来带我的老工程师跟我说了一句话，我记到现在：「别被数字吓到，你只需要盯住三个东西——WNS、TNS、还有那条最差路径。」
嗯，今天我就把怎么看这份「成绩单」的方法，掰开了揉碎了讲给你听。
核心要点：读懂时序报告 = 找到WNS → 分析关键路径 → 评估TNS → 判断修复优先级
4.1 时序报告长什么样？
先看一个典型的Setup时序报告片段。我用的是Synopsys PrimeTime的输出格式，其他工具（如Tempus、Innovus）大同小异。
********************************************************************************
Startpoint: u_core/u_reg_data (rising edge-triggered flip-flop clocked by clk)
Endpoint: u_core/u_ram_addr (rising edge-triggered flip-flop clocked by clk)
Path Group: clk
Path Type: max (setup)
********************************************************************************
Point Incr Path
---------------------------------------------------------------- -----------
clock clk (rise edge) 0.0000 0.0000
clock network delay (propagated) 0.3500 0.3500
u_core/u_reg_data/CK (DFFQ_X1) 0.0000 0.3500 r
u_core/u_reg_data/Q (DFFQ_X1) 0.1200 0.4700 r
u_core/net_1 (net) 0.0000 0.4700 r
U_INV_1/A (INV_X1) 0.0500 0.5200 r
U_INV_1/ZN (INV_X1) 0.0800 0.6000 f
... (中间省略若干级逻辑)
u_core/u_ram_addr/D (DFFQ_X1) 0.0500 1.8500 f
data arrival time 1.8500
clock clk (rise edge) 5.0000 5.0000
clock network delay (propagated) 0.4000 5.4000
clock uncertainty -0.1000 5.3000
u_core/u_ram_addr/CK (DFFQ_X1) 0.0000 5.3000 r
library setup time -0.0800 5.2200
data required time 5.2200
---------------------------------------------------------------- -----------
data required time 5.2200
data arrival time 1.8500
---------------------------------------------------------------- -----------
slack (MET) 3.3700
********************************************************************************这个报告显示slack是3.37ns，说明这条路径时序余量很足。但如果是负的slack，那就麻烦了。
我的小技巧：看报告时先扫一眼slack值。如果是正数且大于你设定的margin（比如0.1ns），直接跳过。只盯着负slack的路径看，效率最高。
4.2 Setup与Hold报告的区别
Setup和Hold，一个是看数据到得晚不晚，一个是看数据走得太快会不会冲过头。
| 对比项 | Setup检查 | Hold检查 |
|---|---|---|
| 检查时机 | 下一个时钟沿 | 同一个时钟沿 |
| 关键参数 | 数据路径延迟 + setup time | 数据路径延迟 - hold time |
| 常见修复 | 降频、插缓冲器、优化逻辑 | 加延迟、插缓冲器、调整时钟树 |
| 报告中的Path Type | max | min |
我遇到过最坑的一次，就是Hold报告没仔细看。Setup全过了，结果流片回来芯片在低温下疯狂出错。后来一查，是Hold violation在PVT corner下炸了。所以记住：Setup看高频，Hold看低温低压。
4.3 关键路径分析：找到那条「最差」的路径
关键路径，就是slack最差的那条路。它决定了你的芯片能不能跑到目标频率。
怎么分析？我一般按这个步骤来：
- 找到WNS对应的路径——工具会帮你排好序，第一条就是最差的。
- 看路径的起点和终点——是寄存器到寄存器？还是IO到寄存器？还是异步路径？
- 看路径上的逻辑级数——级数太多，延迟就大。我一般控制在20级以内（具体看工艺）。
- 看cell的驱动强度——如果路径上全是小驱动cell，那延迟肯定大。
- 看net的RC延迟——长线、高扇出，都是延迟大户。
避坑指南：我曾经遇到一条路径，WNS是-0.5ns，看起来不算太差。但仔细一看，这条路径上有30多级逻辑，而且中间还跨了一个clock domain。这种路径你修起来会非常痛苦。我的建议是：先看路径结构，再看slack数值。
4.4 WNS与TNS：两个最重要的全局指标
WNS（Worst Negative Slack）和TNS（Total Negative Slack），是衡量整个设计时序健康状况的两个核心指标。
- WNS：所有路径中最差的slack值。如果WNS是负的，说明至少有一条路径不满足时序。
- TNS：所有负slack路径的slack值之和。TNS越大，说明violation的路径越多或者越严重。
举个例子：
WNS = -0.15 ns
TNS = -2.35 ns
Number of Violating Paths: 47这个数据说明什么？最差的那条路径只差了0.15ns，但总共有47条路径有问题，加起来差了2.35ns。这种情况下，我通常会先修那47条路径中「好修」的，而不是死磕WNS那条。
注意：WNS和TNS不能只看一个。WNS好不代表TNS好，反之亦然。我见过WNS只有-0.01ns但TNS有-100ns的设计，这种设计其实比WNS=-0.5ns但TNS=-1ns的设计更难收敛。
4.5 知识体系：时序报告解读的核心逻辑
下面这张图，是我自己总结的时序报告解读流程。你照着这个思路走，基本不会漏掉关键信息。
这张图的核心逻辑就是：先看WNS判断有没有问题，有问题就分析关键路径，最后用TNS来评估修复的优先级和整体工作量。
4.6 实战技巧：如何快速定位问题
说了这么多理论，来点实际的。我总结了几条快速定位问题的经验：
- 先看WNS，再看TNS。WNS告诉你最差的情况，TNS告诉你整体情况。
- WNS差但TNS好——说明只有少数几条路径有问题，集中精力修那几条就行。
- WNS好但TNS差——说明有很多路径在临界状态，需要大面积优化。
- WNS和TNS都差——嗯，准备好加班吧。
我的习惯：每次跑完STA，我会把WNS和TNS记录在一个表格里，对比不同版本的变化。如果WNS变差了但TNS变好了，说明你修了大部分路径但把某一条搞得更差了。这种时候要回头看看是不是修错了方向。
好了，关于时序报告解读，核心就是这些。你只要把WNS、TNS、关键路径这三个东西搞明白，剩下的就是多练多看。每个项目的时序报告都有自己的「脾气」，看多了自然就熟了。
一句话总结：WNS告诉你「有没有问题」，TNS告诉你「问题有多大」，关键路径分析告诉你「问题在哪」。三个结合起来，你就能精准定位并修复时序问题。