1. 从“闭门造车”到“开放协作”为什么我们需要一个全新的VLSI基准测试集在超大规模集成电路VLSI设计领域有一个老生常谈却又无比现实的问题当我们在评估一个新的布局布线算法、一个新的时序优化工具或者一个新的物理设计流程时我们到底该用什么来测试它过去很长一段时间里答案往往是那几个“经典”的、甚至有些年头的基准测试电路比如 ISCAS’85/’89或者 ITC’99。这些基准集确实为早期研究做出了巨大贡献但它们更像是博物馆里的标本——它们代表了特定历史时期和特定设计风格比如全定制、门级网表的产物与今天动辄数亿门、采用先进工艺节点、高度依赖高层次综合HLS和知识产权IP复用的复杂片上系统SoC设计相比已经显得有些“脱节”了。这就导致了一个尴尬的局面学术界发表的许多“性能提升显著”的新算法在论文里跑分很漂亮但一旦被工业界拿去测试真实的设计效果往往大打折扣甚至出现反效果。原因很简单测试环境基准集和真实战场工业级设计的差异太大了。这种鸿沟不仅阻碍了技术的有效转化也让研究人员难以准确把握当前设计流程中的真正瓶颈。正是在这样的背景下HighTide 这个由智能体Agent策划的开源 VLSI 基准测试套件应运而生。它瞄准的不是填补一个简单的空白而是试图构建一座连接学术前沿与工业实践、算法创新与真实需求的桥梁。HighTide 的核心价值在我看来可以概括为三个关键词现代性、复杂性与代表性、可复现性。它不再满足于提供一堆孤立的、小规模的网表文件而是致力于打包一整套完整的、从高层次描述到物理布局的、可构建的设计流程。这就像以前学开车给你一个方向盘模拟器现在直接给你一辆可以上路调试的真车虽然更复杂但练出来的才是真本事。接下来我们就深入 HighTide 的内部看看它是如何被“策划”出来的以及我们该如何上手使用它来真正提升我们的研究或工具开发水平。2. HighTide 的架构与“智能体策划”内涵解析HighTide 不是一个简单的文件压缩包。它是一个基于 Bazel 构建系统的、模块化的、可扩展的基准测试套件工程。理解它的架构是有效使用它的前提。2.1 以 Bazel 为核心的构建哲学HighTide 选择 Bazel 作为其构建工具这是一个非常关键且明智的设计决策。在传统的基准集使用中我们经常遇到这样的问题依赖库缺失、构建脚本不兼容、环境变量配置复杂导致“下载-解压-运行”三步走变成“下载-解压-折腾一天环境-放弃”。Bazel 通过声明式的构建规则BUILD文件和强大的沙盒化、缓存机制从根本上解决了可复现性问题。在 HighTide 项目中每一个设计模块比如一个 RISC-V 处理器核、每一个工具流程比如用 Yosys 进行逻辑综合、用 OpenROAD 进行布局布线都被定义为一个或多个 Bazel 目标target。当你执行bazel build //path/to:target时Bazel 会自动解析所有依赖从远程仓库下载特定版本的工具链如 GNU 工具链、Verilator、Yosys 等在一个隔离的环境中执行构建步骤并缓存结果。这意味着只要你的机器上安装了 Bazel理论上就可以一键复现整个流程无需手动安装和配置一堆杂乱的工具。这对于确保不同研究者在不同机器上能得到完全一致的实验结果至关重要。注意虽然 Bazel 带来了强大的可复现性但其学习曲线相对陡峭。初次接触时理解WORKSPACE定义外部依赖、BUILD定义内部构建目标和.bzl定义自定义构建规则文件之间的关系是第一步。HighTide 项目通常会提供顶层的构建脚本示例建议从这些示例开始而不是直接深入最复杂的设计。2.2 “智能体策划”到底意味着什么这是 HighTide 最具特色的部分。这里的“智能体”Agent并非指一个具象的 AI 程序而是一种设计理念和实现方法的隐喻。它指的是通过程序化、自动化的方式从更广阔的开源硬件生态中“筛选”、“组装”、“验证”和“打包”出适合作为基准测试的设计。具体来说这个过程可能包含以下步骤爬取与筛选智能体脚本会扫描如 GitHub、GitLab 等平台上的开源硬件项目根据预设的指标如星星数、活跃度、代码质量、文档完整性、许可证友好度进行初步筛选。依赖分析与解决分析选中项目的依赖关系包括其他 IP 核、特定的工具版本、软件库等。HighTide 的智能体会尝试用 Bazel 规则来描述这些依赖确保它们能被自动拉取和构建。流程集成与标准化将选中的设计集成到 HighTide 统一的构建流程中。这可能涉及为该项目编写或适配 Bazel 构建规则将其 RTL寄存器传输级代码、约束文件SDC、工艺库文件LEF/DEF, Liberty等资源组织成标准的目录结构。质量验证与基准生成运行一系列基本的验证流程如逻辑等效性检查 LEC、静态时序分析 STA 的脚本雏形确保该设计在集成后仍然是功能正确的。同时生成该设计在不同优化阶段综合后、布局后、布线后的标准输出文件网表、时序报告、面积报告、功耗报告这些输出本身就是基准的一部分可用于工具间的横向对比。“策划”一词的精妙之处在于它强调的不是从零创造而是基于现有开源资源的“策展”与“再组织”。这使得 HighTide 能够快速吸纳社区中最活跃、最具代表性的项目保持其基准集的“现代性”。例如它可能集成了基于 Chisel 或 SpinalHDL 编写的现代处理器设计包含了利用 BlackParrot 或 CVA6 等开源核心的 SoC 子系统这些正是当前工业界和学术界关注的热点。3. HighTide 基准套件的核心内容与典型设计剖析那么HighTide 里具体有哪些“干货”呢虽然其具体内容会不断更新但我们可以从其设计目标推断出它可能包含的几类典型设计并分析其作为基准的价值。3.1 设计层次与复杂度谱系一个优秀的基准套件应该覆盖从简单到复杂的各种场景。HighTide 很可能提供这样一个谱系微内核与算术单元例如一个高度优化的 AES 加密内核、一个浮点运算单元FPU。这类设计规模较小几万到几十万门结构规整是测试工具基础算法如逻辑优化、技术映射的“试金石”。它们能快速暴露工具在处理特定电路结构如大量 XOR 门、数据通路时的效率问题。中型处理器核心例如一个完整的、支持 RV32IMC 指令集的 RISC-V 处理器核如 VexRiscv 或 picorv32 的优化版本。这类设计规模达到数十万门包含了控制流、数据通路、存储器接口等典型微架构模块是测试综合、布局布线工具在平衡时序、面积、功耗方面能力的绝佳对象。其瓶颈通常出现在关键路径如 load-use 延迟、分支预测误判恢复路径上。复杂 SoC 子系统例如一个包含处理器核心、片上互连如 TileLink/AXI 总线、DMA 控制器、外部存储器接口如 DDR PHY 模型和多个外设UART, SPI, I2C的子系统。这类设计规模可能达到数百万门并引入了层次化设计、时钟域交叉CDC、功耗域等先进概念。它们是测试工具容量、层次化处理能力、以及签核流程如形式验证、物理验证的“大考”。3.2 关键交付物不止是 RTLHighTide 作为现代基准集提供的远不止是 Verilog/VHDL 源代码。一套完整的基准至少应包括交付物类型文件格式示例作用与价值设计源码.v,.sv,.py(Chisel),.scala(SpinalHDL)设计的原始描述是一切流程的起点。支持多种硬件描述语言是现代基准的标志。约束文件.sdc(Synopsys Design Constraints)定义设计的时序、时钟、功耗约束。这是评估工具优化效果是否达标的“标尺”。一份写得好、符合工业实践的 SDC 文件本身就有很高的参考价值。工艺库文件.lib(Liberty),.lef(Layout Exchange),.def(Design Exchange)描述目标工艺单元的逻辑时序、功耗信息以及物理几何信息。HighTide 可能会提供基于开源 PDK如 Google-SkyWater 130nm或虚拟工艺库的版本确保完全可开源使用。脚本与构建规则BUILD,.bzl,Makefile,Tcl脚本自动化构建和运行流程的脚本。这是 HighTide 的灵魂确保了可复现性。参考结果与黄金数据.v(门级网表),.spef(寄生参数),.timing.rpt,.power.rpt由一套“参考工具流”可能是经过充分验证的开源工具组合如 Yosys OpenROAD运行产生的中间和最终结果。这些数据可以作为“黄金参考”用于与其他工具链的输出进行对比验证正确性和评估优化质量。测试激励与验证环境.sv(SystemVerilog Testbench),.cpp(Co-simulation),.bin(测试程序)用于功能验证的测试平台和测试向量。确保所评估的设计在优化前后功能等价。3.3 以“VLSI 布图规划设计”为例看基准应用“VLSI 布图规划设计”是当前的一个热点它涉及在芯片物理设计初期对宏模块如 SRAM、CPU Core、GPU Cluster进行形状规划、位置摆放和电源网络预布局。HighTide 中的复杂 SoC 子系统基准正是测试布图规划算法的绝佳载体。假设我们有一个集成了 CPU、GPU、多个 SRAM 和 IO 的子系统基准。一个布图规划工具需要处理以下挑战而这些挑战都可以用 HighTide 基准来量化评估形状优化与面积估算CPU 和 GPU 可能由不同的团队设计初始形状和长宽比各异。工具需要能自动或交互式地调整模块形状在满足布线通道需求的前提下最小化芯片总面积。HighTide 提供的模块 LEF 文件定义了它们的物理轮廓和引脚位置。互连驱动布局CPU 和 SRAM 之间可能存在高频宽的数据通路。工具需要将通信密集的模块摆放得更近以减少全局互连延迟和功耗。这需要分析设计中的网络拓扑可以从 DEF 或网表中提取。电源规划集成现代设计对 IR Drop 非常敏感。布图规划阶段就需要预留电源环Power Ring和电源带Power Stripe的位置和宽度。HighTide 的基准可能包含初步的电源网络约束用于评估工具生成的电源网络质量。可布线性预估模块摆得太挤后期布线可能无法完成摆得太松又浪费面积。工具需要能快速预估给定布局下的布线拥堵情况。HighTide 的参考布局布线结果可以提供拥堵图Congestion Map作为对比基准。通过将你的布图规划工具在 HighTide 的多个基准上运行并对比其产生的芯片面积、预估总线长、布线拥堵程度、电源网络压降等指标与参考结果的差异你就能对你的算法性能有一个全面、客观、贴近实际的认识。4. 实战使用 Bazel 构建并运行你的第一个 HighTide 基准理论说了这么多我们来点实际的。假设我们已经从 HighTide 的官方仓库克隆了代码现在要尝试构建并运行其中一个中等复杂度的设计比如一个名为//benchmarks/riscv_core:vexriscv_system的目标。4.1 环境准备与初次构建首先确保你的开发环境满足基本要求Linux/macOS对 Windows 的 WSL2 支持可能较好安装了 Bazel建议使用项目推荐的版本如 5.x 或 6.x以及足够的磁盘空间因为 Bazel 会缓存很多依赖。# 1. 克隆 HighTide 仓库假设仓库地址 git clone https://github.com/hightide-benchmarks/hightide.git cd hightide # 2. 查看项目结构非必须但有助于理解 find . -name BUILD -type f | head -20 ls -la benchmarks/ # 3. 进行首次构建。这可能会花费较长时间因为 Bazel 需要下载所有依赖的工具和库。 # 使用 --jobsN 可以指定并行任务数加速构建。 bazel build //benchmarks/riscv_core:vexriscv_system第一次运行bazel build时你会看到控制台输出大量下载和编译信息。Bazel 正在构建整个依赖图它可能会下载特定版本的 Verilator用于仿真、riscv-gnu-toolchain用于编译测试程序、Yosys用于综合等。这一切都在 Bazel 的沙盒中进行不会污染你的系统环境。构建成功后你会在bazel-bin/目录下找到生成的文件。4.2 理解构建目标与运行流程一个:vexriscv_system目标背后可能定义了一连串的构建动作。我们可以用bazel query来查看其依赖关系# 查看该目标的直接依赖 bazel query deps(//benchmarks/riscv_core:vexriscv_system, 1) --outputgraph | dot -Tpng deps.png # 或者查看其生成的文件 bazel cquery //benchmarks/riscv_core:vexriscv_system --outputfiles通常这样的目标会生成多个输出vexriscv_system.rtl.v经过预处理和打包的顶层 RTL 代码。vexriscv_system.sdc对应的时序约束文件。vexriscv_system.sim.v可能是一个封装好的、可仿真的顶层模块。甚至可能直接生成一个可执行的仿真程序。要运行一个完整的流程例如从 RTL 到门级网表的综合HighTide 可能定义了一个单独的“流程目标”# 运行综合流程使用 Yosys 作为综合工具目标工艺库是 //pdks/sky130:sky130_fd_sc_hd bazel run //benchmarks/riscv_core:vexriscv_system_synth -- --top_module vexriscv_system --pdk //pdks/sky130:sky130_fd_sc_hd这个bazel run命令会先构建目标如果还没构建然后执行目标对应的可执行规则该规则内部会调用 Yosys 脚本读取 RTL 和约束使用指定的工艺库进行综合最终在bazel-bin下生成综合后的网表vexriscv_system_synth.v和相关的时序报告。4.3 自定义与扩展添加你自己的分析脚本HighTide 的强大之处在于它的可扩展性。假设你想在综合流程后自动运行一个自定义的脚本分析网表的扇出Fanout分布情况。创建自定义构建规则在项目根目录或你的工作区目录下创建一个custom_rules.bzl文件。# custom_rules.bzl def _analyze_fanout_impl(ctx): # ctx 是规则上下文包含了输入文件、输出文件等信息 input_netlist ctx.file.input_netlist output_report ctx.actions.declare_file(ctx.label.name _fanout.rpt) # 编写要执行的命令。这里假设我们有一个 Python 脚本 analyze_fanout.py ctx.actions.run( inputs [input_netlist], outputs [output_report], executable ctx.executable._analyze_script, arguments [ --input, input_netlist.path, --output, output_report.path ], progress_message Analyzing fanout distribution for %s % input_netlist.short_path, ) return [DefaultInfo(files depset([output_report]))] analyze_fanout rule( implementation _analyze_fanout_impl, attrs { input_netlist: attr.label(allow_single_file [.v, .sv]), _analyze_script: attr.label( default //tools/scripts:analyze_fanout.py, executable True, cfg exec, ), }, )编写分析脚本在tools/scripts/下创建analyze_fanout.py并为其编写BUILD文件将其定义为py_binary。在基准的 BUILD 文件中使用新规则编辑benchmarks/riscv_core/BUILD在vexriscv_system_synth目标后添加load(//:custom_rules.bzl, analyze_fanout) analyze_fanout( name vexriscv_system_fanout_analysis, input_netlist :vexriscv_system_synth.v, # 依赖于综合生成的网表 )现在你可以通过bazel build //benchmarks/riscv_core:vexriscv_system_fanout_analysis来运行你的自定义分析并集成到整个自动化流程中。5. 在研究与开发中有效利用 HighTide避坑指南与最佳实践将 HighTide 集成到你的日常研究或工具开发中能极大提升效率但也有一些需要注意的地方。5.1 常见问题与排查思路构建失败依赖下载超时或失败。这通常是网络问题。Bazel 支持配置代理。你可以在$HOME/.bazelrc或项目内的.bazelrc中设置build --experimental_remote_downloadergrpc://remote-cache.example.com:8080 # 如果使用远程缓存 startup --host_jvm_args-Dhttp.proxyHostyour.proxy.host --host_jvm_args-Dhttp.proxyPortyour.proxy.port另外检查 HighTide 的WORKSPACE文件看它是否使用了某些需要特殊访问权限的仓库如某些内部 GitLab你可能需要配置 Git 的 SSH 密钥或 HTTPS 凭证。构建成功但运行时工具报错如 Yosys 语法错误。首先确认你构建的目标是否正确。HighTide 可能为同一个设计提供了多个配置如不同的时钟频率、不同的优化目标。使用bazel query //benchmarks/...查看所有可用目标。其次检查工具的版本。Bazel 确保了工具版本的一致性但如果你在本地已经安装了同名工具可能会被误用。确保你通过bazel run来执行流程而不是直接调用系统路径下的工具。结果与参考数据差异巨大。不要急于下结论说自己的工具不好。首先进行“苹果对苹果”的比较约束是否一致检查使用的 SDC 文件是否完全相同。时钟定义、不确定性uncertainty、输入输出延迟是否匹配工艺库是否一致确认 Liberty 文件、LEF/DEF 文件的版本和内容。即使是同一个工艺节点不同厂家或不同版本的 PDK 也会有差异。流程起点是否一致比较输入给工具的 RTL 代码是否经过了一致的预处理例如宏定义、include 文件路径。工具命令与选项HighTide 的参考流程可能使用了特定的工具命令选项如综合策略、布局布线努力程度。查看 Bazel 规则中生成的详细命令行日志。5.2 将 HighTide 集成到你的 CI/CD 流水线对于工具开发团队将 HighTide 作为回归测试集集成到持续集成CI系统中是保证代码质量的最佳实践。以下是一个基于 GitHub Actions 的简化示例# .github/workflows/hightide-regression.yml name: HighTide Regression Test on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Install Bazel uses: bazelbuild/setup-bazeliskv2 - name: Run a subset of HighTide benchmarks run: | # 测试一个小的算术单元快速反馈 bazel test //benchmarks/arithmetic:aes_128 --test_outputerrors # 测试一个中型处理器核心时间稍长 bazel test //benchmarks/riscv_core:vexriscv_system_synth --test_outputerrors # 可以在这里添加对比脚本将本次运行结果与基线结果比较 python scripts/compare_results.py ./bazel-bin/benchmarks/ ./baseline/在 CI 中建议先从运行时间较短的基准开始逐步加入更复杂的设计。可以为关键指标如时序违例总量、总面积、总功耗设置阈值当新提交的代码导致这些指标恶化超过一定比例时CI 任务失败。5.3 贡献回馈社区HighTide 作为一个开源项目其生命力来自于社区贡献。如果你在使用过程中修复了某个基准的构建问题。为某个设计添加了更完善的约束文件或测试向量。将一个新的、高质量的开源设计集成到了 HighTide 框架中。甚至发现并修复了 Bazel 构建规则中的 bug。请务必考虑向 HighTide 项目提交 Pull Request。贡献的过程本身也是对你理解的一次极好检验并能帮助整个社区共同进步。在提交前请仔细阅读项目的贡献指南确保你的代码风格、提交信息格式符合规范并且新增的基准确实具有代表性和高质量。从我个人的使用经验来看像 HighTide 这样的现代基准套件其价值不仅仅在于提供测试用例更在于它定义了一种可复现的研究与开发范式。它迫使我们将关注点从“跑出一个好数字”转移到“构建一个健壮、可复现、可比较的完整流程”上。这或许才是推动 VLSI 设计自动化领域从“纸上谈兵”走向“实战检验”最关键的一步。开始尝试用它来运行你的下一个算法吧你可能会发现以前被忽略的细节现在都成了必须面对和解决的问题而这正是进步的起点。 HighTide：连接学术与工业的现代VLSI基准测试套件
1. 从“闭门造车”到“开放协作”为什么我们需要一个全新的VLSI基准测试集在超大规模集成电路VLSI设计领域有一个老生常谈却又无比现实的问题当我们在评估一个新的布局布线算法、一个新的时序优化工具或者一个新的物理设计流程时我们到底该用什么来测试它过去很长一段时间里答案往往是那几个“经典”的、甚至有些年头的基准测试电路比如 ISCAS’85/’89或者 ITC’99。这些基准集确实为早期研究做出了巨大贡献但它们更像是博物馆里的标本——它们代表了特定历史时期和特定设计风格比如全定制、门级网表的产物与今天动辄数亿门、采用先进工艺节点、高度依赖高层次综合HLS和知识产权IP复用的复杂片上系统SoC设计相比已经显得有些“脱节”了。这就导致了一个尴尬的局面学术界发表的许多“性能提升显著”的新算法在论文里跑分很漂亮但一旦被工业界拿去测试真实的设计效果往往大打折扣甚至出现反效果。原因很简单测试环境基准集和真实战场工业级设计的差异太大了。这种鸿沟不仅阻碍了技术的有效转化也让研究人员难以准确把握当前设计流程中的真正瓶颈。正是在这样的背景下HighTide 这个由智能体Agent策划的开源 VLSI 基准测试套件应运而生。它瞄准的不是填补一个简单的空白而是试图构建一座连接学术前沿与工业实践、算法创新与真实需求的桥梁。HighTide 的核心价值在我看来可以概括为三个关键词现代性、复杂性与代表性、可复现性。它不再满足于提供一堆孤立的、小规模的网表文件而是致力于打包一整套完整的、从高层次描述到物理布局的、可构建的设计流程。这就像以前学开车给你一个方向盘模拟器现在直接给你一辆可以上路调试的真车虽然更复杂但练出来的才是真本事。接下来我们就深入 HighTide 的内部看看它是如何被“策划”出来的以及我们该如何上手使用它来真正提升我们的研究或工具开发水平。2. HighTide 的架构与“智能体策划”内涵解析HighTide 不是一个简单的文件压缩包。它是一个基于 Bazel 构建系统的、模块化的、可扩展的基准测试套件工程。理解它的架构是有效使用它的前提。2.1 以 Bazel 为核心的构建哲学HighTide 选择 Bazel 作为其构建工具这是一个非常关键且明智的设计决策。在传统的基准集使用中我们经常遇到这样的问题依赖库缺失、构建脚本不兼容、环境变量配置复杂导致“下载-解压-运行”三步走变成“下载-解压-折腾一天环境-放弃”。Bazel 通过声明式的构建规则BUILD文件和强大的沙盒化、缓存机制从根本上解决了可复现性问题。在 HighTide 项目中每一个设计模块比如一个 RISC-V 处理器核、每一个工具流程比如用 Yosys 进行逻辑综合、用 OpenROAD 进行布局布线都被定义为一个或多个 Bazel 目标target。当你执行bazel build //path/to:target时Bazel 会自动解析所有依赖从远程仓库下载特定版本的工具链如 GNU 工具链、Verilator、Yosys 等在一个隔离的环境中执行构建步骤并缓存结果。这意味着只要你的机器上安装了 Bazel理论上就可以一键复现整个流程无需手动安装和配置一堆杂乱的工具。这对于确保不同研究者在不同机器上能得到完全一致的实验结果至关重要。注意虽然 Bazel 带来了强大的可复现性但其学习曲线相对陡峭。初次接触时理解WORKSPACE定义外部依赖、BUILD定义内部构建目标和.bzl定义自定义构建规则文件之间的关系是第一步。HighTide 项目通常会提供顶层的构建脚本示例建议从这些示例开始而不是直接深入最复杂的设计。2.2 “智能体策划”到底意味着什么这是 HighTide 最具特色的部分。这里的“智能体”Agent并非指一个具象的 AI 程序而是一种设计理念和实现方法的隐喻。它指的是通过程序化、自动化的方式从更广阔的开源硬件生态中“筛选”、“组装”、“验证”和“打包”出适合作为基准测试的设计。具体来说这个过程可能包含以下步骤爬取与筛选智能体脚本会扫描如 GitHub、GitLab 等平台上的开源硬件项目根据预设的指标如星星数、活跃度、代码质量、文档完整性、许可证友好度进行初步筛选。依赖分析与解决分析选中项目的依赖关系包括其他 IP 核、特定的工具版本、软件库等。HighTide 的智能体会尝试用 Bazel 规则来描述这些依赖确保它们能被自动拉取和构建。流程集成与标准化将选中的设计集成到 HighTide 统一的构建流程中。这可能涉及为该项目编写或适配 Bazel 构建规则将其 RTL寄存器传输级代码、约束文件SDC、工艺库文件LEF/DEF, Liberty等资源组织成标准的目录结构。质量验证与基准生成运行一系列基本的验证流程如逻辑等效性检查 LEC、静态时序分析 STA 的脚本雏形确保该设计在集成后仍然是功能正确的。同时生成该设计在不同优化阶段综合后、布局后、布线后的标准输出文件网表、时序报告、面积报告、功耗报告这些输出本身就是基准的一部分可用于工具间的横向对比。“策划”一词的精妙之处在于它强调的不是从零创造而是基于现有开源资源的“策展”与“再组织”。这使得 HighTide 能够快速吸纳社区中最活跃、最具代表性的项目保持其基准集的“现代性”。例如它可能集成了基于 Chisel 或 SpinalHDL 编写的现代处理器设计包含了利用 BlackParrot 或 CVA6 等开源核心的 SoC 子系统这些正是当前工业界和学术界关注的热点。3. HighTide 基准套件的核心内容与典型设计剖析那么HighTide 里具体有哪些“干货”呢虽然其具体内容会不断更新但我们可以从其设计目标推断出它可能包含的几类典型设计并分析其作为基准的价值。3.1 设计层次与复杂度谱系一个优秀的基准套件应该覆盖从简单到复杂的各种场景。HighTide 很可能提供这样一个谱系微内核与算术单元例如一个高度优化的 AES 加密内核、一个浮点运算单元FPU。这类设计规模较小几万到几十万门结构规整是测试工具基础算法如逻辑优化、技术映射的“试金石”。它们能快速暴露工具在处理特定电路结构如大量 XOR 门、数据通路时的效率问题。中型处理器核心例如一个完整的、支持 RV32IMC 指令集的 RISC-V 处理器核如 VexRiscv 或 picorv32 的优化版本。这类设计规模达到数十万门包含了控制流、数据通路、存储器接口等典型微架构模块是测试综合、布局布线工具在平衡时序、面积、功耗方面能力的绝佳对象。其瓶颈通常出现在关键路径如 load-use 延迟、分支预测误判恢复路径上。复杂 SoC 子系统例如一个包含处理器核心、片上互连如 TileLink/AXI 总线、DMA 控制器、外部存储器接口如 DDR PHY 模型和多个外设UART, SPI, I2C的子系统。这类设计规模可能达到数百万门并引入了层次化设计、时钟域交叉CDC、功耗域等先进概念。它们是测试工具容量、层次化处理能力、以及签核流程如形式验证、物理验证的“大考”。3.2 关键交付物不止是 RTLHighTide 作为现代基准集提供的远不止是 Verilog/VHDL 源代码。一套完整的基准至少应包括交付物类型文件格式示例作用与价值设计源码.v,.sv,.py(Chisel),.scala(SpinalHDL)设计的原始描述是一切流程的起点。支持多种硬件描述语言是现代基准的标志。约束文件.sdc(Synopsys Design Constraints)定义设计的时序、时钟、功耗约束。这是评估工具优化效果是否达标的“标尺”。一份写得好、符合工业实践的 SDC 文件本身就有很高的参考价值。工艺库文件.lib(Liberty),.lef(Layout Exchange),.def(Design Exchange)描述目标工艺单元的逻辑时序、功耗信息以及物理几何信息。HighTide 可能会提供基于开源 PDK如 Google-SkyWater 130nm或虚拟工艺库的版本确保完全可开源使用。脚本与构建规则BUILD,.bzl,Makefile,Tcl脚本自动化构建和运行流程的脚本。这是 HighTide 的灵魂确保了可复现性。参考结果与黄金数据.v(门级网表),.spef(寄生参数),.timing.rpt,.power.rpt由一套“参考工具流”可能是经过充分验证的开源工具组合如 Yosys OpenROAD运行产生的中间和最终结果。这些数据可以作为“黄金参考”用于与其他工具链的输出进行对比验证正确性和评估优化质量。测试激励与验证环境.sv(SystemVerilog Testbench),.cpp(Co-simulation),.bin(测试程序)用于功能验证的测试平台和测试向量。确保所评估的设计在优化前后功能等价。3.3 以“VLSI 布图规划设计”为例看基准应用“VLSI 布图规划设计”是当前的一个热点它涉及在芯片物理设计初期对宏模块如 SRAM、CPU Core、GPU Cluster进行形状规划、位置摆放和电源网络预布局。HighTide 中的复杂 SoC 子系统基准正是测试布图规划算法的绝佳载体。假设我们有一个集成了 CPU、GPU、多个 SRAM 和 IO 的子系统基准。一个布图规划工具需要处理以下挑战而这些挑战都可以用 HighTide 基准来量化评估形状优化与面积估算CPU 和 GPU 可能由不同的团队设计初始形状和长宽比各异。工具需要能自动或交互式地调整模块形状在满足布线通道需求的前提下最小化芯片总面积。HighTide 提供的模块 LEF 文件定义了它们的物理轮廓和引脚位置。互连驱动布局CPU 和 SRAM 之间可能存在高频宽的数据通路。工具需要将通信密集的模块摆放得更近以减少全局互连延迟和功耗。这需要分析设计中的网络拓扑可以从 DEF 或网表中提取。电源规划集成现代设计对 IR Drop 非常敏感。布图规划阶段就需要预留电源环Power Ring和电源带Power Stripe的位置和宽度。HighTide 的基准可能包含初步的电源网络约束用于评估工具生成的电源网络质量。可布线性预估模块摆得太挤后期布线可能无法完成摆得太松又浪费面积。工具需要能快速预估给定布局下的布线拥堵情况。HighTide 的参考布局布线结果可以提供拥堵图Congestion Map作为对比基准。通过将你的布图规划工具在 HighTide 的多个基准上运行并对比其产生的芯片面积、预估总线长、布线拥堵程度、电源网络压降等指标与参考结果的差异你就能对你的算法性能有一个全面、客观、贴近实际的认识。4. 实战使用 Bazel 构建并运行你的第一个 HighTide 基准理论说了这么多我们来点实际的。假设我们已经从 HighTide 的官方仓库克隆了代码现在要尝试构建并运行其中一个中等复杂度的设计比如一个名为//benchmarks/riscv_core:vexriscv_system的目标。4.1 环境准备与初次构建首先确保你的开发环境满足基本要求Linux/macOS对 Windows 的 WSL2 支持可能较好安装了 Bazel建议使用项目推荐的版本如 5.x 或 6.x以及足够的磁盘空间因为 Bazel 会缓存很多依赖。# 1. 克隆 HighTide 仓库假设仓库地址 git clone https://github.com/hightide-benchmarks/hightide.git cd hightide # 2. 查看项目结构非必须但有助于理解 find . -name BUILD -type f | head -20 ls -la benchmarks/ # 3. 进行首次构建。这可能会花费较长时间因为 Bazel 需要下载所有依赖的工具和库。 # 使用 --jobsN 可以指定并行任务数加速构建。 bazel build //benchmarks/riscv_core:vexriscv_system第一次运行bazel build时你会看到控制台输出大量下载和编译信息。Bazel 正在构建整个依赖图它可能会下载特定版本的 Verilator用于仿真、riscv-gnu-toolchain用于编译测试程序、Yosys用于综合等。这一切都在 Bazel 的沙盒中进行不会污染你的系统环境。构建成功后你会在bazel-bin/目录下找到生成的文件。4.2 理解构建目标与运行流程一个:vexriscv_system目标背后可能定义了一连串的构建动作。我们可以用bazel query来查看其依赖关系# 查看该目标的直接依赖 bazel query deps(//benchmarks/riscv_core:vexriscv_system, 1) --outputgraph | dot -Tpng deps.png # 或者查看其生成的文件 bazel cquery //benchmarks/riscv_core:vexriscv_system --outputfiles通常这样的目标会生成多个输出vexriscv_system.rtl.v经过预处理和打包的顶层 RTL 代码。vexriscv_system.sdc对应的时序约束文件。vexriscv_system.sim.v可能是一个封装好的、可仿真的顶层模块。甚至可能直接生成一个可执行的仿真程序。要运行一个完整的流程例如从 RTL 到门级网表的综合HighTide 可能定义了一个单独的“流程目标”# 运行综合流程使用 Yosys 作为综合工具目标工艺库是 //pdks/sky130:sky130_fd_sc_hd bazel run //benchmarks/riscv_core:vexriscv_system_synth -- --top_module vexriscv_system --pdk //pdks/sky130:sky130_fd_sc_hd这个bazel run命令会先构建目标如果还没构建然后执行目标对应的可执行规则该规则内部会调用 Yosys 脚本读取 RTL 和约束使用指定的工艺库进行综合最终在bazel-bin下生成综合后的网表vexriscv_system_synth.v和相关的时序报告。4.3 自定义与扩展添加你自己的分析脚本HighTide 的强大之处在于它的可扩展性。假设你想在综合流程后自动运行一个自定义的脚本分析网表的扇出Fanout分布情况。创建自定义构建规则在项目根目录或你的工作区目录下创建一个custom_rules.bzl文件。# custom_rules.bzl def _analyze_fanout_impl(ctx): # ctx 是规则上下文包含了输入文件、输出文件等信息 input_netlist ctx.file.input_netlist output_report ctx.actions.declare_file(ctx.label.name _fanout.rpt) # 编写要执行的命令。这里假设我们有一个 Python 脚本 analyze_fanout.py ctx.actions.run( inputs [input_netlist], outputs [output_report], executable ctx.executable._analyze_script, arguments [ --input, input_netlist.path, --output, output_report.path ], progress_message Analyzing fanout distribution for %s % input_netlist.short_path, ) return [DefaultInfo(files depset([output_report]))] analyze_fanout rule( implementation _analyze_fanout_impl, attrs { input_netlist: attr.label(allow_single_file [.v, .sv]), _analyze_script: attr.label( default //tools/scripts:analyze_fanout.py, executable True, cfg exec, ), }, )编写分析脚本在tools/scripts/下创建analyze_fanout.py并为其编写BUILD文件将其定义为py_binary。在基准的 BUILD 文件中使用新规则编辑benchmarks/riscv_core/BUILD在vexriscv_system_synth目标后添加load(//:custom_rules.bzl, analyze_fanout) analyze_fanout( name vexriscv_system_fanout_analysis, input_netlist :vexriscv_system_synth.v, # 依赖于综合生成的网表 )现在你可以通过bazel build //benchmarks/riscv_core:vexriscv_system_fanout_analysis来运行你的自定义分析并集成到整个自动化流程中。5. 在研究与开发中有效利用 HighTide避坑指南与最佳实践将 HighTide 集成到你的日常研究或工具开发中能极大提升效率但也有一些需要注意的地方。5.1 常见问题与排查思路构建失败依赖下载超时或失败。这通常是网络问题。Bazel 支持配置代理。你可以在$HOME/.bazelrc或项目内的.bazelrc中设置build --experimental_remote_downloadergrpc://remote-cache.example.com:8080 # 如果使用远程缓存 startup --host_jvm_args-Dhttp.proxyHostyour.proxy.host --host_jvm_args-Dhttp.proxyPortyour.proxy.port另外检查 HighTide 的WORKSPACE文件看它是否使用了某些需要特殊访问权限的仓库如某些内部 GitLab你可能需要配置 Git 的 SSH 密钥或 HTTPS 凭证。构建成功但运行时工具报错如 Yosys 语法错误。首先确认你构建的目标是否正确。HighTide 可能为同一个设计提供了多个配置如不同的时钟频率、不同的优化目标。使用bazel query //benchmarks/...查看所有可用目标。其次检查工具的版本。Bazel 确保了工具版本的一致性但如果你在本地已经安装了同名工具可能会被误用。确保你通过bazel run来执行流程而不是直接调用系统路径下的工具。结果与参考数据差异巨大。不要急于下结论说自己的工具不好。首先进行“苹果对苹果”的比较约束是否一致检查使用的 SDC 文件是否完全相同。时钟定义、不确定性uncertainty、输入输出延迟是否匹配工艺库是否一致确认 Liberty 文件、LEF/DEF 文件的版本和内容。即使是同一个工艺节点不同厂家或不同版本的 PDK 也会有差异。流程起点是否一致比较输入给工具的 RTL 代码是否经过了一致的预处理例如宏定义、include 文件路径。工具命令与选项HighTide 的参考流程可能使用了特定的工具命令选项如综合策略、布局布线努力程度。查看 Bazel 规则中生成的详细命令行日志。5.2 将 HighTide 集成到你的 CI/CD 流水线对于工具开发团队将 HighTide 作为回归测试集集成到持续集成CI系统中是保证代码质量的最佳实践。以下是一个基于 GitHub Actions 的简化示例# .github/workflows/hightide-regression.yml name: HighTide Regression Test on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Install Bazel uses: bazelbuild/setup-bazeliskv2 - name: Run a subset of HighTide benchmarks run: | # 测试一个小的算术单元快速反馈 bazel test //benchmarks/arithmetic:aes_128 --test_outputerrors # 测试一个中型处理器核心时间稍长 bazel test //benchmarks/riscv_core:vexriscv_system_synth --test_outputerrors # 可以在这里添加对比脚本将本次运行结果与基线结果比较 python scripts/compare_results.py ./bazel-bin/benchmarks/ ./baseline/在 CI 中建议先从运行时间较短的基准开始逐步加入更复杂的设计。可以为关键指标如时序违例总量、总面积、总功耗设置阈值当新提交的代码导致这些指标恶化超过一定比例时CI 任务失败。5.3 贡献回馈社区HighTide 作为一个开源项目其生命力来自于社区贡献。如果你在使用过程中修复了某个基准的构建问题。为某个设计添加了更完善的约束文件或测试向量。将一个新的、高质量的开源设计集成到了 HighTide 框架中。甚至发现并修复了 Bazel 构建规则中的 bug。请务必考虑向 HighTide 项目提交 Pull Request。贡献的过程本身也是对你理解的一次极好检验并能帮助整个社区共同进步。在提交前请仔细阅读项目的贡献指南确保你的代码风格、提交信息格式符合规范并且新增的基准确实具有代表性和高质量。从我个人的使用经验来看像 HighTide 这样的现代基准套件其价值不仅仅在于提供测试用例更在于它定义了一种可复现的研究与开发范式。它迫使我们将关注点从“跑出一个好数字”转移到“构建一个健壮、可复现、可比较的完整流程”上。这或许才是推动 VLSI 设计自动化领域从“纸上谈兵”走向“实战检验”最关键的一步。开始尝试用它来运行你的下一个算法吧你可能会发现以前被忽略的细节现在都成了必须面对和解决的问题而这正是进步的起点。