关于instance padding产生overlap warnning的问题

墨默

   在place阶段，为了 解congestion问题，我加了instance padding（route后short只有几个）。然而在eco阶段 source xtop_opt_innovus 脚本（修hold）时，报overlap warning的同时，ecoRoute绕线困难，short从27w开始往下修、很难修，修5 6轮就花了12个多小时。
    所以，我想问一下：为什么instance padding会对xtop插入的buffer造成overlap和绕线困难呢？同样的，module padding是否会产生同样的问题？
如果是的话，module/instance padding是否要删掉？在哪一个阶段要删掉？（以及为什么在这个阶段？）删掉之后会对short、timing产生怎样的影响？
求大神解答~

king-wa

mark 一下

墨默

king-wa 发表于 2022-9-29 09:32
mark 一下

您好，可以说详细一点吗？

suzhouwuyanzu

xtop插的cell又扎堆了？

suzhouwuyanzu

可以先把xtop脚本吃进去然后抓一下位置看看

king-wa

墨默 发表于 2022-9-29 09:34
您好，可以说详细一点吗？

我的意思是我也关注一下哈

墨默

suzhouwuyanzu 发表于 2022-9-29 14:20
可以先把xtop脚本吃进去然后抓一下位置看看

插入了近20000个BUF和DEL，我抓了位置，有一部分集中在congestion附近，和我设置“ instance padding  -left 2 -right 2 ”的地方 相互交错。此外我也试着ecoRoute了一次，short从 万 开始往下修，且short就在这个区域的 4 5 6 三层。——先吃 再删。

另外一版，我先用“ deleteInstPad -all ”命令删padding ，然后再吃进xtop脚本，然后绕线 结果差不多，修short也很费时间。
##############

【最新进展】
我又重开了一版，从手修hold的DB开始，然后跑一轮xtop（脚本6000+条 ecoChangeCell命令，没插buf）。现在跑eco short情况就正常许多，就几个了，和修hold前差不多。timing结果还不知道。
###############

所以，是我xtop脚本出问题了？？？ 不应该呀，设置应该没问题呀。

suzhouwuyanzu

墨默 发表于 2022-9-29 17:26
插入了近20000个BUF和DEL，我抓了位置，有一部分集中在congestion附近，和我设置“ instance padding  -l ...

没出问题，但这里的绕线资源已经接近极限了，xtop也只是预估了一下这里的绕线情况
这里想修下去只能控制cell不要那么密集了