ScaleHLS：基于MLIR的下一代HLS编译器框架，实现FPGA高性能计算与AI加速

1. 项目概述：ScaleHLS，一个基于MLIR的下一代HLS编译器框架

如果你正在FPGA（现场可编程门阵列）领域进行高性能计算或AI加速器的开发，那么“高抽象层级设计”与“后端实现效率”之间的矛盾，一定是你绕不开的痛点。传统的HLS（高层次综合）工具，如Vivado HLS，虽然允许你用C/C++或SystemC描述硬件行为，但其优化过程往往像一个黑盒，对复杂循环嵌套、数据流和内存层次结构的处理能力有限，导致生成的RTL（寄存器传输级）代码在性能、面积和功耗上远未达到手工优化的水平。更棘手的是，当你的算法模型来自PyTorch等深度学习框架时，如何将其高效、自动地映射到FPGA硬件上，更是一个充满挑战的工程问题。

今天要深入探讨的，正是为解决这些痛点而生的一个前沿开源项目——ScaleHLS。它并非另一个简单的HLS工具包装，而是一个构建在LLVM/MLIR基础设施之上的、全新的、可扩展的HLS编译框架。简单来说，ScaleHLS的核心思想是“分而治之”与“因材施教”。它将一个复杂的硬件设计（无论是C++内核还是PyTorch模型）分解成MLIR中多个不同抽象级别的中间表示（IR），然后在最合适的层级上施加最有效的优化变换。这就像你要装修一栋房子，传统HLS可能只给你一张最终效果图就开始施工，而ScaleHLS则提供了从建筑结构图、水电管线图到室内设计图的全套蓝图，允许你在每一层图纸上进行精细化的调整和优化。

我之所以花大量时间研究ScaleHLS，是因为它在两个关键点上做出了突破：一是可扩展性（Scalability），通过MLIR的多级IR机制，它能更好地适配从张量运算到循环展开等不同粒度的优化；二是自动化探索（Automation），其内置的设计空间探索引擎，能自动尝试多种优化策略的组合（如循环分块、流水线、数组分区），寻找接近最优的硬件实现方案。对于硬件工程师和算法工程师而言，这意味着你可以用更高级的语言描述功能，同时获得对硬件实现细节前所未有的可控性和优化潜力，最终目标是生成高质量、可直接交付给Vivado HLS等下游工具进行综合的C/C++代码。

2. 核心架构与设计哲学解析

2.1 为什么是MLIR？理解ScaleHLS的基石

要理解ScaleHLS，必须先理解其基石——MLIR。MLIR并非一个具体的编译器，而是一个用于构建可重用、可扩展编译基础设施的框架。它的核心创新在于“多级中间表示”。传统的编译器（如LLVM）通常只有一种主要的IR，所有优化都在这一层进行。但对于HLS这种涉及高级算法语义和低级硬件细节的领域，单一层级的IR显得力不从心。

ScaleHLS充分利用了MLIR的这一特性，构建了一个垂直集成的编译栈。一个典型的编译流程可能会经历以下几个关键IR层级：

1. 前端级IR：例如torchdialect（对应PyTorch模型）或通过Polygeist前端从C/C++生成的affinedialect（对应循环嵌套）。这一层保留了最高级的算法语义。
2. HLS专用级IR：这是ScaleHLS的核心创新层，例如scalehls.linalg或scalehls.loop等dialect。在这一层，编译器开始理解硬件相关的概念，如流水线（pipeline）、数据流（dataflow）、存储层次（memory hierarchy）和接口协议（interface protocol）。
3. 底层硬件近似的IR：在应用了循环变换、数组分区、流水线打拍等优化后，代码会被逐步lower到更接近硬件描述的IR，如scf（结构化控制流）、cf（控制流）和最终的llvmIR或vhdl/verilogdialect（未来可能）。

这种分层策略的优势是显而易见的。优化可以在最合适的抽象级别进行：例如，在高级别进行算法层面的数据重用分析，在中级别进行循环变换和流水线调度，在低级别进行具体的资源绑定和状态机生成。每一层的变换都更专注、更高效，并且不同层级的优化可以组合起来，产生“1+1>2”的效果。

2.2 ScaleHLS框架组件深度拆解

