【Backend Flow工程实践 08】LEF / Liberty / Verilog / DEF：Backend Flow 为什么依赖多格式协同？

作者Darren H. Chen方向Backend Flow / 后端实现流程 / 工程自动化 / 验证基础设施demoLAY-BE-08_standard_formats标签EDA、Backend Flow、后端实现、LEF、Liberty、Verilog、DEF、标准格式、Design Import、Library Context在后端实现流程中很多人会把工具输入简单理解成几类文件读 Verilog 读 LEF 读 Liberty 读 DEF 读 SDC 然后开始 floorplan / place / CTS / route这种理解不能说错但它只停留在“文件入口”层面。如果从 Backend Flow 工程角度看真正重要的问题不是“工具能读哪些文件”而是这些格式分别表达了设计世界的哪一部分语义它们如何共同构成一个可被后端工具理解、检查、优化和导出的设计数据库LEF、Liberty、Verilog、DEF 不是四个孤立输入。它们更像是同一个芯片设计在不同维度上的投影Verilog 描述逻辑连接 Liberty 描述单元逻辑、时序和功耗 LEF 描述物理抽象和工艺约束 DEF 描述设计实例的物理实现状态后端工具的核心工作之一就是把这些不同格式的信息读入、对齐、关联、验证最终形成一个统一的设计数据库。这就是本文要讨论的问题LEF / Liberty / Verilog / DEFBackend Flow 为什么依赖多格式协同一、为什么单一格式无法描述完整后端设计一个后端设计不是单一维度对象。它至少同时具有几种属性逻辑属性 物理属性 时序属性 功耗属性 工艺属性 布线属性 约束属性 版图交付属性如果只看 Verilog它告诉你有哪些 module 有哪些 instance 有哪些 net 哪些 pin 连接到哪些 net但它并不告诉你cell 多宽多高 pin 在哪里 cell 是否可用于布局 该 cell 的 delay 是多少 该 cell 是否有 clock arc routing layer 有哪些 当前 instance 放在哪里 当前 net 有没有 route如果只看 LEF它告诉你物理抽象但不告诉你完整逻辑功能和时序模型。如果只看 Liberty它告诉你 timing / power / function但不告诉你真实放置位置。如果只看 DEF它告诉你当前设计物理状态但它依赖 LEF 中定义的 cell abstract 和 layer 信息。所以后端设计天然需要多格式协同。这些格式不是重复而是分工。二、Verilog描述逻辑连接关系Verilog netlist 是后端实现最常见的设计逻辑输入。它主要表达top module 子 module standard cell instance macro instance net port pin connection hierarchy例如module top ( input clk, input a, input b, output q ); wire n1; AND2X1 U1 ( .A(a), .B(b), .Y(n1) ); DFFQX1 U2 ( .D(n1), .CK(clk), .Q(q) ); endmodule这段 netlist 告诉后端工具U1 是 AND2X1 U2 是 DFFQX1 U1.Y 连接到 U2.D clk 连接到 U2.CK q 来自 U2.Q但是它没有告诉工具AND2X1 在物理上有多大 DFFQX1 的 CK pin 在 cell 哪一侧 U1 应该放在哪里 n1 应该从哪一层开始布线 clk 是否要走 clock route rule U2 的 setup / hold 约束是多少因此Verilog 是设计连接图但不是完整后端数据库。它必须和 library、technology、physical data 结合才能成为后端工具真正能处理的对象。三、Liberty让逻辑连接具有时序和功耗含义Liberty 通常被称为.lib文件。在后端实现中它的作用非常关键。它通常描述cell function pin direction timing arc setup / hold constraint clock pin attribute transition / capacitance table power model leakage power operating condition PVT corner dont_use / dont_touch 类属性对前面的例子来说Verilog 只说U2 是 DFFQX1但 Liberty 会进一步告诉工具DFFQX1 的 CK 是 clock pin D 到 Q 有 sequential arc CK 到 Q 有 clock-to-Q delay D 相对 CK 有 setup / hold check Q 的输出 transition 如何计算 cell leakage power 是多少 不同输入 transition / output load 下 delay 如何查表这就把“一个 cell 名字”变成了可用于 STA、优化、功耗分析的模型。也就是说Verilog 建立连接Liberty 解释连接的时序和功耗意义。如果 Liberty 缺失或配置错误后端工具可能仍然能读入 netlist但很多核心动作会失去依据timing analysis 不可信 setup / hold 无法判断 cell sizing 无法选择 buffer insertion 缺少 delay 模型 CTS cell selection 可能异常 power estimation 严重偏差所以Liberty 不是“后面 timing 才用的文件”。它从 design import / link 阶段开始就已经决定工具如何理解标准单元。四、LEF让逻辑单元具有物理抽象LEF 在后端实现中承担物理抽象角色。它通常包含technology layer site row 相关信息 standard cell abstract macro abstract pin geometry routing blockage cell boundary routing direction track/grid 相关信息对同一个 AND2X1 来说Verilog 只告诉工具它被实例化了。Liberty 告诉工具它的 timing 和 power。LEF 则告诉工具这个 cell 有多宽 这个 cell 有多高 它是否匹配当前 standard cell row A/B/Y pin 在哪里 pin 可以从哪些 metal layer 接入 cell 内部有哪些 obstruction cell boundary 是什么这就把一个逻辑 cell 变成了可放置、可布线的物理对象。如果 LEF 异常常见问题包括standard cell 无法合法放入 row pin access 异常 routing 无法接入 pin placement overlap macro blockage 缺失 DEF 中的 instance 无法关联 physical master GDS stream out 前后不一致因此LEF 是 Backend Flow 从逻辑走向物理的关键接口。五、DEF记录设计实例的物理实现状态DEF 和 LEF 很容易被放在一起讨论但两者含义不同。可以简单理解为LEF 描述 cell 和工艺的物理抽象 DEF 描述当前 design instance 的物理状态例如 LEF 告诉工具INVX1 这个 master cell 多宽多高pin 在哪里DEF 则告诉工具U123 这个 INVX1 instance 放在坐标 X/Y 它是否 fixed pin / port 在哪里 special net 怎么走 某些 signal net 当前 route 是什么 blockage / region / row 如何定义DEF 常用于表达die area row track component placement pin placement blockage special net regular net route via region / group所以DEF 是实现状态文件。它通常不是 library 层面的抽象而是某个具体 design 的物理快照。在 Backend Flow 中DEF 常见用途包括导入已有 floorplan 导入第三方 placement 保存阶段结果 与其他工具交接 给物理验证或 signoff 工具提供设计物理状态如果 DEF 与 LEF 不一致工具就很难正确解释 DEF 中的 component、pin、net 和 layer。六、四种格式之间的核心关系可以把 LEF / Liberty / Verilog / DEF 的关系画成这样Verilog NetlistDesign DatabaseLiberty Timing/Power ModelLEF Physical AbstractDEF Physical Implementation StateTiming / Power SemanticsPlacement / Routing SemanticsLogical ConnectivityPhysical Instance StatePlace / CTS / Route / Report / Export这个图说明一个关键点后端工具并不是“依次读几个文件”而是在把不同格式提供的语义融合成统一数据库。融合之后工具才能回答这些问题某个 instance 是什么 cell 它在库中是否存在 它的物理尺寸是多少 它的 pin 在哪里 它的 timing arc 是什么 它当前放在什么位置 它是否已经布线 它是否满足时序和物理规则这些问题没有任何单一格式可以独立回答。七、Backend Flow 的本质是多格式语义对齐很多设计导入失败表面看是“读文件失败”。但本质往往是语义没有对齐。常见不一致包括Verilog 中的 cell name 在 LEF 中找不到 Verilog 中的 cell name 在 Liberty 中找不到 LEF 和 Liberty 的 pin name 不一致 LEF 中 pin direction 与 Liberty 不一致 DEF 中 component 引用的 master 在 LEF 中不存在 DEF 中 layer name 与 tech/LEF layer 不一致 SDC 中 clock port 名与 Verilog port 不一致 GDS 中 cell name 与 LEF macro name 不一致这些问题有时不会在第一步就全部暴露。它们可能在不同阶段才出现import 阶段发现文件格式问题 link 阶段发现 cell reference 问题 placement 阶段发现 site / row / boundary 问题 routing 阶段发现 pin access / blockage 问题 timing 阶段发现 arc / constraint 问题 export 阶段发现 name / hierarchy / layer map 问题 signoff 阶段发现 GDS / DEF / netlist 不一致所以一个成熟的 Backend Flow 不应该只问文件能不能读进去更应该问不同格式之间的语义是否已经对齐八、为什么导入顺序也很重要不同工具的具体要求不同但从工程模型看导入顺序通常不是随意的。原因很简单后一个格式经常依赖前一个格式提供的上下文。例如DEF 需要 LEF/technology 提供 layer、site、cell abstract Verilog link 需要 Liberty/LEF 提供 library master timing analysis 需要 Verilog Liberty SDC parasitic context GDS export 需要设计数据库 layer map physical library一个典型的抽象顺序可以是1. 建立工具 session 2. 建立 technology context 3. 导入 LEF / physical library 4. 设置 Liberty search path / link path 5. 导入 Verilog netlist 6. 设置 current design / top 7. link project 8. 导入 DEF 或 floorplan 9. 导入 SDC / timing constraints 10. 生成检查报告这不是为了形式整齐而是为了让每一步都有清楚的上下文。如果顺序混乱常见后果是引用解析失败 layer 无法识别 cell master 缺失 pin 匹配异常 floorplan 无法建立 timing graph 不完整所以Backend Flow 中的 import 不是简单 I/O而是一个有前置语义依赖的数据库构建过程。九、为什么要建立标准格式 precheck如果这些格式之间高度相关那么在正式 import 之前就应该先做 precheck。最基础的检查包括文件是否存在 文件是否可读 文件是否为空 文件版本是否符合工具支持范围 路径是否使用绝对路径或可复现相对路径 文件列表是否完整 输出目录是否可写更进一步需要做格式协同检查Verilog cell list 是否被 LEF 覆盖 Verilog cell list 是否被 Liberty 覆盖 LEF pin list 与 Liberty pin list 是否一致 DEF components 是否都能在 LEF 中找到 master DEF layer 是否在 tech/LEF 中定义 Liberty corner 是否与当前 scenario 匹配 GDS/OASIS cell name 是否与 LEF abstract 匹配这些检查不一定一开始就全部自动完成。但至少应该把它们变成明确的工程目标。因为越早发现格式不一致后续调试成本越低。十、一个多格式协同的最小 Demo 结构对于LAY-BE-08_standard_formatsdemo 的重点不是跑完整 place/route而是验证多种标准格式如何共同构成最小后端设计上下文。可以这样组织LAY-BE-08_standard_formats/ ├─ data/ │ ├─ lef/ │ │ └─ demo_stdcell.lef │ ├─ liberty/ │ │ └─ demo_stdcell.lib │ ├─ verilog/ │ │ └─ demo_top.v │ ├─ def/ │ │ └─ demo_floorplan.def │ └─ sdc/ │ └─ demo_top.sdc ├─ scripts/ │ ├─ run_format_check.csh │ └─ clean.csh ├─ tcl/ │ ├─ 01_precheck_files.tcl │ ├─ 02_import_lef.tcl │ ├─ 03_setup_liberty.tcl │ ├─ 04_import_verilog.tcl │ ├─ 05_link_design.tcl │ ├─ 06_import_def.tcl │ └─ 07_report_format_summary.tcl ├─ logs/ │ ├─ standard_formats.log │ ├─ standard_formats.cmd.log │ └─ standard_formats.sum.log ├─ reports/ │ ├─ file_manifest.rpt │ ├─ format_precheck.rpt │ ├─ cell_name_match.rpt │ ├─ pin_name_match.rpt │ ├─ def_component_check.rpt │ └─ import_summary.rpt └─ README.md这个 demo 只关注几个核心问题文件是否完整 格式是否能被识别 cell 名是否能对齐 pin 名是否能对齐 DEF 是否能被解释 link 是否能建立基本设计上下文只要这些能稳定跑通后面的 design import、link、floorplan 才有可靠基础。十一、一个抽象的 csh 运行入口为了保持工程可复现入口脚本仍然应该显式设置路径和日志。#!/bin/csh -f set nonomatch set ROOT_DIR pwd set LOG_DIR $ROOT_DIR/logs set RPT_DIR $ROOT_DIR/reports set TCL_DIR $ROOT_DIR/tcl mkdir -p $LOG_DIR mkdir -p $RPT_DIR setenv LAY_DEMO_ROOT $ROOT_DIR setenv LAY_LEF_FILE $ROOT_DIR/data/lef/demo_stdcell.lef setenv LAY_LIB_FILE $ROOT_DIR/data/liberty/demo_stdcell.lib setenv LAY_V_FILE $ROOT_DIR/data/verilog/demo_top.v setenv LAY_DEF_FILE $ROOT_DIR/data/def/demo_floorplan.def setenv LAY_SDC_FILE $ROOT_DIR/data/sdc/demo_top.sdc setenv EDA_TOOL_BIN /path/to/backend_tool $EDA_TOOL_BIN \ -batch $TCL_DIR/run_standard_formats.tcl \ -log $LOG_DIR/standard_formats.log \ ! $LOG_DIR/standard_formats.stdout.log这里的重点不是具体工具参数而是模式输入文件显式 路径显式 日志显式 运行入口显式标准格式协同本来就容易因为路径和版本混乱出问题因此入口脚本必须先把这些隐式状态显式化。十二、一个抽象的 Tcl precheck 骨架在真正 import 前先检查文件。proc require_env {name} { if {![info exists ::env($name)]} { error Missing required environment variable: $name } } proc require_file {path} { if {![file exists $path]} { error Required file does not exist: $path } if {![file readable $path]} { error Required file is not readable: $path } if {[file size $path] 0} { error Required file is empty: $path } } foreach var { LAY_LEF_FILE LAY_LIB_FILE LAY_V_FILE LAY_DEF_FILE LAY_SDC_FILE } { require_env $var require_file $::env($var) } puts FORMAT_PRECHECK_PASS这类检查很基础但非常必要。在真实 flow 中很多失败并不是算法问题而是路径错了 文件没传全 版本拿错了 上游生成了空文件 当前用户没有读权限precheck 可以把这些问题提前暴露出来。十三、一个抽象的 import / link 骨架一个最小导入流程可以抽象为puts STAGE_BEGIN: import_lef import_lef $::env(LAY_LEF_FILE) puts STAGE_END: import_lef puts STAGE_BEGIN: setup_liberty set liberty_search_path [file dirname $::env(LAY_LIB_FILE)] set_link_path [list [file tail $::env(LAY_LIB_FILE)]] puts STAGE_END: setup_liberty puts STAGE_BEGIN: import_verilog import_verilog $::env(LAY_V_FILE) puts STAGE_END: import_verilog puts STAGE_BEGIN: link_project link_project puts STAGE_END: link_project puts STAGE_BEGIN: import_def import_def $::env(LAY_DEF_FILE) puts STAGE_END: import_def真实工具中的命令和参数可能不同但这个骨架体现了核心思想LEF 建立物理抽象 Liberty 建立时序/功耗模型 Verilog 建立逻辑连接 link 建立设计和库之间的引用关系 DEF 导入物理实现状态这些动作必须形成清晰阶段而不是混在一个不可读的大脚本里。十四、格式协同检查报告应该包含什么LAY-BE-08_standard_formats的报告不应该只写“import success”。更有价值的是形成格式协同报告。例如file_manifest.rpt format_precheck.rpt cell_name_match.rpt pin_name_match.rpt def_component_check.rpt import_summary.rpt其中报告目的file_manifest.rpt记录本次使用的所有输入文件、路径、大小和时间戳format_precheck.rpt记录文件存在性、可读性、空文件检查cell_name_match.rpt检查 Verilog cell 是否能在 LEF / Liberty 中找到pin_name_match.rpt检查 LEF / Liberty pin 是否一致def_component_check.rpt检查 DEF component 是否能匹配 LEF masterimport_summary.rpt汇总各阶段导入结果这些报告的价值在于把“格式是否协同”变成可检查、可归档、可对比的工程证据。如果后续 link 或 timing 出问题可以先查这些报告而不是直接进入复杂工具调试。十五、为什么多格式协同会影响后续所有阶段一旦 LEF / Liberty / Verilog / DEF 没有对齐后续每个阶段都会受影响。1. 影响 linkcell reference 解析失败 macro reference 缺失 top module 无法建立2. 影响 floorplansite / row 信息错误 macro abstract 缺失 DEF floorplan 无法解释3. 影响 placementcell 尺寸错误 cell class 异常 placement legality 检查失败4. 影响 timingtiming arc 缺失 clock pin 识别错误 PVT corner 不匹配5. 影响 routingpin access 错误 obstruction 不完整 layer / via 信息异常6. 影响 export / signoffDEF / GDS / Verilog 输出不一致 PV 工具无法正确读取 LVS / DRC debug 成本上升所以多格式协同不是前期准备小事。它直接决定整个 Backend Flow 是否建立在正确的设计语义之上。十六、标准格式协同的工程原则可以把标准格式协同总结成几条工程原则。1. 文件清单必须显式不要让输入文件散落在多个脚本里。应该有统一 manifest当前使用哪些 LEF 当前使用哪些 Liberty 当前使用哪个 Verilog 当前使用哪个 DEF 当前使用哪个 SDC2. 版本必须可追踪库文件、netlist、DEF 都应该能追溯版本。否则后续结果变化时很难判断是 flow 变化还是输入变化。3. 命名必须对齐cell name、pin name、layer name、top name 都必须被检查。这是 link 和后续分析的基础。4. 导入顺序必须稳定每个格式进入工具数据库的顺序应该被脚本固定下来。不要依赖个人交互习惯。5. 报告必须归档格式协同检查结果要写入 reports而不是只看屏幕输出。6. 失败必须尽早暴露越靠前发现格式问题越容易修复。越靠后发现越容易误判为工具算法、参数或设计本身问题。十七、从工具输入到工程资产很多团队对标准格式的理解停留在“工具输入文件”。但从 Backend Flow 工程化角度看它们应该被升级为工程资产可追踪的输入资产 可验证的格式资产 可对齐的语义资产 可回归的版本资产 可交接的团队资产也就是说不应该只保存run.tcl还应该保存input_manifest.rpt format_precheck.rpt cell_match.rpt pin_match.rpt import_summary.rpt cmd.log summary.log这样当后续发生问题时团队能快速回答这次到底用了哪些输入 这些输入之间是否一致 哪些格式已经成功导入 哪些引用没有解析 哪些检查是 WARN哪些是 FAIL这才是把“文件使用”变成“工程管理”。十八、总结回到题目LEF / Liberty / Verilog / DEFBackend Flow 为什么依赖多格式协同因为后端设计不是单一文件能描述的对象。四类核心格式分别承担不同职责格式核心语义Verilog逻辑连接关系Liberty时序、功耗和单元逻辑模型LEF物理抽象、工艺层、pin 和 blockageDEF当前设计实例的物理实现状态Backend 工具真正要做的不是简单“读文件”而是把这些格式融合成统一设计数据库。这个过程至少要求文件完整路径可复现格式可解析cell 名一致pin 名一致layer 名一致top / hierarchy 一致导入顺序稳定link 结果可检查report 可归档。因此标准格式协同不是 Backend Flow 的边缘准备工作而是设计数据库建立之前最关键的基础工程。如果多格式语义没有对齐后续 placement、CTS、routing、timing、export 和 signoff 都可能建立在错误基础上。结尾一句话Backend Flow 的第一层复杂性不是算法复杂而是语义复杂。LEF、Liberty、Verilog、DEF 的协同就是把逻辑、物理、时序和实现状态统一到一个可执行工程世界里的过程。