CRPR问题

chenzhao.ee

sta的分析工具例如PT，在做timing分析的时候，缺省的remove_clock_reconvergence_pessimism是false，这个应该是考虑OCV的影响，但是咨询过一些backend designer，.18制程的时候OCV的影响不大，所以把crpr设置成true，关掉reconvergenc_pessimism也可，我想知道这个OCV什么制程或者环境下对chip影响较大？

icfbicfb

90nm以下， 都是OCV 了，

CRPR 肯定开啊，要不然太悲观了，

陈涛

如果使用了OCV（set derating）就要开CRPR
如果没有用OCV，CRPR的on/off没什么区别

yueluofenghen

楼主似乎把crpr和ocv概念没分清

dongkai1003

回复 3# 陈涛


      请教陈版主，OCC和OCV分别指的是什么？跟crpr是什么关系。
      非常感谢！

farren

楼主貌似把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中的结果又是正确的.

不知道有没人碰到同样的问题. 或者说, 我做错了哪个部分?
请指教.

farren

楼主貌似把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中的结果又是正确的.

不知道有没人碰到同样的问题. 或者说, 我做错了哪个部分?
请指教.

farren

我擦. 一不小心打了这么多..

icfbicfb

讲的太清楚了，

report_crpr 没用过，  下次试试，

主要以timing report的 CRPR 为准， 因为timing的结果就是从那里来的，

bingling512

如果只有一条时钟路径，那么这两个命令报出来的公共路径应该是一样的。

但是如果寄存器的时钟有多个路径，那么这两个命令报出来的公共路径肯定是不同的，因为timing report报的是所有路径中最严的一条。比如中间分叉成两条路径，经过不同的delay后再通过mux选择最后输出到寄存器，那么timing路径一共有4条，而timing report只是报出其中最严的一条，且这一条中时钟和数据路径肯定是分别选延时最大或最小的，不可能选择同一路。