读懂timing report

三部分：表头/launch path /capture path

1.表头

1）

• 工具版本信息：如示例中的18.10-p001，对某个具体项目timing signoff 工具的版本最好保证一致；

• 操作系统信息：这一项无关紧要。

• 生产日期：这一项还是有看一下的必要，避免低级错误，哼哧哼哧debug 了半天，结果report 看错了的事情是时有发生的。

• 设计：确定是你的设计。

• 命令：确定report 的时候都加了哪些option, 因为极有可能原始脚本不是你自己写的。

2）

• 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. 

2.

 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 的方向

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 解决，就找后端。