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