STA分析過程中，要兼顧runtime和精度的要求，在分析過程中，一開始用簡單粗放的設置，做初步時序分析和時序收斂，當時序修到一定程度，做特定的設置，針對特定的timing path，讓工具做具體分析，從而提升這些有violation timing path的更精確的分析。

PT在計算crosstalk，通過改變一些設置，提高精確度，提高 PTSI 準確性

• 消除時鐘再收斂悲觀性（clock reconvergence pessimism，CRP）
• 選擇改進的window對齊模式（通過timing window的設置，進一步提升crosstalk計算精度）
• 執行特定路徑的時序（PBA vs?CBA）

修改victim和aggressor網絡的選擇方式

檢查有crosstalk的網絡

消除時鐘再收斂悲觀性（clock reconvergence pessimism）

CRPR這里涉及兩個內容?

• OCV derating
• crosstalk? topic

?OCV derating設置?

• global variation：通過corner形式體現。通過讀入不同PVT setting .lib文件來。global variation指die與die、wafer與wafer、lot與lot之間在生產工藝、供電電壓、溫度的不同所造成的cell的timing的差別。
• local variation：通過?OCV derating系數設置引入額外的margin。同一種類型 std cell在芯片中處于不同位置，由于工藝、所處位置的電壓和溫度的差別，造成同一種cell之間timing的不同。

launch path和capture path的OCV derating系數設置：

• launch path delay，采用OCV ，在計算setup的時候，考慮時序悲觀性，讓launch path延時越長越悲觀，在計算整個launch path delay乘以大于1的 OCVderating系數。不同工藝設置的系數不一樣。例如，1.15x原始的launch path delay
• capture path delay，采用OCV ，在計算setup的時候，考慮時序悲觀性，讓capture path 延時越短越悲觀，在計算整個capture path 所有cell delay乘以小于1的OCV derating系數。不同工藝設置的系數不一樣。例如，0.9 x 原始的capture path delay

common path

clock 產生源頭開始，走launch path和capture path，總是會有一些common path

問題：?

common path的cell，位置固定，某一時刻，OCV derating系數應該是固定不變的。如果按照launch path 和capture path 分別設置不同的OCV derating系數，對于common path的cell有些過于悲觀了。

解決：

需要去掉common path的cell上launch path 和capture path分別設置的OCV derating差值去掉。

工具計算方式：

• 計算launch path 和capture path，按照該有OCV derating系數計算
• 找到launch path 和capture path所有common path
• 減去common path上由于不同設置不同的OCV derating系數所產生的延時差

Clock Reconvergence Pessimism (CRP)

CRP = 到公共點的最晚到達時間 – 到公共點的最早到達時間

從 STA 中去除 CRP（Removal of CRP from STA (CRPR)）

• 默認情況下，PrimeTime 不會刪除 CRP
• 執行芯片內變化時，將以下變量設置為true以從STA中刪除CRP

set timing_remove_clock_reconvergence_pessimism true

timing report中出現?CRPR是0的情況：

• 變量沒有打開，沒有enableCRPR的removal
• launch path 和capture path之間有沒有common path
• 有common path，也開了CRPR，沒有確定的回答，需要具體問題具體分析具體分析，情況不是很多

CRPR考慮crosstalk?

common path上引入的crosstalk

工具處理方式：?

hold timing path 引入crosstalk的處理，可以通過CRPR remove

數據不能在時鐘到達之前發生變化，否則，時鐘采集不到數據。hold檢查同沿檢查?。

同沿檢查情況下，common path上的cell，launch path 和capture path受到的crosstalk影響是一樣的。common path上，由SI引起的的差別也會被remove掉。launch path引入的crosstalk記錄一次，capture path引入的crosstalk記錄一次，一共兩次，需要remove一次記錄。common path上 crosstalk，時序分析的時候還好，會刪掉 。

setup iming path 引入crosstalk的處理，不可以通過CRPRremove

信號在傳遞過程中，capture clock在經過一個cycle之后，是否能夠采到信號。經過一個cycle以后，判斷data delay和clock?delay之間關系。launch path在前一個沿上，capture path是經過一個沿（即經過一個cycle）傳過來。launch path和capture path不在同一沿。區別，aggressor有可能在前一個沿上同時翻轉，timing window overlap，對此產生crosstalk影響，信號下一個周期的沿來的時候，有可能不反轉，不產生crosstalk影響。在做setup分析的時候，common path上launch path和capture path所記錄的crosstalk不一樣，不能remove。common path 有比較大的crosstalk，會對setup分析有很大的影響。

僅當檢查是零周期檢查（zero-cycle check，也即同沿檢查）時，CRPR 算法才會在launch和capture時鐘路徑的common path中消除crosstalk引起delay。?

在零周期檢查中，aggressor ?switching同時以相同的方式影響launch和capture信號。

以下是 CRPR 可能適用于串擾引起的延遲的一些情況：

標準hold檢查（同沿檢查）：