根据项目文档和源码结构，我们可以将ScaleHLS框架解构成几个核心组件：

1. 前端接口层：

• C/C++前端：依赖于子模块polygeist。它是一个将C/C++代码（特别是带有动态指针和复杂控制流的代码）提升（raise）到MLIRaffinedialect的工具。affinedialect非常适合表示规整的循环嵌套和数据访问模式，是进行循环优化（如分块、交换、融合）的理想起点。
• PyTorch前端：依赖于Torch-MLIR项目。它将PyTorch的模型图（通过TorchScript导出）导入并转换为MLIR的torchdialect，再经过一系列 lowering 步骤，最终转换为以线性代数运算为核心的linalgdialect。这为从深度学习框架直接进行硬件综合提供了可能。

2. 核心优化与变换库：这是ScaleHLS的“大脑”。它包含了一系列用C++（和Python绑定）编写的HLS专用分析和变换Pass（编译过程）。这些Pass操作在不同的MLIR dialect上，实现诸如：

• 循环优化：循环分块（tiling）、流水线（pipelining）、展开（unrolling）、融合（fusion）、交换（interchange）。
• 数据布局优化：数组分区（array partitioning）、重塑（reshaping），旨在提升内存带宽利用率，减少访问冲突。
• 设计空间探索引擎：这是ScaleHLS的亮点。它不是一个单一的Pass，而是一个元优化器。给定一个初始设计和一个目标规格（如目标时钟周期、资源约束），DSE引擎会自动尝试上述各种变换的不同参数组合（例如，不同的分块大小、不同的流水线启动间隔II），评估每个候选设计的性能/面积预估，并采用搜索算法（如模拟退火、遗传算法）来寻找 Pareto 最优解。

3. 后端代码生成层：经过优化后的MLIR表示，最终会通过scalehls-translate工具，被“翻译”回高度优化的、符合下游HLS工具（主要是Xilinx Vivado HLS）编码风格的C/C++代码。这一步至关重要，因为它决定了优化成果能否被传统工具链正确继承。生成的代码通常会包含大量的#pragma HLS指令，用于指导Vivado HLS进行最终的RTL生成。

注意：ScaleHLS目前主要面向Xilinx Vivado HLS生态。虽然其架构是开放的，但要适配其他厂商的HLS工具（如Intel HLS Compiler），需要重写或调整其后端代码生成部分。

3. 从零开始：ScaleHLS环境搭建与编译实操

纸上得来终觉浅，绝知此事要躬行。下面我将带你完整走一遍ScaleHLS的搭建和编译流程，并附上我踩过的一些坑和解决方案。

3.1 系统准备与依赖安装

ScaleHLS的编译依赖一个健康的LLVM/MLIR环境。官方推荐使用其脚本自动构建，但这要求你的系统具备完整的开发工具链。

基础依赖安装（以Ubuntu 20.04/22.04为例）：

# 更新系统并安装基础编译工具 sudo apt update sudo apt install -y build-essential cmake ninja-build git python3 python3-pip # 安装LLVM/Clang相关工具（ScaleHLS需要特定版本，但脚本会自行编译LLVM，此处安装系统版仅为辅助） sudo apt install -y clang lld # 安装Python绑定可选依赖 pip3 install pybind11 numpy

关键点解析：

• ninja：比make更快的构建系统，MLIR项目几乎都推荐使用它。
• clang和lld：ScaleHLS的构建脚本可能会用到系统的Clang作为宿主编译器，lld链接器可以加速大型项目的链接过程。
• pybind11：用于生成C++库的Python绑定，如果你想通过Python API调用ScaleHLS的优化能力，则必须安装。

3.2 源码获取与项目编译

步骤一：克隆仓库务必使用--recursive参数，因为ScaleHLS依赖polygeist和llvm-project等子模块。

git clone --recursive https://github.com/UIUC-ChenLab/scalehls.git cd scalehls

如果因为网络问题克隆子模块失败，可以进入目录后，反复执行git submodule update --init --recursive直到成功。

步骤二：执行构建脚本项目根目录下的build-scalehls.sh脚本自动化了整个构建过程，包括编译LLVM、MLIR、Polygeist和ScaleHLS本身。

