全文 - OpenROAD README.md

📅 2026/8/23 18:47:33
全文 - OpenROAD README.md
1. OpenROAD README.md关于 OpenROADOpenROAD 是领先的半导体数字设计开源基础应用。OpenROAD 流程提供自主的、“无人在环路”NHILNo-Human-In-Loop的设计流程可在 24 小时内完成从 RTL 到 GDSII 的周转用于快速的设计探索与物理设计实现。ORFlowFLOW逻辑综合布图规划布局时钟树综合布线收尾Verilog 库文件 约束GDSII最终版图OpenROAD 的使命OpenROAD 旨在消除硬件设计中的成本、进度风险与不确定性壁垒促进快速、低成本的 IC 设计软件与专业知识的开放获取推动系统创新。OpenROAD 应用通过提供 Tcl 与 Python 绑定的 API实现灵活的流程控制。OpenROAD 已被应用于科研与商业项目例如来自 OpenROAD 的OpenROAD-flow-scripts来自 Efabless 的OpenLane来自 Zero ASIC 的Silicon Compiler来自 UC Berkeley 的Hammer来自 IDEA-FASoC 的OpenFASoC用于混合信号设计流程OpenROAD 通过软件开发与关键联盟中的积极协作与伙伴关系培育了一个充满活力的用户生态系统。我们不断壮大的用户社区包括硬件设计师、软件工程师、业界合作者、VLSI 爱好者、学生与研究人员。OpenROAD 大力倡导并支持以 IC 设计为基础的教育与人才培养计划方式包括在全球多所大学开设培训内容与课程Google-SkyWater 穿梭流片shuttle计划还包括 GlobalFoundries 穿梭流片设计竞赛以及 IC 设计研讨会。迄今为止OpenROAD 流程已成功用于超过 600 次硅就绪silicon-ready流片工艺节点最高达 12nm。使用 OpenROAD-flow-scripts 入门OpenROAD 提供 OpenROAD-flow-scripts 作为原生的、开箱即用的原型验证与流片流程。不过它也支持基于底层工具、数据库与分析引擎创建任意的自定义流程控制器。请参阅此处的流程文档。OpenROAD-flow-scriptsORFS是一个完全自主的 RTL-GDSII 流程用于快速的架构与设计空间探索、QoR结果质量的早期预测以及详细的物理设计实现。同时ORFS 也允许通过 Tcl 命令与 Python API 进行人工干预以便用户对各个流程阶段进行更精细的控制。下图展示了 OpenROAD-flow-scripts 的主要阶段逻辑综合输入 [RTL, SDC, .lib,.lef]逻辑综合 (Yosys)输出文件 [网表,SDC]布图规划布图初始化IO 布局 (随机)时序驱动的混合尺寸布局宏单元布局衬底接触单元tapcell与阱连接welltie插入PDN 生成布局无已放置 IO的全局布局IO 布局 (优化)含已放置 IO的全局布局尺寸调整与缓冲详细布局时钟树综合CTS时序优化填充单元fillercell插入布线全局布线详细布线收尾金属填充MetalFill插入签核时序报告生成 GDSII (KLayout)DRC/LVS 检查(KLayout)使用 OpenROAD-flow-scripts 完成 RTL-GDSII以下是使用 OpenROAD 进行物理设计实现的主要步骤布图规划Floorplanning布图初始化——定义芯片面积与利用率IO 引脚布局适用于无焊盘pad的设计衬底接触单元与阱连接插入PDN——供电网络创建全局布局Global Placement宏单元布局RAM、嵌入式宏标准单元布局针对最大转换时间max slew、最大电容、最大扇出违例与过长导线的自动布局优化与修复详细布局Detailed Placement布局合法化——对齐网格、遵守设计规则用于早期估计的增量式时序分析时钟树综合Clock Tree Synthesis为高扇出网络插入缓冲器并调整尺寸建立/保持时序优化Optimize setup/hold timing全局布线Global Routing天线效应修复生成布线引导详细布线Detailed Routing布线合法化执行 DRC 正确的布线以满足时序与功耗约束芯片收尾Chip Finishing使用 OpenRCX 进行寄生参数提取最终时序验证最终物理验证为可制造性插入虚拟金属填充dummy metal fill使用 KLayout 或 Magic 对生成的 GDS 进行 DRC 签核图形界面GUIOpenROAD GUI 是一个功能强大的可视化、分析与调试工具配有可定制的 Tcl 接口。下图展示了各个流程阶段的 GUI 视图包括布图规划、布局拥塞、时钟树综合CTS与布线后的设计。布图规划自动层次化宏单元布局布局拥塞可视化时钟树综合CTS布线PDK 支持OpenROAD 应用本身与 PDK工艺设计套件无关。不过它已在各种流程控制器的上下文下针对特定 PDK 进行了测试与验证。OpenLane 支持 SkyWater 130nm 与 GlobalFoundries 180nm。OpenROAD-flow-scripts 支持多个公有与私有 PDK包括开源 PDKGF180- 180nmSKY130- 130nmNangate45- 45nmASAP7- 预测性 FinFET 7nm专有 PDK这些 PDK 仅在 OpenROAD-flow-scripts 中受支持。它们用于对照商业平台测试和校准 OpenROAD以确保良好的 QoR。由于保密协议NDA限制无法提供这些套件的 PDK 及平台相关文件。不过如果您能够独立获取这些平台的访问权限可以自行创建所需的平台相关文件。GF55- 55nmGF12- 12nmIntel22- 22nmIntel16- 16nmTSMC65- 65nm流片通过 Google 赞助的 Efabless MPW 穿梭流片与 ChipIgnite 计划OpenROAD 已在 SKY130 与 GF180 工艺上完成了超过 600 次流片的完整物理实现。GF12LP 工艺上的 OpenTitan SoC——使用 OpenROAD 进行物理设计与优化将流片持续集成到 CI 中OpenROAD 项目积极将成功流片的 MPW 穿梭设计纳入 CI 回归测试。设计实例包括开源处理器内核、基于 RISC-V 的 SoC、加密货币矿机、机器人应用处理器、业余卫星无线电收发器、基于 OpenPower 的 Microwatt 等。构建 OpenROAD要在本地机器上构建 OpenROAD 工具请按照此处的步骤操作。第三方依赖子模块 vs. Bazel BCROpenROAD 附带两套构建系统它们获取第三方代码的方式不同CMakeCMake 没有版本化依赖的中央注册库因此第三方源码以 git 子模块的形式随附vendor在仓库中参见.gitmodules以及各子模块下嵌套的.gitmodules文件。其中一些子模块看起来像 fork但实际上只是锁定版本的上游代码树它们的存在是为了让 CMake 有一个可指向的目录。这些是上游镜像——保留为子模块是因为这是 CMake 能够消费的形式。Bazel按优先顺序首选以下惯用方式来自 Bazel 中央注册库BCR的模块MODULE.bazel中的bazel_dep。这是默认方式——版本锁定、有镜像、可复现且无需子模块。如果依赖不在 BCR 上则直接使用http_archive首选或模块扩展module extension拉取上游仓库。对于在 BCR 上存在但需要不同版本的模块可以使用git_override按提交锁定或archive_override按 URL SHA256 锁定。仅当上游未附带 BUILD 文件时才提供 BUILD 覆盖层。真正的 fork带有 OpenROAD 特定补丁保留为 git 子模块因为这也是 CMake 所需要的Bazel 随后通过其本地路径引用它。经验法则如果 Bazel 能从 BCR 或直接从上游仓库获取某个依赖就不要仅为 Bazel 添加子模块。子模块是 CMake 一侧的折衷方案而非 Bazel 构建的事实来源。回归测试./test/目录下有一组可执行的回归测试脚本。# 运行所有工具的测试./test/regression# 运行所有流程测试./test/regression flow# 运行 tool 的测试./test/regressiontool# 运行某个 tool 的全部单元测试cdsrc/tool./test/regression# 仅运行 tool 的 TEST_NAME 测试cdsrc/tool./test/regressionTEST_NAME流程测试会检查最差裕量worst slack等结果是否与参考值一致。使用report_flow_metrics [test]...可查看全部指标。% report_flow_metrics gcd_nangate45 insts area util slack_min slack_max tns_max clk_skew max_slew max_cap max_fanout DPL ANT drv gcd_nangate45 368 564 8.8 0.112 -0.015 -0.1 0.004 0 0 0 0 0 0要更新失败的回归测试请按以下说明操作# 更新日志文件即 *ok 文件 save_ok TEST_NAME # 为使用流程测试的测试更新 *.metrics 文件 save_flow_metrics TEST_NAME # 更新 *.metrics_limits 文件 save_flow_metrics_limits TEST_NAME运行openroad [-help] [-version] [-no_init] [-exit] [-gui] [-threads count|max] [-log file_name] [-db file_name] cmd_file -help 显示帮助并退出 -version 显示版本并退出 -no_init 不读取 .openroad 初始化文件 -threads count|max 使用 count 个线程 -no_splash 启动时不显示许可证启动画面 -exit 读取 cmd_file 后退出 -gui 以 GUI 模式启动 -python 以 Python 解释器启动 [仅限数据库操作] -log file_name 将日志写入 file_name -db file_name 启动时打开一个 .odb 数据库 cmd_file 加载并执行 cmd_file除非指定了命令行选项-no_initOpenROAD 会加载 Tcl 命令文件~/.openroad。随后如果命令行上指定了cmd_fileOpenROAD 会加载该命令文件。除非指定了-exit命令行标志否则它会进入交互式 Tcl 命令解释器。OpenROAD 应用所包含的可用工具/模块列表及其说明请参阅此处。Git 快速入门OpenROAD 使用 Git 进行版本控制与代码贡献。请参阅此处的贡献快速入门教程熟悉相关流程。理解警告与错误消息遇到看不懂的 OpenROAD 警告或错误我们编制了一张包含所有消息的表格您或许可以在此处找到答案。许可证BSD 三条款许可证BSD 3-Clause License。详见 LICENSE 文件。2. OpenROAD 中使用的软件OpenROAD 是一个开源的 RTL-to-GDSII 数字芯片物理设计流程由 DARPA IDEA 计划资助开发目标是实现24 小时内、无需人工干预的自动化芯片设计。以下从设计步骤、工具软件和开源归属三个维度说明2.1. OpenROAD 完成的设计步骤OpenROAD 覆盖从综合后网表到可制造 GDSII 版图的完整后端物理设计流程主要步骤如下 阶段主要工作内容1. Floorplanning布局规划定义芯片面积与利用率IO 引脚放置宏单元Macro放置插入 Tap cell / Well tie构建 PDN电源分配网络2. Global Placement全局布局标准单元与宏单元的全局放置时序驱动与可布线性优化自动修复 max slew、max capacitance、max fanout 违规3. Detailed Placement详细布局合法化Legalize——对齐到网格、遵守设计规则增量时序分析4. Clock Tree SynthesisCTS插入缓冲器/反相器构建低偏斜、低功耗的时钟树分布网络5. Timing OptimizationSetup / Hold 时序优化缓冲器插入与尺寸调整Buffering Sizing6. Global Routing全局布线生成布线导引Routing Guides天线效应修复7. Detailed Routing详细布线基于 MILP 的 panel 级详细布线生成 DRC 正确的金属与通孔几何图形8. Chip Finishing芯片收尾寄生参数提取OpenRCX最终时序验证Filler cell 插入Dummy metal fill9. Signoff签核DRC、LVS、天线规则检查导出 GDSII完整流程在 OpenROAD-flow-scriptsORFS中被实现为自动化流水线 。2.2. 使用的工具软件OpenROAD 采用模块化架构各阶段由不同引擎完成基于共享内存数据库OpenDB进行数据交换 2.2.1. 核心引擎OpenROAD 项目原生/主导工具功能来源OpenDB共享内存数据库统一数据模型OpenROAD 项目TritonFPlan布局规划、IO 放置、PDN 生成OpenROAD 项目RePlAce全局布局分析优化 拥塞感知UC San Diego / OpenROADTritonCTS时钟树综合H-tree、动态规划OpenROAD 项目FastRoute全局布线OpenROAD 项目TritonRoute详细布线UC San Diego为 OpenROAD 开发OpenSTA静态时序分析STA最初独立开源现主要由 OpenROAD 维护OpenRCX寄生参数提取RC ExtractionOpenROAD 项目PDNSim电源网络分析IR Drop / EMOpenROAD 项目OpenROAD GUI可视化、调试、 congestion/CTS 分析OpenROAD 项目2.2.2. 集成的第三方开源工具工具功能来源/归属YosysRTL 逻辑综合、工艺映射YosysHQ独立第三方开源项目ABC逻辑优化与技术映射UC Berkeley常与 Yosys 联用MagicDRC、LVS、Dummy fill、GDS 导出UC Berkeley独立第三方开源项目NetgenLVS版图 vs 原理图验证独立第三方开源项目KLayoutGDS 合并、DRC 签核、版图可视化独立第三方开源项目2.3. 这些工具都是第三方开源项目吗不全是。需要区分两类2.3. 1.OpenROAD 原生/主导维护的工具如 TritonRoute、TritonCTS、TritonFPlan、OpenRCX、PDNSim、OpenDB 等是 OpenROAD 项目由 UC San Diego、Precision Innovations 等机构主导专门为该流程从头开发的引擎。它们虽然以开源许可主要为 BSD 3-Clause发布但属于 OpenROAD自身的核心组件而非第三方项目 。2.3.2.第三方独立开源项目如Yosys、Magic、Netgen、KLayout等在 OpenROAD 诞生之前就已存在由各自的社区独立维护后被 OpenROAD 集成到完整流程中作为前后端衔接或签核工具 。总结OpenROAD 完整流程built entirely on open-source tools 所有工具均为开源软件但工具集合中既包含 OpenROAD 项目自研的核心引擎也包含外部第三方开源工具。不存在商业闭源组件。3. 不流片时OpenROAD 的闭环能力不流片的情况下OpenROAD 可以把闭环推进到可流片就绪tapeout-ready的 GDSII 签核级signoff 风格物理验证——也就是版图生成后的 DRC/LVS 收敛、寄生参数提取后的最终时序确认。再往后真正的流片、硅后测试才需要晶圆厂。下面分层说明。闭环能走到哪里以 OpenROAD-flow-scriptsORFS为例全流程是 RTL → GDSII各环节自带验证反馈阶段闭环中的验证手段不流片能否完成逻辑综合Yosys语法/可综合性检查可用 Yosysequiv_*做综合前后网表的形式等价验证✅布图规划 / 布局时序驱动布局内嵌 OpenSTA 增量时序分析、拥塞估计✅时钟树综合CTS时钟偏斜/延迟报告、建立/保持时序修复✅全局/详细布线TritonRoute 内部 DRC 检查、天线效应修复、布线 DRC 收敛✅收尾FinishingOpenRCX 寄生提取SPEF→ 回注 OpenSTA 做最终时序签核报告✅物理验证用 KLayout / Magic / netgen 对生成的 GDS 做 DRC 与 LVS版图 vs 原理图一致性检查✅开源 PDK 下也就是说设计→实现→验证→修复→再验证的迭代闭环完全在流片前闭合你最终拿到的是一份 DRC 干净、LVS 通过、含真实寄生参数的最终时序报告、带签核 QoR 指标的 GDSII 文件——这已经是送去流片前的最后一步。OpenROAD 在 Sky130、GF180 上的 600 次成功流片正是这样验证出来的很多 MPW 项目直接把这个结果送进晶圆厂。但有三条边界要注意1. 功能逻辑验证不在 OpenROAD 范围内。OpenROAD 是物理设计工具不验证RTL 功能对不对。完整闭环需要自己补上仿真Verilator / Icarus Verilog cocotb 测试平台形式验证SymbiYosysSVA 断言、Yosys 等价性检查保证综合/优化后网表与 RTL 功能一致这一步在 RTL 进入 OpenROAD 之前完成与物理闭环拼接起来才是真正的端到端闭环。2. 物理验证的含金量取决于 PDK。开源 PDKSKY130、GF180有完整开放的 DRC/LVS 规则文件Magic/KLayout/netgen 能做工坊认可的完整物理签核——这类工艺的闭环是真闭环流片成功率有实际背书。专有 PDKTSMC、Intel、GF12 等受 NDA 限制代工厂的黄金签核规则Calibre deck 等不可用OpenROAD 只能做内部 DRC 和保守的构造即正确设计不能算真正的签核收敛——这正是之前那篇论文提到的guardband问题。3. 缺少代工厂级精度与硅后环节。相比商业签核流程PrimeTime、StarRC、CalibreOpenSTA/OpenRCX 的精度有差距流程会靠加大裕量补偿IR 压降/电迁移分析只有基础能力OpenROAD 的 PSM 模块可做电源网格分析工艺角覆盖、变异分析也不完整。而功耗实测、良率、硅后调试这些只有流片之后才能闭环——这是任何无流片流程都无法跨越的物理边界。总结不流片时OpenROAD 能把闭环做到GDSII 就绪 DRC/LVS/最终时序全通过开源 PDK 下即为真实签核级若再自行加上 Verilator/SymbiYosys 的功能验证就是完整的RTL 进、可流片版图出的端到端闭环。唯一无法闭合的是硅本身——实际芯片的功耗、性能、良率只能等流片后验证。