#### 數字IC設計實現hierarchical flow物理驗證Physical Verification 物理驗證是芯片physical signoff必須做的一項工作，類似timing signoff階段要用PrimeTime來進行時序收斂。目前業界公認采用Mentor Graphics公司出品的Calibre工具，它提供了高效的DRC，LVS和ERC的解決方案，同時支持層次化和Flatten模式的檢查方式，大大提高了整個驗證過程的效率。 **DRC檢查** DRC檢查是指工具基于Foundary提供的rule file來檢查當前design的GDS是否符合工藝生產需求，比如base layer的檢查，metal之間的spacing檢查，via之間的spacing check，via enclosure check和metal denstiy的檢查等。 如果發現DRC，工具會把對應的錯誤標出來，同時還會指出該地方違法了哪條rule。用戶在使用calibre檢查完DRC后，可以將DRC結果導入到PR工具中，高亮顯示，分析產生此類DRC的根本原因，進而fix掉。 [如何用工具自動修復數字IC后端設計實現繞線后的Physical DRC?](https://link.zhihu.com/?target=http%3A//mp.weixin.qq.com/s%3F__biz%3DMzU5NzQ1NDI5Nw%3D%3D%26mid%3D2247484153%26idx%3D1%26sn%3D648f4ff1977f8eeb19ecb9bfc872238f%26chksm%3Dfe527e4fc925f7593fbdd4de792026c9ab0daf50e7cc84e7f674b686c8b8978b865f812d40a4%26scene%3D21%23wechat_redirect) **Hierarchical DRC** 通過前面兩個hierarchical flow的內容分享，我們知道現在的design基本上都是走的Hierarchical Flow（Chip規模比較大，Signoff周期可以縮短）。 仍然以之前分享的案例，Design A由子模塊B，子模塊C和Other Logic組成。當我們完成各個子模塊和頂層的數字后端實現，我們需要將這些模塊的GDS進行merge操作，合并成為一個Flatten A\_merge.gds。最后再將這個merge好的GDS拿去跑DRC檢查。  由于DRC檢查并不是只檢查，修改一次就可以馬上收斂掉的。因此如果對于一個design每次都要通過將各個子模塊merge成一個GDS再去跑DRC，那么整個DRC檢查的周期可能增加一倍甚至更多。所以，我們在DRC檢查前中期階段，一般不采用這種方式。 那么，對于hierarchical設計實現的設計，我們應該如何大幅減少DRC檢查周期呢? **DRC檢查流程** * 各自模塊的GDS Merge * 各自模塊DRC Check & Fixing * 頂層A only的GDS merge (這里可以不merge下面的子模塊) * 頂層A only DRC Check & Fixing 采用這種方式的DRC檢查應該特別關注以下幾點 * 模塊拼接地方的PG (Metal的spacing & Base layer DRC ) * 模塊interface的**天線效應** **[教你輕松玩轉天線效應(Process Antenna Effect)](https://link.zhihu.com/?target=http%3A//mp.weixin.qq.com/s%3F__biz%3DMzU5NzQ1NDI5Nw%3D%3D%26mid%3D2247484049%26idx%3D1%26sn%3D3fded05a51a3c43f1c5a2fca7e91960e%26chksm%3Dfe527e27c925f7313c879dbbd7ecbfc47f1ccde4abb3c4c862bc6a01da6f5e3dc8445ec191e7%26scene%3D21%23wechat_redirect)** **DRC Fixing的方法和手段** 吾愛IC社區小編再次強調下，DRC Fixing千萬不要去手工fix，這真的不應該是你們該干的活，它應屬于**tool的本職工作**。能自動化的東西盡量要自動實現。特別是在22nm及以下工藝節點，由于底層有幾層metal是屬于**double pattern的layer**，手工修DRC也變得不太現實，往往手工修DRC會越修越多。 * 添加route guide（route blockage） * 調整cell的位置 * 換VIA的類型或者VIA數量 想徹底擺脫手工修復DRC的困境，可以前往小編知識星球上查閱。如果仍然有技術困惑，也可以在星球上提問。 **LVS檢查** LVS(Layout VS Schematic)檢查主要是檢查自動布局布線后的layout（Physical)是否Schematic（Logic）是一致的。很多初學者可能會覺得既然PR工具自己完成的布局布線，那么寫出來的GDS理論上一定與邏輯功能是一致的。為何還要多此一舉呢？ 的確從APR工具本身來說，它確實不會改變原來的邏輯功能，僅僅只會做一些優化，但是跑APR的command是人為指定的，而且整個PR過程沒有你們想象中的那么美好，還是有很多的人工干預步驟。比如你在ICC中為了修short刪了一些線，為了修DRC的spacing問題，可能會將某些線open掉了。而一旦存在net open，那顯然就是physical和logic是不match的，LVS檢查結果一定是incorrect的。  不知道各位還記得小編之前分享過一個確保PR出去的GDS一定是LVS clean的方法嗎？ * Verify\_pg\_net (check\_pg\_connectivity) * Verify\_lvs (check\_lvs ) 以上兩大法寶請各位理解清楚并在工作中熟練使用。 **Hierarchical LVS檢查流程** * PR工具吐GDS和Netlist LVS數據準備階段，PR完成自動布局布線后，需要通過寫出設計的GDS和Netlist。寫netlist需要特別留意，比如physical only cell是不需要寫出來的。 * 整理Hcell list 一般情況下，為了LVS檢查debug的便利性，我們強烈建議使用HCELL來進行LVS的比對。這個hcell list主要包含任何有device的cell，可以在PR工具中寫個小腳本來獲得。 * Merge GDS 這里的Merge GDS需要將子模塊A和B都merge進去，合并成一個整體的GDS，而不像跑Hierarchical DRC時不需要merge下面的子模塊。這點需要特別注意。 * Create\_text 在比LVS之前，還需要給design的GDS打上標簽text，主要是給power net groud net打上對應的net名字。對于做power domain的設計，有時候還需要給local的power net打text，視情況而定。打text這步既可以在PR工具中完成，也可以在calibre中完成。 * V2LVS PR吐出的netlist是gate level的netlist，而calibre LVS所需要的數據輸入netlist必須是spice格式的，因此需要通過calibre工具提供的v2lvs進行轉換。 值得提出的是，在hierarchical設計中，模塊接口處的信號可能會存在位寬順序不一致，比如八位寬的信號，子模塊可能是從0-7，而頂層調用可能是從1-7。碰到這種情況需要帶上**\-l的選項**，即轉換spice netlist時讀入子模塊的netlist。 * 抽取GDS LVS檢查本質是將兩個netlist進行對比，因此需要對design的GDS進行netlist抽取，這步往往需要消耗大量的時間。為了提高工作效率，同一個GDS只需要抽取一次netlist即可，后續LVS的比對只需要拿抽取后的netlist即可。 * Netlist對比 將GDS抽取后的netlist與v2lvs轉換后的spice netlist進行比對。對于hierarchical LVS比對中，還需要將子模塊A和B設置bbox，這樣工具在做LVS檢查時，只檢查子模塊和頂層接口處，而不會trace到子模塊內部中，大大節省了LVS的檢查時間。 無論DRC檢查還是LVS檢查，建議大家養成使用腳本的方式來check，而不是還停留在使用gui界面來操作。每次小編看到不少人用gui來操作，我都替他著急。能自動化實現的東西為何要每次通過鼠標去點呢？本文中所用到的create text，Merge GDS，DRC和LVS檢查的詳細腳本可以移步知識星球查閱。 **ERC檢查** ERC檢查主要是檢查版圖的電性能，比如襯底是否正確連接電源或地，有無柵極懸空等。說的再直白點就是檢查電路中是否存在input floating的現象。大家還記得小編之前在知識星球上分享的檢查input floating的golden腳本嗎？那個腳本是檢查gate level的input floating，比如與非門的一個輸入端懸空問題，通過這個腳本可以直接報告出來。而ERC檢查則是device level的input floating檢查，你們可以將它理解成GDS**flatten level的input floating檢查**。 ERC的檢查規則還是蠻復雜的，一般foundary提供的rule file比較通用，在實際項目中往往會報出很多假錯，比如tie high和tie low cell上報ERC錯誤。因此為了更高效地debug ERC問題，需要按照自己的需求改rule file，然后再去RUN ERC，否則ERC假錯太多，很難定位到真問題。