论STA | 读懂timing report，很重要 - 极术社区 - 连接开发者与智能计算生态

从数字电路实现阶段开始，Timing report 便成了一个需要被时刻认真分析的『萌宠』，然而并不是所有人都读得懂它，懂与不懂跟工作年限无关，跟哪个工具生成的无关，只跟是否认真对待过有关，因为它的结构就那么简单，东西就那些，只要认真搞过一次就能门儿清。今天驴试着来阅读一次timing report, 以Tempus 产生的一个timing report 为例。

驴在面试时经常会问一个问题：给你一个timing report 如何看？都能分别得到什么信息？这个问题看似简单，但作用非凡，认真做过的人一定讲得头头是道，没有做过或假装做过或只点过按钮的人说出slack 后一定一脸懵逼，并伴有内心OS : 什么傻逼问题！

WeChat Image_20210324140710.jpg

那么，拿到一个timing report 到底要如何看？

不同工具产生的timing report 大同小异，基本都包括三部分：表头或表头+表尾，launch path, capture path. 上图是Tempus 产生的timing report 的表头，这个表头分两部分，有些工具会把第二部分放到表尾，从这个表头能得到：

表头第一部分

工具版本信息：如示例中的18.10-p001，对某个具体项目timing signoff 工具的版本最好保证一致；
操作系统信息：这一项无关紧要。
生产日期：这一项还是有看一下的必要，避免低级错误，哼哧哼哧debug 了半天，结果report 看错了的事情是时有发生的。
设计：确定是你的设计。
命令：确定report 的时候都加了哪些option, 因为极有可能原始脚本不是你自己写的。

表头第二部分

Timing path 的起点和驱动时钟及时钟的有效沿：示例中分别为my\_start\_point, clk, 上升沿。
Timing path 的终点和驱动时钟及时钟的有效沿：示例中分别为my\_end\_point, clk, 上升沿。
Timing path 所在的path group：示例中为clk, 大多数工具默认会为每一个clock 定义一个path group，用户可以根据需求自定义path group, 如无用户自定义的path group 某条path 会被归为该path endpoint 驱动时钟对应的group.
Analysis View：STA 中一个view = 一组具有相同PVT 的std/macro cell + 一个RC corner, 要确定当前View 是否正确。如果你还不清楚二者分别是什么，关系如何，请翻看驴号之前的文章。
Other end arrival time: capture path 的delay。
Setup: 从capture 寄存器对应的std cell lib 中查表得到。
Phase shift: 如果没有MCP ( multi cycle path ) 设置，该值即为单个clock 的周期。
CPPR: 在考虑OCV 的STA 分析中，会分别对launch clock path 跟capture clock path 设不同的derate 值，如setup check: launch clock path 会设一个late 的derate, capture clock path 会设一个early 的derate. 而对于同一段path 在实际中不可能会有不同方向的variation 所以为了剔除悲观度，工具会将common path 上的这部分影响减除即CPPR; 对于0 沿check ( 如hold check) 除了Variation, CPPR 还会减除common path 上SI 的影响。这也是为什么common path 越长越好的原因。
Uncertainty: 该值来自SDC, 通常signoff uncertainty = foundry requirest margin + PLL jitter + IR-drop modeling.
Required time: 在此时间内到达时序即能满足 = clock period + capture clock path delay + CPPR - Setup - Uncertainty.
Arrival time: launch data 实际到达时间 = launch clock path delay + data path delay.
slack: 最终检验值，为正该path pass 为负该path 违规 = required time - arrival time.

WeChat Image_20210324140715.png

示例中的path 没有timing violation, 如果有timing violation 下一步就要去看完整的timing path, 包括launch path 跟capture path。并不是说没有timing violation 的path 就不需要看，是通常不会去看，除非第一次跑timing 就全clean 一定有惊喜。

WeChat Image_20210324140717.jpg

timing path 主体

check RC 的反标：在Tempus 的report 中有一列 "Arc annotation" 会标明每一条net RC 的来历，如果RC 来自SPEF, 则值为SPEF. 如果有net 没有正确反标，首先要找出未反标的原因。如果所有net 都已正确反标，再进行下一步。
check clock skew: 可分别从launch clock path 跟cpature clock path 中得到到start point clock pin 的clock network delay 和到endpoint clock pin 的clock network delay，如果skew 过大需要找后端确认是有意为之还是给了一版垃圾数据，至于『大』的定义每家公司每个项目都有自己衡量的标准，有的人认为12已经算大了，但有的人认为18才是真的大，所以请根据自己的需求定义大。如果clock skew 也正常。
check derate: std cell 是否有用AOCV, 如果有check derate 的值是否合理，Depth 的值是否合理，是否对net 有设flat OCV, 如果有分别check launch 跟capture path 的derate 值是否合理。如果都合理。
check cross talk 引入的delta delay: 先看clock path 上的SI, 如果有较大较多的SI 要去找后端确认，clock path 的SI 要尽量修掉；再看data path 上的SI, 最好把大于某个值的SI 对应的net 都抓出来在layout 上看一下，然后再确定fix 的方向。如果SI 也合理。
check clock common point: 确认时钟分叉点，是不是时钟分叉太早，如果common path 非常短需要跟后端确认是否可以做长。
如果以上都合理，就需要详细check 每一级的cell 跟net delay, 最好在layout 上把该条path highlight 出来，先check 是否有cell 堆叠的情况尤其是buffer 跟inverter 的堆叠，如果有，需要找后端确认；再check delay 较大的某些cell 的输入transition 跟fanout 是否合理，如果transition 太大需要确认是由于前一级的驱动能力太弱还是输入net 太长造成的，如果fanout 太大需要找后端确认；再check delay 大的net, 在layout 上量一下该net 的距离，对于什么类型的cell 能驱动多长的net 自己心里要有数，而这个数是由对所用工艺研究得到的，如果某个cell 驱动了超出其能力所及的net 如果不能通过cell swap 解决，就找后端。

WeChat Image_20210324140728.jpg