上週吾愛IC社群小編分享了數字IC設計實現Hierarchical flow中關於邏輯綜合，佈局佈線階段的相關內容。今天我們繼續分享下半部分內容——-寄生引數提取（RC Extraction），靜態時序分析（Static Timing Analysis）。限於篇幅，物理驗證部分內容放在下期。
2019年數字IC後端校招筆試題目（附數字後端培訓影片教程）
Dummy新增
在晶片chip finish階段需要插dummy，而插dummy後timing會有所變化，因此在最後階段的RC抽取時必須事先把design的dummy插好。
一般foundary都會提供插dummy的utility，我們可以利用它在calibre中自動完成dummy insertion，從而滿足foundary要求的poly，metal density等要求。如果某些個別地方仍然有min或者max density的violation，需要找foundary進行確認，
是否可以waived
。
寄生引數提取
業內比較公認的寄生引數提取工具是Synopsys家的Star-RC。如果你們公司不是特別牛逼，沒有一套自己的signoff標準或者經驗體系，請嚴格按照業界的標準來做。所以不要問能不能用calibre來提取RC，能不能在ICC中抽RC看timing等類似問題，甚至面試的時候跟面試官說你是在ICC中抽RC看timing的。因為這些問題都暴露了一個問題——-你做的數字後端很不專業。
STAR-RC作為一個業界公認的RC抽取工具，必然要考慮到幾大主流工具資料轉換問題。因此RC抽取主要有兩種常用方式，一種是
Milkyway Flow
，另外一種是
LEF/DEF Flow
。
Milkyway flow
RC抽取的Milkyway flow如下圖所示。這種主要針對數字IC後端實現用的工具是ICC或者ICC2，RC抽取時只需告訴工具design的milkyway database即可，無需進行任何的轉換。
對於hierarchical方式實現的design，還需要提供子模組的Fram View和CELL View。對於層層巢狀的設計，特別需要
注意Fram view和cell view的一致性問題
，否則RC抽取可能不準確。在抽取RC時需要將子模組的模組名稱填入skip cell中。
Milkyway方式RC抽取的官方參考指令碼如下：
MILKYWAY_DATABASE： /project/local/angela/design。mw
BLOCK：design
SKIP_CELLS： *
NETS：*
NETLIST_FILE：
MAPPING_FILE： nxtgrd/layer。map
OPERATING_TEMPERATURE：125
TCAD_GRD_FILE： cln28hpm_1p08m+ut-alrdl_5x2z_cbest。nxtgrd
MAGNIFY_DEVICE_PARAMS：NO
MILKYWAY_ADDITIONAL_VIEWS： FILL （帶dummy）
BUS_BIT： ［］
HIERARCHICAL_SEPARATOR： /
MILKYWAY_EXPAND_HIERARCHICAL_CELLS： NO
EXTRACTION： RC
COUPLE_TO_GROUND： NO
COUPLING_MULTIPLIER： 1
REDUCTION： LAYER
METAL_FILL_POLYGON_HANDLING：FLOATING
NETLIST_FORMAT：SPEF
EXTRACT_VIA_CAPS：YES
DENSITY_BASED_THICKNESS：YES
NETLIST_COMPRESS_COMMAND：gzip -q -f
NUM_CORES： 8
LEF/DEF flow
LEF/DEF流程如下圖所示。這種方式比較適用於PR是在cadence家工具innovus中做的，當然ICC/ICC2也可以寫出def，走lef和def flow。
LEF/DEF flow的參考指令碼與milkyway flow大同小異，限於篇幅，參考指令碼請移步小編
知識星球
檢視下載。
同樣對於hierarchical實現的設計，RC抽取時也需要提供子模組的lef和def檔案，並在skip cell中填入對應需要flatten的各個子模組的module名字。
RC抽取的資料準備
從前面介紹的RC抽取流程和參考flow中，可以知道整個RC抽取需要以下資料資訊：
Milkyway Database/LEF DEF
Nxtgrd
Layer map
Skip cell
Temperature
有了以上所講述的Flow後，就可以輕鬆對deisgn進行RC Extraction了。但是我們應該如何確保工具抽的RC檔案SPEF是否正確呢？很多新手都是為了抽RC而去抽RC，抽完也完全不知道準確與否。如果你抽完RC並不能保證抽取結果是否正確，那prime time中的timing還準確嗎？因此小編總結下RC抽取應該要review的checklist，有了它從此不用擔心RC抽取出現問題。
RC抽取的checklist
nxtgrd和溫度檢查
Dummy
是否存在
short和open
關於short和open，這裡簡單提一下，因為實在是太重要了。如果你的design中存在short或者open，STAR-RC一定會報出來，一旦報出來基本上都是真的short或者open，所以請認真對待。
如果你確定你的database中並沒有short和open，而工具仍然報出來，那麼問題可能會變得很嚴重。因為大機率是database和milkyway不一致導致的。在出現問題，排除問題時，請
首先相信工具，排查自身問題
，往往大部分問題都是人為粗心導致的。
限於篇幅，關於checklist的細節可以前往知識星球上提問交流。
靜態時序分析STA
在當今的工藝製程下，設計的規模都非常大，使用傳統flatten方式來進行timing signof的方法已經慢慢不被大家所接受。一方面是整個timing signoff週期更長，另外一方面是對server提出了更高的挑戰。
prime time input&outputs
靜態時序分析Prime Time參考flow
對採用hierarchical方式的設計來說，其timing signoff主要要用到子模組的ETM，ITM和netlist。
ETM（Extracted Timing Model）
ETMs use abstraction to
minimize the amount of data
while attempting to preserve accuracy。
ETMs replace respective blocks in hierarchical timing analysis， which significantly
speed-up analysis
and reduce the memory footprint for the full-chip analysis。
ILM(Interface Logic Model)
The components within an ILM include a netlist， parasitic loading， constraints， and aggressor information pertinent to the preserved logic inside the ILM。 ILMs are
highly accurate
and can also speed up analysis considerably， while reducing the memory footprint。
從ETM和ILM的定義和模型上看，ILM比ETM更為準確，但是由於其大小較大，因此在hierarchical設計實現時更偏向於使用ETM模型。
SPEF
通常情況，我們為了更準確地看介面處的時序，我們還需要各個子模組提供各自的寄生引數檔案SPEF。這種方式其實你們也可以理解成flatten方式來進行timing signoff。由於這種方式還是各個子模組分別進行RC抽取，各自的工作仍然是並行的，我們仍然將這種timing signoff稱之為hierarchical timing signoff。
STA的checklist
Library是否已經update到新版本
這裡所說的library是指標準單元，memory，IP等library的db檔案。在timing signoff時，請務必檢查所有用到的db是foundary或者vendor release的最新版本。
Timing Constraint是否完備
因為工具的分析結果是基於特定的constraint檔案，所以如果你提供的timing constraint不正確或者不完備，那麼結果可能就不準確甚至是錯誤的。
SI等引數變數是否正確設定
CRPR能補償crosstalk嗎？
RC引數反標是否正確
PT跑完後，要養成檢視RC反標情況的習慣。我們可以透過report_annotated_parasitics來檢視，結果如下圖所示。請問下圖的report中是否所有net都反標上了？
Timing Signoff標準是否符合要求
對於hierarchical方式實現的設計，對於介面處的時序約束是否正確。比如我們抽子模組ETM時，已經含有ocv所帶進的derate值，如果在頂層分析時序時又對介面處再額外加derate值，則會出現過度悲觀的情況。
對於hierarchical方式實現的設計，可能各個子模組實現所用的library不一樣，比如B模組是用12Track做的，而top是用9Track來做實現的，那麼介面處的derate值應該如何設定呢？design的clock uncertainty應該如何設定呢？
以上為今天分享的內容，關於數字IC hierarchical設計實現Flow中物理驗證（DRC和LVS的詳細內容）過程的內容分享，敬請關注下期內容。
小編知識星球簡介（如果你渴望進步，期望高薪，喜歡交流，歡迎加入）：
在這裡，目前已經規劃並正著手做的事情：
ICC/ICC2 lab的編寫
基於ARM CPU的後端實現流程
利用ICC中CCD（Concurrent Clock Data）實現高效能模組的設計實現
基於ARM 四核CPU 數字後端Hierarchical Flow 實現教程
時鐘樹結構分析
低功耗設計實現
定期將專案中碰到的問題以案例的形式做技術分享
吾愛IC社群
知識星球星主為公眾號”吾愛IC社群”號主，從事數字ic後端設計實現工作近八年，擁有55nm，40nm，28nm，22nm，14nm等先進工藝節點成功流片經驗，成功tapeout過三十多顆晶片。
這裡是一個數字IC設計實現高度垂直細分領域的知識社群，聚集了無數數字ic前端設計，後端實現，模擬layout 工程師們。
在這裡大家可以多建立連線，多交流，多拓展人脈圈，甚至可以組織線下活動。 在這裡你可以就數字ic後端設計實現領域的相關問題進行提問，也可以就職業發展規劃問題進行諮詢，也可以把困擾你的問題拿出來一起討論交流。對於提問的問題儘量做到有問必答，如遇到不懂的，也會透過查閱資料或者請教專家來解答問題。在這裡鼓勵大家積極發表主題，提問，從而促進整個知識社群的良性迴圈。每個月小編會針對活躍使用者進行打賞。
最重要的是在這裡，能夠藉助這個知識社群，短期內實現
年薪百萬的夢想
！不管你信不信，反正已經進來的朋友肯定是相信的！相遇是一種緣分，相識更是一種難能可貴的情分！如若有緣你我一定會相遇相識！知識星球二維碼如下，可以掃描或者長按識別二維碼進入。目前已經有
220位
星球成員，感謝這
220位
童鞋的支援！歡迎各位渴望進步，期望高薪的鐵桿粉絲加入！
終極目標
是打造實現本知識星球
全員年薪百萬的宏偉目標
。
