静态时序分析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
  

1. 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之间的均衡会有差别的设置
命令:

1. set si_xtalk_delay_analysis_mode <mode>

复制代码

两种选择方式：

1. all_paths     //(default)
2. 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。

1. #default and recommended
2. set timing_slew_propagation_mode worst_slew
3. # recalculate timing path using PBA user interface:
4. report_timing -pba_mode path ...    //PBA
6. get_timing_paths -pba_mode path ...
8. # OR
9. report_timing -pba_mode exhaustive...    //PBA
11. get_timing_paths -pba_mode exhaustive …

复制代码

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

复制代码

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

复制代码

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！