16. 开发者指南将新平台集成到 OpenROAD Flow指南。添加新设计指南。持续集成指南。如何更新代码库根据您的安装方式更新代码库有不同的方法。我们在这份指南中提供了详细说明。如何贡献代码请参阅我们的 Git 快速上手指南地址在这里。计时与日志run_command.py每个流程阶段综合、布图规划、CTS、布线等都由flow/scripts/run_command.py封装它以纯 Python 实现取代了之前 GNUtimetee的 shell 管道。功能说明run_command.py运行一个命令并且使用 Python 的time.monotonic()和resource.getrusage()测量墙上时钟时间、CPU 时间user sys和峰值内存。将输出逐行同时流式输出到控制台和日志文件取代tee每行之后都会刷新以实现实时的tail -f可观察性。追加一行Elapsed time: ...格式符合genElapsedTime.py和genMetrics.py的预期。用法python3 flow/scripts/run_command.py [--log FILE] [--append] [--tee] -- command [args...]标志作用--log FILE将命令输出和计时行写入 FILE--append追加到日志文件而不是覆盖--tee同时将输出写到 stdout类似tee命令监控长时间运行的阶段当在 Bazelbazelisk test ...或其他隐藏控制台输出的批处理系统下运行时您可以通过查找并跟踪日志来监控进度# 找到正在运行的阶段的日志文件ps-Af|greprun_command# 或ps-Af|greptmp.log# 实时查看tail-f/path/to/logs/4_cts.tmp.log输出会立即出现在日志文件中行缓冲并带刷新因此tail -f可以显示实时进度。跨平台支持仅使用 Python 标准库模块在 Linux 和 macOS 上均可运行。峰值内存会自动归一化ru_maxrss在 Linux 上为 KB在 macOS 上为字节。测试python3-mpytest flow/test/test_run_command.py-v17. Git 快速上手本教程是 Git 以及向我们仓库贡献代码的快速上手指南。如果您尚未搭建 OpenROAD-flow-scripts请按照这里的说明操作。如果您想设置 SSH 身份验证请按照这份[指南](https://help.github.com/set-up-git-redirect)操作。分叉Forking您需要自己的 fork 来处理代码。前往OpenROAD-flow-scripts项目页面点击Fork按钮。然后您需要将您的 fork 克隆到您的机器上gitclone https://github.com/your-user-name/OpenROAD-flow-scripts.gitcdOpenROAD-flow-scriptsgitremoteaddupstream https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts.gitgitfetch upstream这会创建OpenROAD-flow-scripts目录并将您的仓库连接到上游主项目OpenROAD-flow-scripts仓库。分叉 OpenROADOpenROAD-flow-scripts 在tools/OpenROAD处将 OpenROAD 作为 Git子模块使用。当您 fork OpenROAD-flow-scripts 时.gitmodules中的子模块 URL 仍然指向上游 OpenROAD 仓库。如果您的贡献需要修改OpenROAD您也必须 fork 它并在本地克隆中更新子模块的远程地址。在 GitHub 上 fork OpenROAD。递归克隆您的 OpenROAD-flow-scripts fork 后将子模块的远程地址更新为指向您的 OpenROAD forkcdtools/OpenROADgitremote set-url origin https://github.com/your-user-name/OpenROAD.gitgitremoteaddupstream https://github.com/The-OpenROAD-Project/OpenROAD.git验证远程地址设置是否正确gitremote-v创建分支您应当让 master 分支只反映可用于生产环境的代码因此请创建一个功能分支来进行更改。例如gitcheckout mastergitbranch shiny-new-featuregitcheckout shiny-new-feature# 或者等效地gitcheckout mastergitcheckout-bshiny-new-feature这会将您的工作目录切换到 shiny-new-feature 分支。请将该分支中的任何更改保持为只针对某一个 bug 或某一个功能这样可以清楚地看出该分支为 OpenROAD-flow-scripts 带来了什么。您可以拥有许多个shiny-new-feature 分支并使用 git checkout 命令在它们之间切换。创建此分支时请确保您的 master 分支与最新的上游 master 版本保持同步。要更新您的本地 master 分支可以执行gitcheckout mastergitpull upstream master当您在创建分支之后想用 master 中的更改来更新功能分支时请查看更新 PR 一节。提交您的代码请将风格修复放在单独的提交中以使您的拉取请求更易读。完成更改后您可以输入以下命令查看它们gitstatus如果您创建了新文件它尚未被 git 跟踪。通过以下命令添加它gitaddpath/to/file-to-be-added.py再次执行git status应该会显示类似如下的内容# On branch shiny-new-feature## modified: /relative/path/to/file-you-added.py#最后将您的更改提交到本地仓库并附上说明性的提交信息。请注意-s选项是开发者签署developer signoff所必需的。gitcommit-s-myour commit message goes here推送您的更改当您希望更改公开显示在您的 GitHub 页面上时推送您 fork 的功能分支的提交gitpush origin shiny-new-feature这里的origin是您在 GitHub 上的远程仓库的默认名称。您可以查看远程仓库gitremote-v如果您按照上述说明添加了上游仓库您会看到类似如下的内容origin https://github.com/your-user-name/OpenROAD-flow-scripts.git(fetch)origin https://github.com/your-user-name/OpenROAD-flow-scripts.git(push)upstream https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts.git(fetch)upstream https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts.git(push)现在您的代码已经在 GitHub 上但它还不是 OpenROAD-flow-scripts项目的一部分。要实现这一点需要在 GitHub 上提交拉取请求pull request。审查您的代码当您准备好请求代码审查时请提交一个拉取请求。在此之前请再次确保您已遵循开发者指南中列出的所有准则包括代码风格、测试、性能测试和文档。您还应该将您的分支更改与其所基于的分支再次核对在 GitHub 上导航到您的仓库 —— https://github.com/your-user-name/OpenROAD-flow-scripts点击Branches点击您的功能分支的Compare按钮如有必要选择base和compare分支。它们将分别是master和shiny-new-feature。提交拉取请求如果一切看起来都没问题您就可以发起拉取请求了。拉取请求是本地仓库中的代码向 GitHub 社区开放的方式代码会被审阅并最终合并到master 版本中。该拉取请求及其相关更改最终会被提交到 master 分支并在下一个版本中提供。提交拉取请求的步骤在 GitHub 上导航到您的仓库点击Compare pull request按钮然后您可以点击Commits和Files Changed最后确认一切无误在Preview Discussion选项卡中编写更改说明点击Send Pull Request。该请求随后会发送给仓库维护者他们将审查代码。更新您的拉取请求根据您在拉取请求上收到的审查意见您可能需要对代码进行一些更改。在这种情况下您可以在您的分支中进行更改向该分支添加新提交将其推送到 GitHub拉取请求就会自动更新。再次推送到 GitHub 的命令是gitpush origin shiny-new-feature这会自动用最新代码更新您的拉取请求并重新启动持续集成测试。您可能需要更新拉取请求的另一个原因是解决与自您发起拉取请求以来已合并到 master 分支的更改之间的冲突。为此您需要在您的分支中merge upstream mastergitcheckout shiny-new-featuregitfetch upstreamgitmerge upstream/master如果没有冲突或者冲突可以自动修复会打开一个带有默认提交信息的文件您只需保存并退出该文件即可。如果存在合并冲突您需要解决这些冲突。有关如何操作的说明请参阅这篇文章。一旦冲突合并完成并且解决了冲突的文件已被添加您就可以运行git commit来保存这些修复。如果您在想用 master 更新分支时有未提交的更改则需要在更新之前先stash它们。请参阅 stash [文档](https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning)。这会有效地存储您的更改更新之后可以重新应用它们。在功能分支于本地更新之后您现在可以通过推送到 GitHub 上的分支来更新您的拉取请求gitpush origin shiny-new-feature成功提交拉取请求的技巧如果您已经完成了「审查您的代码」阶段可能会有一位核心贡献者来查看。不过请注意只有少数几个人负责审查所有贡献这常常会造成瓶颈。要提高您的拉取请求被审查的机会您应该对于非平凡的更改引用一个开放的 issue以阐明 PR 的目的确保您有适当的测试。这些应当是任何 PR 的首要部分让您的拉取请求尽可能简单。越大的 PR 审查时间越长确保 CI 处于绿色状态。否则审查者可能根本不会看持续更新您的拉取请求无论是应要求还是每隔几天致谢本页面改编自 pandas 开发者指南。18. 将新平台集成到 OpenROAD 流程的指南概述本文档是面向代工厂和第三方 IP 提供商的指南帮助他们轻松地将新工艺技术集成到 OpenROAD RTL 到 GDS 流程中并进行测试。OpenROAD允许您集成任何特征尺寸的 PDK工艺设计套件并实现完全开源的RTL-GDSII 流程从可综合的 Verilog 到合并的 GDSII。OpenROAD流程已在低至 7nm 的特征尺寸上得到验证迄今已用于设计和流片600 多个 ASIC 和 SoC。前提条件要为 OpenROAD 构建并添加新平台必须根据工艺节点提供关键的技术和库组件。这些通常作为代工厂或第三方 IP 提供商提供的标准设计套件的一部分提供。它们包括标准单元库库中所有标准单元的 GDS 文件或从版图文件生成它们的方法例如 Magic VLSI 版图工具。所使用 PDK 的工艺 LEF 文件包含有关金属层、过孔和间距要求的所有相关信息。参见flow/platforms/nangate45/lef/NangateOpenCellLibrary.tech.lef作为工艺 LEF 文件示例。标准单元套件的宏单元 LEF 文件包含每个单元的 MACRO 定义和引脚指定input/output/inout。参见flow/platforms/nangate45/lef/NangateOpenCellLibrary.macro.lef作为宏单元 LEF 文件示例。标准单元库的 Liberty 文件包含 PVT 特征化、输入输出特性、每个单元的时序和功耗定义。参见flow/platforms/nangate45/lib/NangateOpenCellLibrary_typical.lib作为 Liberty 文件示例。对于 KLayoutLEF/DEF 到 GDS 的layers:datatypes映射添加新平台还需要以下条件已验证可用的 OpenROAD flow scripts 安装。说明见这里。具备 VLSI 设计和 RTL 到 GDS 流程的一般知识。OpenROAD 实现了全自动的 RTL-GDSII但调试问题需要熟悉 OpenROAD flow scripts。向 OpenROAD 添加新平台设置本节介绍构建平台所需的文件和目录。除非另有说明所有创建/编辑的文件和目录彼此独立。Makefile对 Makefile位于flow/Makefile进行以下编辑以便 OpenROAD能够使用新平台在设计上运行流程。在 Makefile 的开头有一组被注释掉的DESIGN_CONFIG变量。这些变量告诉 OpenROAD 运行哪个设计以及在哪个平台上运行。DESIGN_CONFIG具体指向相应平台的 designs 目录中的一个config.mk文件。并不要求将相应平台中某个设计的DESIGN_CONFIG变量直接添加到 Makefile 中——在Makefile中添加DESIGN_CONFIG变量只是一种便利做法也可以在调用 make 时设置。OpenROAD 已经有多个现成的 Verilog 设计可与任何平台配合使用可用设计列表见flow/designs/src。例如在新平台上使用gcd设计的DESIGN_CONFIG变量如下所示:caption: Makefile DESIGN_CONFIG./designs/MyNewPlatform/gcd/config.mkconfig.mk文件将在本文档后面的设计目录一节中生成。平台目录在flow/platforms内为新工艺创建一个目录用于存放 OpenROAD流程所需的文件。mkdirflow/platforms/MyNewPlatform(content:design:directory)设计目录设计目录包含特定平台所有设计的配置文件。在 flow/designs 中为新平台创建一个目录用于存放该特定平台上流程的所有设计的相关文件和目录。每个设计都需要自己的config.mk和constraint.sdc文件。:::{tip}按照以下步骤创建必要的目录和文件。注意 gcd 只是一个示例名称不是必需的。mkdir-pflow/designs/MyNewPlatform/gcdtouchflow/designs/MyNewPlatform/gcd/config.mktouchflow/designs/MyNewPlatform/gcd/constraint.sdc这会在flow/designs/MyNewPlatform/gcd中创建两个目录MyNewPlatform 和gcd以及两个空文件config.mk和constraint.sdc。:::平台配置本节介绍平台目录中 OpenROAD 流程所需的文件。具体来说平台目录中的config.mk文件包含流程使用的所有配置变量。有关可设置的配置变量的完整列表请参阅 OpenROAD-flow-scripts 文档。有关如何在 OpenROAD-flow-scripts 中使用环境变量来配置平台和设计特定参数的详细信息请参阅流程变量文档。平台config.mk文件的示例请参阅flow/platforms/sky130hd/config.mk。设计配置本节介绍设计目录中的文件。config.mkconfig.mk文件描述设计特定的变量。例如DESIGN_NAME PLATFORM VERILOG_FILES SDC_FILE CORE_UTILIZATION CORE_ASPECT_RATIO CORE_MARGIN PLACE_DENSITY另外也可以指定DIE_AREA和CORE_AREA来代替CORE_UTILIZATION、CORE_ASPECT_RATIO和CORE_MARGIN。所有变量的完整说明见这里。以下是gcd设计的示例config.mk文件:caption: config.mk export DESIGN_NAME gcd export PLATFORM sky130hd export VERILOG_FILES $(sort $(wildcard ./designs/src/$(DESIGN_NAME)/*.v)) export SDC_FILE ./designs/$(PLATFORM)/$(DESIGN_NAME)/constraint.sdc export CORE_UTILIZATION 30 export CORE_ASPECT_RATIO 1 export CORE_MARGIN 2 export PLACE_DENSITY 0.70constraint.sdcconstraint.sdc文件定义设计的时序约束。create_clock命令允许您定义连接到网络的时钟或虚拟时钟并可以自定义。create_clock的单位需要与 liberty 时间单位一致。下面是一个constraint.sdc文件的示例它定义了一个周期为 8.4 纳秒的时钟clk纳秒与liberty 时间单位一致。:caption: constraint.sdc create_clock [get_ports clk] -period 8.4 #单位为纳秒有关create_clock命令的完整文档请参阅OpenSTA用户指南。Liberty、LEF 和 GDS 文件从技术上讲liberty、LEF 和 GDS 文件不必放在相应技术的平台目录内只要config.mk文件中设置的路径指向正确的文件即可。不过将所有相关文件放在一个集中的目录中是良好的实践。.lib、.lef和.gds分别放在为特定技术命名的目录中。例如mdkir flow/platforms/MyNewPlatform/lib mdkir flow/platforms/MyNewPlatform/lef mdkir flow/platforms/MyNewPlatform/gds可以使用合并的 GDS 文件而不必添加标准单元库中每个单独的.gds文件。一旦生成了 liberty 文件、工艺和宏单元 LEF 文件以及合并的标准单元 GDS 或单个标准单元 GDS 文件就将它们放入各自的目录并在平台config.mk文件中将lib、lef和gds变量设置为正确的路径。时钟门控Clock GatesYosys目前无法自动推断时钟门控。但是用户可以使用通用接口在其 RTL 中手动实例化时钟门控。该接口的目的是将平台特定的 RTL也称为「硬化」RTL与平台无关的 RTL通用 RTL分离。只有当您想在设计中实例化时钟门控时才需要此文件。要创建此模块需要一个门控时钟标准单元。该标准单元用于创建通用模块OPENROAD_CLKGATE如下所示。:caption: cells_clkgate.v module OPENROAD_CLKGATE (CK, E, GCK); input CK; input E; output GCK; clkgate_std_cell latch (.CLK(CK), .GATE(E), .GCLK(GCK)); endmodule用户设计中此模块的实例化示例如下所示。:caption: buffer.v // 这不是平台文件这是一个用户设计示例 module buffer (clk, enable, in, out); input clk, enable; input [7:0] in, output [7:0] out reg [15:0] buffer_reg; wire gck; // 门控时钟 OPENROAD_CLKGATE clkgate (.CK(clk), .E(enable), .GCK(gck)); // 当 enable 为低时buffer 不改变 always (posedge gck) begin buffer_reg[15:8] in; buffer_reg[ 7:0] buffer_reg[15:8]; end assign out buffer_reg[ 7:0];锁存器LatchesYosys 可以自动从 RTL 推断锁存器但它需要一个行为级 Verilog模块。下面提供了锁存器定义示例。DLATCH_P是高电平有效的电平敏感锁存器DLATCH_N是低电平有效的电平敏感锁存器。只有当您想为设计推断锁存器时才需要此文件。:caption: cells_latch.v module $_DLATCH_P_(input E, input D, output Q); d_latch_std_cell _TECHMAP_REPLACE_ ( .D (D), .G (E), .Q (Q) ); endmodule module $_DLATCH_N_(input E, input D, output Q); d_latch_std_cell _TECHMAP_REPLACE_ ( .D (D), .GN (E), .Q (Q) ); endmoduleFastRoute 配置FastRoute 是用于对设计进行全局布线的工具。FastRoute 需要一个 Tcl文件来设置信号使用哪些布线层、调整布线层资源、设置布线时使用哪种布线启发式算法等。建议使用默认的fastroute.tcl因为它简单且有效。下面是默认的 FastRoute 配置文件。:caption: fastroute.tcl set_global_routing_layer_adjustment $::env(MIN_ROUTING_LAYER)-$::env(MAX_ROUTING_LAYER) 0.5 set_routing_layers -signal $::env(MIN_ROUTING_LAYER)-$::env(MAX_ROUTING_LAYER)第一个命令set_global_routing_layer_adjustment调整设计的布线资源。它实际上减少了全局布线器假定存在的布线轨道数量。将其设置为 0.5会将所有布线层的布线资源减少到 50%这有助于缓解拥塞并降低详细布线的难度。第二个命令set_routing_layers通过-signal选项设置信号网络的最低和最高布线层。可以进行更多自定义以提高全局布线和详细布线的效率。请参阅FastRoute 文档。金属轨道配置OpenROAD 需要一个金属轨道配置文件用于布图规划。对于每个金属层需要定义 x 和 y 偏移量以及 x 和 y 间距pitch。要查找 x 和 y 的间距和偏移量请参阅工艺 LEF 中每个金属层的LAYER定义部分。下面是一个通用的金属轨道配置文件定义了五个金属轨道。单位为微米。:caption: make_tracks.tcl make_tracks metal1 -x_offset 0.24 -x_pitch 0.82 -y_offset 0.24 -y_pitch 0.82 make_tracks metal2 -x_offset 0.28 -x_pitch 0.82 -y_offset 0.28 -y_pitch 0.82 make_tracks metal3 -x_offset 0.28 -x_pitch 0.82 -y_offset 0.28 -y_pitch 0.82 make_tracks metal4 -x_offset 0.28 -x_pitch 0.82 -y_offset 0.28 -y_pitch 0.82 make_tracks metal5 -x_offset 0.28 -x_pitch 0.82 -y_offset 0.28 -y_pitch 0.82下面是sky130hd工艺 LEF 中metal1的LAYER定义。LAYER met1 TYPE ROUTING ; DIRECTION HORIZONTAL ; PITCH 0.34 ; OFFSET 0.17 ; WIDTH 0.14 ; # Met1 1 # SPACING 0.14 ; # Met1 2 # SPACING 0.28 RANGE 3.001 100 ; # Met1 3b SPACINGTABLE PARALLELRUNLENGTH 0 WIDTH 0 0.14 WIDTH 3 0.28 ; AREA 0.083 ; # Met1 6 THICKNESS 0.35 ; MINENCLOSEDAREA 0.14 ; ANTENNAMODEL OXIDE1 ; ANTENNADIFFSIDEAREARATIO PWL ( ( 0 400 ) ( 0.0125 400 ) ( 0.0225 2609 ) ( 22.5 11600 ) ) ; EDGECAPACITANCE 40.567E-6 ; CAPACITANCE CPERSQDIST 25.7784E-6 ; DCCURRENTDENSITY AVERAGE 2.8 ; # mA/um Iavg_max at Tj 90oC ACCURRENTDENSITY RMS 6.1 ; # mA/um Irms_max at Tj 90oC MAXIMUMDENSITY 70 ; DENSITYCHECKWINDOW 700 700 ; DENSITYCHECKSTEP 70 ; RESISTANCE RPERSQ 0.125 ; END met1在上面的示例中met1的 x 和 y 间距为 0.34x 和 y 偏移量为0.17。PDN 配置PDN 是一个简化向布图规划添加电源网格的实用工具。根据 PDN 配置文件中给出的规格例如使用哪一层、条带宽度和间距该工具可以生成用于电源网格的金属条带。要创建和配置电源网格请参阅PDN 文档。Tapcell 配置tapcell 配置文件用于将 tapcell 和端帽单元endcap插入设计中。有关如何构建此文件请参阅Tapcell文档。setRC 配置setRC允许用户使用set_layer_rc命令定义层和过孔的电阻和电容。还有一个命令允许您使用set_wire_rc设置布线导线的电阻和电容。set_wire_rc期望的单位是单位长度值。通常单位长度值可以在 PDK 用户指南中找到。对于set_layer_rc需要使用 Liberty 单位。下面是一个通用的setRC配置文件示例它设置了五个金属层、四个过孔、一根信号导线和一根时钟导线的电阻和电容。:caption: setRC.tcl set_layer_rc -layer M1 -capacitance 1.449e-04 -resistance 8.929e-04 set_layer_rc -layer M2 -capacitance 1.331e-04 -resistance 8.929e-04 set_layer_rc -layer M3 -capacitance 1.464e-04 -resistance 1.567e-04 set_layer_rc -layer M4 -capacitance 1.297e-04 -resistance 1.567e-04 set_layer_rc -layer M5 -capacitance 1.501e-04 -resistance 1.781e-05 set_layer_rc -via V1 -resistance 9.249146E-3 set_layer_rc -via V2 -resistance 4.5E-3 set_layer_rc -via V3 -resistance 3.368786E-3 set_layer_rc -via V4 -resistance 0.376635E-3 set_wire_rc -signal -layer M2 set_wire_rc -clock -layer M5KLayoutKLayout 在 OpenROAD 流程中用于提供 GDS 合并、DRC 和 LVS。KLayout需要两个文件它们在 KLayout GUI 中生成。请在主机上安装 KLayout因为它不包含在 OpenROAD 构建过程中。然后按照下面的说明创建properties属性文件和 tech工艺文件。KLayout 工艺文件按照以下步骤生成 KLayout 工艺文件在终端中打开 KLayout。转到 Tools - Manage Technologies管理工艺。点击左下角的 创建新工艺。在弹出的框中设置工艺名称。现在您应该能在左侧列表中看到该工艺名称。点击箭头展开该工艺然后点击 General常规。将基本路径设置为您的平台目录并加载之前生成的.lyp层属性文件。在左侧的新工艺下点击 Reader Options然后点击顶栏上的 LEF/DEF。在 LEFMacro Files 部分点击框右侧的 按钮添加 LEF 文件。注意只添加您原始的合并 LEF 文件。确保包含 LEF 文件的完整路径。在 Production 部分向下滚动并点击 Load File 按钮添加层映射文件。注意确保包含完整路径。在同一部分的上方更改层名后缀和 GDS 数据类型使其与层映射对应。右键点击新工艺名称点击 Export Technology生成.lyt文件。以.lyt扩展名保存。KLayout 属性文件获得 GDS 并不需要属性文件它仅用于内部显示的样式目的。按照以下步骤生成 KLayout 属性文件打开 KLayout。安装tf_import软件包。在 KLayout 中转到 Tools。Manage Packages管理软件包。Install New Packages安装新软件包。选择tf_import。如果该软件包的来源是 GitHub则需要编辑 “” 文件以包含 “source stdio”。重新启动 KLayout。File - Import 某个 LEF。具体哪个 LEF 无所谓没有它您只会收到一条错误消息。选择后转到左下角的 Options。在 Production 选项卡下选择您的层映射文件。转到 LEFMacro Files 选项卡然后在 Additional LEF files 下添加平台目录中合并的原始LEF 文件。在 Macro Layout Files 下添加平台目录中的 GDS 文件。File - Import Cadence tech file导入 Cadence 工艺文件。您必须选择一个工艺文件在 PDK 中通常在 Virtuoso 文件夹内。KLayout 还需要一个.drf文件如果它与 cadence 工艺文件位于同一目录中则会自动包含在 PDK 的 Virtuoso 文件夹中找到。File - Save Layer Properties保存层属性。在您的平台目录中保存为.lyp文件。验证新平台要验证新平台只需使用该新平台让一个设计跑一遍流程。Makefile应该已经包含了在本文档「设置」一节中生成的新平台的DESIGN_CONFIG变量。只需在 Makefile 中取消对新平台的某个DESIGN_CONFIG变量的注释保存然后在终端中运行make即可让设计跑通流程。先尝试一个小型设计即gcd这样运行时间较短您可以更快地发现并修复错误。作者/贡献者James Stine - 俄克拉荷马州立大学Teo Ene - 俄克拉荷马州立大学Ricardo Hernandez - 俄克拉荷马州立大学Ryan Ridley - 俄克拉荷马州立大学Indira Iyer - OpenROAD 项目顾问19. CI 指南本文档介绍开发者和代码维护者在 Jenkins 服务器上可用的流水线。请注意带有*-Private后缀的流水线仅对代码维护者和 The OpenROAD Project 成员开放因为它们可能包含机密信息。因此要访问 Private 流水线需要拥有访问机密数据的授权并登录 Jenkins网站。下面是可用功能的列表。有关如何在 Jenkins 中导航以访问这些功能的说明请参阅这里。通过 Jenkins 网站或 GitHub 查找您的构建。查看测试状态通过/失败。每个测试的日志文件。用于复现失败的构建产物。关于代码覆盖率和指标的 HTML 报告。OpenROAD FlowOpenROAD-flow-script-Public [文件夹]public_tests_all描述运行在三小时内完成的流程测试。目标master 分支。public_tests_all-pr描述运行在三小时内完成的流程测试。目标所有开放的 PR。publish-results-to-dashboard描述将指标上传到仪表盘网站。目标master 分支。OpenROAD-flow-scripts-Nightly-Public描述运行所有流程测试包括 RTLMP 设计。目标master 分支。OpenROAD-flow-scripts-Private [文件夹]public_tests_small描述运行在一小时内完成的快速流程测试。目标所有未提交为 PR 的分支。对于 PR 分支CI 会在“Ready to Sync Public” 工作流之后在公共侧运行。OpenROAD-flow-scripts-All-Tests-Private描述为私有分支运行流程测试。目标安全分支。20. 贡献者公约行为准则我们的承诺作为成员、贡献者和领导者我们承诺让每个人都能在社区中获得无骚扰的参与体验无论年龄、体型、可见或不可见的残疾、族裔、性别特征、性别认同与表达、经验水平、教育程度、社会经济地位、国籍、个人外貌、种族、宗教或性认同与性取向如何。我们承诺以有助于建设开放、友好、多元、包容和健康的社区的方式行事和互动。我们的标准有助于为我们的社区营造积极环境的行为示例包括对他人表现出同理心和善意尊重不同的意见、观点和经历给予并优雅地接受建设性反馈承担责任向受我们错误影响的人道歉并从中吸取教训关注的不仅是我们个人的最佳利益更是整个社区的最佳利益不可接受的行为示例包括使用性暗示的语言或图像以及任何形式的性关注或性挑逗恶意挑衅、侮辱或贬损性评论以及人身或政治攻击公开或私下的骚扰未经他人明确许可公布他人的私人信息例如住址或电子邮件地址其他在专业场合中可被合理认为不适当的行为执行责任社区领导者负责澄清和执行我们的可接受行为标准并将针对任何他们认为不适当、威胁性、冒犯性或有害的行为采取适当而公正的纠正措施。社区领导者有权利和责任删除、编辑或拒绝不符合本行为准则的评论、提交、代码、wiki 编辑、issue 和其他贡献并将在适当的时候说明管理决定的理由。适用范围本行为准则适用于所有社区空间也适用于个人在公共场合正式代表社区的情况。代表我们社区的示例包括使用官方电子邮件地址、通过官方社交媒体账户发帖或在在线或线下活动中担任指定代表。执行虐待、骚扰或其他不可接受行为的实例可以向负责执行的社区领导者举报邮箱为 complaintsopenroad.tools。所有投诉都将得到及时而公正的审查和调查。所有社区领导者都有义务尊重任何事件举报者的隐私和安全。执行指南社区领导者将遵循以下社区影响指南来确定任何他们认为违反本行为准则的行为的后果1. 纠正社区影响使用不当语言或其他被认为不专业或不受社区欢迎的行为。后果社区领导者发出私下的书面警告说明违规的性质并解释该行为为何不当。可能会要求公开道歉。2. 警告社区影响通过单一事件或一系列行为造成的违规。后果警告并说明继续此类行为的后果。在指定的时间段内不得与相关人员进行任何互动包括不得主动与执行行为准则的人员互动。这包括避免在社区空间以及社交媒体等外部渠道中的互动。违反这些条款可能导致临时或永久封禁。3. 临时封禁社区影响严重违反社区标准包括持续的不当行为。后果在指定的时间段内临时禁止与社区进行任何形式的互动或公开交流。在此期间不允许与相关人员进行公开或私下的互动包括不得主动与执行行为准则的人员互动。违反这些条款可能导致永久封禁。4. 永久封禁社区影响表现出违反社区标准的行为模式包括持续的不当行为、骚扰个人或对某类人群的攻击或贬低。后果永久禁止在社区内进行任何形式的公开互动。出处本行为准则改编自 Contributor Covenant 2.0 版。社区影响指南的灵感来自 Mozilla 的行为准则执行阶梯。有关本行为准则常见问题的解答请参见这里的常见问题。翻译版本见这里。