为什么说bc_wc分析模式是乐观的 我觉得不对啊

问一个困扰比较久的问题
analyze type有bc_wc和ocv还有singal三种
无论user guide还是哪里，对于bc_wc 都说这种分析模式过于乐观，我想问下：
bc_wc是setup和hold check分别采用两个极端的情况来分析，比如setup check，那么clock launch path和data path采用maximum delay，
clock capture path 也采用maximum delay，如果只从capture角度来看，确实是乐观的，但是从data path角度看，岂不是悲观的吗?
这个如何理解呢? 只从capture角度看?但觉得这样不科学啊

你说的是对的，static ocv中对典型setup的最紧corner在概率论上击不中。详见这篇paper：Hold is not Setup http://bbs.eetop.cn/thread-283480-1-1.html

bc-wc 只用于0.18 um及其以上工艺， 不了解也罢

推荐的文章不错，看了一点，有一些没有理解；
但是这个和我的问题说的不是一个事，我问的是bc_wc分析模式到底是悲观还是乐观，还没有谈到ocv的事情

不过还是谢谢你啦

您能形象说下上面这个是什么意思吗? 没有理解 觉得这篇文章写得挺晦涩的

对于setup来说有时钟信号 数据信号 BC_WC模式中都是调用max_lib最慢的来算延迟的就是说你数据信号按最慢的 但是你的时钟信号这个时候也是算的最慢的了.......就有一个情况 要是时钟要是走的没那么慢 就反应不出来了 .......hold 反过来同理...... OCV就是更详细的分开了来算的..........

那数据信号按最慢的来，时钟信号也按最慢的来计算；请问此时，对于setup check是悲观分析了还是乐观分析了

乐观了额..你的数据用最慢的 时钟也是最慢的 对于你的setup更容易建立额.....你可以画一个简单的图看看就知道了 对于setup来说 数据往后推 时钟往前推...对于建立的setup来说苛刻了一点......hold反过来也是一样的.......其实有一个soc的对工具的说明文档里面有介绍的.....

不对；你想对于setup来说，如何分析是乐观的，肯定是data path和clock launch path快一些，clock capture path慢一些；
而bc_wc说的是上面三种path全部变慢了，如果从clock capture path来理解，就是乐观的，但是从前两个path来理解，就是悲观的；

你画个图就知道了；所以bc_wc到底悲观乐观并不是很清楚

简单说吧BC_WC模式吧;setup来说数据信号和时钟信号都是用max_lib就是最慢的库来, 这样就不会有数据信号用最慢的情况同时钟信号用最快的模式了（对于前面的时序有可能不能满足后面的时序，因为后一种的时钟信号提前到了） 我就理解BC_WC仿真不出来最差的情况就是乐观的........hold同理......

恩，我觉得这样理解就可以了；
首先，悲观乐观是相对来说的；bc_wc在分析setup时，data path采用slow slew，clock path也采用slow slew，

这种分析相对于 data path采用fast slew，clock path采用slow slew的分析方式来说就是悲观的；

相对于data path采用slow slew，clock path采用fast slew(这种情况也就是我们常用的ocv)的分析方式来说，它就是乐观的！