ICode9
精准搜索请尝试： 精确搜索
首页
编程语言>
数据库
系统相关
互联网
其他分享
Python
Java
JavaScript
android
PHP
首页 > 其他分享> 文章详细

STA: CPPR and OVC + Comments

2021-10-25 16:34:28  阅读：299  来源： 互联网

标签：capture STA clock launch Comments delay OVC timing path


ZZ from 驴子大神
后附comments

S CRPR  clock reconvergence pessimism removal

C CPPR  clock path pessimism removal

剔除公共clock path上的悲观度。

看图说话，上图是最常见最基本的一条timing path: 有launch clock path, data path 跟 capture clock path; 大多数电路中的大多数timing path 的launch clock 跟 capture clock 都从同一个时钟源头来，经过一段『共享路径』后分离，再各自达到自己的『彼岸』。这段『共享路径』的英文名儿叫: common clock path;  launch clock path 跟 capture clock path 分道扬镳点的英文名儿叫: common point. CRPR/CPPR 的操作对象就是common point 跟common clock path.

一个view 对应一套PVT 的库跟某一个确定的RC corner, 在确定的PVT 跟 RC corner 下，common clock path 上的cell 不论是被当做launch clock path 还是capture clock path 其delay 值都是固定的，但是在做STA 分析时为了模拟Variation 会对launch clock path, data path 跟 capture clock path 分别设不同的derate 值，可能是Flat OCV, AOCV 或POCV/SOCV.

拿setup 分析为例，通常会设一个late 的derate 值（大于1的值）到launch clock path 上，同时会设一个early 的derate 值（小于1的值）到capture clock path 上，这就使得common clock path 在被当做launch clock path 和capture clock path 时的delay 有了差别，但是对于同一段path 在一个固定时间内，它的delay 值一定是固定的，不可能忽大忽小，所以在STA 分析时，需要把由于derate 引起的common path 上delay 的差值剔除掉，这就是所谓的CRPR/CPPR.

CRPR/CPPR 跟时钟沿的关系：

在计算CRPR/CPPR 需要考虑时钟沿，工具会分别计算时钟上升沿跟下降沿到达common point 的时间及对应的CRPR/CPPR. 在Innovus 跟Tempus 中默认行为是：如果launch clock 跟capture clock 在时钟源处边沿相同且到达common point 时边沿亦相同，那CRPR/CPPR 的值就是对应时钟沿计算所得的值；如果 launch clock 跟capture clock的时钟沿不同，则取 min ( <rise-cppr>, <fall-cppr>).

该行为可以通过变量控制，目前主流工具中都有对应变量，在tempus 中是 timing_cppr_transition_sense, 该变量默认值是normal 行为如上所述，如果设成 "same_transition" , 在 launch clock 跟capture clock的时钟沿不同时 CRPR/CPPR 取0.

CPPR 跟cross talk delta delay 的关系

因为耦合电容存在，在先进工艺结点，cross talk 几乎不能避免，所以通常STA 分析都要使能SI, 即：在计算timing 时将耦合电容的影响考虑在内。cross talk 是STA 一个巨大的话题，除了对timing 的影响，还有glitch 的分析。

耦合电容好比传播介质，做得好的设计好比隔音好的房子，隔壁啪得声音再大，也传不过来，因为耦合电容小到几乎没有，做得差的设计就是没隔音的破房子，恨不得隔壁的悄悄话都能在这边绕梁三日。带SI 的STA 分析，有两个基本对象：Victim 跟 Aggressor, 太难记，对应成『受』跟『攻』就好记多了。『受』就是当前分析的这条net, 每个『受』的周围都可能有一个或多个『攻』。当『攻』跟『受』同向翻转时，会加快『受』的跳变，当『攻』跟『受』异向翻转时，会减缓『受』的跳变。

在当前STA 方法学中，对由cross talk 引起的delta delay 的计算方式是：先分别计算『攻』和『受』的timing window ，选取有overlap 的『攻』来计算对『受』的影响，如果『攻』的力度太小也会被过滤掉，只有强大到一定的『攻』才会被计算在内。

  • 对于setup: 会假设launch clock and data path 上所有『受』的『攻』都跟『受』异向翻转，都会减缓『受』的跳变，使整条timing path delay 变长；同时也假设capture clock path 上所有『受』的『攻』都跟『受』同向翻转，都会加快『受』的跳变，使整条timing path delay 变短。

  • 对于hold: 会假设launch clock and data path 上所有『受』的『攻』都跟『受』同向翻转，都会加快『受』的跳变，使整条timing path delay 变短；同时也假设capture clock path 上所有『受』的『攻』都跟『受』异向翻转，都会减缓『受』的跳变，使整条timing path delay 变长

