静态时序分析11——精度提升（Improve Accuracy）

STA分析过程中，要兼顾runtime和精度的要求，在分析过程中，一开始用简单粗放的设置，做初步时序分析和时序收敛，当时序修到一定程度，做特定的设置，针对特定的timing path，让工具做具体分析，从而提升这些有violation timing path的更精确的分析。

PT在计算crosstalk，通过改变一些设置，提高精确度，提高 PTSI 准确性

• 消除时钟再收敛悲观性（clock reconvergence pessimism，CRP）
• 选择改进的window对齐模式（通过timing window的设置，进一步提升crosstalk计算精度）
• 执行特定路径的时序（PBA vs CBA）

修改victim和aggressor网络的选择方式

检查有crosstalk的网络

消除时钟再收敛悲观性（clock reconvergence pessimism）

CRPR这里涉及两个内容 

• OCV derating
• crosstalk  topic

 OCV derating设置 

• global variation：通过corner形式体现。通过读入不同PVT setting .lib文件来。global variation指die与die、wafer与wafer、lot与lot之间在生产工艺、供电电压、温度的不同所造成的cell的timing的差别。
• local variation：通过 OCV derating系数设置引入额外的margin。同一种类型 std cell在芯片中处于不同位置，由于工艺、所处位置的电压和温度的差别，造成同一种cell之间timing的不同。

launch path和capture path的OCV derating系数设置：

• launch path delay，采用OCV ，在计算setup的时候，考虑时序悲观性，让launch path延时越长越悲观，在计算整个launch path delay乘以大于1的 OCVderating系数。不同工艺设置的系数不一样。例如，1.15x原始的launch path delay
• capture path delay，采用OCV ，在计算setup的时候，考虑时序悲观性，让capture path 延时越短越悲观，在计算整个capture path 所有cell delay乘以小于1的OCV derating系数。不同工艺设置的系数不一样。例如，0.9 x 原始的capture path delay

common path

clock 产生源头开始，走launch path和capture path，总是会有一些common path

问题： 

common path的cell，位置固定，某一时刻，OCV derating系数应该是固定不变的。如果按照launch path 和capture path 分别设置不同的OCV derating系数，对于common path的cell有些过于悲观了。

解决：

需要去掉common path的cell上launch path 和capture path分别设置的OCV derating差值去掉。

工具计算方式：

• 计算launch path 和capture path，按照该有OCV derating系数计算
• 找到launch path 和capture path所有common path
• 减去common path上由于不同设置不同的OCV derating系数所产生的延时差

Clock Reconvergence Pessimism (CRP)

CRP = 到公共点的最晚到达时间 – 到公共点的最早到达时间

从 STA 中去除 CRP（Removal of CRP from STA (CRPR)）

• 默认情况下，PrimeTime 不会删除 CRP
• 执行芯片内变化时，将以下变量设置为true以从STA中删除CRP

set timing_remove_clock_reconvergence_pessimism true

timing report中出现 CRPR是0的情况：

• 变量没有打开，没有enableCRPR的removal
• launch path 和capture path之间有没有common path
• 有common path，也开了CRPR，没有确定的回答，需要具体问题具体分析具体分析，情况不是很多

CRPR考虑crosstalk 

common path上引入的crosstalk

工具处理方式： 

hold timing path 引入crosstalk的处理，可以通过CRPR remove

数据不能在时钟到达之前发生变化，否则，时钟采集不到数据。hold检查同沿检查 。

同沿检查情况下，common path上的cell，launch path 和capture path受到的crosstalk影响是一样的。common path上，由SI引起的的差别也会被remove掉。launch path引入的crosstalk记录一次，capture path引入的crosstalk记录一次，一共两次，需要remove一次记录。common path上 crosstalk，时序分析的时候还好，会删掉 。

setup iming path 引入crosstalk的处理，不可以通过CRPRremove

信号在传递过程中，capture clock在经过一个cycle之后，是否能够采到信号。经过一个cycle以后，判断data delay和clock delay之间关系。launch path在前一个沿上，capture path是经过一个沿（即经过一个cycle）传过来。launch path和capture path不在同一沿。区别，aggressor有可能在前一个沿上同时翻转，timing window overlap，对此产生crosstalk影响，信号下一个周期的沿来的时候，有可能不反转，不产生crosstalk影响。在做setup分析的时候，common path上launch path和capture path所记录的crosstalk不一样，不能remove。common path 有比较大的crosstalk，会对setup分析有很大的影响。

仅当检查是零周期检查（zero-cycle check，也即同沿检查）时，CRPR 算法才会在launch和capture时钟路径的common path中消除crosstalk引起delay。 

在零周期检查中，aggressor  switching同时以相同的方式影响launch和capture信号。

以下是 CRPR 可能适用于串扰引起的延迟的一些情况：

标准hold检查（同沿检查）：