• 如在 2 分頻時鐘電路中，register的Q pin出來，反接一個inverter到D pin?，有hold check的時候，就是同沿檢查。
• 由于register的Q pin output和D pin input之間存在寄生電容，保持對crosstalk feedback的檢查
• multicycle設置為0的hold檢查，例如，在launch 和capture之間存在設計偏差，使用單個時鐘邊沿進行launch 和capture信號的電路。
• transparent latch的setup檢查（setup變成同沿檢查）（latch，電平觸發。高電平觸發，時鐘高電平這一段是導通的，把數據從D傳到Q。design中，出現兩個同沿（無論正沿還是負沿）觸發的latch級聯，同時導通，會造成，同沿觸發的latch，時序分析中做的是同沿setup檢查）

二分頻電路：?

transparent latch（ latch 級聯）

?同沿觸發，但是latch之間存在延時（例如100ps），怎么滿足時序要求。

timing borrow（借時序）

對于latch，只要是高電平，就是導通的，整個高電平的周期內，都可以鎖存數據。?

前級發數據，同沿，對后一個latch向后delay100ps，在這里采集數據

disable timing borrow的方法，把latch當作沿觸發的register做時序分析（PT工具里面有相關命令）

crosstalk分析方式

PrimeTime SI的victim 和?aggressor的timing window計算方式

精度和runtime之間的平衡會有不同的設置

命令:

set si_xtalk_delay_analysis_mode 

兩種選擇方式：

all_paths     //(default)all_path_edges

timing window：到達某個點最短和最長時序路徑之差?

選用all_paths設置，只要aggressor window跟這個點上經過不同路徑組成的大的timing window，只要overlap，不同路徑上的所有crosstalk都會做一個計算。

但是，最長路徑的timing window和aggressor timing window沒有overlap，不需要做crosstalk計算。但是all_path是計算不同路徑上的所有crosstalk。這樣過于悲觀了。方法簡單粗暴。計算快，但是精確度低。

選用all_path_edges設置，分別算。aggressor window跟最快的路徑的timing window有overlap就計算crosstalk，和最慢的路徑的timing window沒有overlap就不計算crosstalk。

?不同階段選擇不同的設置

簡單粗放地報出整個design過程中，哪些路徑存在crosstalk影響：

使用 all_paths

• 想要準確report哪些路徑有violation，哪些沒有

專注分析有crosstalk影響的timing path：

使用 all_paths_edges

• 專注于分析有violation的時序路徑
• 使用 ECO 迭代去關閉時序
• 結合PBA的分析
• 具有多個時鐘傳播或大delta

?執行特定路徑的時序?

?Path Vs Graph

GBA（graph based analysis）：為了悲觀性的考慮，只記錄所有路徑傳遞過來的最差的transition。計算setup的時候只用這個最差的transition來計算所有路徑的delay。【數據量變小，計算非常快。】用GBA進行大面積的時序收斂。

有些情況下過于悲觀（比如某個pin上的transition很小，這種計算延時工具提供PBA來計算）

PBA（path based analysis）：取每個cell timing arc上的具體的transition值來計算。【完全依靠實際情況計算，計算準確，但是runtime變得很慢】
先用GBA先粗略進行時序分析，剩下的path不多，violation不大（跟工藝有關，到幾十p的時候）的時候使用PBA。看是否滿足時序要求。滿足時序要求可以去做timing signoff要求。

PBA分析，采用OCV derating，建議總的violation條數控制在5000條以下考慮。timing violation最好小于-100ps，在這個時候，基本滿足setup時序分析要求。violation條數大于1萬條時，runtime很長，通常需要一個小時以上分析完。violation條數過大，PBA之后也只是將violation降低，無法收斂。

??GBA和PBA的區別：Slew propagation（transition propagation）

AOCV：violation小于5000條，做PBA分析

POCV：GBA和PBA的timing差距在縮小，兩個run之后的延時信息基本不會有太大差別

?foundry廠，12nm以下采用PBA設置；28nm、40nm提供AOCV設置。

基于路徑的分析 （Path-Based Analysis，PBA）

?沿用戶指定的感興趣的時序路徑執行特定于路徑的slew propagation。

沿感興趣的路徑傳播路徑正確的slew，忽略來自門側輸入的slew。

#default and recommendedset timing_slew_propagation_mode worst_slew# recalculate timing path using PBA user interface:report_timing -pba_mode path ...    //PBAget_timing_paths -pba_mode path ...# ORreport_timing -pba_mode exhaustive...    //PBAget_timing_paths -pba_mode exhaustive …

-pba_mode path ...//只對已經報出來有timing violation的path，再去做PBA分析-pba_mode exhaustive ...//不管有沒有timing violation，只要給定一個點，就對其所有path進行PBA分析//遍歷所有的timing path

report_timing  path//把整個timing path打印出來，包括startpoint和endpoint，common cell的點、groupget_timing    path//把得到的timing path做一個返回，返回數據類型collecting（Synopsys工具里面的數據類型）