CRPR问题
90nm以下， 都是OCV 了，
CRPR 肯定开啊，要不然太悲观了，
如果使用了OCV（set derating）就要开CRPR
如果没有用OCV，CRPR的on/off没什么区别
小编似乎把crpr和ocv概念没分清
请教陈小编，OCC和OCV分别指的是什么?跟crpr是什么关系。
非常感谢！
小编貌似把OCV和crpr的概念搞混乱了. 我先理理概念.
OCV是on-chip variation. 是指在同一个芯片上, 由于制造工艺等原因造成的偏差. 具体表现在到两个ff的clk端的时钟路径. 本来时间应该是一样的. 但是因为制造工艺也就是OCV的原因, 造成工具无法计算的快慢偏差.
说到OCV就必须要提timing derate. 这个值就是告诉工具, OCV的影响有多大. 通常signoff的时候. derate会有5%到10%. 不同工艺不同设计, 由工程师的经验决定.
如果两个clk path 的长度都是1, 在OCV 分析模式下, 1.05和0.95的derate.
原本是0的 skew就变成了 1x1.05 - 1x0.95 = 0.1的skew.
以上就是OCV和timing derate的关系. 在18甚至13工艺下. ocv的影响很小, 基本可以不考虑. 但是90及以下,基本都会设.
cppr (clock path pessimism removal) 或者 crpr (clock reconveregence pessimism removal)是同一件事情的两种叫法. C公司的叫前者, S公司的叫后者. 在开启OCV模式之后, 这个选项才有意义.
在前面OCV的介绍中, 可以看到. 那种分析方式过于悲观了. 因为两个时钟可能有共同路径. 既然是共同路径, 逻辑上就不可能有偏差. cppr就是干这的. 去除共同路径上过于悲观的估计. 只计算不同路径的OCV影响.
而且你对pt的这个选项好像理解也有问题.
timing_clock_reconvergence_pessimism 是设置以何种方式crpr. normal 还是same_transition
timing_remove_clock_reconvergence_pessimism 设置为true是开启crpr.
PS:我对比ets和pt对crpr的理解. 发现业界标准的pt 在计算crpr的时候, 有失误.
具体表现在: report_crpr的结果和timing report中crpr的结果冲突.
研究发现timing report中crpr的值是错的. 对共同路径的长度计算有误.
而report_crpr中的结果又是正确的.
不知道有没人碰到同样的问题. 或者说, 我做错了哪个部分?
请指教.
小编貌似把OCV和crpr的概念搞混乱了. 我先理理概念.
OCV是on-chip variation. 是指在同一个芯片上, 由于制造工艺等原因造成的偏差. 具体表现在到两个ff的clk端的时钟路径. 本来时间应该是一样的. 但是因为制造工艺也就是OCV的原因, 造成工具无法计算的快慢偏差.
说到OCV就必须要提timing derate. 这个值就是告诉工具, OCV的影响有多大. 通常signoff的时候. derate会有5%到10%. 不同工艺不同设计, 由工程师的经验决定.
如果两个clk path 的长度都是1, 在OCV 分析模式下, 1.05和0.95的derate.
原本是0的 skew就变成了 1x1.05 - 1x0.95 = 0.1的skew.
以上就是OCV和timing derate的关系. 在18甚至13工艺下. ocv的影响很小, 基本可以不考虑. 但是90及以下,基本都会设.
cppr (clock path pessimism removal) 或者 crpr (clock reconveregence pessimism removal)是同一件事情的两种叫法. C公司的叫前者, S公司的叫后者. 在开启OCV模式之后, 这个选项才有意义.
在前面OCV的介绍中, 可以看到. 那种分析方式过于悲观了. 因为两个时钟可能有共同路径. 既然是共同路径, 逻辑上就不可能有偏差. cppr就是干这的. 去除共同路径上过于悲观的估计. 只计算不同路径的OCV影响.
而且你对pt的这个选项好像理解也有问题.
timing_clock_reconvergence_pessimism 是设置以何种方式crpr. normal 还是same_transition
timing_remove_clock_reconvergence_pessimism 设置为true是开启crpr.
PS:我对比ets和pt对crpr的理解. 发现业界标准的pt 在计算crpr的时候, 有失误.
具体表现在: report_crpr的结果和timing report中crpr的结果冲突.
研究发现timing report中crpr的值是错的. 对共同路径的长度计算有误.
而report_crpr中的结果又是正确的.
不知道有没人碰到同样的问题. 或者说, 我做错了哪个部分?
请指教.
我擦. 一不小心打了这么多..
讲的太清楚了，
report_crpr 没用过，下次试试，
主要以timing report的 CRPR 为准， 因为timing的结果就是从那里来的，
如果只有一条时钟路径，那么这两个命令报出来的公共路径应该是一样的。
但是如果寄存器的时钟有多个路径，那么这两个命令报出来的公共路径肯定是不同的，因为timing report报的是所有路径中最严的一条。比如中间分叉成两条路径，经过不同的delay后再通过mux选择最后输出到寄存器，那么timing路径一共有4条，而timing report只是报出其中最严的一条，且这一条中时钟和数据路径肯定是分别选延时最大或最小的，不可能选择同一路。
收藏下
analysis_type 有single bc_wc on_chip_variation这三种模式
OCV时,同一clock line上的cell,对launch和capture也是分别按照最悲观计算延时，即同cell不同delay
而这种悲观在实际上是不可能出现的，所以要remove掉这种悲观
即打开CRPR后，launch和capture clock line上的共同cell的delay将完全相同
这个你可以在report里面看到
mark一下！
CRP in report_timing ∈ range[ (actual CRP - timing_crpr_threshold_ps), (actual CRP)]
CRP in report_crpr = actual CRP
mark下！
路过，学习了。
长知识了。
新手入职，能不能帮忙，讲一下CPPR通俗的解释么?还有prime time的应用，多谢了！
MARK
回复 3# 陈涛
"如果使用了OCV（set derating）就要开CRPR
如果没有用OCV，CRPR的on/off没什么区别"
==>为什么"如果没有用OCV,CRPR的on/off没有区别"?
Xtalk引起的Incremental delay也会被CRPR抵消吧！
请涛大分析一下,感激不尽！
这个在每日一题里面讨论过，结论是 setup时，CRPR不能抵消xtalk，hold时可以
一个连OCV都不开的设计，基本上也就不用考虑xtalk了
好贴aaaa
mark~
恩，以前还以为CRPR是一种技术，看了PT的user guide之后发现CRPR原来是分析工具的一种算法。学习了。看来这个后端还是经验活啊
没看明白您所说的，能详细讲讲吗?多谢了
学习下
我學習到了
你没有搞错，是工具的原因。
report_crpr比较准，report_timing因为会update_timing，如果使用精确的crpr，运算量太大。所以工具会进行折中，report_timing报出的CRP一般为report_crpr-x ~ report_crpr，其中x为折中值，默认为20ps。
非常感谢！