在线咨询
eetop公众号 创芯大讲堂 创芯人才网
切换到宽版

EETOP 创芯网论坛 (原名:电子顶级开发网)

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
查看: 3036|回复: 7

Latch up Rule的难点

[复制链接]
发表于 2018-8-19 16:10:13 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?注册

x

    在 IC设计规则中,我们经常遇到有关Latch up rule的描述,这些规则由于不太容易在DRC Code中实现,因此,大部分Foundry给设计工程师的建议是:通过“目视”的手段来手工检查这些规则,这给设计留下了一些隐患。




Latchup Rule
最常见的规则是“隔离”或者“挡住”问题,如下:



1.JPG



    该规则要求在IO区域到内部区域必须有一个完整的Guard Ring隔离开,上图中左边图形是符合设计规则的,而右边图形是不符合设计规则的。



     看起来似乎很简单,但是,由于通用的DRC工具只支持2layer的相互关系检查,不支持3layer的几何操作,而隔离问题一般都是要求layer Alayer B之间必须有layer C的隔离,它是一个典型的3 layer操作,该如何解决呢?



     除了正对方向的隔离问题,斜线方向的隔离也是常见的规则,如下:



2.JPG



    上图中,从IO区域到内部区域不是正对的方向,而是斜线的方向,规则要求二者之间也要有Guard Ring隔离。可以看到,竖向的隔离层把虚线斜线区域全部隔离开了,符合规则。而横向的隔离层图形长度不够长,没有完全把IO到内部区域隔离,需要报错。



     那么,斜线的隔离检查又该如何做呢?



     除了IO区域与内部区域是否有GuardRing隔离的问题,同时隔离的Guard Ring还有顺序的问题,如下:



3.JPG



    左边图示从IO区域到内部区域是先PGuard Ring,后N Guard Ring,其顺序是正确的,而右边图形顺序反了,是不符合规则的。顺序问题该如何检查呢?




    不仅是IO区域到内部区域需要有隔离规则,内部区域的mos管如果total width比较大,同样也需要有隔离规则,如下:


4.JPG



     左图是一个totalwidth超过了一定范围的NMOS管,它右侧首先保证有一个Guard Ring把它与pmos管隔开,同时规则还要求pmos左边还要有一个VDD contactpickup把其与Guard Ring隔离。右侧图形,VDD contact的位置不对,没有位于pmos管与Nch之间,因此不符合设计规则。



    总结这些规则的共同点,“隔离”或者“挡住”问题是Latch up最基本的检查,所谓挡住就是指在layerA, LayerB之间检查是否有layer C的图形挡住。


     需求:提供一个三layer输入的基本命令


     常用的DRC工具只提供1layer或者2layer的检查命令,不提供三layer输入的检查命令。 如果利用DRC的多个命令组合来生成上述命令,由于普通的DRC命令会将不同图形的结果连成一片,会导致报错结果无法区分具体的区域,失去了检查的意义。如下图所示:



5.JPG



    上图中,黄色图形是IO区域,红色图形是内部区域的mos管,要检查在黄色图形与绿色图形之间在200um范围内是否有一个绿色的图形被隔离开。



    普通的DRC命令方法是:首先把红色图形和黄色图形做一个间距为200um的检查,把左右的报错结果组合成一个或多个多边形图形,然后判断这个多边形图形是否被绿色图形隔断了。



    上述方法的问题是: 当绿色图形只要位于200um的范围内隔离了某几个mos管,就会被判定为把所有的mos管都隔离开了。上图中的绿色图形与黄色图形之间还有几个红色mos管没有被实际隔离,但是DRC Code的间距检查由于把结果连接成了一个大片的图形,它无法判断方位,只能判断这个大片的图形是否有被绿色图形切开,因此出现了误判。



    有些DRC工具的间距检查提供了Shield的选项,试图只把最近的间距图形报错,不去把所有符合间距错误的图形都报错出来,试图避免这个问题。但是,Shield的选项是专门为了2层图形的检查设计的,它不是为了3层图形检查设计的。因此2层图形检查的结果输出是“边”,而不是图形。作为“边”是无法参与后续的3层图形操作的。如果把“边”再转换为很细的小图形去做后续的运算,则又陷入了“边”形成图形后连接成一片大的图形,无法区分方位和具体位置的问题,从而出现误判。



    因此,必须寻找一种方法:它可以把2layer之间被隔离的图形准确找到。这个方法实现困难吗?为什么大部分Foundry没有提供这样的检查?国内只有个别Foundry给用户提供了该问题的解决方案,他们的方案为什么采用了helmet的设计思路?该思路可以推广到其它Foundry吗?如果某些Foundry不提供该方案,IC设计公司可以自行写DRC Code实现吗?如何实现?



     感兴趣的可以关注微信公众号:   microscapes8     看后续文章如何解决。




发表于 2018-8-20 22:06:07 | 显示全部楼层
多谢分享
发表于 2018-8-21 03:25:36 | 显示全部楼层
谢谢你!
发表于 2018-8-21 09:47:03 | 显示全部楼层
分析的十分透彻啊,期待后续文档解析
 楼主| 发表于 2018-8-21 10:08:56 | 显示全部楼层
明天的帖子和微信公众号回继续就该问题展开探讨。
 楼主| 发表于 2018-8-22 08:42:20 | 显示全部楼层
Latch up Rule的难点(2)的文章已经在Layout讨论区发布,可以参看:

http://bbs.eetop.cn/thread-767975-1-1.html

       也可以关注微信公众号:  microscapes8  参看。
 楼主| 发表于 2018-8-22 08:43:27 | 显示全部楼层
回复 5# houjs


    Latch up Rule的难点(2)的文章已经在Layout讨论区发布,可以参看:

http://bbs.eetop.cn/thread-767975-1-1.html

       也可以关注微信公众号:  microscapes8  参看。
发表于 2020-1-20 23:38:33 | 显示全部楼层
最早在微信某公号上看过,意外在eetop上看到这篇文章,一开始还以为涉及“知识产权”问题,看后才发现,原来其实你们就是一家人,哈哈

干货满满,强烈推荐.
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

站长推荐 上一条 /1 下一条

小黑屋| 手机版| 关于我们| 联系我们| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2025-6-29 07:18 , Processed in 0.032893 second(s), 8 queries , Gzip On, MemCached On.

eetop公众号 创芯大讲堂 创芯人才网
快速回复 返回顶部 返回列表