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