# 基础构建，启用并行编译以加快速度（根据你的CPU核心数调整-j后的数字） ./build-scalehls.sh -j $(nproc) # 如果你需要Python绑定功能，则必须加上 `-p ON` 参数 ./build-scalehls.sh -p ON -j $(nproc)

实操心得与避坑指南：

1. 内存要求：完整编译LLVM和ScaleHLS是一个内存消耗巨大的过程。建议系统内存至少为8GB，如果遇到编译过程中被kill，大概率是内存不足。可以尝试减少并行任务数，如使用-j 2。
2. 磁盘空间：整个构建目录（build/）最终可能会占用20GB以上的磁盘空间，请确保所在分区有足够容量。
3. 时间成本：在普通台式机上，首次完整构建可能需要1-2小时，请保持耐心。构建成功后，后续增量编译会很快。
4. Python虚拟环境：强烈建议在构建和后续使用Python绑定前，创建一个独立的Python虚拟环境，避免污染系统Python环境。

   python3 -m venv scalehls_venv source scalehls_venv/bin/activate # 在此虚拟环境中安装pybind11和numpy，然后执行带 `-p ON` 的构建脚本

步骤三：配置环境变量构建成功后，为了方便使用，需要将生成的工具路径加入环境变量。

# 在scalehls项目根目录下执行 export PATH=$PWD/build/bin:$PWD/polygeist/build/bin:$PATH export PYTHONPATH=$PWD/build/tools/scalehls/python_packages/scalehls_core:$PYTHONPATH

为了方便，你可以将这两行命令添加到你的shell配置文件（如~/.bashrc或~/.zshrc）中。

3.3 验证安装

运行以下命令，如果能看到帮助信息，说明核心工具链安装成功。

scalehls-opt --help | head -20 cgeist --help | head -20

4. 实战演练一：优化C/C++内核（以矩阵乘法为例）

让我们用一个经典的gemm（通用矩阵乘法）例子，来感受ScaleHLS的自动化优化能力。示例代码位于samples/polybench/gemm/。

4.1 原始C代码与手动优化困境

原始test_gemm.c代码通常是类似这样的三层嵌套循环：

void test_gemm(int ni, int nj, int nk, double *A, double *B, double *C) { for (int i = 0; i < ni; i++) { for (int j = 0; j < nj; j++) { double sum = 0; for (int k = 0; k < nk; k++) { sum += A[i*nk + k] * B[k*nj + j]; } C[i*nj + j] = sum; } } }

手动为这种代码编写高效的HLS实现是繁琐的：你需要决定哪个循环可以流水线化，循环体是否要展开，数组A、B、C应该如何分区（完全分区、块分区、循环分区）以匹配计算吞吐量，循环顺序（i, j, k）是否应该交换以优化局部性。这是一个多维度的设计空间，手动探索效率极低。

4.2 使用ScaleHLS进行自动化设计空间探索

ScaleHLS通过一个config.json文件来定义设计目标和约束。这个文件是DSE引擎的“寻宝图”。

步骤一：生成初始MLIR使用cgeist（Polygeist的一部分）将C代码解析为MLIR的affine表示。

cd samples/polybench/gemm cgeist test_gemm.c -function=test_gemm -S -memref-fullrank -raise-scf-to-affine > test_gemm.mlir

• -function=test_gemm：指定要处理的顶层函数。
• -memref-fullrank：生成多维的memref类型（MLIR中用于表示内存缓冲区的类型），这有利于后续的数组分区分析。
• -raise-scf-to-affine：将较低级的scf循环提升为更规整、更适合优化的affine循环。 生成的test_gemm.mlir文件是人类可读的MLIR代码，描述了算法的循环结构和数据访问。

步骤二：启动DSE引擎并生成优化代码这是最关键的一步。我们使用scalehls-opt工具加载DSE引擎的Pass。

scalehls-opt test_gemm.mlir -debug-only=scalehls \ -scalehls-dse-pipeline="top-func=test_gemm target-spec=../config.json" \ | scalehls-translate -scalehls-emit-hlscpp > test_gemm_dse.cpp

