公司动态

全文 - 第01 部分- openroad-flow-scripts UserGuide

📅 2026/8/25 23:44:38
全文 - 第01 部分- openroad-flow-scripts UserGuide
原文00. Document 首页欢迎使用 OpenROAD Flow Scripts 文档OpenROAD“开放、可访问设计的 foundation 与实现”项目于 2018 年 6 月在 DARPA IDEA 计划下启动。OpenROAD 旨在消除目前阻碍设计人员使用先进工艺进行硬件实现的成本、专业知识和不可预测性等障碍。项目团队由高通、Arm 和多所大学及合作伙伴组成加州大学圣地亚哥分校牵头正在开发一套完全自主的开源工具链用于数字 SoC 版图生成专注于系统级芯片设计的 RTL 到 GDSII 阶段。因此OpenROAD 全面应对当今设计成本危机的多个方面工程资源、设计工具许可证、项目进度和风险。IDEA 计划的目标是无人参与NHIL设计要求 24 小时周转时间且零损耗功率-性能-面积PPA设计质量。NHIL 目标要求工具能够成功自适应和自动调整以完成流程无需或只需最少人工干预。机器智能通过在整个综合、布局和布线过程中对流程和优化结果进行高效建模和预测增强人类专业知识。这还伴随着指标和机器学习基础设施的开发。24 小时运行时间目标意味着必须在整个设计过程中对问题进行战略性分解通过智能分配和管理计算资源来求解和重组聚类和划分的子问题。这确保了 NHIL 设计优化在其可用的[线程数 * 小时数]资源盒子内完成。实现云资源并行和分布式搜索的分解会带来结果质量的损失但随后通过改进的流程可预测性和增强的优化来恢复。在我们的网站和资源页面此处了解更多关于该项目的信息。OpenROAD Flow Scripts 入门OpenROAD Flow 是一个完全基于开源工具的全流程 RTL 到 GDS 流程。该项目旨在实现自动化、无人参与的数字电路设计周转时间为 24 小时。更多信息请参阅我们的仓库 README。请参阅这些 技巧 以帮助改进您的搜索结果。设置支持的操作系统请注意根据安装方法的不同我们对各种操作系统的支持程度也有所不同。图例Y表示支持。-表示不支持。操作系统本地安装预编译二进制文件Docker 安装Windows 子系统 for LinuxDebian 12YYY-Debian 13YYY-Ubuntu 22.04YYY-Ubuntu 24.04YYY-Ubuntu 26.04YYY-RHEL 8/9Y-Y-Rocky 8Y-Y-Rocky 9Y-Y-macOSY-Y-Windows 10 及以上--YY系统要求要构建二进制文件并运行gcd流程最低要求1 个 CPU 核心和 8GB 内存。推荐配置4 个 CPU 核心和 16GB 内存。gcd 是一个小型设计因此需要较少的计算能力。 更大的设计可能需要更好的硬件。构建或安装 ORFS 依赖项我们支持四种主要的安装方式Docker预编译二进制文件Windows 子系统 for Linux (WSL)本地安装您也可以选择并使用构建脚本来自定义构建过程。详见下一节。构建命令和选项./build_openroad.sh--help./build_openroad.sh脚本的选项参数描述-h或--help打印帮助信息。-o或--local本地构建而不是构建 Docker 镜像。-l或--latest使用 --or_branch 分支或默认 ‘master’ 分支的 tools/OpenROAD 最新版本。--or_branch BRANCH_NAME使用 BRANCH 分支的 tools/OpenROAD 最新版本。--or_repo REPO_URL使用 REPO-URLhttps/ssh上的 fork 作为 tools/OpenROAD。--no_init跳过初始化子模块。-t N或--threads N编译软件时使用 N 个 CPU。-n或--nice对所有作业使用 nice。除非同时给出--threads否则使用所有 CPU此时使用 N 个线程。--yosys-args-overwrite在 Yosys 编译期间不使用此脚本设置的默认标志。--yosys-args STRINGYosys 编译的额外编译标志。--openroad-args-overwrite在 OpenROAD 应用编译期间不使用此脚本设置的默认标志。--openroad-args STRINGOpenROAD 应用编译的额外编译标志。--install-path PATH安装工具的路径。默认为${INSTALL_PATH}。--clean编译前交互式调用 git clean。有助于删除旧构建文件。--clean-force编译前调用 git clean。警告此选项不会要求确认。有助于删除旧构建文件。-c或--copy-platforms仅适用于 Docker 构建。将平台复制到 Docker 镜像内部。--docker-args-overwrite仅适用于 Docker 构建。不使用此脚本为 Docker 构建设置的默认标志。--docker-args STRING仅适用于 Docker 构建。Docker 构建的额外编译标志。运行设计示例设计配置可在designs目录中找到。您可以使用以下任一方法选择设计流程Makefile在文件顶部包含示例设计配置列表。取消注释相应的行以选择设计。使用 shell 环境指定设计。例如# 确保您在 ./flow 目录中makeDESIGN_CONFIG./designs/nangate45/swerv/config.mk# 或exportDESIGN_CONFIG./designs/nangate45/swerv/config.mkmake默认情况下使用nangate45平台选择gcd设计。生成的 GDS 将位于flow/results/nangate45/gcd/6_final.gds。对于此设计流程只需几分钟即可生成 GDS。我们建议首先实现此设计以验证您的流程和工具设置。设计探索和自动参数调优AutoTuner 是一个自动参数调优框架能够为商业和学术 RTL 到 GDS 流程执行自动参数调优。AutoTuner 提供的两个主要功能是OpenROAD-flow-scripts 的自动超参数调优框架OpenROAD-flow-scripts 的参数扫描实验有关 AutoTuner 的详细说明请参阅此处的说明。添加设计要将新设计添加到flow目录请参阅此处的文档。平台OpenROAD-flow-scripts 支持以下开放平台从 Verilog 到 GDSASAP7Nangate45 / FreePDK45SKY130GF180SG13G2这些平台具有允许我们重新分发 PDK 和 OpenROAD 平台特定文件的许可许可证。平台文件和许可证位于platforms/{platform}。OpenROAD-flow-scripts 还支持以下专有平台GF55GF12Intel22Intel16TSMC65由于 NDA 限制无法提供这些套件的 PDK 和平台特定文件。但是如果您能够访问这些平台您可以自己创建必要的平台特定文件。平台设置完成后您可以创建包含设计信息的新设计配置。请参阅design目录中的示例配置。有关如何在 OpenROAD-flow-scripts 中使用环境变量配置平台和设计特定参数的详细信息请参阅流程变量文档。添加平台请参阅平台引入文档以设置 OpenROAD-flow-scripts 的新平台。实现设计运行make以执行从 Verilog 到 GDS 的流程。最终输出将位于flow/results/{platform}/{design_name}/6_final.gds其他顶层 Verilog 设计的冒烟测试框架将您的 Verilog 文件放入designs/src/harness启动工作流从设计中只有几个引脚的非常小的子模块开始。makeDESIGN_NAMETopLevelNameDESIGN_CONFIG$(pwd)/designs/harness.mk如何贡献如果您愿意贡献请参阅参与方式部分。如果您是具有 EDA 背景的开发人员请在开发人员指南部分了解更多关于如何使用 OpenROAD 作为工具基础设施的信息。联系方式我们维护以下沟通渠道项目主页和新闻https://theopenroadproject.orgTwitterhttps://twitter.com/OpenROAD_EDA问题和错误OpenROAD Flowhttps://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/issues带有 OpenROAD Flow Scripts 的 OpenROADhttps://github.com/The-OpenROAD-Project/OpenROAD/issues/讨论OpenROAD Flowhttps://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/discussions咨询openroaducsd.edu另请参阅我们的常见问题。行为准则请阅读我们的行为准则此处。网站地图省略。。。。01. 用户指南OpenROAD 项目使用三个工具来执行自动化的 RTL 到 GDS 版图生成yosys逻辑综合OpenROAD从布图规划到详细布线KLayoutGDS 合并、DRC 和 LVS针对公共PDK为了实现 RTL 到 GDS 的自动化我们提供了OpenROAD Flow其中包含集成上述三个工具的脚本。代码组织OpenROAD Flow仓库是一个使用 OpenROAD 工具的 RTL 到 GDS 示例流程。仓库中的build_openroad.sh脚本会自动构建 OpenROAD 工具链。两个主要目录是tools/包含完整的 yosys 和OpenROAD App的源代码两者均通过子模块引入以及流程所需的其他工具。flow/包含用于运行设计流程的参考配方和脚本。它还包含公共平台和测试设计。环境搭建请参阅快速上手指南。使用 OpenROAD Flow有关流程的详细信息以及如何通过流程运行设计请参阅这里的文档。使用 OpenROAD App有关该应用程序及其可用功能和命令的详细信息请参阅这里的文档。02. 使用预编译二进制文件安装 KLayout 和 Yosys请确保 KLayout 的版本以klayoutVersion变量表示与DependencyInstaller 脚本中使用的版本一致。安装说明Klayout0.28.8Yosys0.58安装 OpenROAD从 Precision Innovations 的 GitHub releases 页面下载包含自足依赖项的预编译二进制文件地址在这里。感谢 Precision Innovations 托管并维护这些二进制文件。目前支持以下平台Ubuntu 20.04/22.04Debian 11按以下步骤下载第 1 步点击 Precision Innovations 的 GitHub releases 链接。第 2 步下载适用于您发行版的构建产物。第 3 步根据平台使用软件包安装器运行安装命令。例如 Ubuntu 20.04 使用sudoaptinstall./openroad_2.0_amd64-ubuntu20.04.deb验证安装您可以以非递归方式克隆 OpenROAD-flow-scripts 仓库。git clone https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts.git相应地导出路径变量。# 这些变量在 flow/Makefile 中使用。请务必确保 yosys 路径已生效。 export OPENROAD_EXE$(command -v openroad) export YOSYS_EXE$(command -v yosys) # 仅当 KLayout 是从源码构建时才需要 export LD_LIBRARY_PATHklayout_location/bin:$PATH yosys -help yosys -m slang -p slang_version openroad -help cd flow make make gui_final03. 使用 Docker 从源码构建:::{Note}本文档介绍如何构建您自己的 Docker 镜像。如果您的目标是使用最新版本的 OpenROAD-Flow-Scripts请参阅 Docker Shell 文档。:::前提条件使用此方法您只需在机器上安装Docker。确保按照我们的系统要求为虚拟机VM分配了足够的内存。有关设置 CPU 核心数和内存限制请参阅这份 Docker 指南。:::{Warning}build_openroad.sh将使用主机的 CPU 数量来编译openroad。请检查您的 Docker 守护进程设置确保所有主机 CPU 都可用。如果不确定可以使用下面的命令检查。如果输出的数字与您机器的 CPU 数量不同建议您限制脚本使用的 CPU 数量见下文说明。:::dockerrun--rmubuntu:22.04 nproc基于预编译二进制文件使用 Docker 构建感谢 Precision Innovations他们定期发布适用于 Ubuntu 和 Debian 的 OpenROAD.deb安装包。这大大减少了所需的编译时间。我们建议使用受支持操作系统的 Docker 镜像并使用来自Precision Innovations 的预编译二进制文件安装 OpenROAD。您可以使用下面的命令以交互模式启动容器。dockerrun-itubuntu:22.04现在您已准备好安装预编译二进制文件。安装预编译二进制文件的说明请参阅这里。基于源码使用 Docker 构建另外如果您希望使用 OpenROAD 仓库的最新提交请按照下面的说明操作。克隆并构建以下说明以 Ubuntu 22.04 作为基础操作系统构建 Docker 镜像gitclone--recursivehttps://github.com/The-OpenROAD-Project/OpenROAD-flow-scriptscdOpenROAD-flow-scripts ./build_openroad.sh您可以使用-t|--threads N参数限制 CPU 数量./build_openroad.sh--threadsN验证安装二进制文件只能在 Docker 容器内部使用。下面是一个从已创建的Docker 镜像启动容器的示例。dockerrun--rm-it-u$(id-u${USER}):$(id-g${USER})-v$(pwd)/flow:/OpenROAD-flow-scripts/flow openroad/orfs然后在 docker 内部source./env.sh yosys-helpyosys-mslang-pslang_versionopenroad-helpcdflowmakeexit另外您也可以按如下方式使用docker_shell实用工具。请务必确保您位于flow目录中。cdflow util/docker_shellmake启用 GUI 支持要使用 GUI 功能您需要使用以下命令启动 docker适用于 Ubuntu/Debian 操作系统用户docker run --rm -it \ -u $(id -u ${USER}):$(id -g ${USER}) \ -v $(pwd)/flow:/OpenROAD-flow-scripts/flow \ -e DISPLAY${DISPLAY} \ -v /tmp/.X11-unix:/tmp/.X11-unix \ -v ${HOME}/.Xauthority:/.Xauthority \ --network host \ --security-opt seccompunconfined \ openroad/orfs在 Mac OS X 上使用 Docker 运行 GUI 的用户请参阅这里。然后使用docker run --rm -it -e DISPLAYIP_LIKE_FROM_TUTORIAL:0 --network host --privileged IMAGE_NAME另外您也可以按如下方式使用docker_shell实用工具来运行 GUI。请务必确保您位于flow目录中。cdflow util/docker_shell gui_finaldocker_shell 是一个实用的工具它使用用户的参数来自动化执行 上述 Docker 命令。请参阅[这里](./DockerShell.md)的文档。为不同操作系统构建 Docker 镜像以下说明以参数化的操作系统分两个阶段构建 Docker 镜像。这些说明面向 CI 以及希望使用 Ubuntu 22.04 以外操作系统的开发者普通用户应使用前面章节中的步骤。dev 阶段安装运行 OpenROAD 和OpenROAD Flow Scripts 所需的所有依赖项和软件包。builder 阶段生成运行流程所需的全部二进制文件即openroad和yosys。gitclone--recursivehttps://github.com/The-OpenROAD-Project/OpenROAD-flow-scriptscdOpenROAD-flow-scripts ./etc/DockerHelper.sh create-targetdev-os$OS_NAME./etc/DockerHelper.sh create-targetbuilder-os$OS_NAME04. 使用 Docker 镜像构建示例设计docker_shell脚本用于通过 OpenROAD-flow-scripts 的 Docker 镜像启动命令。此外当前工作目录会以当前用户的凭据映射到 Docker 镜像中。构建 Docker 镜像如果您想使用 master 分支的最新版本可以跳过此步骤。如果您正在开发 ORFS/OR则应当构建自己的镜像。cd OpenROAD-flow-scripts ./build_openroad.sh使用docker_shell运行 ORFS构建一个示例设计并运行 GUIcd flow util/docker_shell make util/docker_shell make gui_final您也可以启动一个交互式 bash 会话util/docker_shell bash如果您需要使用与默认不同的 Docker 镜像可以通过docker_shell_IMAGE环境变量进行覆盖OR_IMAGEopenroad/orfs:v1234 util/docker_shell make如果您的 OpenROAD Docker 镜像是使用预编译二进制文件构建的您可能需要按如下方式为模块指定自定义路径。OR_IMAGEopenroad_prebuilt_image YOSYS_EXE/oss-cad-suite/bin/yosys util/docker_shell make在OpenROAD-flow-scripts/flow文件夹之外使用docker_shell如果您的设计保存在一个并非 OpenROAD-flow-scripts git 仓库分叉fork的 git 源码仓库中您仍然可以使用docker_shell脚本。使用docker_shell的两种方式直接从 ORFS 所在位置调用它。将该脚本复制到您的源码文件夹中。这样您就可以构建 Docker 镜像并发布到私有 Docker 仓库并将 ORFS 版本锁定为与您源码相对应的版本。这为您提供了一种轻松部署 ORFS 更新的方式发布新的Docker 镜像、修改docker_shell的副本并创建拉取请求pull request以便在您的私有构建服务器上测试升级。05. 在 Docker 中运行 Claude Codeclaude.sh脚本在 Docker 容器内运行Claude Code并带有--dangerously-skip-permissions参数。该容器提供了一个沙箱环境Claude Code 在其中拥有完整的 shell 访问权限但除挂载的仓库之外无法影响主机系统。该容器支持使用CMake和Bazel构建和测试 OpenROAD运行ORFS 流程基于 Makefile 的 RTL-GDSII通过卷挂载将所有文件更改同步反映到主机上前提条件在您的机器上安装 DockerClaude Code 凭据在主机上运行一次claude进行身份验证或在您的环境中设置ANTHROPIC_API_KEY快速上手./claude.sh首次运行时会自动构建 Docker 镜像。来自~/.claude/的凭据会被挂载到容器中。ORFS 环境env.sh会自动加载因此工具无需任何手动设置即可在PATH中使用。用法./claude.sh [OPTIONS] [-- CLAUDE_ARGS...]选项选项描述--build强制重新构建 Docker 镜像--shell启动 bash shell 而不是 Claude Code--image NAME覆盖 Docker 镜像默认openroad/flow-claude:latest--name NAME覆盖容器名称默认claude-orfs-h,--help显示帮助--之后的参数会直接传递给claude。示例# 交互式 Claude Code 会话./claude.sh# 向 Claude Code 传递提示词./claude.sh ---pfix the failing test in src/drt# 交互式 bash shell用于手动构建./claude.sh--shell# 更新后强制重新构建镜像./claude.sh--build# 运行并行会话CONTAINER_NAMEclaude-2 ./claude.sh在容器内构建和测试使用--shell时工具已经在PATH中# CMake 构建./build_openroad.sh--local--no_init-t$(nproc)# Bazel 构建cdtools/OpenROADbazel build //...# 运行 ORFS 流程cdflowmakeDESIGN_CONFIG./designs/nangate45/gcd/config.mkClaude Code 可以在交互式会话中自主运行这些相同的命令。跨运行持久化的内容容器在退出时会被删除--rm但以下主机目录会被挂载因此其内容会保留主机路径容器路径内容仓库根目录/workspace所有源代码和构建产物~/.claude/~/.claude/凭据、设置、会话历史~/.cache/bazel-claude/~/.cache/bazel/Bazel 外部依赖项~/.gitconfig~/.gitconfigGit 身份信息只读$SSH_AUTH_SOCK转发用于通过 SSH 访问 git 的 SSH 代理环境变量所有环境变量都是可选的。当在主机上设置时它们会被传入容器。变量用途ANTHROPIC_API_KEYAPI 密钥可替代存储的凭据ANTHROPIC_MODEL模型覆盖CLAUDE_IMAGEDocker 镜像覆盖与--image相同CONTAINER_NAME容器名称覆盖与--name相同BAZEL_CACHE_DIRBazel 缓存的主机路径默认~/.cache/bazel-claudeCLAUDE_CODE_USE_BEDROCK使用 AWS BedrockAWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_REGION用于 Bedrock 的 AWS 凭据工作原理该配置由三个文件组成docker/Dockerfile.claude在openroad/flow-ubuntu22.04-dev基础镜像已包含所有OpenROAD 构建依赖项之上扩展了Java 21 和 Bazelisk用于 Bazel 8.x 构建Node.js 22 LTS 和 Claude Code CLIVS Code CLI、sudo 及其他便利工具镜像中没有复制任何源代码。所有内容都来自卷挂载。docker/claude-entrypoint.sh处理 UID/GID 映射使容器内创建的文件在主机上具有正确的所有权。该入口点脚本会创建与主机 UID/GID 匹配的用户加载env.sh以设置工具路径在运行命令之前通过setpriv降低权限这遵循了与tools/OpenROAD/etc/docker-entrypoint.sh以及flow/util/docker_shell中--user模式相同的模式。claude.sh封装脚本使用正确的卷挂载、环境变量和入口点参数来组装docker run命令。安全模型Claude Code 在容器内部以--dangerously-skip-permissions运行这意味着它无需确认即可执行任何 shell 命令。Docker 容器提供了隔离文件访问仅限于挂载的仓库无法访问主机系统的软件包、服务或其他项目无法访问绑定到 localhost 的主机网络服务docker kill claude-orfs可立即停止一切:::{Warning}容器具有网络访问权限Anthropic API 和 Bazel 依赖项获取需要。原则上 Claude Code 可以发起出站网络请求。如果担心这一点请使用Docker 网络策略将出站流量限制为仅允许访问 Anthropic API 端点。:::06. 从源码本地构建克隆并安装依赖项setup.sh脚本会安装所有依赖项包括 OpenROAD 的依赖项如果尚未安装的话。支持的配置为Ubuntu 20.04、Ubuntu 22.04、Ubuntu 22.04aarch64、RHEL 8、RockyLinux 9 和 Debian 11。gitclone--recursivehttps://github.com/The-OpenROAD-Project/OpenROAD-flow-scriptscdOpenROAD-flow-scriptssudo./setup.sh使用 Bazel 构建 OpenROAD 并运行 ORFS 流程不受支持面向 ORFS/OpenROAD 开发者。当使用 Bazel 构建 OpenROAD 时./setup.sh中的大部分内容并不需要——这里提供的是构建OpenROAD 并测试 ORFS 流程的最低限度配置。无需 sudo。请先安装 Bazelisk。gitclone--recursivehttps://github.com/The-OpenROAD-Project/OpenROAD-flow-scriptscdOpenROAD-flow-scripts bazelisk run //:install_for_bazelcdflowmake构建./build_openroad.sh--local:::{Note}每次构建都会在主目录中生成一个build_openroad.log文件。如需提交 issue可以将它上传到 OpenROAD-flow-scripts 仓库issue 表单的「Relevant log output」相关日志输出部分。:::验证安装设置好环境后二进制文件应该可以在您的$PATH中使用。make命令会使用nangate45PDK 为默认设计gcd运行从RTL 到 GDSII 的生成流程。source./env.sh yosys-helpyosys-mslang-pslang_versionopenroad-helpcdflowmake您可以使用以下命令在 OpenROAD GUI 中查看最终版图图像。makegui_final在 Visual Studio Code 中编译和调试使用dev_env.sh设置环境变量然后启动 Visual Studio Code。请确保已安装 CMake 插件。../dev_env.sh code tools/OpenROAD/使用 Bazel 构建 OpenROAD 并运行一些 ORFS 流程本地使用场景仅安装 Bazelisk无需其他依赖项也不需要运行sudo ./setup.sh修改并构建 OpenROAD用几个 ORFS 流程测试构建好的 OpenROADOpenROAD 和 ORFS 中的 Bazel 支持仍在开发中在深入探索 Bazel构建之前建议先积累一些 Bazel 使用经验。欢迎贡献代码要构建designs/asap7/gcd:gcd_floorplancd flow (cd ../tools/OpenROAD bazel build :openroad -c opt) bazelisk build designs/asap7/gcd:gcd_floorplan或者运行当前 Bazel 中可用的所有流程cd flow (cd ../tools/OpenROAD bazel build :openroad -c opt) bazelisk build ...注意在 OpenROAD 切换到 bzlmod 之前ORFS 以临时过渡的方式使用OpenROAD 的 Bazel 构建产物切换之后构建所有流程会变得更简单因为 ORFS 将直接构建所需的 OpenROADcd flow bazelisk build ...ORFS 使用 bazel-orfs来实现流程并从 Docker 镜像中获取部分依赖项如 yosys。随着时间推移所有依赖项都将使用 Bazel 构建对 ORFS Docker 镜像的依赖将逐步淘汰。使用最新的 bazel-orfs 和 ORFS Docker 镜像升级 MODULE.bazel运行bazelisk run bazel-orfs//:bump然后提交 MODULE.bazel 和 MODULE.bazel.lock。07. 使用 WSL 构建Windows Subsystem for Linux简称 WSL可以让您在 Windows 机器上挂载一个基于 Linux 的操作系统从而使您既能在本地也能通过 Docker构建 OpenROAD-flow-scripts。安装 WSLWSL 的安装说明见这里。您可以使用任何受支持的内核发行版例如Ubuntu 20.04、Ubuntu 22.04、RHEL 8、RockyLinux 9、Debian 11。我们建议用户继续按照下面的 Docker 构建指南操作。不过如果您希望在本地安装可以按照这里的本地构建说明操作。提示您可以使用这份指南删除您的 WSL 内核发行版。Docker 配置本节假设您已经在 Windows 上设置好了 Docker。如果没有请参阅Docker 官方网站的说明地址在这里。您需要启用以下选项以允许 WSL 使用 Docker。General常规 Use the WSL 2 Based engine使用基于 WSL 2 的引擎应为默认选项Resources资源 WSL integrationWSL 集成 Enable integrationwith my default WSL distro启用与我的默认 WSL 发行版的集成并选择 “Ubuntu-22.04”或您所安装的发行版。访问 WSL您可以通过名为 “Ubuntu 22.04 LTS” 的应用程序访问 WSL。运行以下命令sudo apt-get update; sudo apt-get upgrade; sudo apt install -y build-essential python3 python3-venv python3-pip make验证 Docker 是否正在运行docker run hello-world您应该看到Hello from Docker! This message shows that your installation appears to be working correctly.如果到这里一切顺利恭喜您已经配置好了一个带有必要依赖项的Linux 系统现在可以按照 Docker 指南继续操作了。08. 向 ORFS 添加新设计本节介绍如何向 ORFS 仓库添加 Verilog 设计以执行完整的RTL-GDS 流程。下面的设计示例基于spm设计它使用gf180平台实现了一个单端口存储器Single-port memory。此流程适用于您所选平台上的任何设计。注意以下命令以OpenROAD-flow-scripts/flow目录作为流程的起始基准目录。第 1 步根据顶层模块名创建 Verilog 源文件目录。cddesigns/srcmkdirspmcdspmvispm.v将这个Verilog 代码复制到 spm.v 中。第 2 步创建config.mk以定义设计配置。cddesigns/gf180mkdirspmcdspmviconfig.mk第 3 步在config.mk中定义关键设计参数。export PLATFORM gf180 export DESIGN_NAME spm export VERILOG_FILES $(sort $(wildcard ./designs/src/$(DESIGN_NICKNAME)/*.v)) export SDC_FILE ./designs/$(PLATFORM)/$(DESIGN_NICKNAME)/constraint.sdc export CORE_UTILIZATION 40 export PLACE_DENSITY 0.60 export TNS_END_PERCENT 100要为config.mk定制或添加新变量请参阅其他内置设计示例或这里的流程变量列表。第 4 步定义 SDC 约束。cddesigns/gf180/spmviconstraint.sdc根据需要编辑以定义设计约束。current_design spm set clk_name core_clock set clk_port_name clk set clk_period 10 set clk_io_pct 0.2 set clk_port [get_ports $clk_port_name] create_clock -name $clk_name -period $clk_period $clk_port set non_clock_inputs [lsearch -inline -all -not -exact [all_inputs] $clk_port] set_input_delay [expr $clk_period * $clk_io_pct] -clock $clk_name $non_clock_inputs set_output_delay [expr $clk_period * $clk_io_pct] -clock $clk_name [all_outputs]只需根据设计要求更新current_design、clk_port_name和clk_period。默认模板中的其余值请勿修改。第 5 步将设计名称添加到Makefile以便使用make命令运行流程。viMakefile如果已有启用的DESIGN_CONFIG请将其注释#掉。将以下行添加到Makefile中并保存更改。DESIGN_CONFIG./designs/gf180/spm/config.mk运行make命令以执行从 RTL 到 GDSII 生成的流程。make如果您不想修改Makefile也可以直接运行makeDESIGN_CONFIG./designs/gf180/spm/config.mk