如题所述
物理验证是芯片physical signoff必须做的一项工作,类似timing signoff阶段要用PrimeTime来进行时序收敛。目前业界公认采用Mentor Graphics公司出品的Calibre工具,它提供了高效的DRC,LVS和ERC的解决方案,同时支持层次化和Flatten模式的检查方式,大大提高了整个验证过程的效率。
DRC检查
DRC检查是指工具基于Foundary提供的rule file来检查当前design的GDS是否符合工艺生产需求,比如base layer的检查,metal之间的spacing检查,via之间的spacing check,via enclosure check和metal denstiy的检查等。
如果发现DRC,工具会把对应的错误标出来,同时还会指出该地方违法了哪条rule。用户在使用calibre检查完DRC后,可以将DRC结果导入到PR工具中,高亮显示,分析产生此类DRC的根本原因,进而fix掉。
如何用工具自动修复数字IC后端设计实现绕线后的Physical DRC?
Hierarchical DRC
通过前面两个hierarchical flow的内容分享,我们知道现在的design基本上都是走的Hierarchical Flow(Chip规模比较大,Signoff周期可以缩短)。
仍然以之前分享的案例,Design A由子模块B,子模块C和Other Logic组成。当我们完成各个子模块和顶层的数字后端实现,我们需要将这些模块的GDS进行merge操作,合并成为一个Flatten A_merge.gds。最后再将这个merge好的GDS拿去跑DRC检查。
由于DRC检查并不是只检查,修改一次就可以马上收敛掉的。因此如果对于一个design每次都要通过将各个子模块merge成一个GDS再去跑DRC,那么整个DRC检查的周期可能增加一倍甚至更多。所以,我们在DRC检查前中期阶段,一般不采用这种方式。
那么,对于hierarchical设计实现的设计,我们应该如何大幅减少DRC检查周期呢?
DRC检查流程
各自模块的GDS Merge
各自模块DRC Check & Fixing
顶层A only的GDS merge (这里可以不merge下面的子模块)
顶层A only DRC Check & Fixing
采用这种方式的DRC检查应该特别关注以下几点
模块拼接地方的PG (Metal的spacing & Base layer DRC )
模块interface的 天线效应
教你轻松玩转天线效应(Process Antenna Effect)
DRC Fixing的方法和手段
吾爱IC社区我再次强调下,DRC Fixing千万不要去手工fix,这真的不应该是你们该干的活,它应属于 tool的本职工作 。能自动化的东西尽量要自动实现。特别是在22nm及以下工艺节点,由于底层有几层metal是属于 double pattern的layer ,手工修DRC也变得不太现实,往往手工修DRC会越修越多。
添加route guide(route blockage)
调整cell的位置
换VIA的类型或者VIA数量
想彻底摆脱手工修复DRC的困境,可以前往我知识星球上查阅。如果仍然有技术困惑,也可以在星球上提问。
LVS检查
LVS(Layout VS Schematic)检查主要是检查自动布局布线后的layout(Physical)是否Schematic(Logic)是一致的。很多初学者可能会觉得既然PR工具自己完成的布局布线,那么写出来的GDS理论上一定与逻辑功能是一致的。为何还要多此一举呢?
的确从APR工具本身来说,它确实不会改变原来的逻辑功能,仅仅只会做一些优化,但是跑APR的command是人为指定的,而且整个PR过程没有你们想象中的那么美好,还是有很多的人工干预步骤。比如你在ICC中为了修short删了一些线,为了修DRC的spacing问题,可能会将某些线open掉了。而一旦存在net open,那显然就是physical和logic是不match的,LVS检查结果一定是incorrect的。
不知道各位还记得我之前分享过一个确保PR出去的GDS一定是LVS clean的方法吗?
Verify_pg_net (check_pg_connectivity)
Verify_lvs (check_lvs )
以上两大法宝请各位理解清楚并在工作中熟练使用。
Hierarchical LVS检查流程
PR工具吐GDS和Netlist
LVS数据准备阶段,PR完成自动布局布线后,需要通过写出设计的GDS和Netlist。写netlist需要特别留意,比如physical only cell是不需要写出来的。
整理Hcell list
一般情况下,为了LVS检查debug的便利性,我们强烈建议使用HCELL来进行LVS的比对。这个hcell list主要包含任何有device的cell,可以在PR工具中写个小脚本来获得。
Merge GDS
这里的Merge GDS需要将子模块A和B都merge进去,合并成一个整体的GDS,而不像跑Hierarchical DRC时不需要merge下面的子模块。这点需要特别注意。
Create_text
在比LVS之前,还需要给design的GDS打上标签text,主要是给power net groud net打上对应的net名字。对于做power domain的设计,有时候还需要给local的power net打text,视情况而定。打text这步既可以在PR工具中完成,也可以在calibre中完成。
V2LVS
PR吐出的netlist是gate level的netlist,而calibre LVS所需要的数据输入netlist必须是spice格式的,因此需要通过calibre工具提供的v2lvs进行转换。
值得提出的是,在hierarchical设计中,模块接口处的信号可能会存在位宽顺序不一致,比如八位宽的信号,子模块可能是从0-7,而顶层调用可能是从1-7。碰到这种情况需要带上 -l的选项 ,即转换spice netlist时读入子模块的netlist。
抽取GDS
LVS检查本质是将两个netlist进行对比,因此需要对design的GDS进行netlist抽取,这步往往需要消耗大量的时间。为了提高工作效率,同一个GDS只需要抽取一次netlist即可,后续LVS的比对只需要拿抽取后的netlist即可。
Netlist对比
将GDS抽取后的netlist与v2lvs转换后的spice netlist进行比对。对于hierarchical LVS比对中,还需要将子模块A和B设置bbox,这样工具在做LVS检查时,只检查子模块和顶层接口处,而不会trace到子模块内部中,大大节省了LVS的检查时间。
无论DRC检查还是LVS检查,建议大家养成使用脚本的方式来check,而不是还停留在使用gui界面来操作。每次我看到不少人用gui来操作,我都替他着急。能自动化实现的东西为何要每次通过鼠标去点呢?本文中所用到的create text,Merge GDS,DRC和LVS检查的详细脚本可以移步知识星球查阅。
ERC检查
ERC检查主要是检查版图的电性能,比如衬底是否正确连接电源或地,有无栅极悬空等。说的再直白点就是检查电路中是否存在input floating的现象。大家还记得我之前在知识星球上分享的检查input floating的golden脚本吗?那个脚本是检查gate level的input floating,比如与非门的一个输入端悬空问题,通过这个脚本可以直接报告出来。而ERC检查则是device level的input floating检查,你们可以将它理解成GDS flatten level的input floating检查 。
ERC的检查规则还是蛮复杂的,一般foundary提供的rule file比较通用,在实际项目中往往会报出很多假错,比如tie high和tie low cell上报ERC错误。因此为了更高效地debug ERC问题,需要按照自己的需求改rule file,然后再去RUN ERC,否则ERC假错太多,很难定位到真问题。
DRC检查
DRC检查是指工具基于Foundary提供的rule file来检查当前design的GDS是否符合工艺生产需求,比如base layer的检查,metal之间的spacing检查,via之间的spacing check,via enclosure check和metal denstiy的检查等。
如果发现DRC,工具会把对应的错误标出来,同时还会指出该地方违法了哪条rule。用户在使用calibre检查完DRC后,可以将DRC结果导入到PR工具中,高亮显示,分析产生此类DRC的根本原因,进而fix掉。
如何用工具自动修复数字IC后端设计实现绕线后的Physical DRC?
Hierarchical DRC
通过前面两个hierarchical flow的内容分享,我们知道现在的design基本上都是走的Hierarchical Flow(Chip规模比较大,Signoff周期可以缩短)。
仍然以之前分享的案例,Design A由子模块B,子模块C和Other Logic组成。当我们完成各个子模块和顶层的数字后端实现,我们需要将这些模块的GDS进行merge操作,合并成为一个Flatten A_merge.gds。最后再将这个merge好的GDS拿去跑DRC检查。
由于DRC检查并不是只检查,修改一次就可以马上收敛掉的。因此如果对于一个design每次都要通过将各个子模块merge成一个GDS再去跑DRC,那么整个DRC检查的周期可能增加一倍甚至更多。所以,我们在DRC检查前中期阶段,一般不采用这种方式。
那么,对于hierarchical设计实现的设计,我们应该如何大幅减少DRC检查周期呢?
DRC检查流程
各自模块的GDS Merge
各自模块DRC Check & Fixing
顶层A only的GDS merge (这里可以不merge下面的子模块)
顶层A only DRC Check & Fixing
采用这种方式的DRC检查应该特别关注以下几点
模块拼接地方的PG (Metal的spacing & Base layer DRC )
模块interface的 天线效应
教你轻松玩转天线效应(Process Antenna Effect)
DRC Fixing的方法和手段
吾爱IC社区我再次强调下,DRC Fixing千万不要去手工fix,这真的不应该是你们该干的活,它应属于 tool的本职工作 。能自动化的东西尽量要自动实现。特别是在22nm及以下工艺节点,由于底层有几层metal是属于 double pattern的layer ,手工修DRC也变得不太现实,往往手工修DRC会越修越多。
添加route guide(route blockage)
调整cell的位置
换VIA的类型或者VIA数量
想彻底摆脱手工修复DRC的困境,可以前往我知识星球上查阅。如果仍然有技术困惑,也可以在星球上提问。
LVS检查
LVS(Layout VS Schematic)检查主要是检查自动布局布线后的layout(Physical)是否Schematic(Logic)是一致的。很多初学者可能会觉得既然PR工具自己完成的布局布线,那么写出来的GDS理论上一定与逻辑功能是一致的。为何还要多此一举呢?
的确从APR工具本身来说,它确实不会改变原来的逻辑功能,仅仅只会做一些优化,但是跑APR的command是人为指定的,而且整个PR过程没有你们想象中的那么美好,还是有很多的人工干预步骤。比如你在ICC中为了修short删了一些线,为了修DRC的spacing问题,可能会将某些线open掉了。而一旦存在net open,那显然就是physical和logic是不match的,LVS检查结果一定是incorrect的。
不知道各位还记得我之前分享过一个确保PR出去的GDS一定是LVS clean的方法吗?
Verify_pg_net (check_pg_connectivity)
Verify_lvs (check_lvs )
以上两大法宝请各位理解清楚并在工作中熟练使用。
Hierarchical LVS检查流程
PR工具吐GDS和Netlist
LVS数据准备阶段,PR完成自动布局布线后,需要通过写出设计的GDS和Netlist。写netlist需要特别留意,比如physical only cell是不需要写出来的。
整理Hcell list
一般情况下,为了LVS检查debug的便利性,我们强烈建议使用HCELL来进行LVS的比对。这个hcell list主要包含任何有device的cell,可以在PR工具中写个小脚本来获得。
Merge GDS
这里的Merge GDS需要将子模块A和B都merge进去,合并成一个整体的GDS,而不像跑Hierarchical DRC时不需要merge下面的子模块。这点需要特别注意。
Create_text
在比LVS之前,还需要给design的GDS打上标签text,主要是给power net groud net打上对应的net名字。对于做power domain的设计,有时候还需要给local的power net打text,视情况而定。打text这步既可以在PR工具中完成,也可以在calibre中完成。
V2LVS
PR吐出的netlist是gate level的netlist,而calibre LVS所需要的数据输入netlist必须是spice格式的,因此需要通过calibre工具提供的v2lvs进行转换。
值得提出的是,在hierarchical设计中,模块接口处的信号可能会存在位宽顺序不一致,比如八位宽的信号,子模块可能是从0-7,而顶层调用可能是从1-7。碰到这种情况需要带上 -l的选项 ,即转换spice netlist时读入子模块的netlist。
抽取GDS
LVS检查本质是将两个netlist进行对比,因此需要对design的GDS进行netlist抽取,这步往往需要消耗大量的时间。为了提高工作效率,同一个GDS只需要抽取一次netlist即可,后续LVS的比对只需要拿抽取后的netlist即可。
Netlist对比
将GDS抽取后的netlist与v2lvs转换后的spice netlist进行比对。对于hierarchical LVS比对中,还需要将子模块A和B设置bbox,这样工具在做LVS检查时,只检查子模块和顶层接口处,而不会trace到子模块内部中,大大节省了LVS的检查时间。
无论DRC检查还是LVS检查,建议大家养成使用脚本的方式来check,而不是还停留在使用gui界面来操作。每次我看到不少人用gui来操作,我都替他着急。能自动化实现的东西为何要每次通过鼠标去点呢?本文中所用到的create text,Merge GDS,DRC和LVS检查的详细脚本可以移步知识星球查阅。
ERC检查
ERC检查主要是检查版图的电性能,比如衬底是否正确连接电源或地,有无栅极悬空等。说的再直白点就是检查电路中是否存在input floating的现象。大家还记得我之前在知识星球上分享的检查input floating的golden脚本吗?那个脚本是检查gate level的input floating,比如与非门的一个输入端悬空问题,通过这个脚本可以直接报告出来。而ERC检查则是device level的input floating检查,你们可以将它理解成GDS flatten level的input floating检查 。
ERC的检查规则还是蛮复杂的,一般foundary提供的rule file比较通用,在实际项目中往往会报出很多假错,比如tie high和tie low cell上报ERC错误。因此为了更高效地debug ERC问题,需要按照自己的需求改rule file,然后再去RUN ERC,否则ERC假错太多,很难定位到真问题。
温馨提示:答案为网友推荐,仅供参考