• -debug-only=scalehls：启用ScaleHLS相关的调试输出，可以在终端看到DSE引擎正在尝试的变换和评估结果，对于理解其工作过程非常有帮助。
• -scalehls-dse-pipeline=：指定DSE流水线Pass，并传入参数。
  • top-func=test_gemm：指定顶层函数名。
  • target-spec=../config.json：指定包含目标频率、资源约束和优化指令（如“尝试流水线化所有循环”）的配置文件。
• scalehls-translate -scalehls-emit-hlscpp：将优化后的MLIR转换回C++代码。

步骤三：解读优化结果打开生成的test_gemm_dse.cpp，你会看到代码已经面目全非。ScaleHLS可能应用了如下变换：

1. 循环分块：将大的i、j、k循环分解为外层块循环和内层元素循环，以提升缓存/BRAM的局部性。
2. 循环流水线：在内层最关键的循环（可能是k循环或分块后的内层循环）上添加了#pragma HLS pipeline，并尝试最小化启动间隔（II）。
3. 数组分区：为数组A、B、C添加了#pragma HLS array_partition指令，可能是完全分区或循环分区，以提供足够的数据端口供流水线内的操作并行访问。
4. 循环展开：可能将某些内层小循环完全展开，以暴露更多的指令级并行。

config.json文件配置精要：一个典型的配置文件可能包含：

