下冰雹 · 2023年06月08日

innovus中的DanglingWire(悬垂线)的理解和处理

innovus里边有不少physical DRC检查工具,其中的verifyConnectivity 别有一番有趣的用法,借此机会,一起来看看其中的一个亮点。

image.png

在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标注在一起的原因。

image.png

在上述拓扑结构结构中,有两个连结关系: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的现象。

image.png

这里的PG连接是从M6 -> VIA56 -> M5,从INVS的理解来看,这条M5 wire的的最右侧部分(从VIA56结束一直到M5的最右端,红色高亮区域),是一小段的DanglingWire绕线,因为在VIA56的部分,这条M5已经完成了PG贯通的使命,多出来的那部分就被INVS判定为没有贡献的DanglingWire。
在PG创建的时候,无法在addStripe的命令从根本上解决,这是因为PG stripe通常都是两横两纵的布局,总会有一个VIA56 距离M5的端点较远。

image.png

如上图所示,尽管PG 布局里边已经将VSS的VIA56推到了最右侧,但是VDD的DanglingWire还是无法避免。由此可见,用户在创建PG的时候。在使用同样M6/M5的时候,通过调整offset,可以让DanglingWire问题缓解,可以间接的提高IR的质量,但是不能根治DanglingWire的问题

DanglingWire问题的解决方法

INVS评判DanlingWire的标准是:wire走线在通过最右一个有效连结VIA或者load\_pin后,绕线长度不能超过走线宽度的一半,否则会被判定为DanglingWire

image.png

以上图为例,对于上边比较短的M5是没有DanglingWire违例的。可以看到,此时M5的右侧只比VIA56的右侧超出了0.825um,正好是M5绕线宽度的一半(0.162/2),这个时候就不会出现DanglingWire的问题了。对应的下边的M5,右侧长度没有修剪,所以依然能看到DanglingWire的违例。
经测算,在这个示例当中,通过缩短M5的长度,可以释放大概 7.375um 的M5的绕线资源

image.png

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的问题。

image.png

但是,这样的M1 DanglingWire会在chipfinish的时候完全消失,这是因为所有的std-cell row上,最后都会布满std-cell或者std-filler,这个M1上的DanglingWire的违例在PD DB上不需要理会,除非是这个区域不需要放置std-cell,那么用户需要从site-row的剪裁下手,节约std-cell的资源占用

同样的数据库,在进入到chipfinish后,M1的DanglingWire已经自愈了。
image.png

DanglingWire 和 open的区别

经过上述的讨论,应该已经很好的理解INVS里边对于DanglingWire的定义,对于普通用户而言,DanglingWire的影响主要是侵占一些设计的绕线资源(但是要注意不同阶段的DanglingWire由于负载的改变,这个违例的形态会发生一定的变化,譬如上述的std-cell rail 的DanglingWire问题)。相较而言,用户更应该优先关注open问题,
INVS 对open有两种定义:

  • 对于同样的net,但是没有连接在一起的wire piece,这里的定义比较像S家的 floating shape,譬如下图左侧的几个wire piece,这个就是open(也就是常说的floating shape),如果确定不需要,也可以做直接删除处理

image.png

但是,更为常见的open,是缺少从M6到M1 的VIA,这个时候就是需要用户及时处理,否则最后的LVS是过不去的

image.png

  • 没有连接到网络的PG pin:UnConnPin

这里需要注意一点,由于INVS的verifyConnectivity 是基于wire shape的,所以如果需要查验某一个net的open或者UnConnPin,前提是这个net至少一根wire shape,否则INVS会给出下列提示,

image.png

同时,会在Violations Browser里边以NoRoute 表示出来:意即该net没有任何的wire shape

image.png

敲黑板划重点

INVS里的DanglingWire是潜在的绕线资源浪费,需要用户自行判断,并进行处理,在不影响IR分析的基础上,可以更好的利用现有资源。

参考资料

Cadence _Innovus user guide_
Synopsys _ICC user guide_
Cadence _CDN support center_

作者:艾思后端设计
文章来源:艾思后端实现

推荐阅读

更多嵌入式AI干货请关注嵌入式AI专栏。欢迎添加极术小姐姐微信(id:aijishu20)加入技术交流群,请备注研究方向。
推荐阅读
关注数
10944
内容数
1211
主要交流IC以及SoC设计流程相关的技术和知识
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息