• 注册
  • 查看作者
  • 数字IC设计实现hierarchical flow之物理验证篇

    吾爱IC社区上周推出了七月份的第一波福利活动。整个活动共有6人参与(公众号后台看到共20人转发文章,可能是个别有看完文章默默转发的习惯吧,感谢!),虽然活动参与度不高,但是前3名点赞数还是特别高。因此本次活动中奖率高达75%


    一等奖:Hongki (点赞数163,转发12个群)

    二等奖:darry (点赞数为44,转发10个群)

    三等奖:Sinx (点赞数为54,转发5个群)


    祝贺以上这三位朋友,都是本社区的铁杆粉丝了。请中奖的朋友将地址和联系方式,私信小编。小编会在当天将礼品卡(美容卡和水果茶券)快递到各位手上。


    没有中奖或者没有看到上次活动的朋友们,请继续关注公众号本月的第二波活动推送。听说将吾爱IC社区公众号置顶后就不会错过任何精彩干货分享和福利奖品活动。


    最近小编在忙芯片tapeout,也没空去打印书籍送给大家。又恰逢上海南汇水蜜桃上市季节,第二波活动打算先送出4箱水蜜桃,每箱价值100元。活动细节过两天再推送(如果你是老铁,应该知道小编每年都会送水蜜桃的哦)。


    2019年数字IC后端校招笔试题目(附数字后端培训视频教程)

    史上最全的数字IC后端设计实现培训教程(整理版)


    好了,下面进入今天的主题分享。


    吾爱IC社区之前分享了数字IC设计实现hierarchical flow的逻辑综合,后端布局布线,寄生参数提取和静态时序分析。今天继续分享最后一部分内容----物理验证(Physical Verification)


    物理验证是芯片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假错太多,很难定位到真问题。



    小编知识星球简介(如果你渴望进步,期望高薪,喜欢交流,欢迎加入


    在这里,目前已经规划并正着手做的事情:

    • ICC/ICC2 lab的编写

    • 基于ARM CPU的后端实现流程

    • 利用ICC中CCD(Concurrent Clock Data)实现高性能模块的设计实现

    • 基于ARM 四核CPU  数字后端Hierarchical Flow 实现教程

    • 时钟树结构分析

    • 低功耗设计实现

      定期将项目中碰到的问题以案例的形式做技术分享


    吾爱IC社区知识星球星主为公众号”吾爱IC社区”号主,从事数字ic后端设计实现工作近八年,拥有55nm,40nm,28nm,22nm,14nm等先进工艺节点成功流片经验,成功tapeout过三十多颗芯片


    这里是一个数字IC设计实现高度垂直细分领域的知识社群,聚集了无数数字ic前端设计,后端实现,模拟layout 工程师们。 


    在这里大家可以多建立连接,多交流,多拓展人脉圈,甚至可以组织线下活动。在这里你可以就数字ic后端设计实现领域的相关问题进行提问,也可以就职业发展规划问题进行咨询,也可以把困扰你的问题拿出来一起讨论交流。对于提问的问题尽量做到有问必答,如遇到不懂的,也会通过查阅资料或者请教专家来解答问题。在这里鼓励大家积极发表主题,提问,从而促进整个知识社群的良性循环。每个月小编会针对活跃用户进行打赏。 


    最重要的是在这里,能够借助这个知识社群,短期内实现年薪百万的梦想!不管你信不信,反正已经进来的朋友肯定是相信的!相遇是一种缘分,相识更是一种难能可贵的情分!如若有缘你我一定会相遇相识!知识星球二维码如下,可以扫描或者长按识别二维码进入。目前已经有265位星球成员,感谢这265位童鞋的支持!欢迎各位渴望进步,期望高薪的铁杆粉丝加入!终极目标是打造实现本知识星球全员年薪百万的宏伟目标



    欢迎关注“吾爱IC社区

    微信号:ic-backend2018



  • 0
  • 0
  • 0
  • 1.29w
  • 请登录之后再进行评论

    登录
  • 单栏布局 侧栏位置: