lvs的一个报错问题[已解决]

damonzhao

刚才做了个实验,调用了一个CLKINVX32和DLY1X4
layout上是同一个GND,然后对应的pin分别为A1,Y1,VDD 和 A2, Y2, VCC

做的网表中,
.SUBCKT CLKINVX32 Y A inh_vdd
.....
.ENDS CLDINVX32

.SUBCKT DLY1X4 Y A inh_vdd
...
.ENDS DLY1X4


做的top我测试了两种网表方式：
方式一：cadence抽出网表的形式
.SUBCKT a A1 A2 Y1 Y2 VDD VCC GND
Xabd Y1 A1 VDD / CLKINVX32
Xcba Y2 A2 VCC / DLY1X4
.ENDs
方式二： calibre v2lvs转出网表的形式
.SUBCKT a A1 A2 Y1 Y2 VDD VCC GND
Xabc CLKINVX32 $PINS Y=Y1 A=A1 inh_vdd=VDD
Xcba DLY1X4 $PINS Y=Y2 A=A2 inh_vdd=VCC
.ENDS

由于上述两个单元原有网表中ground为VSS
所以还在网表中添加
*.equiv GND=VSS

另外添加 .GLOBAL VSS

上述两种网表都能通过LVS验证，你可以分析一下。希望对你的design有启发

estyzq

回复 32# damonzhao


    版主，你的两个字模块，CLKINV32和DL1X4，inh_vdd是后面加在spice网表上的吧？

inh_vdd在定义这两个网表的时候，是不是仅仅声明在了端口上？
比如说，CLKINV32，仅仅是在端口上加了一个inh_vdd，但是具体这个信号没有在内部中体现。

在顶层top（a）中，在调用CLKINV32时，做了“赋值”：inh_vdd=VDD？同时要在top(a)上，加上在CLKINV32和DLX4所要用的电源名称。

还有个问题，顶层(top)中为何要加上GND？

equiv可否用*CONNECT替代？

此时你的lvs规则文件的lvs power/ground name是什么？

我的做法也是这样的，可是就是会报lvs警告，我都怀疑是foundry的ip问题了

damonzhao

版主，你的两个字模块，CLKINV32和DL1X4，inh_vdd是后面加在spice网表上的吧？

对呀，只有spice网表才有.SUBCKT呀

inh_vdd在定义这两个网表的时候，是不是仅仅声明在了端口上？
比如说，CLKINV32，仅仅是在端口上加了一个inh_vdd，但是具体这个信号没有在内部中体现。

inh_vdd只是个阶层的信号，用来指代子单元的电源,可以把网表中该单元内部的相应电源变成inh_vdd，是为了规避VDD，VCC等可能当成GLOBAL的电源的名称

在顶层top（a）中，在调用CLKINV32时，做了“赋值”：inh_vdd=VDD？同时要在top(a)上，加上在CLKINV32和DLX4所要用的电源名称。
还有个问题，顶层(top)中为何要加上GND？

顶层上来说，从版图也可以知道应该含有那几个pin的，所以应该还有GND，
底层不同单元的inh_vdd应该对应接到VDD或VCC上
Xabc CLKINVX32 $PINS Y=Y1 A=A1 inh_vdd=VDD
Xcba DLY1X4 $PINS Y=Y2 A=A2 inh_vdd=VCC

equiv可否用*CONNECT替代？
网表中.equiv属于替换的意思，和calibre的*CONNECT应该属于两个意思。待查证

此时你的lvs规则文件的lvs power/ground name是什么？

我之前给你说过的，
LVS POWER “？？VDD？？” “？？VCC？？”
LVS GROUND “？？VSS？？” “？？GND？？”

我的做法也是这样的，可是就是会报lvs警告，我都怀疑是foundry的ip问题了

只能你自己分析网表和layout的连接情况了

damonzhao

estyzq 说：版主你好 最近又遇到一个lvs的问题，由于设计的需要我需要将所有的pad设置成一个black box（foundry有给 ...

这个怎么在帖子里看不到呀？

estyzq

回复 35# damonzhao
我后来需要做一个设计，本来core的电源需要core power pad接进来供电的，但是因为设计需要，没有使用core power pad，而是电源环裸露出来，然模拟的工程师接入电源到power ring上。这么做就导致了lvs的错误，如果我加上core power pad，同样的设计就没有问题。
后来，我想把所有的pad都作为black box，只检查pad的连接情况，这些pad都是foundry提供了spice网表的，但不需要检查pad里面的东西
我做了和你帖子介绍的方法一样的操作，从设置pad为black box，到black box的spice网表顶层的声明等，发现还是不能通过lvs。
折磨了很久，后来我问了前辈，他说这个错误可以不用管，还有那个eeprom的黑盒子的lvs警告（non-indetical power or ground nets or pins），我当时就凌乱了。。。。。。这有错的lvs他们都敢拿去投片。。。。。。

我想问问版主，还有没有什么别的方法，除了black box，能够用来只检查某个module或者macro的连接的？

还有一个问题，我感觉我修改spice网表，其目的是为了能够让gds提出来的网表和spice网表一样，但实际上gds已经固定下来了。如果gds是对的，那么修改这些spice网表不是没什么意义吗（就好像是在凑一个正确答案一样）？
因为我现在修的都是一些电源问题，或者说接口问题，这些问题，在apr的时候都是自动布线上去的，错了我也没招呐。
是不是说，设计中使用的std cell的lvs都正确了，那么pad的或者macro的lvs检查是否不用那么重视？

而且，感觉如果lvs真的有错误，我又是全部自动布局布线的，lvs要是错了我也不知道怎么修改。我感觉全自动的pr，lvs错了只能从edi导出gds的streamout map或者corner的旋转角度不对的问题入手，一般是没有问题的，不知道我这么理解对不对？

damonzhao

模拟的工程师接入电源到power ring上
你对应的lvs用网表怎么处理的呢？

还有没有什么别的方法，除了black box，能够用来只检查某个module或者macro的连接的？
如果只检查这个macro在它上层的端口连接，hier的lvs box就是最好的方法了

如果gds是对的，那么修改这些spice网表不是没什么意义吗（就好像是在凑一个正确答案一样）？
设计中使用的std cell的lvs都正确了，那么pad的或者macro的lvs检查是否不用那么重视？
设计中最不可靠的因素是人的因素，工具存在的价值就在于全面的检查盲区，认为gds是对的，但是你不能排除不同层次的单元调用时存在的overlap导致的short问题。所以顶层的检查要做，并且，有条件的话，不要什么lvs box等控制语句来进行最终验证。

感觉如果lvs真的有错误，我又是全部自动布局布线的，lvs要是错了我也不知道怎么修改。我感觉全自动的pr，lvs错了只能从edi导出gds的streamout map或者corner的旋转角度不对的问题入手，一般是没有问题的，不知道我这么理解对不对？
一般来讲，你这么说没错，但是也有例外的情况，比如metro工艺的，你以为pr后没问题了，但是lvs后发现器件不识别，后来分析发现忘了加WELL TIE单元，这样你的整个pr设计要重来。当然我说的极端个例，但是也能从一个角度说明了LVS的重要性。总之，项目中检查的越仔细越认真，分析的越到位，给你的片子的生产成功加的砝码越大