FPGA多计算引擎架构优化与CNN加速实践
1. FPGA加速器设计中的多计算引擎挑战
在深度学习硬件加速领域，FPGA因其可重构特性成为实现定制化CNN加速器的理想平台。传统单计算引擎架构面临"one size does not fit all"的困境——当处理具有不同计算特性的CNN层时，固定的计算引擎设计会导致动态资源利用率低下。多计算引擎(Multiple-CE)架构通过为不同类型的CNN层配置专用计算单元，理论上可以显著提升资源利用率，但同时也引入了复杂的设计空间探索问题。
1.1 多计算引擎架构的三种范式
当前主流的多计算引擎架构主要呈现三种设计范式：
Segmented架构采用层分组策略，将CNN网络划分为若干连续层段，每个计算引擎负责处理一个完整的层段。这种架构的优势在于：
- 层间数据局部性得到充分利用
- 片上缓冲区可以跨层复用
- 适合处理具有规则计算模式的层序列
典型实现如[32,33]所示，其缓冲区管理采用"最大需求"原则——为每个CE分配足以容纳其所处理层段中最大特征图和权重块的存储空间。
SegmentedRR架构引入轮询调度机制，多个计算引擎以流水线方式循环处理网络各层。Wei等[41]的研究表明：
- 采用细粒度瓦片级流水(tile-grained pipelining)比粗粒度方案更高效
- 需要为每个CE配置独立的权重缓冲区
- 通过双缓冲技术隐藏数据传输延迟
Hybrid架构则结合了前两种方案的优点，通常包含：
- 一组专用处理引擎，每个引擎优化用于特定层类型
- 一个通用处理引擎，负责剩余层的计算
- 在专用与通用引擎间建立粗粒度流水
这种架构在ResNet等具有明显层类型区分的网络上表现优异[30]，但对缓冲区管理提出了更高要求。
1.2 设计空间探索的复杂度
多计算引擎架构的设计空间维度包括：
- 计算引擎数量与PE分配
- 并行化策略(1D/2D/3D)
- 数据流模式(权重/输入/输出驻留)
- 层到引擎的映射关系
- 流水线粒度选择
以Xilinx ZCU102平台运行ResNet50为例，表I展示了不同架构在关键指标上的权衡：
| 架构类型 | 延迟(归一化) | 片上缓冲区 | 片外访问 |
|---|---|---|---|
| SegmentedRR | 1.0 | 2.64x | 1.79x |
| Segmented | 4.7x | 1.0x | 1.99x |
| Hybrid(b) | 1.11x | 1.74x | 1.0x |
这种指标间的trade-off使得传统试错式设计方法效率低下——使用HLS工具综合评估单个设计点可能需要数小时，而完整的设计空间可能包含数百万个可行点。
2. MCCM成本模型的核心架构
MCCM模型采用模块化建模方法，将任意多计算引擎加速器分解为两种基础构件：单计算引擎块(single-CE)和流水线计算引擎块(pipelined-CEs)。这种抽象使得模型可以灵活组合各种架构变体。
2.1 模型输入与表示方法
模型接受三个核心输入：
- 加速器描述：使用简洁的符号化表示
{L1-L4:CE1}表示层1-4由CE1顺序处理{L1-L4:CE1-CE4}表示四引擎流水处理这些层
- CNN结构定义：支持DAG或Keras格式
- FPGA资源约束：包括DSP数量、内存带宽和容量
这种表示法可以精确描述图2中的三种架构。例如SegmentedRR架构可表示为{L1-Last:CE1-CE4}，而Hybrid架构则可描述为{L1-L3:CE1-CE3, L4-Last:CE4}。
2.2 分层建模方法
MCCM采用自底向上的建模策略，如图3所示：
单计算引擎模型重点解决：
- PE利用率计算：考虑层维度与引擎并行度的匹配
- 数据流模式影响：权重驻留vs输出驻留的访问模式
- 缓冲区需求估计：基于层特征图尺寸和权重分布
流水线引擎模型则额外考虑：
- 流水线气泡(Pipeline bubble)导致的CE闲置
- 流水线平衡性对吞吐量的制约
- 跨引擎数据依赖关系
两种模型的接口通过统一的性能指标(吞吐量、延迟、缓冲区需求、片外访问)进行标准化，使得它们可以灵活组合。
3. 关键性能指标的解析建模
3.1 延迟与吞吐量计算
对于单计算引擎，延迟计算遵循公式1的累加原则。考虑一个处理ResNet50 stage1的CE(包含3个卷积层)：
- 若CE配置为4×4×4的3D并行(64PEs)
- 首层输入尺寸112×112，64个3×3滤波器
- 理论峰值利用率= (64/(112×112×64))×100% ≈ 0.008%
- 实际利用率需考虑数据复用和流水线效率
流水线引擎的延迟计算(公式2)则呈现不同特征：
# 伪代码示例：四引擎流水线延迟计算 pipe_stages = determine_stages(cnn_layers) stage_latency = [max(ce_latency) for ce in active_ces] total_latency = sum(stage_latency) + pipeline_reg_overhead实测数据显示，当处理ResNet50时：
- SegmentedRR架构可实现最低延迟(比Segmented快4.7倍)
- 但需要更大的片上缓冲(2.64倍)来支持流水执行
3.2 片上缓冲区需求模型
缓冲区需求建模需考虑两种场景：
独立层处理模式（公式4）：
Buffer_{CE} = \max_{layers}(FM_{size}) + \max_{layers}(W_{tile})流水线处理模式（公式5）：
Buffer_{pipe} = \sum_{layers}(W_{size} + 2×FM_{buffer})实际部署时，MCCM采用启发式策略动态调整：
- 当剩余片上内存充足时，优先扩大权重缓冲区
- 内存紧张时，采用平铺(Tiling)策略平衡访问次数
- 对残差连接等特殊结构，预留额外缓冲区副本
3.3 片外访问优化技术
片外访问优化是提升能效的关键。MCCM支持三种数据流策略的自动选择：
输出驻留-局部输入驻留(OS-LIS)：
- 每个输入特征图元素只加载一次
- 权重需要多次加载
- 适合特征图尺寸远大于权重的层
输出驻留-局部权重驻留(OS-LWS)：
- 每个权重只加载一次
- 特征图元素需要多次加载
- 适合权重尺寸较大的层
混合策略：
- 根据层特性动态选择
- 考虑FPGA内存带宽限制
- 最小化公式6中的访问代价
在Xilinx Alveo U280上的实验表明，智能数据流选择可减少片外访问达35%。
4. 模型验证与设计空间探索
4.1 精度与效率基准测试
MCCM在多个平台上进行了严格验证：
| 评估指标 | 传统HLS | MCCM | 加速比 |
|---|---|---|---|
| 单次评估时间 | 2.5小时 | 90ms | 100,000x |
| 延迟预测误差 | - | 6.2% | - |
| 吞吐量误差 | - | 4.8% | - |
| 缓冲区需求误差 | - | 8.7% | - |
测试覆盖了ResNet/VGG/GoogleNet等五种CNN和四种FPGA平台。模型平均准确率超过90%，使其成为设计空间探索的理想工具。
4.2 典型应用场景
场景一：架构比较分析通过MCCM快速对比三种架构在ResNet50上的表现：
- SegmentedRR在延迟上最优(1.0x)
- Segmented在内存效率上最佳(1.0x缓冲区)
- Hybrid在片外访问上最优(1.0x)
场景二：瓶颈分析模型可以定位性能瓶颈的具体来源：
- PE利用率低下(如VGG16的首层仅利用12%PE)
- 流水线不平衡(最慢CE限制整体吞吐)
- 内存带宽饱和
场景三：自动设计空间探索结合遗传算法，MCCM可在数分钟内探索数百万设计点：
- 随机生成初始种群(引擎数量/并行策略/映射关系)
- MCCM快速评估适应度(延迟/吞吐/能效)
- 通过交叉变异产生新一代设计
- 迭代直至收敛
实验发现，对ResNet50在Zynq平台：
- 最优延迟设计使用5个CE，3D并行
- 最优能效设计采用3个CE，混合并行策略
- 没有单一架构在所有指标上最优
5. 工程实践中的关键考量
5.1 资源分配启发式策略
MCCM内置的智能资源分配策略包括：
PE分配原则：
- 为计算密集型层分配更多PE
- 保持各CE的PE数量为2的幂次
- 考虑DSP模块的物理布局限制
并行策略选择：
- 对早期大特征图层：采用2D空间并行
- 对后期深层：采用通道维度并行
- 1x1卷积：优选滤波器维度并行
缓冲区划分经验：
- 70-30规则：70%内存用于特征图，30%用于权重
- 对残差连接保留15%额外缓冲
- 使用BRAM的ECC功能增强可靠性
5.2 实际部署中的调优技巧
基于多个实际项目的经验总结：
冷启动问题：
- 首次加载大权重会导致延迟峰值
- 解决方案：预取+权重压缩(8bit量化可减50%加载时间)
非均匀流水线：
- 各阶段CE的时钟频率可独立调节
- 对关键路径CE适度提频(需考虑功耗)
动态重配置：
- 利用FPGA部分重配置特性
- 运行时切换CE功能(需额外5-10%逻辑开销)
混合精度策略：
- 首尾层保持16bit精度
- 中间层可采用8bit计算
- 需要相应调整PE数据路径
5.3 常见问题排查指南
问题1：吞吐量不达预期
- 检查：使用MCCM的瓶颈分析功能
- 可能原因：流水线不平衡/内存带宽饱和
- 解决方案：重分配PE/优化数据流策略
问题2：资源利用率低下
- 检查：各CE的PE利用率报告
- 可能原因：层维度与并行策略不匹配
- 解决方案：调整并行维度或层映射
问题3：片上内存不足
- 检查：MCCM的缓冲区分析
- 可能原因：特征图平铺策略不当
- 解决方案：采用更激进的平铺因子或压缩
在Xilinx VCU1525平台上的实测数据显示，经过MCCM指导优化的设计可比基线方案提升1.8倍能效比。