OCV： on-chip-variation 是指芯片在制造工艺P、工做电压V、环境温度T 等参数的局部变化状况下致使的 cell &net delay 变化，好比假设从clk 到两个reg D端的走线长度相同，RC 参数相同，xtalk 状况也相同，两个reg的size也相同，理论上来讲这两条path 上的delay应该相同，可是因为两条path 的PVT参数的误差，实际的delay 值也会有所误差，这种误差就称之为 ocv 。app
对于APR tool 来讲，ocv 是没法精确计算的，可是在先进工艺制程中，ocv 的影响又不能忽略，通常经过设置 timing derate 参数来估算ocv 带来的影响。
spa
在 set_operating_condition 时，须要设置 analysis type，通常分为 bc_wc 和 ocv 两种blog
bc_wc：在 wc 条件下 check setup （launch path ：wc， latch path：wc），ip
在 bc 条件下 check hold （launch path ：bc，latch path：bc）rem
可是设想一种状况：在wc条件下，ocv 致使 latch path 出现误差，latch path delay 比原来小，此时就可能出现 setup violation，因此bc_wc 模式是偏乐观的；it
ocv： 在 wc 条件下 check setup （launch path：wc，latch path：ocv_ wc）io
在 bc 条件下 check hold （launch path：bc，latch path：ocv_bc ）class
这样才能比较准确的考虑到芯片实际工做时的状况。可是这里也存在一个问题：wc corner bc corner 都是由 db 来描述的，若是采用ocv模式来分析timing的话，就须要一套 ocv_wc / ocv_bc 的 db 库，这个会比较麻烦，因此实际在使用ocv模式时，是直接用derate参数来分析的方法
举个栗子：im
foundry 给出的signoff 要求中的 DRT_H 以下：
那么在建立这个scenario时就须要这样设置：
set_timing_derate -cell_delay -early 0.954 -clock
set_timing_derate -net_delay -early 1 -clock （这行可删去）
set_timing_derate -cell_delay -late 1.046 -clock
set_timing_derate -net_delay -late 1.085 -clock
这里只设置了clock derating， 若是foundry 也给出了 data derating，DATA_DRT_H，就将 data 也设置一遍
因此，对比 BC_WC 和 OCV 区别以下图：
通常在90nm以上的工艺，ocv 影响较小，直接用 bc_wc 分析便可；而到了90nm如下，如 u55 / u40 等等，都须要设置 derating 参数。
那么如何开启 OCV，参考如下脚本：
create_scenario func_wc_cmax
set_operating_condition \
-analysis_type on_chip_variation \
-max wc -min wc
set_timing_derate -cell_delay -early 0.954 -clock
…………
CRPR：
实际上，ocv 模式有时也会太悲观，好比若是 launch 和 capture 有 common path，那么这段 common path 的 ocv 就是同样的，此时就再也不须要用 early-drt 和 late-drt 来修正，因此开启了ocv 模式后，须要同时开启 crpr （clock reconveregence pessimism removal），开启方法：
set_app_var timing_remove_clock_reconvergence_pessimism true