1. 内联（Inline）：打破物理边界的利器与代价 既然 HLS 把子函数当黑盒，这就带来一个问题：它无法做全局优化。 比如，如果在小黑盒的末尾有一个乘法，在大黑盒里拿到结果后马上跟了一个加法。因为有函数边界的阻挡，HLS 可能会强行在这两个操作中间插入寄存器（断开操作链接）。

这时候，inline（内联指令） 就派上用场了。 如图 2.11 所示，一旦你在子函数上加了 inline：

HLS 会直接抹除函数的物理边界。

所有的子逻辑全部暴露给顶层，融合成一坨巨大的组合逻辑。

好处： HLS 获得了“上帝视角”，它可以跨界进行资源共享和操作链接（Operation Chaining），从而缩短延迟（Latency），省下一些边界上的寄存器。

坏处与警告： 就像之前提到的“循环完全展开”一样，如果你的顶层逻辑极度复杂，你还把所有子模块都 inline 进来，这会生成一个无比庞大的数据流图。Vivado HLS 会被这海量的约束关系搞得内存溢出、耗费几个小时都综合不出来，甚至导致布线失败。

一句话总结： 层次化结构（不内联）是帮 EDA 工具减负，让代码结构模块化，但可能损失一点点跨界优化的性能；内联（Inline）是帮硬件提速，让逻辑融会贯通，但极容易让综合工具崩溃。合理的架构设计，就是在两者之间找平衡。

static 意味着这是必须保存状态的物理寄存器（D触发器）。你需要 4 个独立的滤波器同时运行，就必须在芯片上分配 4 套完全不同的物理寄存器。写 4 个不同的函数名，就是强迫 HLS 去生成 4 个独立的物理黑盒子。（注：在现代 HLS C++ 开发中，我们通常用面向对象的 Class/Template 或 HLS Allocation 指令来优雅地解决这个问题，而不需要傻傻地复制 4 遍代码）。

它是一个由 Xilinx 提供、专为硬件综合定制的 C++ 第三方类库。如果你试图脱离 Vivado HLS 环境，用纯 GCC 或 Clang 编译器去编译这段代码且不指定 Xilinx 头文件的路径，编译器是会报错找不到 ap_int 定义的。

虽然它是 Vivado HLS 专有的，但它完全符合 C++ 的语法规范。 实际上，ap_int 和 ap_uint 是 Xilinx 工程师用 C++ 写好的 模板类（Template Classes）。

当你 #include "ap_int.h" 时，你实际上引入了一大堆 C++ 的类定义。

这些类内部使用了 C++ 运算符重载（Operator Overloading） 技术，重载了 +、-、*、>>、== 等所有常用运算符。

这就使得你在写代码时，操作 ap_uint<12> a; 感觉就像在操作一个普通的 int 一样自然，但底层其实是在调用 Xilinx 写好的类方法进行位运算。

在第 44 个时钟周期结束那一瞬间，最终的累加结果 acc 已经被成功写入了寄存器。至于第 45 个周期硬件还在那里傻傻地检查退出条件、清理状态机，这些动作对下游接收数据的模块来说毫无意义。 因为在第 44 拍末尾，结果已经有效（Valid）了。所以，HLS 的报告会减去最后那个无效等待周期，告诉你：“下游模块在第 44 个周期就能拿走数据了”。

对于微小循环（Micro-loops），尽情使用“完全展开”来榨干延迟；但对于大循环（Macro-loops），必须老老实实使用带有特定因子的“部分展开（Partial Unroll）”再配合“流水线（Pipeline）”，这才是寻找最佳性价比硬件架构的核心能力。

硬件上会表现为全1（-1的补码），读出来的数可能全是XXX

操作链接（Operation Chaining）是指在硬件电路中，将多个“组合逻辑（Combinational Logic）”首尾相连，中间不插入任何寄存器（Register/FF），从而让这些串联的计算在“同一个时钟周期内”一口气完成的综合技术。

加上标签，可以在TCL和GUI中实现更明确的定位，如果不手动写标签，就会被HLS工具自动赋值，导致混乱和意义不明：

在 Tcl 脚本中精准，定位你可以直接在配套的 directives.tcl 文件里写：

set_directive_unroll "fir/Shift_Accum_Loop"

set_directive_pipeline -II 1 "fir/Shift_Accum_Loop"

输出端口 赋值参数值

也可以改成data_t &y 使用“引用”的方式接收参数

但是不能使用以下情况：

多级指针（ptr）：硬件很难解析运行时的多级地址跳转。

动态指针（malloc/free）：FPGA 的硬件资源（寄存器、连线）在编译（综合）时就必须固定下来，不可能在电路运行期间“动态生成”新的物理内存。

指针的随意转型（Casting）：例如将 float * 强转为 int *，这会导致硬件总线位宽和内存对齐出现混乱。

只读输入引脚

例如，资源DSP本身数量有限，用户给出使用DSP使用数量的限制，HLS工具就会在此限制下获得RTL硬件结构

例如BRAM，一个时钟周期至多同时读写两个数，一旦超过2个数，就会受到资源的限制，无法展开循环，流水线并行

即数据依赖。例如求和累加，只有在当前运算数累加完成并反馈之后，才能计算下一个数，在顺序话结构中数据依赖不会影响数据效率，因为其本身就是一个一个实现的，而在流水线并行结构下，这种数据依赖的关系就很难实现了

为了优先保证HLS的C代码可以转化成硬件，会以牺牲并行化结构为代价，用顺序化的状态机实现逻辑功能。这保证了功能实现的下限，无论怎样复杂的结构，都能实现。而加入HLS pipeline这样类似的指令后，可以通知HLS尽可能利用流水线和并行化，即函数流水，但不能保证所有代码都能被设计为并行结构

双文件结构。这里是main.c，用于测试输入输出是否正确，不会综合成硬件代码；fir.c中才会包含fir的具体实现

传统CPU： 固定的5级流水线（取指、译码、执行、访存、写回）。无论什么程序，都要硬塞进这个固定的物理结构中。

Vivado HLS： 它生成的是定制化电路。它可以根据你的C/C++代码逻辑，自由决定流水线的级数、并行展开的程度、以及各个计算单元之间的连线。它可以做到“因地制宜”。

吞吐量 = 工作频率 / 任务间隔(II)

HLS工具通过分析数据从输入到输出的最长路径（关键路径），并在中间插入寄存器（Registers）来打拍（切割时序）。插入的寄存器层数，决定了任务延迟的周期数。 “0周期任务延迟”： 意味着输入和输出之间没有任何寄存器，纯粹由组合逻辑（Combinational Logic）构成。信号像水流一样在一个周期内直接从输入端流到输出端。

完整BRAM为36K，可配置为32K1，16K2，8K4，4K9，2K18，1K36，512*72。位宽大于4bit时，需要额外的校验位，8bit需要1位校验位，16bit需要2位校验位，以此类推

加入固化的加法器结构减弱了slice的可编程性（灵活性），但在更多情况下，减少了由LUT组成加法器的消耗，提升了效率