OCV： on-chip-variation 是指芯片在制造工艺P、工作电压V、环境温度T 等参数的局部变化情况下导致的 cell &net delay 变化，比如假设从clk 到两个reg D端的走线长度相同，RC 参数相同，xtalk 情况也相同，两个reg的size也相同，理论上来说这两条path 上的delay应该相同，但是由于两条path 的PVT参数的偏差，实际的delay 值也会有所偏差，这种偏差就称之为 ocv 。
对于APR tool 来说，ocv 是无法精确计算的，但是在先进工艺制程中，ocv 的影响又不能忽略，一般通过设置 timing derate 参数来估算ocv 带来的影响。
在 set_operating_condition 时，需要设置 analysis type，一般分为 bc_wc 和 ocv 两种
bc_wc：在 wc 条件下 check setup （launch path ：wc， latch path：wc），
在 bc 条件下 check hold （launch path ：bc，latch path：bc）
但是设想一种情况：在wc条件下，ocv 导致 latch path 出现偏差，latch path delay 比原来小，此时就可能出现 setup violation，所以bc_wc 模式是偏乐观的；
ocv： 在 wc 条件下 check setup （launch path：wc，latch path：ocv_ wc）
在 bc 条件下 check hold （launch path：bc，latch path：ocv_bc ）
这样才能比较准确的考虑到芯片实际工作时的情况。但是这里也存在一个问题：wc corner bc corner 都是由 db 来描述的，如果采用ocv模式来分析timing的话，就需要一套 ocv_wc / ocv_bc 的 db 库，这个会比较麻烦，所以实际在使用ocv模式时，是直接用derate参数来分析的
举个栗子：
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