• 如在 2 分频时钟电路中，register的Q pin出来，反接一个inverter到D pin ，有hold check的时候，就是同沿检查。
• 由于register的Q pin output和D pin input之间存在寄生电容，保持对crosstalk feedback的检查
• multicycle设置为0的hold检查，例如，在launch 和capture之间存在设计偏差，使用单个时钟边沿进行launch 和capture信号的电路。
• transparent latch的setup检查（setup变成同沿检查）（latch，电平触发。高电平触发，时钟高电平这一段是导通的，把数据从D传到Q。design中，出现两个同沿（无论正沿还是负沿）触发的latch级联，同时导通，会造成，同沿触发的latch，时序分析中做的是同沿setup检查）

二分频电路： 

transparent latch（ latch 级联）

 同沿触发，但是latch之间存在延时（例如100ps），怎么满足时序要求。

timing borrow（借时序）

对于latch，只要是高电平，就是导通的，整个高电平的周期内，都可以锁存数据。 

前级发数据，同沿，对后一个latch向后delay100ps，在这里采集数据

disable timing borrow的方法，把latch当作沿触发的register做时序分析（PT工具里面有相关命令）

crosstalk分析方式

PrimeTime SI的victim 和 aggressor的timing window计算方式

精度和runtime之间的平衡会有不同的设置

命令:

set si_xtalk_delay_analysis_mode 

两种选择方式：

all_paths     //(default)all_path_edges

timing window：到达某个点最短和最长时序路径之差 

选用all_paths设置，只要aggressor window跟这个点上经过不同路径组成的大的timing window，只要overlap，不同路径上的所有crosstalk都会做一个计算。

但是，最长路径的timing window和aggressor timing window没有overlap，不需要做crosstalk计算。但是all_path是计算不同路径上的所有crosstalk。这样过于悲观了。方法简单粗暴。计算快，但是精确度低。

选用all_path_edges设置，分别算。aggressor window跟最快的路径的timing window有overlap就计算crosstalk，和最慢的路径的timing window没有overlap就不计算crosstalk。

 不同阶段选择不同的设置

简单粗放地报出整个design过程中，哪些路径存在crosstalk影响：

使用 all_paths

• 想要准确report哪些路径有violation，哪些没有

专注分析有crosstalk影响的timing path：

使用 all_paths_edges

• 专注于分析有violation的时序路径
• 使用 ECO 迭代去关闭时序
• 结合PBA的分析
• 具有多个时钟传播或大delta

 执行特定路径的时序 

 Path Vs Graph

GBA（graph based analysis）：为了悲观性的考虑，只记录所有路径传递过来的最差的transition。计算setup的时候只用这个最差的transition来计算所有路径的delay。【数据量变小，计算非常快。】用GBA进行大面积的时序收敛。

有些情况下过于悲观（比如某个pin上的transition很小，这种计算延时工具提供PBA来计算）

PBA（path based analysis）：取每个cell timing arc上的具体的transition值来计算。【完全依靠实际情况计算，计算准确，但是runtime变得很慢】
先用GBA先粗略进行时序分析，剩下的path不多，violation不大（跟工艺有关，到几十p的时候）的时候使用PBA。看是否满足时序要求。满足时序要求可以去做timing signoff要求。

PBA分析，采用OCV derating，建议总的violation条数控制在5000条以下考虑。timing violation最好小于-100ps，在这个时候，基本满足setup时序分析要求。violation条数大于1万条时，runtime很长，通常需要一个小时以上分析完。violation条数过大，PBA之后也只是将violation降低，无法收敛。

  GBA和PBA的区别：Slew propagation（transition propagation）

AOCV：violation小于5000条，做PBA分析

POCV：GBA和PBA的timing差距在缩小，两个run之后的延时信息基本不会有太大差别

 foundry厂，12nm以下采用PBA设置；28nm、40nm提供AOCV设置。

基于路径的分析 （Path-Based Analysis，PBA）

 沿用户指定的感兴趣的时序路径执行特定于路径的slew propagation。

沿感兴趣的路径传播路径正确的slew，忽略来自门侧输入的slew。

#default and recommendedset timing_slew_propagation_mode worst_slew# recalculate timing path using PBA user interface:report_timing -pba_mode path ...    //PBAget_timing_paths -pba_mode path ...# ORreport_timing -pba_mode exhaustive...    //PBAget_timing_paths -pba_mode exhaustive …

-pba_mode path ...//只对已经报出来有timing violation的path，再去做PBA分析-pba_mode exhaustive ...//不管有没有timing violation，只要给定一个点，就对其所有path进行PBA分析//遍历所有的timing path

report_timing  path//把整个timing path打印出来，包括startpoint和endpoint，common cell的点、groupget_timing    path//把得到的timing path做一个返回，返回数据类型collecting（Synopsys工具里面的数据类型）