• Legalizer的演进史(一)


    第一层

     

    在28nm及更老的工艺,legalizer要做的事情就是把stdcell放在row上,不要overlap with row。作为完美主义的我,必须指出,放在row上不够,确切的说是放在unit tile上。所以那时候,一个R&D就可以轻松搞定整个的legalizer代码,据说他还经常去度假,因为代码太稳定了,连bug都很难找到。

    第二层

    还记得40nm和28nm,不允许有x1的spacing不?这个事情谁来做?当然是legalizer了。

    第三层

     

    到了16nm,min VT spacing, min VT area, min OD area等等rule忽然都冒出来了,legalizer要处理的事情多起来了。此时,需要三剑合璧:

    第一剑,techfile,要定义好min spacing,min area等rule。

    第二剑,ndm,记录每个std cell的VT layer,OD layer的形状等物理信息

    第三剑,legalizer,R&D干的活,最后插filler没有任何问题的legalizer才是一个合格的legalizer。

    到此,legalizer开始复杂起来了,据说那个R&D开始要准时上下班了。

    第四层

     

    还是16nm,std cell面积很小,忽然带来了pin access的问题,因为pin密度太高了。太高了咋办?一个统计办法,如果哪两个cell挨在一起,容易有drc问题,那么就写个spacingrule,让legalizer把两个cell放远点。

    第五层

     

    工艺演进到了10nm,Metal1 routing track有color了,都是DPT这个工艺惹的祸。然后还有M1的shape只能是正方形的,不让绕弯。为了满足这两些变态需求,活又落在legalizer身上了。Legalizer要多做两个事:

    第一:std cell pin必须和track align,不能偏。

    第二:std cell pin的color必须和routing track的color一致,不能反(除非这个pin是个胖子)

    据说,那个R&D此时要天天加班了。

    第六层

     

    到了7nm,PG开始走到底层金属了,开始走到M1了。所以M1 PG下面,不能有std cell的M1 pin,不然会short。其实不仅要防止short,pin还要和PG保持一定的距离,不然容易有spacing的DRC。除了要防止和M1的PG擦枪走火,还要防止和M2的PG有暧昧关系。也即M2的PG下面或者下面附近不要有M1的pin,不然容易有DRC。所以legalizer在放cell的时候,开始看PG的脸色了。

    到此,据说legalizer的R&D已经开始加人了。

  • 相关阅读:
    JVM 启动参数设置
    Linux文件分割与合并
    设置tomcat使用指定的jdk版本
    java字符编码
    HASH 哈希处理完数据导致数据集第一行数据缺失
    HASH 何时将key加载到h.definedata()中
    字符串 批量全角、半角转换
    SAS_正则表达式 字符意义
    正则表达式基础篇
    sas options有用的全局设置
  • 原文地址:https://www.cnblogs.com/lelin/p/12697917.html
Copyright © 2020-2023  润新知