作者Darren H. Chen方向Backend Flow / 后端实现流程 / 工程自动化 / 验证基础设施demoLAY-BE-09_design_import标签EDA、Backend Flow、后端实现、Design Import、设计数据库、Verilog、LEF、Liberty、DEF、Tcl 自动化、工程可复现在 Backend Flow 里很多人第一次写脚本时会把 design import 理解成几条简单命令import_verilog top.v import_lef stdcell.lef import_liberty stdcell.lib import_def floorplan.def看起来import 似乎就是“把文件读进工具”。但在真实后端实现工程中Design Import 远远不是读文件这么简单。它真正做的是把外部文件中的逻辑、物理、时序、工艺和已有版图信息转化成工具内部可以查询、可以检查、可以优化、可以保存、可以继续流转的设计数据库第一层语义。也就是说import 的目标不是“读完文件”而是建立一个后续 flow 能够理解的设计世界。如果 import 做得不清楚后面的 link、floorplan、placement、timing、CTS、routing、report、export 都会变得不可靠。本文只讨论一个问题为什么 Design Import 不是读文件而是在建立设计数据库的第一层语义一、为什么“读文件”这个说法容易误导从表面看Backend 工具确实需要读取很多文件Verilog LEF Liberty DEF GDS / OASIS SDC SPEF / parasitic files UPF technology file所以很多人会自然地认为import read file但这只是文件系统角度的理解。从 EDA 工具内部看import 至少要完成四件事解析文件 识别语义 建立对象 挂接上下文例如读入一行 Verilog instanceDFFQX1 U1 (.D(n1), .CK(clk), .Q(q));工具不能只把这一行当字符串保存下来。它要把它变成内部对象关系module: top instance: U1 master cell name: DFFQX1 pins: D / CK / Q nets: n1 / clk / q connectivity: U1.D - n1, U1.CK - clk, U1.Q - q再进一步工具还要等后续 library context 建立后判断DFFQX1 是否存在 D pin 是否存在 CK 是否是 clock pin Q 是否是输出 这个 instance 能不能被放置 它是否有 timing arc 它是否能参与优化所以import 的本质不是读文本而是把文本转成可计算的对象网络。二、Design Import 是数据库建模入口Backend 工具真正工作的对象不是文件而是数据库。后续 flow 操作的也不是文本行而是对象module instance cell net pin port clock shape row site blockage route guide property scenario这些对象必须先进入工具内部后面的命令才有意义。例如get_cells * get_nets * get_pins * report_timing report_utilization这些命令能够工作前提是 import 阶段已经把外部文件转化成了内部对象。因此Design Import 可以理解为从文件世界到对象世界的入口。如果没有这个入口Backend Flow 只是文件堆叠。有了这个入口工具才开始拥有“当前设计”的概念。三、Design Import 建立的是第一层语义不是完整理解这里要注意一个层次区别。Design Import 建立的是第一层语义。它不一定已经完成所有理解。例如读入 Verilog 后工具可能已经知道有哪些 module 有哪些 instance 有哪些 net 有哪些 port 有哪些层次关系但它未必已经完全知道每个 instance 的物理尺寸 每个 pin 的几何位置 每条 timing arc 的延迟模型 每个 macro 的 blockage 每个 clock 的约束 每条 net 的寄生这些信息需要 library、technology、constraint、DEF、parasitic 等进一步补齐。所以import 阶段更像是建立骨架先把设计对象放进数据库 再逐步把物理、时序、约束和工艺语义挂上去从这个角度看import 和 link 的关系也会更清楚import 负责把外部数据转成内部对象 link 负责把这些对象和 library / project context 关联起来。本文重点先看 import 本身。四、不同输入格式在 import 阶段承担不同语义Design Import 不是单一文件入口而是多种格式协同进入数据库。不同文件表达的语义不同。输入格式进入数据库的核心语义Verilogmodule、instance、net、port、hierarchy、logic connectivityLEFcell abstract、pin geometry、site、layer、blockageLibertycell function、pin direction、timing arc、power modelDEFdie/core、row、component placement、net routing、special netGDS/OASISdetailed layout geometry、stream-out/signoff physical viewSDCclock、IO delay、exception、timing constraintTechnology filelayer、via、rule、unit、manufacturing grid这些文件不是并列的“附件”。它们共同定义了工具内部设计数据库的不同维度。可以把它们看成下面这个结构Input FilesImport ParserVerilogLEFLibertyDEFTechnology FileGDS / OASISSDC / ConstraintsObject CreationDesign DatabaseLogic ObjectsPhysical AbstractsTiming ModelsPlacement / Routing StateTechnology Context这个图说明import 的核心不是文件数量而是语义进入数据库的路径。五、Verilog Import建立逻辑对象图Verilog import 是 design import 中最典型的一类。它主要建立逻辑对象图。读入 Verilog 后工具需要识别module 定义 module 端口 instance 实例 net 连接 bus 表达 hierarchy 层次 black box assign / constant例如module top(input clk, input rst_n, input a, output y); wire n1; AND2X1 U_AND (.A(a), .B(rst_n), .Y(n1)); DFFQX1 U_DFF (.D(n1), .CK(clk), .Q(y)); endmoduleimport 后工具内部不应该只是保存这段文本而是建立类似这样的对象关系top ├─ ports │ ├─ clk │ ├─ rst_n │ ├─ a │ └─ y ├─ nets │ ├─ n1 │ ├─ clk │ ├─ rst_n │ ├─ a │ └─ y └─ instances ├─ U_AND : AND2X1 └─ U_DFF : DFFQX1这里最关键的是 connectivity。因为后续所有分析都依赖连接关系timing path fan-in / fan-out clock propagation optimization cone ECO impact route connectivity如果 Verilog import 阶段连接关系就错了后面的 flow 即使跑完也可能是在错误设计上做优化。六、LEF Import建立物理抽象对象LEF import 的作用不是建立逻辑连接而是建立物理抽象。它让工具知道standard cell 多大 macro 多大 pin 在哪里 哪些区域有 blockage cell 属于哪个 site metal layer 如何定义 routing layer 有什么基本属性例如一个标准单元在 Verilog 里只是一个名字INVX1但在 LEF 里它有物理含义宽度 高度 边界 pin 几何 routing obstruction site 对齐规则import LEF 后工具才可能回答INVX1 能否放入当前 row pin A / Y 在哪一层 router 如何接入 pin 是否存在 obstruction macro 的 halo / blockage 如何影响布线所以LEF import 把“单元名字”变成了“可放置、可布线的物理对象”。这也是为什么 Project Library 中 LEF / Liberty / Technology 要尽早加载和检查。七、Liberty Import建立时序和功耗语义Liberty import 进入数据库的不是几何而是 timing / power / logic model。它让工具知道cell function pin direction timing arc setup / hold constraint transition / capacitance table leakage power internal power operating condition PVT corner clock pin 属性例如Verilog 中的DFFQX1只是一个 cell type。Liberty 会进一步定义D 是输入 CK 是 clock pin Q 是输出 D - Q 不是普通组合 arc CK - Q 是 clock-to-Q arc D 对 CK 有 setup / hold 约束 不同 corner 下 delay 不同这会直接影响STA placement optimization CTS buffer selection hold fix setup fix power analysis leakage optimization因此Liberty import 不是“导入一个时序文件”而是把 cell 的时序和功耗语义送入数据库。没有这层语义工具可以识别连接但无法可靠分析时序。八、DEF Import导入已有物理状态如果说 Verilog 更多描述逻辑LEF 描述物理抽象那么 DEF 通常描述当前设计的物理状态。DEF import 可能带入die area core area rows tracks components placement pins blockages special nets routing vias这意味着 DEF import 并不只是“读一个 floorplan 文件”。它可能直接改变当前数据库的物理状态。例如component 已经有坐标 macro 已经被 fixed power stripe 已经存在 某些 net 已经有 route IO pin 已经摆放因此DEF import 是高影响 import。它应该有更严格的 precheckDEF 对应的 top 是否一致 DEF 中的 component 是否能在 netlist/library 中找到 DEF 单位是否匹配 layer 是否匹配 technology row/site 是否匹配 LEF special net 是否和 power/ground 策略一致否则导入 DEF 后数据库可能进入一个看似有物理信息、但实际不一致的状态。九、GDS / OASIS Import导入详细版图视图GDS / OASIS import 通常和 signoff、stream out、library cell detailed view、abstract generation 等有关。它提供的是更详细的 layout geometry。对 Backend Flow 来说GDS / OASIS 可能用于加载 standard cell detailed layout 加载 macro layout 生成或检查 physical abstract stream out 前合并库版图 和 signoff PV 工具闭环这里要注意LEF 是抽象物理视图 GDS / OASIS 是详细物理视图。两者如果不一致后续会产生很隐蔽的问题。例如LEF pin 和 GDS pin 不一致 LEF blockage 缺失 GDS cell boundary 与 LEF boundary 不一致 LEF 认为可布线GDS 实际有图形冲突所以在 import 阶段不仅要看文件是否读入还要看多个视图之间是否可对齐。十、Design Import 必须处理 top / current design 概念导入设计时有一个非常关键的概念current design / current top因为一个 Verilog 文件里可能有很多 module。工具必须知道哪个 module 是当前设计入口 哪个 module 是 top 后续 get_cells / report / floorplan 针对谁执行 哪些 module 是子层次 哪些 module 是 unresolved black box如果 current design 没有明确后面很多命令会出现歧义。例如get_cells * report_utilization init_floorplan export_def这些命令都隐含一个前提当前工具 session 已经知道自己正在操作哪个设计。所以Design Import 不应该只关心文件列表还要明确设计入口。一个工程化 import 脚本应该显式记录TOP_NAME VERILOG_FILES CURRENT_DESIGN IMPORT_MODE这比让工具自动猜 top 更可靠。十一、Design Import 的前置条件一个成熟的 import 阶段应该在执行前检查入口条件。例如工具版本已记录 工作目录已固定 日志目录可写 临时目录可写 netlist 文件存在 LEF 文件存在 Liberty 文件存在 technology 文件存在 TOP_NAME 已定义 文件路径没有隐式依赖 HOME 命令帮助基线已确认 import 命令可用可以用一个简单的 Tcl precheck 表达proc require_env {name} { if {![info exists ::env($name)]} { error Missing environment variable: $name } } proc require_file {path} { if {![file exists $path]} { error Required file does not exist: $path } } proc check_import_inputs {} { require_env PROJECT_ROOT require_env TOP_NAME require_file $::env(PROJECT_ROOT)/data/netlist/top.v require_file $::env(PROJECT_ROOT)/data/lef/stdcell.lef require_file $::env(PROJECT_ROOT)/data/liberty/stdcell.lib require_file $::env(PROJECT_ROOT)/data/tech/demo.tech }这类检查看起来普通但它能把大量低级错误挡在真正 import 之前。十二、Design Import 的执行顺序也很重要不同工具对执行顺序有不同要求。但从工程逻辑上看一个常见顺序是1. 固定 session 环境 2. 加载 technology / layer / site 信息 3. 导入 LEF / physical abstract 4. 导入 Liberty / timing library 5. 导入 Verilog / logical design 6. 设置 current design / top 7. 导入 DEF / 既有物理状态 8. 生成 import summary 9. 做基本一致性检查这不是唯一顺序但它体现了一个原则先建立解释环境再导入设计对象再补充物理状态再生成检查报告。如果顺序混乱就容易出现Verilog 中的 cell 找不到物理视图 DEF component 找不到 master row site 不存在 timing library 未加载 current top 不明确所以Design Import 也需要被当成一个阶段化 flow而不是几条命令随便堆起来。十三、一个推荐的 import 阶段脚本骨架下面给出一个抽象骨架不绑定具体商业工具。# # 01_import_design.tcl # puts IMPORT_BEGIN # ------------------------------------------------------------ # PRECHECK # ------------------------------------------------------------ source ./tcl/common_check.tcl check_import_inputs # ------------------------------------------------------------ # TECHNOLOGY / LIBRARY CONTEXT # ------------------------------------------------------------ source ./data/tech/demo.tech import_lef ./data/lef/stdcell.lef import_liberty ./data/liberty/stdcell.lib # ------------------------------------------------------------ # LOGICAL DESIGN # ------------------------------------------------------------ import_verilog ./data/netlist/top.v current_design $::env(TOP_NAME) # ------------------------------------------------------------ # OPTIONAL PHYSICAL STATE # ------------------------------------------------------------ if {[file exists ./data/def/floorplan.def]} { import_def ./data/def/floorplan.def } # ------------------------------------------------------------ # REPORT # ------------------------------------------------------------ redirect_to_file ./reports/import_summary.rpt { puts TOP_NAME $::env(TOP_NAME) puts IMPORT_STATUS DONE } puts IMPORT_END这段脚本只是表达结构重点不是具体命令写法而是 import 阶段必须分清precheck technology / library context logical design physical state summary report这才是工程化 import 的基本形态。十四、Design Import 后应该立即生成哪些报告导入完成后不应该直接进入下一个大阶段。应该先生成 import 报告。推荐至少包括import_summary.rpt import_file_list.rpt import_top_summary.rpt import_module_summary.rpt import_instance_summary.rpt import_net_summary.rpt import_unresolved_reference.rpt import_warning_error_summary.rpt这些报告回答的是到底导入了哪些文件 当前 top 是什么 识别了多少 module 识别了多少 instance 识别了多少 net 是否有 unresolved module 是否有 missing cell 是否有 pin mismatch 是否有路径或格式 warning这些信息非常关键。因为后续 link、floorplan、placement 出问题时你需要先确认设计是否真的按照预期进入了数据库。如果连 import 结果都没有报告后面的调试就会变成盲查。十五、Design Import 的常见错误模式Design Import 阶段最常见的问题可以分成几类。1. 文件路径错误netlist 不存在 LEF 路径错误 Liberty 路径错误 DEF 文件没找到 相对路径依赖当前目录解决思路固定工作目录 使用统一 PROJECT_ROOT 执行前 require_file 输出 import_file_list.rpt2. top 不明确没有指定 current design 多个 module 都像 top 脚本中 top 名和 netlist 中不一致 top 被层次路径写错解决思路显式定义 TOP_NAME import 后检查 current design 输出 import_top_summary.rpt3. cell 名称不一致Verilog 中 instance master 找不到 LEF 有 cellLiberty 没有 Liberty 有 cellLEF 没有 大小写不一致 库版本不匹配解决思路提前建立 project library summary import 后输出 unresolved reference 在 link 前做 missing cell 检查4. pin 不一致netlist pin 名和 library pin 名不同 bus pin 展开规则不一致 power/ground pin 未正确处理 macro pin 定义不完整解决思路检查 pin mismatch 检查 bus notation 检查 global net strategy 生成 pin mismatch report5. technology / layer 不一致DEF 中 layer 在 tech 中不存在 LEF layer 和 tech layer 不匹配 GDS layer map 不一致 unit / dbu 不一致解决思路先导入并检查 technology 输出 layer summary 在 DEF / GDS import 前做 layer precheck这些问题都说明import 阶段不是“读完没报 fatal 就可以”而是必须建立可检查的数据库入口状态。十六、Design Import 和可复现性的关系Design Import 对可复现性影响很大。因为它决定了后续 flow 的初始数据库状态。如果 import 不可复现后面的优化结果也不可能可复现。常见不可复现来源包括相对路径不固定 隐式搜索路径不同 HOME 配置影响 import library 版本不同 自动 top 推断不同 DEF 是否导入不一致 不同用户环境变量不同所以 import 阶段应该坚持输入文件显式 搜索路径显式 top 显式 日志显式 报告显式 失败策略显式例如#!/bin/csh -f set ROOT_DIR /path/to/project set LOG_DIR $ROOT_DIR/logs set RPT_DIR $ROOT_DIR/reports set TCL_DIR $ROOT_DIR/tcl mkdir -p $LOG_DIR $RPT_DIR setenv PROJECT_ROOT $ROOT_DIR setenv TOP_NAME top $EDA_TOOL_BIN -batch $TCL_DIR/01_import_design.tcl \ -log $LOG_DIR/import.log \ -cmd_log $LOG_DIR/import.cmd.log \ ! $LOG_DIR/import.stdout.log这个模板的关键不是参数名而是模式固定入口 固定目录 固定 top 固定脚本 固定日志 固定报告十七、Design Import 不是孤立阶段而是 Backend Flow 的地基Design Import 之后工具才开始拥有一个可以继续加工的数据库。后续阶段都依赖它link_project 依赖 import 产生的 design objects object query 依赖 import 产生的 cell/net/pin/port floorplan 依赖 current design 和 technology context placement 依赖 instance library row/site routing 依赖 net connectivity LEF pin technology layers timing analysis 依赖 netlist Liberty constraints export 依赖完整数据库状态因此如果 import 阶段没有做好后面的错误可能表现得很晚但根因却在最开始。例如placement 找不到 cell size根因可能是 LEF import 问题 report_timing 路径缺失根因可能是 Liberty 或 top 设置问题 routing pin 接不上根因可能是 LEF pin 或 DEF layer 问题 link 失败根因可能是 Verilog module 名和 library cell 名不一致。这就是为什么 import 阶段必须留下报告、日志和检查结果。十八、一个推荐的 Design Import Demo 目录结构如果要把本文做成一个可复现 demo可以这样组织LAY-BE-09_design_import/ ├─ data/ │ ├─ tech/ │ │ └─ demo.tech │ ├─ lef/ │ │ └─ demo_stdcell.lef │ ├─ liberty/ │ │ └─ demo_stdcell.lib │ ├─ netlist/ │ │ └─ top.v │ └─ def/ │ └─ floorplan.def ├─ scripts/ │ ├─ run_import.csh │ └─ clean.csh ├─ tcl/ │ ├─ common_check.tcl │ ├─ 01_precheck_import.tcl │ ├─ 02_import_technology.tcl │ ├─ 03_import_libraries.tcl │ ├─ 04_import_verilog.tcl │ ├─ 05_import_def_optional.tcl │ └─ 06_report_import_summary.tcl ├─ logs/ │ ├─ import.log │ ├─ import.cmd.log │ └─ import.sum.log ├─ reports/ │ ├─ import_file_list.rpt │ ├─ import_top_summary.rpt │ ├─ import_object_summary.rpt │ ├─ import_unresolved_reference.rpt │ └─ import_warning_error_summary.rpt └─ README.md这个 demo 的重点不是跑完整后端流程而是验证输入是否显式 top 是否明确 文件是否能进入数据库 对象是否能被查询 import 结果是否有报告 错误是否能被定位这正是 Design Import 阶段最应该工程化的地方。十九、Design Import 的工程价值Design Import 的价值可以概括为四点。1. 它把文件变成对象Verilog、LEF、Liberty、DEF 进入工具后不再只是文件而是 module、instance、net、pin、cell、layer、row、shape 等对象。2. 它把对象变成上下文对象不是孤立存在的。它们共同构成当前设计上下文使后续命令知道自己在操作什么。3. 它把输入变成可检查状态成熟 import 不只是执行命令还要输出 summary、warning、unresolved reference 和 object count。4. 它把后续 flow 的风险前移越早发现 top、library、pin、layer、路径问题后续 placement、routing、timing 的调试成本越低。二十、总结回到题目Design Import 不是读文件它是在建立设计数据库的第一层语义。因为 Backend Flow 真正操作的不是文件而是工具内部设计数据库。Design Import 至少完成了这些工作解析 Verilog建立 module / instance / net / port / hierarchy解析 LEF建立 physical abstract / pin geometry / site / layer / blockage解析 Liberty建立 timing / power / pin direction / cell function解析 DEF导入 floorplan / placement / routing / special net 状态明确 current design / top为 link、object query、floorplan、placement、timing 和 routing 建立初始数据库输出 import summary 和 warning/error report把外部文件世界转化成内部对象世界。所以工程化 Backend Flow 不能把 import 当成几条 read 命令。它应该被设计成一个独立、可验证、可记录、可回放、可交接的阶段。结尾一句话Design Import 的真正意义不是把文件读进工具而是让工具第一次“看见”一个可以被理解、被检查、被优化的设计世界。