3. 流水线设计与并行计算
各位同学，今天我们来聊聊FPGA加速的核心——流水线与并行计算。说实话，很多做图像处理的软件工程师刚接触FPGA时，最困惑的就是：为什么同样的算法，在FPGA上能跑得那么快？答案就藏在这两个概念里。
3.1 流水线原理：从工厂流水线说起
想象一下汽车装配线。如果一辆车全部装好才下线，效率极低。但分成焊接、喷漆、总装等工位，每个工位只干一件事，车流就源源不断了。FPGA的流水线也是这个道理。
在数字电路里，流水线就是把一个组合逻辑大任务，切成若干小段，每段之间插入寄存器。数据像接力棒一样，一拍一拍往下传。
关键指标：吞吐率 vs 延迟
流水线不减少单次任务的延迟，但极大提升吞吐率。我做过一个边缘检测项目，没加流水线时，一帧图像要等所有像素算完才能输出下一帧；加了三级流水线后，每时钟周期都能出一个结果，帧率直接翻了3倍。
举个例子，一个简单的加法链：A + B + C + D。如果不做流水线，需要三级加法器串行，路径延迟很大，时钟频率上不去。如果插入两级寄存器：
// 非流水线
assign result = a + b + c + d; // 路径太长
// 两级流水线
reg [7:0] sum1, sum2;
always @(posedge clk) begin
sum1 <= a + b; // 第一级
sum2 <= sum1 + c; // 第二级
end
assign result = sum2 + d; // 第三级嗯，这里要注意：流水线级数不是越多越好。每加一级寄存器，延迟增加一个时钟周期，资源也多一点。我一般建议，在满足时序的前提下，级数越少越好。
3.2 FPGA的并行优势：天生的多核战士
CPU是串行执行的，一个时钟周期只能处理一条指令。GPU虽然有上千个核心，但受限于SIMT架构，同一时刻所有核心必须执行相同指令。FPGA呢？它没有指令的概念，每个LUT、每个DSP都是独立的硬件资源。
说白了，FPGA的并行是真正的、无条件的并行。你可以同时做1000个8x8的乘法，只要资源够。这在图像处理中太有用了——一个3x3的卷积核，9个乘法器可以同时工作，一个时钟周期就出结果。
| 架构 | 并行粒度 | 典型时钟频率 | 适合场景 |
|---|---|---|---|
| CPU | 指令级（ILP） | 3-5 GHz | 控制密集、分支多 |
| GPU | 线程级（SIMT） | 1-2 GHz | 数据并行、计算密集 |
| FPGA | 门级/算子级 | 100-500 MHz | 流水线、低延迟、定制化 |
为什么FPGA频率低反而快？因为它的并行度是CPU的几十上百倍。我曾经把一个Sobel边缘检测算法从CPU移植到FPGA，CPU跑30fps，FPGA只用了不到10%的资源就跑到了60fps。频率只有150MHz，但每个像素的处理时间从几十纳秒降到了几个纳秒。
我的经验：评估并行度时，先看数据依赖性。图像处理中，大多数操作是像素独立的（点运算、卷积），天然适合并行。但像直方图统计、排序这类有全局依赖的操作，并行起来就麻烦些。
3.3 Systolic Array架构简介
Systolic Array（脉动阵列）这个名字听起来很玄乎，其实原理很简单：一组处理单元（PE）像心跳一样，有节奏地接收数据、计算结果、传递数据。每个PE只做简单的乘加运算，数据在阵列中流动，最终汇聚出结果。
为什么叫“脉动”？因为数据像血液一样，在时钟的驱动下，一拍一拍地向前推进。这种架构特别适合矩阵乘法、卷积运算——而这些正是图像处理和神经网络的核心。
下面这张图展示了一个3x3的Systolic Array，用于矩阵乘法：
你看，每个PE只和相邻的PE通信，没有全局连线。这意味着什么？布局布线非常规整，时序容易收敛。我在做卷积神经网络加速器时，就用了类似的结构，把3x3卷积映射到9个PE上，数据从左边和上边流入，结果从右下角流出，一气呵成。
避坑指南：我曾经在做一个8x8的Systolic Array时，忽略了数据对齐问题。矩阵乘法要求数据按特定顺序流入，如果输入顺序错了，结果全乱套。一定要先画好数据流时序图，再动手写代码。
3.4 时序约束基础
流水线和并行设计搞定了，但能不能跑起来，还得看时序约束。说白了，时序约束就是告诉工具：我的电路要在多快的时钟下工作，哪些路径是关键路径。
最基本的约束是时钟周期约束：
# 创建时钟，周期10ns，对应100MHz
create_clock -name clk -period 10.000 [get_ports clk]
# 输入延迟约束
set_input_delay -clock clk -max 5.000 [get_ports data_in]
set_input_delay -clock clk -min 2.000 [get_ports data_in]
# 输出延迟约束
set_output_delay -clock clk -max 6.000 [get_ports data_out]
set_output_delay -clock clk -min 1.000 [get_ports data_out]嗯，这里要注意：输入输出延迟的值怎么定？我一般看数据手册，或者根据上下游芯片的时序参数算。如果设得太紧，工具会疯狂优化，导致面积增大、功耗上升；设得太松，又可能跑不到目标频率。
时序分析的核心是检查建立时间和保持时间：
- 建立时间（Setup Time）：数据必须在时钟沿到来前稳定。如果路径太长，数据来不及到达，就违例了。
- 保持时间（Hold Time）：数据必须在时钟沿到来后保持稳定。如果路径太短，数据变化太快，也会违例。
流水线设计对时序有什么影响？你想想看，每加一级流水线，就把长路径切短了。原本一个时钟周期要算完10级逻辑，现在分成3级，每级只算3-4级逻辑，路径延迟大大降低，建立时间自然容易满足。
我的习惯：写完RTL后，先跑一遍综合，看时序报告。如果setup违例，优先考虑加流水线；如果hold违例，可能是时钟偏斜或路径太短，加个buffer就能解决。千万别一上来就调约束，先看代码结构合不合理。
最后分享一个经验：做图像处理加速时，我通常把流水线级数控制在3-5级。太少了时序紧张，太多了延迟增加、资源浪费。比如一个5x5的高斯滤波，我分成：行缓冲读取（1级）、乘法累加（2级）、归一化（1级）、输出（1级），总共5级流水线，200MHz稳稳的。