第四节：时序报告解读——PrimeTime/Tempus报告结构、关键路径分析、slack直方图与分布、最差路径（Worst Negative Slack）定位
各位同学，大家好。我是你们的后端芯片设计讲师。今天我们来聊聊一个非常实际的话题——时序报告解读。
说实话，我见过不少工程师，跑完PrimeTime或者Tempus，看到一堆数字就头大。其实，时序报告就像医生的体检单。你得知道哪些指标是关键的，哪些是虚惊一场。今天我就带大家把这份“体检单”彻底看懂。
一、PrimeTime/Tempus报告结构——先搞清楚“体检单”长什么样
不管是PrimeTime还是Tempus，它们的报告结构其实大同小异。我习惯把报告分成三个层次来看：
- 顶层摘要：告诉你整体情况——有没有违例？最差slack是多少？
- 路径报告：详细列出每一条路径的延迟、转换时间、负载等信息。
- 汇总统计：比如slack直方图、违例路径数量等。
举个例子，PrimeTime的典型报告开头是这样的：
****************************************
Report : timing
-max_paths 10
-nworst 1
-path_type full_clock
Design : my_chip
Version: P-2019.03-SP1
Date : Mon Mar 15 10:23:45 2024
****************************************
Startpoint: reg_A (rising edge-triggered flip-flop clocked by clk)
Endpoint : reg_B (rising edge-triggered flip-flop clocked by clk)
Path Group: clk
Path Type : max
Point Incr Path
------------------------------------------------------------
clock clk (rise edge) 0.0000 0.0000
clock network delay (propagated) 0.5000 0.5000
reg_A/CLK (DFFQ_X1) 0.0000 0.5000 r
reg_A/Q (DFFQ_X1) 0.3500 0.8500 r
net_123 (net) 0.1200 0.9700 r
U1/A (NAND2_X1) 0.0800 1.0500 r
U1/ZN (NAND2_X1) 0.1500 1.2000 f
net_456 (net) 0.1000 1.3000 f
U2/A (INV_X1) 0.0500 1.3500 f
U2/ZN (INV_X1) 0.1200 1.4700 r
net_789 (net) 0.0900 1.5600 r
reg_B/D (DFFQ_X1) 0.0000 1.5600 r
data arrival time 1.5600
clock clk (rise edge) 2.0000 2.0000
clock network delay (propagated) 0.5000 2.5000
clock uncertainty -0.1000 2.4000
reg_B/CLK (DFFQ_X1) 0.0000 2.4000 r
library setup time -0.0800 2.3200
data required time 2.3200
------------------------------------------------------------
data required time 2.3200
data arrival time -1.5600
------------------------------------------------------------
slack (MET) 0.7600
看到没？报告分成了上下两部分。上半部分是数据路径，下半部分是时钟路径。中间用一条横线隔开。我最开始看报告时，总搞不清“data arrival time”和“data required time”到底谁减谁。后来我总结了一个口诀：required - arrival = slack。正数就是满足，负数就是违例。
二、关键路径分析——找到真正的“瓶颈”
关键路径，说白了就是整个设计里最慢的那条路。但这里有个坑：最慢的不一定是最重要的。
我在项目中遇到过这样的情况：一条路径slack是-0.5ns，另一条是-0.3ns。按理说应该先修-0.5ns的。但仔细一看，-0.5ns那条路径是测试模式下的，而-0.3ns是功能模式下的。你想想看，测试模式下的违例，只要不影响功能测试，优先级其实可以放低。所以，分析关键路径时，一定要结合路径的实际工作场景。
PrimeTime里，我们可以用report_timing命令来抓关键路径。常用的选项有：
-max_paths 10：显示最差的10条路径-nworst 1：每个端点只显示最差的一条-path_type full_clock：显示完整的时钟路径-group clk：只看某个时钟域
我个人习惯先看-max_paths 100，然后根据slack值排序。如果发现某条路径的slack特别差，我会再用-path_type full_clock_expanded把时钟路径也展开，看看是不是时钟偏斜（skew）在作怪。
三、Slack直方图与分布——从宏观把握全局
只看最差路径是不够的。你得知道整个设计的时序“健康度”。Slack直方图就是干这个的。
PrimeTime里生成直方图的命令很简单：
report_timing -histogram -max_paths 10000 -group clk输出结果大概长这样：
Slack Path Count
----------------------
-0.50 to -0.40: 2
-0.40 to -0.30: 5
-0.30 to -0.20: 12
-0.20 to -0.10: 28
-0.10 to 0.00: 45
0.00 to 0.10: 60
0.10 to 0.20: 55
0.20 to 0.30: 40
0.30 to 0.40: 30
0.40 to 0.50: 20
看到这个分布，你就能判断：是只有少数几条路径违例，还是整个设计都偏慢。如果违例路径集中在-0.1到0.0之间，那说明设计基本没问题，只是需要微调。但如果违例路径从-0.5开始就有一大堆，那就要考虑是不是时钟周期设得太紧，或者综合策略有问题了。
四、最差路径（Worst Negative Slack）定位——找到“罪魁祸首”
好了，现在我们知道整个设计的时序状况了。接下来就是找到最差的那条路径，然后修复它。
PrimeTime里定位最差路径，我常用的命令是：
report_timing -max_paths 1 -nworst 1 -path_type full_clock -group clk这条命令会输出整个设计里slack最差的那条路径。然后我会仔细看路径上的每一个cell和net，找出延迟最大的那一段。
举个例子，假设报告里显示：
U1/ZN (NAND2_X1) 0.1500 1.2000 f
net_456 (net) 0.1000 1.3000 f
U2/A (INV_X1) 0.0500 1.3500 f
U2/ZN (INV_X1) 0.1200 1.4700 r
net_789 (net) 0.0900 1.5600 r这里U1/ZN到U2/A的延迟是0.15ns，但net_456的延迟只有0.10ns。说明问题可能出在U1这个cell上，而不是连线。我会检查U1的驱动能力是不是不够，或者它的输入转换时间是不是太大。
另外，Tempus用户也别担心。Tempus的命令和PrimeTime基本一致，只是有些选项名称不同。比如PrimeTime的report_timing在Tempus里是report_timing，但-histogram选项可能变成-histogram。具体可以查一下工具手册。
五、知识体系结构图
为了让大家更直观地理解时序报告解读的流程，我画了一张图：
这张图把时序报告解读分成了三个层次：先看报告结构，再分析关键路径，最后用直方图做宏观判断。每一步都有对应的工具命令和分析方法。
好了，关于时序报告解读，我就讲到这里。记住，读报告不是目的，目的是找到问题并修复它。下一节我们会讲如何根据报告里的信息，制定修复策略。到时候我会分享一些我实际项目中的案例，保证干货满满。
可可精品资料库