innovus中悬垂线的理解和处理-电子发烧友网

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