jerrylz的个人空间 https://blog.eetop.cn/366790 [收藏] [复制] [分享] [RSS]

空间首页 动态 记录 日志 相册 主题 分享 留言板 个人资料

日志

OCV(On Chip Variation)和CPPR/CRPR的解释【转】

已有 4163 次阅读| 2012-7-20 22:56

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中的结果又是正确的.


点赞

评论 (0 个评论)

facelist

您需要登录后才可以评论 登录 | 注册

  • 关注TA
  • 加好友
  • 联系TA
  • 0

    周排名
  • 0

    月排名
  • 0

    总排名
  • 0

    关注
  • 1

    粉丝
  • 0

    好友
  • 0

    获赞
  • 0

    评论
  • 152

    访问数
关闭

站长推荐 上一条 /2 下一条


小黑屋| 手机版| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2024-11-22 12:30 , Processed in 0.023993 second(s), 13 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
返回顶部