第二讲：常见描述符类型解析 —— LEF、DEF、SDC、Liberty
做后端设计的人，手里都要跟几本“天书”打交道。LEF、DEF、SDC、Liberty，这四个文件几乎贯穿了整个PD（Physical Design）流程。我早期入行的时候，总觉得解析工作是EDA工具的事，自己读不读无所谓。直到有一次定位floorplan异常，花了两天去查，最后发现是LEF里的一条金属层规则写错了……嗯，从那以后我再也不敢轻视这些描述符文件了。
说白了，它们是物理、时序、逻辑信息的载体。解析得准不准，直接决定了你调试时看到的现象是真实现象还是假象。这一讲，我们就一个一个过一遍。
LEF 文件：工艺厂的“地图”
LEF（Library Exchange Format），它描述的是芯片的物理抽象层，包括工艺信息、金属层参数、通孔规则、宏单元的边界和端口位置。我习惯把它比作工艺厂给你的一张地图，告诉你哪里能走线，哪里是禁区。
LEF 里最重要的几类数据：
- 工艺层定义：层名、层次ID、最小宽度、最小间距、方向（水平/垂直）。
- 宏单元 OBS（Obstruction）：不可走线的阻挡区，比如硬宏内部的禁止布线层。
- 端口几何：单元输入输出引脚的物理位置、层次、形状。
- 天线规则：天线效应相关的最大门级面积比。
我记得有一次做28nm项目，单元库的LEF里把某一层的最小间距写成了0.07μm，实际该层是0.08μm。我调试时发现布局后绕线总有缺口，DRC一片红。最后对照工艺文档才发现LEF解析错误。所以，拿到LEF后建议先快速人工过一遍关键层参数，尤其是间距和宽度。
我个人的小习惯：写一个简单的Tcl脚本，把LEF里所有层的最小间距和最小宽度抓出来，跟工艺参考手册逐条对比。十几分钟就能避免后续几天的返工。
DEF 文件：设计网表与布局的“快照”
DEF（Design Exchange Format），它承载的是设计实例的物理信息：单元名称、坐标、方向、电路连线（NET）、分块（Region）、电源网络等。流片前最终的DEF就是版图的本体。
我经常跟新人讲：调试 DEF 就是调试版图的灵魂。假如某个模块的单元坐标在DEF里偏差了0.01μm，后端工具读进去就会产生几何错误。你想想看，如果DEF里少了某个inst的坐标，那后续PR全乱套。
我曾经踩过的一个坑：旧版EDA工具在DEF解析时，会把“NONDEFAULTRULE”段里的绕线规则丢掉，导致顶层绕线按默认规则跑，实际期望的是更宽的线。还好在后仿真前被我发现了，否则流片回来可能短路。从那以后，我每次读取DEF都会grep一下“NONDEFAULTRULE”段是否完整。
DEF 的常见分段我整理了一个对照表：
| DEF 段 | 内容 | 调试关注点 |
|---|---|---|
| COMPONENTS | 所有实例的master名称、坐标、方向 | 坐标有无缺失？方向是不是与floorplan一致？ |
| NETS | 逻辑连接与物理走线（WIRE段） | 走线层分配是否正确？特殊宽度线是否保留？ |
| REGIONS | 物理分组，用于约束布局域 | 区域边界是否重叠？是否覆盖了全chip？ |
| PINS | 顶层端口坐标、层 | 端口是否与I/O pad对齐？ |
| SPECIALNETS | 电源网络，包括VDD、VSS和PG pin连接 | 电源环是否有开口？跳线是否合规？ |
SDC 文件：时序的“宪法”
SDC（Synopsys Design Constraints），它是定义芯片工作时序约束的文件。说白了就是告诉工具：你必须在多少纳秒内把信号送到，否则就是失效。SDC里面会写时钟周期、生成时钟、输入输出延迟、虚假路径、多周期路径等。
PD调试时，SDC解析出问题的情况简直太多了。
- 时钟定义错误：比如把主时钟的波形设定错了，整个STA结果都是错的。我见过有人把上升沿设在0ns、下降沿设在10ns，实际设计是10ns周期50%占空比，结果setup和hold全反了。
- False Path 和 Multiple Cycle Path 漏写：该放宽的路径没放宽，导致工具为了修那些根本不用care的路径而过度优化面积和功耗。
- set_input_delay / set_output_delay 取值偏大或偏小：直接影响接口时序收敛。
我的习惯是：每次跑完PrimeTime先看一眼report_clock和report_timing，确认SDC所有时钟都正确创建、所有路径确实都被约束到了。这一步花不了几分钟，但能挡住很多低级错误。
Liberty 文件：单元的“性格画像”
Liberty (.lib) 文件描述的是逻辑单元的时序与功耗特性。比如一个AND2X1单元，在不同输入转换时间（slew）和输出负载（load）下，其延迟、输出转换时间、内部功耗、漏电流等都有对应表。
我年轻时候觉得.lib就是查表，没什么好解析的。后来发现.lib文件版本很多（如Liberty NCX、CCS、NLDM），不同版本在非线性延迟建模上有差异。
- NLDM（Non-Linear Delay Model）：二维查找表，输入slew vs 输出load，查延迟。这是最传统的。
- CCS（Composite Current Source）：用电流波形描述输出，更精准，尤其适合先进工艺下库延迟的非线性变化。
- LVF（Liberty Variation Format）：增加了统计偏差，用于统计STA。
如果库解析时选了错误的模型类型，setup/hold结果可能偏差20%以上。我曾在某个7nm项目中，工具默认用NLDM解析，实际库里包含的是CCS数据，还不做警告。结果STA跑出来完全不对，排查了一周……后来我强制指定set_timing_model_type ccs才解决。
四种描述符的解析关联
你可能会问：这四种文件在PD调试里是各自独立的，还是互相影响的？一句话回答：牵一发而动全身。
我画了一张简图表达它们如何共同作用于PD调试流程：
你看，从LEF/DEF/SDC/Liberty四个方向为输入，经过后端工具解析引擎，最终影响到物理验证、时序分析、功耗与IR分析三大调试领域。任何一个描述符解析出错，都会导致你站在错误的数据上做决策。
解析典型问题与应对
- 版本不兼容：同一个工艺节点可能有多个版本的LEF或Liberty，新旧格式混用会导致工具解析失败或读取错误数据。我建议统一使用工艺厂推荐的版本，并在makefile里做版本crc校验。
- 缺失文件/段：比如DEF里缺少了SPECIALNETS段，电源网络就无法正确识别。我习惯在脚本里加检查section是否存在，只要有缺失就终止flow。
- 数据单位误解：LEF里常用微米(micron)，SDC里时间单位默认ns，如果工具单位设置错了（比如会把DEF里的微米当毫米读），那整个坐标就缩放1000倍。每次新项目我第一件事就是确认所有文件的单位并统一。
- 非标扩展属性：有些库供应商会在Liberty里添加自扩展属性（如特殊的温度系数），工具若不解析这些属性，功耗计算就会不准。解决办法是充分阅读release notes，并跟FAE确认。
记住：不要过度信任工具的隐性容错。工具在解析时遇到无法识别的字段通常会静默跳过，但跳过意味着信息丢失。在调试时如果发现奇怪的不收敛现象，不妨先检查一下每个描述符的解析日志，看看有没有warning级别的“unrecognized keyword”。我至少三次因此发现了解析异常。
嗯，这一讲我们把四个描述符文件的核心内容、解析容易出问题的点、调试注意事项都过了一遍。你实际工作中遇到的解析问题，大概率都能在上面的列表里找到影子。下一小节我们就正式进入描述符解析错误对PD调试的具体影响案例，到时候我会拿真实的后端bug来剖析——那才叫“痛过才知道”。但那是后面的事，今天先把这句话收好：解析正确是调试正确的前提。