在这种情况下，common path 上由cross talk 引起的delta delay 如何处理？

  • 对于setup, 通常launch clock 跟capture clock 都不是同沿clock, 而在实际电路中，不能保证非同沿clock 对应的timing window 一致，所以就不能保证『受』在非同沿clock 遇到相同的『攻』，在这种情况下，common path 上由cross talk 引起的delta delay 是不能够用CPPR 减掉的。< 特别声明：在一些特别的设计里，有同沿的setup check 对于同沿的setup check 由cross talk 引起的delta delay 是能够用CPPR 减掉的. >

  • 对于hold, 通常launch clock 跟capture clock 都是同沿clock, 同沿clock 对应的timing window 一致，所以『受』在同沿clock 总能遇到相同的『攻』，在这种情况下，common path 上由cross talk 引起的delta delay 是能够用CPPR 减掉的。

clock Reconvergence 的CPPR

所谓clock reconvergence 就是分开又相聚的clock path, 看图说话，在下图CLK1 在C1 点分了叉在CP2 点又相聚，又分叉在CP3 点再相聚。对于这样的clock path 在计算CPPR 时，不同工具都有相应变量控制，在Tempus 跟Innovus 中由如下变量控制：

timing_cppr_skip_clock_reconvergence 

在该report 中有一行：Pessimism Threshold Value: 0.020, 这个值在不同工具中也是由变量控制的，为了runtime 可以牺牲掉部分精度，如果记忆正确，目前大部分工具中默认值都是20ps, 通常在timing signoff 的最后阶段为了追求timing 精度（其实是工程师想得到更好看的timing）会将该值设成一个非常小的值比如1ps 或5ps, 在Tempus 跟Innovus 中对应的变量是：timing_cppr_threshold_ps.

Notes@C.A.

  • CPPR
    • 做STA 分析时为了模拟Variation OCV -on chip variation
      • 对launch clock path, data path 跟 capture clock path 分别设不同的derate 值
    • 拿setup 分析为例，通常会设一个late 的derate 值（大于1的值）到launch clock path 上，同时会设一个early 的derate 值（小于1的值）到capture clock path 上，这就使得common clock path 在被当做launch clock path 和capture clock path 时的delay 有了差别，但是对于同一段path 在一个固定时间内，它的delay 值一定是固定的，不可能忽大忽小，所以在STA 分析时，需要把由于derate 引起的common path 上delay 的差值剔除掉，这就是所谓的CRPR/CPPR.
      • i.e: 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的关系. 在.18um甚至.13um工艺下. ocv的影响很小, 基本可以不考虑. 但是90nm及以下,基本都会设.
    • 如果launch clock 跟capture clock 在时钟源处边沿相同且到达common point 时边沿亦相同，那CRPR/CPPR 的值就是对应时钟沿计算所得的值；如果 launch clock 跟capture clock的时钟沿不同，则取 min ( , ).
    • Rules
      • 对于setup: 会假设launch clock and data path 上所有『受』的『攻』都跟『受』异向翻转，都会减缓『受』的跳变，使整条timing path delay 变长；同时也假设capture clock path 上所有『受』的『攻』都跟『受』同向翻转，都会加快『受』的跳变，使整条timing path delay 变短。
      • 对于hold: 会假设launch clock and data path 上所有『受』的『攻』都跟『受』同向翻转，都会加快『受』的跳变，使整条timing path delay 变短；同时也假设capture clock path 上所有『受』的『攻』都跟『受』异向翻转，都会减缓『受』的跳变，使整条timing path delay 变长
        • Setup 是对应于两个clock edge的计算，所对应的timing window 不一致
        • Hold 是针对一个clock edge的计算，对应的timing window 一致

标签：capture,STA,clock,launch,Comments,delay,OVC,timing,path
来源： https://blog.csdn.net/politefish/article/details/120952934

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

关于我们 | 联系我们 | 留言反馈

专注分享技术，共同学习，共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有