ocv scenarios

我理解的ocv是指当launch和capture ff在chip上距离很远时，也会有一个很小的corner变化，但这个变化是随机的，可能是launch bc,capture wc,也可能是launch wc，capture bc，所以在同一个corner下，即可能有setup violation,也可能hold violation，但是最近看到的脚本都是wc对应setup,bc对应hold，icc sg上给的也是这种，请问，这样设置有道理吗。大家都是怎么做的?

追加一个问题：似乎很多fab都只有max和min的tluplus，如果logical lib使用正确的ocv lib，net delay使用set_timing_derate -net_delay value ,这样能否正确模拟cell delay和net delay 的ocv模型?如果可以应该怎么分别设置setup scenario 和 hold scenario 的net_delay derate?

建议你加强下对ocv的理解。
同一个conner下同一条path是不可能同时出现setup和hold violation，除了sdc的错误设置。
set_timing_derate设的是一个经验值。

不会有可能是launch bc,capture wc,也可能是launch wc，capture bc。
过度悲观了吧

同一条path上正常情况是不会同时出现setup和hold violation，但是同一条pah上有可能是setup violation，也可能是hold violation,假如wc下，cts后path1 setup非常好，但是hold timing slack恰好为0，capture path上加一个timing derate的延迟slack就是负的，ocv的出现就是考虑这种情况的吧

不是的，
setup time:launch wc，capture less_wc,或者launch less_bc，capture bc
hold time:launch bc,capture less_bc,或者launch less_wc,capture wc

论坛中这么多关于ocv的资料，你为什么不自己认真看看呢，而在这猜。

我的理解是这样的，但是看到的脚本都没有这样做（包括参考设计），所以来请教坛友帮忙解答，可能我哪里理解有错，请大侠指点下，我对前端时序的理解只是一般水平。

那你在论坛里找找ocv和wc_bc这两个的区别。

额 我知道 我的意思你说上面说的不对吧