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分析的基础上，可以更好的利用现有资源。
参考资料
Cadence _Innovus user guide_
Synopsys _ICC user guide_
Cadence _CDN support center_
作者：艾思后端设计
文章来源：艾思后端实现
推荐阅读
更多嵌入式AI干货请关注嵌入式AI专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
