1. Agilex平台与算法加速概览

在讨论“如何用FPGA做算法加速”之前，需要先建立一张清晰的地图：Agilex到底包含哪些器件、它们各自适合什么场景、算法加速在整条计算链路中处于什么位置，以及我们最终用什么维度来判断“加速是否成功”。本章不涉及具体代码，但会为后续所有章节提供统一的术语、参照系和评估框架。

1.1 Agilex器件家族：从FPGA到SoC FPGA

Agilex是Intel（现Altera）面向10nm及以下工艺节点推出的高端FPGA产品线，其内部并非单一型号，而是按性能、功耗、集成度和应用场景划分为多个系列。理解这些系列的差异，是选择加速平台的第一步。

Agilex F系列（F-Series）强调通用逻辑密度与DSP资源，适合需要大量并行乘加运算的信号处理、图像处理和金融计算。Agilex I系列（I-Series）在F系列基础上强化了收发器速率和接口带宽，面向400G/800G通信、数据中心互连等对I/O吞吐要求极高的场景。Agilex M系列（M-Series）则把重点放在存储带宽与片上存储容量上，适合高带宽存储、数据库加速和内存计算类任务。此外，Agilex还提供集成ARM硬核处理器的SoC FPGA版本，即Agilex SoC，它在同一芯片内同时包含FPGA可编程逻辑和处理器子系统（HPS），使得“控制流跑在ARM上、数据流跑在FPGA上”的异构模式成为可能。

从加速视角看，选择器件的核心依据不是“哪个系列更新”，而是三个问题：算法需要多少并行度？数据从哪里来、到哪里去？控制逻辑有多复杂？如果算法以规则并行乘加为主、数据流稳定，F系列往往足够；如果瓶颈在接口带宽，I系列更合适；如果瓶颈在片上存储访问，M系列更值得考虑；如果算法需要操作系统、网络协议栈或复杂分支控制，SoC版本能显著降低系统复杂度。

1.2 异构计算架构：CPU、FPGA与数据通路的分工

Agilex SoC的典型异构架构可以概括为“ARM负责控制，FPGA负责计算，DDR与高速接口负责搬运”。ARM硬核运行Linux或RTOS，负责任务调度、参数配置、结果汇总和对外通信；FPGA逻辑实现算法流水线，以固定或可变并行度持续处理数据；DDR控制器和收发器则保证数据能以足够带宽进出芯片。

这种分工的关键在于“谁适合做什么”。CPU擅长分支密集、串行依赖强的控制逻辑，但并行乘加能力有限；FPGA擅长把规则计算展开成空间并行的流水线，但实现复杂控制状态机代价较高。因此，一个典型的加速系统不会让FPGA“什么都做”，而是让CPU把算法中计算密集、数据并行度高的部分卸载到FPGA，CPU只保留调度和边界处理。

下面这张图展示了Agilex SoC异构加速的典型数据流与控制流关系。图中区分了控制路径（ARM配置FPGA加速器）和数据路径（DDR/接口→加速器→DDR/接口），并标出了性能评估时最值得关注的几个观察点。

1.3 边缘与数据中心：两种截然不同的加速定位

同样是Agilex，放在边缘和放在数据中心，设计目标几乎相反。边缘场景强调低延迟、低功耗、小体积和确定性响应。例如工业视觉检测中，相机以固定帧率输出图像，系统必须在几十毫秒内完成缺陷判断并触发执行机构。此时FPGA的价值在于把预处理、特征提取和分类推理全部流水线化，避免数据在CPU和内存之间反复搬运。功耗预算可能只有几瓦到十几瓦，散热条件有限，因此资源利用率不能盲目追求“用满”，而要留出功耗和时序余量。

数据中心场景则强调高吞吐、可扩展和虚拟化。例如推荐系统或数据库加速，FPGA通常以PCIe加速卡形式存在，主机CPU通过PCIe下发任务，FPGA在片内完成批量计算后回传结果。此时单次延迟不是首要指标，每秒能处理多少查询、多少样本才是关键。设计上更关注DDR带宽是否饱和、PCIe传输是否成为瓶颈、多个加速实例能否并行调度。

这两种定位直接决定了后续性能评估的侧重点：边缘看“最坏情况延迟”和“功耗上限”，数据中心看“持续吞吐”和“资源复用率”。在阅读后续章节时，建议始终先问一句：这个设计面向边缘还是数据中心？

1.4 性能评估的基本维度

性能评估不是简单地跑一个测试然后看数字。对FPGA算法加速而言，至少需要同时观察四个维度，并且明确它们之间的制约关系。

吞吐量（Throughput）：单位时间内完成的运算量或处理的数据量，常用样本/秒、帧/秒、GOPS表示。它取决于并行度、时钟频率和流水线是否连续。提高并行度通常能提升吞吐，但会消耗更多DSP和逻辑资源。

延迟（Latency）：从输入数据进入到对应输出结果产生的端到端时间。流水线设计可以做到每个时钟周期出一个结果，但单个结果从输入到输出仍可能经历数十到数百个周期。边缘控制场景对延迟敏感，必须关注最坏情况而非平均值。

资源占用（Resource Utilization）：DSP、BRAM、ALM和布线资源的利用率。资源占用不是越低越好，而是要与目标吞吐和功耗匹配。一个只用了30% DSP但吞吐不达标的设计，和用了90% DSP但时序无法收敛的设计，同样需要返工。

能效（Energy Efficiency）：性能与功耗的比值，常用GOPS/W表示。边缘设备尤其看重这一项，因为它直接决定散热方案和电池寿命。降低时钟频率、减少无效翻转、使用低精度数据类型，都是提升能效的常见手段。

这四个维度之间存在明确的权衡关系。例如，把并行度从8提高到16，吞吐可能接近翻倍，但DSP占用翻倍、功耗上升、时序收敛难度增加；把数据位宽从16位降到8位，能效和资源占用都会改善，但精度可能不再满足要求。因此，性能评估的最终目的不是追求某一个维度的极值，而是在给定约束下找到可接受的平衡点。

1.5 本章小结与统一参照系

本章建立了三个后续反复使用的参照系。第一，器件选择参照系：F系列重逻辑与DSP，I系列重接口带宽，M系列重存储带宽，SoC版本重控制与计算的分工。第二，场景参照系：边缘看延迟与能效，数据中心看吞吐与扩展性。第三，评估参照系：吞吐、延迟、资源、能效四维联动，加速比必须基于明确的基准和输入条件。