4. HLS工具链与工程结构
把C/C++算法变成可综合的RTL，并不是“点一下按钮”就结束的动作，而是一条由工程结构、脚本流程和编译选项共同支撑的工具链。不同厂商的HLS工具在语法支持、综合策略和工程组织上各有侧重，但它们的核心工作方式高度一致：以工程目录承载源码与约束，以脚本驱动编译与综合，以编译选项控制接口、时序与优化方向。理解这条工具链，才能让算法到RTL的转换过程可复现、可调试、可交付。
一、主流HLS工具链的定位与差异
目前工程中使用最广的三类HLS工具分别是Xilinx（AMD）的Vitis HLS、Siemens EDA的Catapult HLS，以及Cadence的Stratus HLS。它们都支持从C/C++/SystemC生成RTL，但在输入语言偏好、综合调度方式和工程组织上存在明显差异。
| 工具 | 主要输入语言 | 工程组织特点 | 典型驱动方式 | 常见应用场景 |
|---|---|---|---|---|
| Vitis HLS | C/C++、SystemC | 以solution为单位，含src、tb、directive、script | Tcl脚本 + GUI | FPGA加速、IP核生成 |
| Catapult HLS | C++、SystemC | 以project/flow为单位，强调库映射与约束文件 | Makefile + Tcl | ASIC/SoC高层综合 |
| Stratus HLS | C/C++、SystemC | 以project目录组织，含source、testbench、constraint | Tcl脚本 + GUI | 复杂控制与数据通路综合 |
可以看到，三者虽然界面和命令不同，但都遵循“源码 + 测试平台 + 约束/指令 + 脚本”的四要素结构。掌握其中一种后，迁移到另一种工具时，主要成本在于命令和指令语法的差异，而不是方法论的重新学习。
二、脚本驱动流程：从GUI操作到可复现工程
初学者常依赖GUI完成综合，但工程化项目必须使用脚本。原因很直接：GUI操作无法版本管理，参数调整无法追溯，团队协作时环境不一致。脚本驱动流程把“打开工程—设置选项—运行综合—导出RTL”固化为可重复执行的命令序列。
以Vitis HLS为例，一个典型的Tcl脚本会依次完成工程创建、源码添加、测试平台设置、指令加载和综合运行：
open_project hls_fft
set_top fft_top
add_files src/fft.cpp
add_files -tb tb/fft_tb.cpp
open_solution "solution1" -flow_target vivado
set_part {xc7z020clg400-1}
create_clock -period 10 -name default
source ./directive/fft_directive.tcl
csim_design
csynth_design
cosim_design -trace_level all
export_design -format ip_catalog
这段脚本的价值在于：任何人拿到工程目录后，只需执行一次vitis_hls -f run_hls.tcl，就能得到与原始开发者完全一致的仿真、综合和协同验证结果。Catapult和Stratus同样支持Tcl脚本，只是命令名称和工程对象不同，例如Catapult常用project new、solution options等命令组织流程。
三、目录结构与编译选项的工程约定
一个可维护的HLS工程目录通常包含以下层级。以Vitis HLS为例：
hls_fft/
├── src/ # 算法源码
│ ├── fft.cpp
│ └── fft.h
├── tb/ # 测试平台
│ └── fft_tb.cpp
├── directive/ # 综合指令
│ └── fft_directive.tcl
├── script/ # 驱动脚本
│ └── run_hls.tcl
├── solution1/ # 综合输出（自动生成）
│ ├── syn/
│ │ ├── verilog/
│ │ └── report/
│ └── sim/
└── README.md
其中src/、tb/、directive/、script/是人工维护的输入，solution1/是工具生成的输出，通常不纳入版本控制。Catapult的工程目录类似，但会额外包含lib/用于库映射，以及constraints/用于时序和面积约束。Stratus则常以project/为根，内含source/、testbench/、constraint/和script/。
编译选项是控制综合结果的关键杠杆。常见选项可分为四类：
- 目标器件与时钟：
set_part、create_clock，决定资源类型和时序目标。 - 接口协议：
INTERFACE指令中的ap_none、ap_hs、axi4、axi4lite等，决定端口如何映射到总线。 - 流水与并行：
PIPELINE、UNROLL、ARRAY_PARTITION，直接影响吞吐率和资源占用。 - 综合策略：
config_schedule、config_bind、config_interface等全局配置，控制调度和绑定的激进程度。
PIPELINE的II设为1，同时又把数组完全分区，可能带来资源爆炸；而接口选择axi4后，若未正确设置突发长度，仿真通过但协同验证可能失败。每次调整选项后，都应重新运行C/RTL协同验证，而不是只看综合报告。
四、案例与复盘：一次接口选项导致的协同验证失败
某团队用Vitis HLS实现一个图像滤波模块，C仿真和综合均通过，但cosim_design报出RTL仿真结果与C结果不一致。排查后发现，源码中滤波函数使用了指针参数，综合时默认推断为ap_none接口，而测试平台按ap_hs握手方式提供数据。C仿真时指针直接访问内存，行为正确；RTL中ap_none没有握手信号，导致数据采样时刻错位。
复盘结论有三点：第一，接口指令必须与测试平台的调用方式一致，不能依赖工具默认推断；第二，协同验证不是“可选项”，而是暴露接口和时序问题的关键环节；第三，工程目录中应保留每次综合的指令快照，便于对比不同选项下的结果差异。
把工具链、脚本、目录和选项四者统一起来，HLS工程才具备可复现性和可交付性。工具只是执行者，真正决定项目成败的，是工程结构的清晰度和流程的纪律性。