FPGA加速基础概念：并行计算与流水线设计原理

说实话，很多刚接触FPGA加速的朋友，第一反应都是：“这玩意儿到底比CPU快在哪？”

我当年刚入行时也这么想。直到我在一个图像处理项目里，用CPU跑一个3x3的卷积核，一帧1080p图像要算几十毫秒。换成FPGA之后，延迟直接掉到微秒级。差别在哪？说白了，就是并行计算和流水线设计这两个基本功。

并行计算：FPGA的“人多力量大”

CPU是顺序执行的。一个四核CPU，最多同时跑四个线程。但FPGA不一样——你可以把成千上万个逻辑单元同时派上用场。

举个例子。你要对1024个数据做加法。CPU得循环1024次，每次加一个。FPGA呢？你可以例化1024个加法器，一个时钟周期全算完。

当然，实际项目里不会这么极端。资源是有限的。我一般会先算一下并行度和资源消耗的平衡点。比如在Zynq上，LUT和DSP slice就那么些，你得精打细算。

流水线设计：让每个时钟都不闲着

并行计算是“同时干多件事”。流水线是“把一件事拆成多段，每段同时干”。

我习惯用洗车来比喻。一辆车洗一遍要四步：冲水→打泡沫→擦洗→烘干。如果一次只洗一辆，后面车就得干等。但如果你把洗车房分成四个工位，每辆车在每个工位只待一步的时间——第一辆车在烘干时，第二辆在擦洗，第三辆在打泡沫，第四辆在冲水。吞吐量瞬间翻四倍。

FPGA里的流水线也是这个道理。一个复杂的计算路径，拆成多个寄存器级，每级只算一小部分。这样虽然单次计算的延迟没变（甚至略增），但吞吐量大幅提升。

FPGA加速的适用场景分析

不是所有算法都适合FPGA加速。我踩过不少坑，总结下来，适合的场景有三个特征：

• 数据并行度高：比如像素点之间没有依赖，可以同时算。
• 计算模式固定：不需要频繁分支跳转，流水线能稳定跑。
• 延迟敏感：比如雷达信号处理，几微秒的延迟都受不了。

具体到三类典型应用：

应用领域	典型算法	为什么适合FPGA	我在项目中遇到的坑
矩阵运算	矩阵乘法、SVD、FFT	数据流规整，可深度流水	矩阵维度不是2的幂时，边界处理容易出bug
信号处理	FIR滤波、CORDIC、数字下变频	乘加操作密集，DSP slice正好用上	滤波器系数量化精度不够，输出噪声变大
图像处理	卷积、直方图均衡、边缘检测	像素级并行，行缓存结构成熟	行缓存深度没算对，图像边缘出现撕裂

加速比与性能评估模型

做FPGA加速，最终要回答一个问题：到底快了多少？

最常用的指标是加速比：

加速比 = 原始执行时间 / FPGA执行时间

但光看这个不够。我一般会从三个维度评估：

1. 吞吐量：单位时间内处理多少数据。比如多少帧/秒，多少MB/s。
2. 延迟：从输入到输出，单个数据花了多久。注意，流水线虽然提高了吞吐，但延迟可能没变。
3. 资源效率：每用掉一个LUT或DSP，换来了多少性能。这个在Zynq上特别重要，因为PS和PL共享资源。

我习惯用Roofline模型来评估。简单说，就是看你的算法是计算受限还是带宽受限。

• 如果计算强度高（比如大量乘加），瓶颈在DSP slice数量。
• 如果计算强度低（比如简单拷贝），瓶颈在DDR带宽。

在Zynq上，PL和PS之间的带宽是有限的。我曾经有个项目，算法在PL里算得飞快，结果数据从DDR搬进搬出花了90%的时间。加速比只有1.2倍，白忙一场。

知识结构图：FPGA加速核心逻辑

下面这张图总结了本章的核心脉络。你可以看到，并行计算和流水线是基础，适用场景是判断依据，加速比模型是评估手段。三者缺一不可。

嗯，这张图把本章的核心逻辑串起来了。你从并行和流水线入手，再对照适用场景判断要不要做，最后用加速比模型验证效果。每一步都有据可依。