{ "target": { "clock_period": 5, // 目标时钟周期，单位ns（对应200MHz频率） "resources": { // 目标FPGA芯片的资源约束（可选，用于评估面积） "DSP": 1000, "BRAM": 500, "LUT": 100000 } }, "directives": { // 给DSE引擎的优化指令 "pipeline_loops": "all", // 尝试流水线化所有循环 "explore_tiling": true, // 探索循环分块 "explore_partitioning": true // 探索数组分区 } }

DSE引擎会根据这个配置，在变换空间中搜索，使用一个成本模型（综合预估的时钟周期数、资源使用量）来评估每个设计点的优劣，最终输出它认为的“最优”或“较优”实现。

5. 实战演练二：从PyTorch模型到HLS代码（以ResNet-18为例）

将深度学习模型部署到FPGA是当前的热点。ScaleHLS通过集成Torch-MLIR，打通了从PyTorch到优化HLS代码的路径。

5.1 环境准备：安装Torch-MLIR

Torch-MLIR是连接PyTorch和MLIR世界的桥梁。ScaleHLS的示例要求安装其预编译版本。

# 创建并激活一个新的虚拟环境，避免与ScaleHLS的Python绑定环境冲突 python -m venv torch_mlir_venv source torch_mlir_venv/bin/activate # 安装Torch-MLIR及其依赖（注意：请始终从官方仓库获取最新安装命令） pip install --pre torch-mlir torchvision -f https://llvm.github.io/torch-mlir/package-index/ --extra-index-url https://download.pytorch.org/whl/nightly/cpu

重要提示：Torch-MLIR和PyTorch的版本兼容性要求很严格。务必按照ScaleHLS项目README或示例目录中的说明安装指定版本，否则极易出现导入错误或运行时错误。

5.2 模型导出与MLIR生成

进入ResNet-18示例目录：

cd samples/pytorch/resnet18

查看resnet18.py，其核心工作是使用Torch-MLIR的API将PyTorch模型导出为MLIR。关键步骤通常包括：

1. 加载预训练的ResNet-18模型。
2. 准备一个示例输入张量。
3. 使用torch_mlir.compile函数，将模型和输入编译到torchdialect的MLIR。
4. 将torchdialect逐步lower到linalgdialect（线性代数），这是ScaleHLS优化的主要入口点。

执行脚本生成MLIR：

# 确保在torch_mlir_venv虚拟环境中 python3 resnet18.py > resnet18.mlir

生成的resnet18.mlir文件包含了模型在linalgdialect下的表示，其中主要是linalg.generic操作，代表了矩阵乘法、卷积等张量运算。

5.3 使用ScaleHLS优化与代码生成

现在，我们使用ScaleHLS的专用Pass（-scaleflow-pytorch-pipeline）来优化这个MLIR表示。

# 确保PATH环境变量已包含scalehls-opt（在ScaleHLS的构建环境中） scalehls-opt resnet18.mlir \ -scaleflow-pytorch-pipeline="top-func=forward loop-tile-size=8 loop-unroll-factor=4" \ | scalehls-translate -scalehls-emit-hlscpp > resnet18.cpp

• -scaleflow-pytorch-pipeline=：这是针对PyTorch模型（通过Torch-MLIR导入）的优化流水线。
  • top-func=forward：指定模型的入口函数（通常是forward）。
  • loop-tile-size=8：指定循环分块的大小。这里是一个全局提示，实际DSE过程可能会调整。
  • loop-unroll-factor=4：指定循环展开因子。

优化逻辑解析：对于像ResNet这样的CNN模型，ScaleHLS会识别出其中的卷积层、全连接层等。优化过程包括：

• 循环变换：将卷积的N（批大小）、C（通道）、H（高）、W（宽）、K（输出通道）、R（卷积核高）、S（卷积核宽）等多维循环进行分块、重排序，以最大化数据复用（例如，将输入特征图块缓存在片上内存）。
• 数据布局转换：可能将数据从NCHW格式转换为更适合FPGA流水线计算的格式。
• 操作符融合：将相邻的线性代数操作（如卷积+偏置+激活）融合在一起，减少中间结果的写回和读取，提升效率。 生成的resnet18.cpp是一个巨大的、高度优化的、但可读性较差的C++文件，其中包含了所有层的计算逻辑，并插满了HLS Pragmas，可以直接交给Vivado HLS进行综合。

6. 常见问题、调试技巧与进阶指南

在实际使用ScaleHLS的过程中，你一定会遇到各种问题。以下是我总结的一些常见坑点及其解决方法。

6.1 编译与构建问题

6.2 工具运行与优化问题

6.3 调试与性能分析技巧

1. 善用调试输出：-debug-only=scalehls参数是理解ScaleHLS内部工作的最佳窗口。它会打印出DSE引擎尝试的每一种变换、循环的II（启动间隔）预估、资源使用预估等信息。通过分析这些输出，你可以判断优化是否按预期进行。
2. 分阶段优化：不要一开始就运行完整的DSE。可以先用scalehls-opt运行单个Pass来观察效果，例如：

   # 只应用循环分块变换 scalehls-opt input.mlir -scalehls-loop-tile="tile-sizes=64,64,64" > output_tiled.mlir # 查看分块后的MLIR cat output_tiled.mlir

3. 可视化MLIR：MLIR文本对于复杂模型可读性差。可以尝试将MLIR输出为.dot图文件，然后用Graphviz工具查看。虽然ScaleHLS没有直接提供此功能，但MLIR核心的-view-op-graph等Pass有时可用。
4. 与原始HLS对比：始终保留一份未经ScaleHLS优化的、手写或基础版本的HLS代码。将ScaleHLS优化后的代码与它一起在Vivado HLS下综合，对比频率、资源利用率、吞吐量等关键指标，这是衡量ScaleHLS价值的唯一标准。

6.4 进阶使用与二次开发

如果你不满足于使用命令行工具，希望更灵活地控制优化流程，或者为特定算法定制优化策略，那么ScaleHLS的C++和Python API为你打开了大门。

• C++ API：你可以编写自己的MLIR Pass，集成到ScaleHLS的编译流程中。这需要你熟悉MLIR框架和C++编程。主要工作目录在include/scalehls和lib下。
• Python API：如果构建时启用了-p ON，你可以使用pyscalehls工具或直接导入scalehlsPython模块。这为快速原型设计和交互式优化提供了可能。例如，你可以写一个Python脚本，遍历不同的分块大小，调用ScaleHLS库进行评估，然后绘制性能-面积曲线。

ScaleHLS代表了一种趋势：将硬件编译从封闭的、黑盒的工程，转变为开放的、基于现代编译器技术的、可定制和可扩展的科学。它目前仍是一个学术驱动的前沿项目，在易用性、稳定性和对复杂工业设计的支持上还有很长的路要走。但它所提供的范式——基于多级IR的、可组合的、自动搜索的硬件编译——无疑是解决HLS生产力与性能矛盾的一盏明灯。对于研究者、敢于尝试新工具的开发者和追求极致性能的硬件加速团队来说，投入时间学习并参与贡献ScaleHLS，很可能是在为未来的硬件设计方法论进行投资。