第三章：C/C++代码风格与规范

写HLS代码，说白了就是写C/C++，但又不完全是。我见过太多人把PC上的软件思维直接搬过来，结果综合出来的电路要么跑不动，要么资源爆炸。这一章，咱们聊聊怎么写出「可综合」的好代码。

3.1 可综合代码风格

什么叫「可综合」？就是你的C/C++代码能老老实实被HLS工具翻译成硬件电路。不是所有C++语法都能过这一关。

可综合代码的核心原则就三条：

• 静态分配：数组大小在编译时确定，别指望运行时new
• 固定循环边界：循环次数必须是常数，别搞while(1)或者break
• 指针有限制：可以用指针，但别玩指针运算和多重间接

// ❌ 不可综合
int* ptr = (int*)malloc(1024 * sizeof(int));
for (int i = 0; i < n; i++) {  // n不是常数
    ...
}

// ✅ 可综合
int arr[1024];
for (int i = 0; i < 1024; i++) {
    ...
}

3.2 数据类型选择

数据类型选得好，资源省一半。我个人习惯用ap_int<W>和ap_uint<W>，而不是int或long long。为什么？因为你可以精确控制位宽。

我在项目中遇到过一个问题：用int存一个0~255的像素值，综合出来用了32个LUT。改成ap_uint<8>后，只用了8个。你想想看，这差距有多大。

3.3 循环与数组优化

循环是HLS优化的主战场。说白了，循环决定了你的电路是串行还是并行。

3.3.1 循环展开

用#pragma HLS UNROLL把循环展开，相当于复制多份硬件。面积换速度。

// 不展开：1个加法器，循环4次
for (int i = 0; i < 4; i++) {
    sum += a[i];
}

// 展开：4个加法器，1次完成
#pragma HLS UNROLL
for (int i = 0; i < 4; i++) {
    sum += a[i];
}

3.3.2 数组分割

数组默认存在BRAM里，只有一个读写端口。用#pragma HLS ARRAY_PARTITION把数组拆成多个小BRAM或寄存器，就能并行访问。

我曾经调试一个图像处理模块，瓶颈就在数组访问。把一个大数组按cyclic方式分成4块，吞吐量直接翻了4倍。嗯，这里要注意：分得太细会爆寄存器，得权衡。

3.4 函数内联与层次化设计

函数在HLS里会被综合成独立的硬件模块。怎么组织这些模块，决定了你的设计是否清晰、可复用。

3.4.1 函数内联

用#pragma HLS INLINE把函数内联掉，相当于把子模块的代码直接嵌入到上层。好处是减少层级、降低延迟，坏处是代码复用性变差。

// 不内联：生成独立模块
void sub_func(...) {
    ...
}

// 内联：嵌入到上层
#pragma HLS INLINE
void sub_func(...) {
    ...
}

我个人习惯：小函数（比如一个简单的乘加）直接内联，大函数（比如整个滤波模块）保持独立。这样既优化了性能，又保留了可读性。

3.4.2 层次化设计

把大功能拆成多个小函数，每个函数对应一个硬件模块。这样调试方便，也方便团队协作。

举个例子，一个图像处理流水线：

• read_input()：读数据
• process_pixel()：像素处理
• write_output()：写结果

每个函数独立综合，最后用顶层函数串起来。我曾经用这种方式重构过一个老项目，原来一个3000行的main函数，拆成10个小模块后，bug率降了70%。

本章知识体系

下面这张图，帮你理清这一章的核心逻辑：

这一章的内容，说白了就是四个字：规范第一。代码写得好，综合没烦恼。我见过太多项目因为代码风格混乱，后期优化改到崩溃。你想想看，与其花时间debug，不如一开始就养成好习惯。

嗯，这些就是我在实际项目中反复验证过的经验。照着做，你的HLS代码至少能少踩一半的坑。