简介《LEF/DEF 5.8 语言参考》是 Cadence 于 2017 年发布的官方英文手册面向数字后端物理设计、版图规划与 EDA 工具开发方向的工程师及高年级研究生用于系统查证 LEF 与 DEF 两种集成电路描述语言的语法与语义。LEF 侧重工艺侧描述涵盖金属层、多晶硅层等层次定义与电气特性、标准单元与宏模型的几何抽象以及间距规则、填充与隔离区域DEF 面向设计实现记录模块布局与方向、信号与电源网络连接、DRC/LVS/ERC 约束、物理分区与过孔属性。两者同为 EDA 工具间交换设计信息的行业标准是物理综合、布局布线与签核验证衔接的关键。资源包仅含 1 个 PDF 文件约 2.48MB带完整目录与章节索引便于按关键字定位条目目前已有 2177 人学习。读者可据此查证 5.8 版本的官方一手定义、约束管理增强与先进工艺节点支持细节作为编写脚本、配置流程和排查工具报错时的对照依据。1. 到底什么是 LEF 和 DEF一张芯片版图的说明书加施工图装修过房子的人都有体会工人手里通常捏着两样东西。一份是建材和家具的规格册写着每块砖多大、每扇门多宽、插座离地至少几厘米另一份是这户人家的施工图写着沙发摆在客厅东墙、水管从厨房穿到卫生间。芯片设计里的 LEF/DEF 语言参考讲的就是这两样东西该怎么写。LEF 是 Library Exchange Format管的是「规矩」——这块工艺上有几层金属、每层最细能画多宽、标准单元长什么模样DEF 是 Design Exchange Format管的是「现场」——这次设计里哪个单元摆在哪个坐标、线从哪儿连到哪儿。搞懂这一对格式你就看懂了芯片从图纸走向硅片的那个交接环节为什么工具之间能接得上为什么换个软件不用把设计重画一遍为什么一条看起来没问题的走线会被判违规。这份语言参考本质上是给这两个文件立的一份「书写规范」也是排查问题时最该翻的那本字典。2. 为什么非得拆成两种格式芯片设计流程里的「交接班」难题2.1 从代码到硅片中间要换好几拨工具一颗芯片从一行行硬件描述代码走到硅片上真实的晶体管中间要过好几道手。综合工具先把逻辑门连成网表布局工具决定每个门放在哪布线工具决定线怎么走再往后还有时序分析、功耗分析、物理验证、可制造性检查。这些环节用的工具往往来自不同厂商内部数据结构差别很大。要是每换一个工具就把设计重新导一遍、重新认一遍整个流程根本收敛不了。打个比方装修队进场水电工、木工、瓦工各干各的。如果每个人用的图纸语言都不一样水电工标的位置木工看不懂木工留的洞瓦工对不上最后只能砸墙重来。行业里解决这个问题的办法很朴素定一套大家都能读写的中间图纸。LEF 和 DEF 就是芯片物理设计这一段路上被广泛接受的中间图纸。关键在于这套中间图纸不是一份而是两份。为什么不能合成一份因为芯片设计里有两类信息它们的「保质期」完全不同。2.2 一份管「规矩」一份管「现场」LEF 描述的是可复用的东西。某条工艺线上有几层金属、每层的间距规则是多少、标准单元库里每个门的外框尺寸和引脚位置——这些信息一次写清楚可以喂给无数个不同的设计。它天然属于工艺厂和库提供方一个库文件可能在几十上百个项目里被反复引用。DEF 描述的是这一次的东西。这个设计里编号 U1 的那个单元被摆在坐标 (2400, 0)朝向是 N某根信号线从 U1 的 A 脚出发经过两个通孔落到 U2 的 Y 脚。这些信息只对一个设计成立换个项目就完全作废。举个更具体的例子。一个两输入与非门内部可能由四个晶体管组成但布局布线工具根本不需要知道这四个管子怎么连。它只需要知道这个单元占地 1.2 微米乘 2.4 微米左边有个输入引脚、右边有个输出引脚中间那块区域是布线禁区。这种「只保留外部轮廓和接口」的表示方法业内叫抽象视图英文是 abstract。LEF 里的 MACRO 语句写的就是这个抽象视图。提示抽象视图这个词很容易被想复杂。它的核心就一句——够用就好。工具需要什么就给什么多一个坐标都是浪费。2.3 拆成两份换来的是什么拆开的好处很直接。库信息写一次多个设计复用改工艺规则时只改一处设计数据每次只传自己那一份文件体积小、传输快、版本管理也清楚。更实际的一点是做库的人和做设计的人可以并行工作互不阻塞。代价也有而且很具体。两份文件必须对得上单位要对得上名字要对得上语言版本要对得上。LEF 里写数据库单位是一千分之一微米DEF 里写的也得是同一个数否则所有坐标整体错位工具不会报语法错误只会给你一堆莫名其妙的布局重叠。这种错最难查因为它不吵不闹只是安静地把结果搞坏。这就是为什么需要一个专门的《语言参考》。它不教你怎么做设计它告诉你这两个文件里每个关键字能吃什么样的值、值之间有什么约束、哪些语句有先后顺序。当你遇到「工具读进去了但结果不对」这类玄学问题时答案通常就藏在这些约束里。3. LEF 里究竟写了什么工艺规矩和单元外形的那本字典3.1 技术层定义金属层、切割层、注入层各管什么LEF 的第一大块是工艺描述核心是各种 LAYER 语句。语言参考里按用途把层分成几类每类的属性完全不同。布线层Layer Routing是最常用的一类描述金属走线。它要写清楚方向是水平还是垂直、布线间距是多少、最小线宽是多少、方块电阻和单位面积电容大概多少。这几个参数直接决定了布线工具能不能算准延迟、会不会违反规则。切割层Layer Cut描述的是通孔所在的层也就是连接上下两层金属的「电梯井」。它关心的是通孔的最小尺寸、通孔之间的最小间距、以及不同金属层叠起来时的 enclosure 要求。还有两类不那么常被提起。主切片层或覆盖层Masterslice 或 Overlap在早期门阵列工艺里是主角现在多用来描述衬底和阱这类不直接走线的结构。注入层Implant描述离子注入区域影响器件的阈值电压通常在模拟和特殊器件里才会细写。为什么分这么细因为它们在制造上是不同的掩膜规则来源不同、失效模式也不同。金属层怕短路和电迁移注入层怕对不准。把这些混在一个语句里写规则检查工具就没法分别校验。3.2 MACRO 与抽象视图给每个单元建一张外形档案LEF 的第二大块是单元库描述主角是 MACRO。一个标准单元在 LEF 里大致长这样先声明类别是普通核心单元、焊盘还是大块的 IP 宏再写原点、尺寸、对称性、所在的行站点然后是若干 PIN 语句描述引脚最后用 OBS 语句圈出布线禁区。引脚这一段值得多说两句。每个 PIN 下面会有 DIRECTION 说明是输入输出还是双向再往下是 PORTPORT 里用 LAYER 加 RECT 的组合画出引脚在每一层上的实际形状。有的单元引脚在多层上都有形状那是为了方便不同层的线接进来。OBS 是很多人第一次看 LEF 时会忽略、但实际最要命的部分。它表示这块区域内工具不许布线。标准单元内部有大量的器件和内部连线外面来的信号线穿进去就会短路。所以 OBS 相当于给布线工具划了一片禁飞区。某个单元如果 OBS 写小了工具会欢快地把线布进去然后在物理验证阶段炸出一堆短路错误——这就是典型的翻车现场而且排查起来极费时间。注意OBS 写漏或写小语法检查完全通得过错误要到版图比对阶段才暴露。这类问题的排查成本远高于写的时候多花五分钟。3.3 规则类语句间距、轨道与非默认规则除了层和单元LEF 里还有一批专门管约束的语句它们平时不显眼出问题时却常常是根因。SPACING 定的是同层图形之间的最小距离。但真实工艺里线宽不同要求也不同——宽线在制造时更容易出现缺陷需要更大的间距。这时候就要用 SPACINGTABLE按线宽分段给出不同的间距值。语言参考里对这张表的写法和查找顺序有明确说明顺序写错工具就可能取到偏小的那个值。非默认规则NONDEFFAULTRULE是给特殊线准备的另一套参数。比如某几根电源线要走得特别宽宽线的间距、通孔规则都和普通线不同就可以单独定义一条规则在布线时指定使用。这相当于给这几根线开了个「特殊通道」。布轨TRACKS定义的是每层金属上可以走线的网格位置。工具不会随便找地方画线它只在轨道上画。轨道间距和偏移写错工具算出来的可用布线资源就是错的表现出来就是「明明看着有空间却布不通」。行站点SITE定义标准单元行的基本单位也就是行高和行宽的最小粒度。所有标准单元的高度必须是站点高度的整数倍否则排不成行。这条约束在库和设计之间必须一致否则布局阶段会直接报错。单位UNITS和制造网格MANUFACTURINGGRID是两个不起眼但要命的语句。前者定义数据库单位换算后者定义所有坐标必须对齐的最小网格。坐标没对齐网格有些工具会静默取整有些会直接拒绝——行为不统一是最容易让人怀疑人生的地方。3.4 一段最小 LEF 长什么样看一段简化的片段比读十页描述管用。下面的数值只是为了说明结构不代表任何真实工艺。VERSION 5.8 ; UNITS DATABASE MICRONS 1000 ; # 数据库里 1000 个单位 1 微米 END UNITS LAYER M1 TYPE ROUTING ; # 这是一层金属走线层 DIRECTION HORIZONTAL ; # 只允许水平走线 PITCH 0.2 ; # 相邻轨道的间距 WIDTH 0.1 ; # 最小线宽 SPACING 0.1 ; # 同层最小间距 RESISTANCE RPERSQ 0.08 ; # 方块电阻用于延迟估算 END M1 MACRO NAND2_X1 CLASS CORE ; # 普通核心单元 ORIGIN 0 0 ; SIZE 1.2 BY 2.4 ; # 外框尺寸必须是站点尺寸的整数倍 SYMMETRY X Y ; # 允许镜像摆放的方向 SITE core_site ; PIN A DIRECTION INPUT ; PORT LAYER M1 ; RECT 0.15 0.6 0.35 0.9 ; # 引脚在 M1 上的矩形范围 END END A OBS LAYER M1 ; RECT 0.4 0.1 1.1 2.3 ; # 单元内部禁区外部线不许进入 END END NAND2_X1这段代码的逻辑顺序是有讲究的。VERSION 必须最先出现告诉解析器按哪个版本的语法读UNITS 紧随其后因为后面所有的坐标数值都依赖这个换算比例LAYER 定义要在 MACRO 之前因为 MACRO 里的 PORT 和 OBS 会引用层名。语言参考里专门有一节讲语句顺序顺序颠倒通常不是「警告」而是直接解析失败。参数上最值得盯的是三个DATABASE MICRONS 决定全局比例SIZE 必须是 SITE 的整数倍OBS 的范围要覆盖单元内部所有不该被穿过的区域。这三处只要有一处不对后面整条流程都会带着错误往下走而且往往到很晚才被发现。4. DEF 里究竟写了什么设计落地之后的现场记录4.1 组件、引脚与网络住户、门牌和电线DEF 的第一大块是设计内容本身三条主线撑起了整个文件。组件COMPONENTS记录设计里每一个实例。它写清楚这个实例叫什么名字、用的是哪个 MACRO、摆在哪个坐标、朝向是什么。朝向那几个缩写值得记一下N、S、E、W 是四个基本方向前面加 F 表示翻转所以 FN、FS、FE、FW 是另外四种组合一共八种摆放方式。有些单元还会用更细的掩膜偏移选项用于光学邻近效应补偿在先进工艺里越来越常见。引脚PINS记录设计对外的接口。一个芯片最终要和封装、和外部世界连接这些连接点就是引脚。DEF 里写清楚每个引脚的名字、方向、在哪个层上、形状多大。网络NETS记录连接关系。它本质上是一组端点列表告诉工具这些引脚和端口之间是电气相连的。至于具体怎么连——走哪条路径、打几个通孔——布线之前是空的布线之后会被写入 DEF 的走线段。这三者合起来正好对应一个很生活化的场景组件是楼里的住户引脚是楼门和信箱的编号网络是「谁家和谁家要通电话」的清单。清单本身不告诉你电话线怎么走那是施工队的事。4.2 行、站点、区域和阻塞布局的地基与禁停区标准单元不是随便乱放的它们要排在整齐的行里。行ROWS语句定义的就是这些行的起点、重复次数、每一步的步长。每行的起点必须落在站点网格上行高必须等于站点高度否则单元放上去会悬空或重叠。区域REGIONS用来把设计切块。某个模块要集中放在一片区域里、某个电源域要独立成片都可以用区域语句圈定。这在多电压域设计里特别常用因为不同电压域的单元不能随便混放。阻塞BLOCKAGES是布局和布线的禁区。它可以按层来分也可以在全局范围内生效。和 LEF 里的 OBS 有点像但作用范围不同OBS 是单元自带的、跟着单元走的BLOCKAGES 是设计级的、由设计者主动加的。比如某块区域要留给模拟电路或者某个位置要放大的 IP 宏就可以先加一块阻塞把地方占住。4.3 特殊网络与通孔电源地怎么走普通信号网络的走线通常在布线阶段由工具自动生成。但电源和地这类网络不一样它们往往要用手工或半自动的方式规划线宽大、结构规整、优先级高。DEF 里专门有一类特殊网络SPECIALNETS来记录这些内容包括走线的路径、每段的宽度、使用的通孔类型。通孔VIAS语句则定义具体的通孔结构。有些通孔是工艺库自带的直接引用名字就行有些是设计过程中临时生成的需要在 DEF 里完整描述它的每一层形状。语言参考里对这两种写法都有说明混用会导致工具读不进来。还有一个容易被忽略的细节特殊网络的走线常常要配合非默认规则使用。宽线用普通间距规则会判违规得在 DEF 里指定它走哪条规则。这个对应关系如果断了物理验证阶段会冒出一堆莫名其妙的间距错误。4.4 一段最小 DEF 长什么样同样看一段结构化的片段理解它和 LEF 的呼应关系。VERSION 5.8 ; DIVIDERCHAR / ; BUSBITCHARS [] ; DESIGN top ; UNITS DISTANCE MICRONS 1000 ; # 必须和 LEF 的单位一致 DIEAREA ( 0 0 ) ( 20000 20000 ) ; # 整个芯片的可用范围 ROW ROW_0 core_site 0 0 N DO 500 BY 1 STEP 1200 0 ; COMPONENTS 2 ; - U1 NAND2_X1 PLACED ( 2400 0 ) N ; # 引用 LEF 里定义的 MACRO 名 - U2 NAND2_X1 PLACED ( 3600 0 ) FS ; # FS 表示翻转后南北向摆放 END COMPONENTS NETS 1 ; - n1 ( U1 A ) ( U2 Y ) ; # 两个引脚之间的连接关系 END NETS END DESIGN最关键的呼应点在第一行和最后一行之间。DEF 里的 UNITS DISTANCE MICRONS 必须和 LEF 里的 DATABASE MICRONS 取同一个值否则 U1 的坐标 (2400, 0) 在两份文件里代表的位置根本不是一回事。这是跨工具交接时最经典的踩坑点而且因为两边语法都合法工具不会主动报错。COMPONENTS 里的 NAND2_X1 这个名字必须能在 LEF 的 MACRO 列表里找到。找不到就只有两种结果工具拒绝读入或者更糟——默默跳过这个实例让设计悄悄少了一个门。后者在做形式验证时会被抓出来但那时候你已经花了不少时间在别处排查。ROW 语句里的 1200 是标准单元的宽度步长对应 LEF 里 SITE 定义的那个数。这个数对不上单元排不成行布局工具会用一堆重叠告警把你淹没。5. 易混与误区LEF 和 DEF 到底差在哪别再搞反5.1 误区一LEF 和 DEF 必须成对出现这是最常见的误解。很多人第一次接触这两个格式会以为它们是一份文件拆成了两半缺一不可。实际情况是LEF 完全可以独立存在。一个标准单元库交付给客户时通常就是一堆 LEF 文件加配套的时序库里面根本没有 DEF 的影子。因为库描述的是「可能被用到的东西」跟具体哪个设计没关系。DEF 则离不开 LEF。原因很直接DEF 里的组件要引用 MACRO 名坐标要依赖单位定义层名要和 LEF 里的一致。没有 LEFDEF 里那些名字全都指向空气。区分方法很简单问一句「这份数据换个项目还能用吗」。能用的是 LEF不能用的是 DEF。库、工艺规则、单元外形都归 LEF某个具体设计里东西摆在哪归 DEF。5.2 误区二LEF 只是「库文件」跟工艺没关系「LEF 是库文件」这个说法流传很广但它只对了一半。LEF 里确实有一大块是 MACRO属于库的范畴但另一大块是 LAYER、SPACING、TRACKS、UNITS 这些完完全全是工艺描述。语言参考开篇就写得很清楚LEF 定义的是工艺技术的元素和相关的单元模型库两件事并列。把 LEF 纯粹当成库文件后果是在排查工艺相关问题时想不起来去翻它。比如布线工具抱怨某层没有可用轨道你会去查工具配置、查设计约束绕一大圈最后发现是 LEF 里 TRACKS 语句写漏了一层。这类错误在语法检查里是发现不了的因为少写一条语句不构成语法错误。区分方法看内容。出现 LAYER、SPACING、TRACKS、UNITS 这些关键字的是工艺部分出现 MACRO、PIN、OBS 的是库部分。同一个文件里两者都有很正常。5.3 误区三DEF 里既然有技术段就不需要 LEF 了DEF 语言里确实存在一个技术TECHNOLOGY段可以写一些层信息。有人看到这个就以为 DEF 能自给自足把 LEF 省掉。这是个很危险的误解。DEF 里的技术段主要作用是「把必要的技术信息带进设计文件」让某些场景下工具能少读一个文件或者让设计文件自带上下文。但它并不承担完整工艺规则的职责。间距表、非默认规则、完整的单元抽象视图这些仍然在 LEF 里。语言参考对 DEF 技术段能写什么有明确边界越界的内容写了也不会被识别。区分方法把 DEF 的技术段理解成一份「随身携带的摘要」而不是「完整的规则手册」。真正要查规则细节还是得回到 LEF。5.4 误区四抽象视图就是完整版图只是格式不同LEF 里的 MACRO 画出了单元的外框和引脚形状看起来挺像那么回事。于是有人以为这就是单元的版图只是换了个文件格式存。这个误解的代价可能很大。抽象视图只有轮廓、引脚、禁区这三类信息。单元内部晶体管的实际图形、栅极的具体形状、注入区的边界全都不在里面。拿 LEF 去做流片是绝对不行的流片要的是完整版图数据那是另一套格式的事。区分方法记住抽象视图的目的。它是给布局布线工具用的工具只需要知道「占多大地方、从哪儿接线、哪儿不能碰」。它天生就不是给人看细节的也不是给制造用的。5.5 误区五关键字和名字大小写随便写LEF 和 DEF 的语法里关键字是大写的而用户自定义的名字——单元名、实例名、网络名、层名——是区分大小写的。这两条规则混起来很容易写出「语法通过但语义错乱」的文件。举个具体的LEF 里定义了一个层叫 M1DEF 里引用的时候写成 m1某些工具会认为是两个不同的层然后在检查时报「引用了未定义的层」另一些工具可能做了大小写不敏感的兼容处理让你以为没事。等换了个工具问题突然冒出来这时候再回头查成本就高了。区分方法关键字照抄大写自定义名字全程保持一致最好在项目开始就定一个命名约定。这不是洁癖是给自己省后悔药。6. 什么时候该翻这份语言参考边界判断与真实取舍语言参考这类文档有个特点平时用不上用上的时候往往是出了事。所以真正的问题不是「要不要读」而是「什么时候值得花时间深读什么时候翻两页就够」。先看一张简单的判断表。场景建议第一次接手一份陌生工艺的 LEF重点看 UNITS、LAYER、SITE 三段其余可跳读布线工具报出看不懂的间距违规精读 SPACINGTABLE 和 NONDEFFAULTRULE 两节跨工具交接后布局整体错位先核对两边的单位定义再查坐标网格单元摆不进标准单元行查 SITE 高度和 MACRO 的 SIZE 是否成整数倍只想跑通某个工具的默认流程先看工具自带文档语言参考暂时不用做库交付或工艺规则整理值得从头到尾过一遍这是主战场举个具体例子。某开发者做一个小模块的布局布线工具反复报某几根宽线的间距违规但他量了图上距离明明大于最小间距。折腾半天后翻到语言参考里非默认规则那一节才发现宽线走的是另一套间距值比普通线大得多。他之前一直在按普通规则核对自然对不上。这个错误的根因不在工具也不在设计而在于他不知道 LEF 里可以给同一层配多套规则。反过来也有不该硬啃的时候。如果只是想知道某个坐标代表什么、某个单元为什么摆在那儿打开版图可视化工具看一眼比翻文档快得多。语言参考是查语法和约束的不是查具体数值的。把它的定位搞对能省下大量时间。真正需要警惕的是「语法对但语义错」这一类问题。单位不一致、名字大小写不统一、OBS 范围写小、轨道漏定义这些问题在解析阶段一路绿灯要等到很晚才暴露。所以我自己的习惯是拿到任何一份新的 LEF先不看它写了什么先核对三件事——数据库单位、层清单、站点高度。这三样对上了后面的坑能少一大半。从那以后我每次接手跨团队的库文件都强制走一遍这三项核对宁可多花十分钟也不想再体验那种查到凌晨三点发现是一个数字写错的感觉。这份语言参考本身带使用授权说明个人查阅、打印一份自用没问题别拿去做二次分发或商用。它对应的是 5.8 版语言文档标注时间是 2017 年内容覆盖 LEF 语法、DEF 语法、别名语句、错误检查机制以及工艺天线、布线优化这些专题附录。需要完整版本的时候按下面的方式获取就行。希望帮到你。本文还有配套的精品资源点击获取