innovus里邊有不少physical DRC檢查工具，其中的verifyConnectivity 別有一番有趣的用法，借此機會，一起來看看其中的一個亮點。

在innovus工具里邊，用戶經常會使用verifyConnectivity 來進行open ，繞線完整性等問題的查驗。對于繞線結果，尤其是PG繞線結果，使用這個命令可以很好的幫助用戶在power planning階段查驗PG的閉合連接的狀態（在pg DB中使用，有點類似S家的verify_pg_nets ），這個命令的檢查點包括并不限于

PG的整體貫通性：open check

macro的PG pin 連接閉合

信號開路檢查 (signal routing open)

懸垂繞線/天線效應檢查（DanglingWire/Antenna）

上述前三點都是比較常規的檢查，通常沒有太多的歧義，但是對于最后一個DanglingWire/Antenna，INVS有自己獨到的理解方式，這里仔細理解和分析以下這個檢查項目

DanglingWire的原理描述

DanglingWire描述：wire通常是指連接在某一個pin/terminal的net在物理上的形狀，Danglng是指這個wire后面有沒有連接任何的負載，如果這個wire同時也連接在其他的input pin，由于這個DanglingWire的存在，勢必會引入潛在的antenna問題，這就是為什么INVS把DanglingWire和antenna標注在一起的原因。



在上述拓撲結構結構中，有兩個連結關系：U1.Z -> U2.A 和 U1.Z -> U3.A ，對應的實際物理繞線如上述黑色和紅色走線標記。這種繞線方式在INVS的verifyConnectivity評判里，就會將紅色部分的繞線（wire）報告一個DanglingWire的問題。
紅色部分繞線已經對這個繞線閉合結構沒有任何貢獻，同時還會導致net1的繞線被無意中變長，這樣的繞線會導致三個影響：

紅色繞線部分會占用額外的繞線資源，但是對數據庫有沒有貢獻，所以這是對繞線資源的浪費

紅色繞線會讓net1的RC變大， 會讓net1的傳輸變慢，導致不期望的延遲

對于U2.A和U3.A 輸入pin而言，由于輸入管腳對應的繞線變長，紅色繞線有可能導致更多的輸入管腳的antenna違例。

由于PG via drop的特點，這種DanglingWire的情形在PG 繞線會比較常見，反而由于NanoRoute特有的算法，對于信號連接，基本不會出現DanglingWire的現象。



這里的PG連接是從M6 -> VIA56 -> M5，從INVS的理解來看，這條M5 wire的的最右側部分（從VIA56結束一直到M5的最右端，紅色高亮區域），是一小段的DanglingWire繞線，因為在VIA56的部分，這條M5已經完成了PG貫通的使命，多出來的那部分就被INVS判定為沒有貢獻的DanglingWire。

在PG創建的時候，無法在addStripe的命令從根本上解決，這是因為PG stripe通常都是兩橫兩縱的布局，總會有一個VIA56 距離M5的端點較遠。



如上圖所示，盡管PG 布局里邊已經將VSS的VIA56推到了最右側，但是VDD的DanglingWire還是無法避免。由此可見，用戶在創建PG的時候。在使用同樣M6/M5的時候，通過調整offset，可以讓DanglingWire問題緩解，可以間接的提高IR的質量，但是不能根治DanglingWire的問題

DanglingWire問題的解決方法

INVS評判DanlingWire的標準是：wire走線在通過最右一個有效連結VIA或者load_pin后，繞線長度不能超過走線寬度的一半，否則會被判定為DanglingWire



以上圖為例，對于上邊比較短的M5是沒有DanglingWire違例的。可以看到，此時M5的右側只比VIA56的右側超出了0.825um，正好是M5繞線寬度的一半（0.162/2），這個時候就不會出現DanglingWire的問題了。對應的下邊的M5，右側長度沒有修剪，所以依然能看到DanglingWire的違例。

經測算，在這個示例當中，通過縮短M5的長度，可以釋放大概7.375um的M5的繞線資源

Std-cell rail 的DanlingWire 問題理解

假設當前設計的std-cell PG rail在M1層，INVS對M1的關注和M5是一致的，如果用戶沒有進行任何的preplace std-cell的規劃，布局（包括tapcell，endcap等pre-place的器件），或者preplace std-cell的節點距離M1的終點有一些距離，那么在PG里邊也會報告類似的DanglingWire的問題。



但是，這樣的M1 DanglingWire會在chipfinish的時候完全消失，這是因為所有的std-cell row上，最后都會布滿std-cell或者std-filler，這個M1上的DanglingWire的違例在PD DB上不需要理會，除非是這個區域不需要放置std-cell，那么用戶需要從site-row的剪裁下手，節約std-cell的資源占用 同樣的數據庫，在進入到chipfinish后，M1的DanglingWire已經自愈了。

DanglingWire 和 open的區別

經過上述的討論，應該已經很好的理解INVS里邊對于DanglingWire的定義，對于普通用戶而言，DanglingWire的影響主要是侵占一些設計的繞線資源（但是要注意不同階段的DanglingWire由于負載的改變，這個違例的形態會發生一定的變化，譬如上述的std-cell rail 的DanglingWire問題）。相較而言，用戶更應該優先關注open問題，
INVS 對open有兩種定義：

對于同樣的net，但是沒有連接在一起的wire piece，這里的定義比較像S家的 floating shape，譬如下圖左側的幾個wire piece，這個就是open（也就是常說的floating shape），如果確定不需要，也可以做直接刪除處理

但是，更為常見的open，是缺少從M6到M1 的VIA，這個時候就是需要用戶及時處理，否則最后的LVS是過不去的

沒有連接到網絡的PG pin：UnConnPin

這里需要注意一點，由于INVS的verifyConnectivity 是基于wire shape的，所以如果需要查驗某一個net的open或者UnConnPin，前提是這個net至少一根wire shape，否則INVS會給出下列提示，



同時，會在Violations Browser里邊以NoRoute 表示出來：意即該net沒有任何的wire shape

【敲黑板劃重點】

INVS里的DanglingWire是潛在的繞線資源浪費，需要用戶自行判斷，并進行處理，在不影響IR分析的基礎上，可以更好的利用現有資源。

審核編輯：劉清