FPGA在自动驾驶中的挑战与实践

在前不久的 Baidu Create 2019 百度 AI 开发者大会上，Apollo 发布了业内首创的 AVP 专用车载计算平台——百度 AVP 专用量产计算单元 ACU-Advanced。这是一篇“硬核”的技术文章。正是这些后台的“硬核”技术，成就了令人炫目的自动驾驶。本文中介绍的相关技术已经落实在 Valet Parking 产品中的量产 ACU 硬件上。

人工智能技术是自动驾驶的基础，算法、算力和数据是其三大要素。本文探讨的就是其中的“算力”。算力的高低，不仅直接影响了行驶速度的高低，还决定了有多大的信息冗余用来保障驾驶的安全。算力最直观地体现在硬件上，而汽车对自动驾驶的控制器有特殊的要求。实践中遇到的挑战是，多种多样的加速需求和有限的硬件资源的矛盾。需求的来源既包括深度学习前向推测、也包括基于规则的算法。硬件资源受限包括了：FPGA 资源受限和内存带宽受限。

算法工程师采用浮点数 float32 对模型进行训练，产出的模型参数也是浮点型的。然而在我们使用的 FPGA 中，没有专用的浮点计算单元，要实现浮点数计算，代价很大，不可行。使用 int8 计算来逼近浮点数计算，也即实现量化计算，这是需要解决的第一个问题。

在量化前，需要完成1000000次 float32 的乘法。量化成 int8 后，需要完成1000000次 int8 的乘法，和30000次量化、反量化乘法。由于量化和反量化占的比重很低，量化的收益就等于 int8 取代 float32 乘法的收益，这是非常显著的。

FPGA 片上存储非常受限，对于绝大多数的算子，不可能将输入或者输出完整缓存到片上内存中。而是从内存中一旦读取足够的数据，就开始计算。一旦计算到足够多，就立即把结果写到内存。和内存数据的流式交互是个公共的需求，我们开发了能兼顾所有算子的 DMA 的接口。

只有对于单次计算耗时很长、或调用非常频繁的独立任务算子，我们才为其定制单独 DMA 的模块，取得的收益是，这个算子可以通过多线程调度和其它 FPGA 算子并行计算。这是综合收益和代价后，做出的以资源换时间的折衷。

Int8 的计算，可以使用 DSP 或其它逻辑资源来完成。逻辑资源有更多的用途，所以我们占用 DSP 来完成 int8 的乘累加计算。FPGA 内部的 DSP48E2 可以接受 27bit 的乘数。可以把两个 int8 的乘数排列在高 8bit 和低 8bit，进行一次乘法后，再两个乘积完整的分离出来。这样，就实现了单个 DSP 一个时钟周期完成了两个乘法，达到了算力倍增的效果。

Deconv 和 conv 是网络中计算量最大的两个算子，计算资源复用收益很大。但它们计算形式上差别很大，直接复用计算资源很困难。我们在理论上进行突破，实现了通用的资源复用的方法。简言之，SDK 要对 conv 的计算参数进行扩充以兼容 deconv，在计算 deconv 时，需要对卷积核进行分拆、重排，伪装成 conv。FPGA 计算完毕后，增加少量逻辑对结果进行修饰。

ARM 计算：有些算子，比如多通道的 softmax、concat、split 等，出现频率很低，数据量不大，对整体帧率影响很小，还有些算子比如 PSRoiPooling、计算区域不确定、数据不能保证对齐，非常不适合 FPGA 加速。把这两类算子放在 ARM 上实现。在 ARM 上对计算影响最大的单个因素是缓存命中率。通过数据重排、改变遍历顺序等，提高缓存命中率，可以把表观 ARM 算力提高几十倍。

NEON 加速：采用 NEON 指令可以对多通道的 Softmax 算子有效加速，加速比虽然不及 FPGA，但相对于直接采用未优化的 C++ 的代码在 ARM 上执行，效果可以提升数倍。其它对齐的计算，大多可以通过 NEON 处理器加速数倍。

MaliGPU：我们目前使用 Xilinx ZU 系列的 FPGA，自带 MaliGPU 400，原本被设计用来显示时渲染，并不支持 CUDA、OpenCL 等常用库。经过特殊的驱动方式，我们做到可以利用它实现一些受限的逐像素算子。我们实际计算使用的硬件资源包括了 FPGA、MaliGPU、ARM 主处理器、ARM Neon 协处理器4种。通过 ARM（主处理其和协处理器）和 MaliGPU 实现对部分算子进行承接，有效缓解了 FPGA 的资源压力。

而采用动态量化，搜索量化尺度和进行量化，需要分散在相邻的两个算子中实现。为了保证精度，中间结果需要以半浮点（float16）形式表示。这带来两个问题：CPU 并不能直接对 FP16 的数据进行转换或计算，所以需要 FPGA 提供额外的算子，提供快速的 float32 / int8 和 float16 转换。这些额外的算子，是 CNN 本身不需要的，这构成了浪费。Float16 需要的缓存比 int8 大了一倍。浪费了 FPGA 的存储资源。

而静态量化，离线提供了固定的量化参数，中间计算结果以量化后的 int8 形式来表示。以上的浪费都得以避免。尽管静态量化对模型训练做额外的要求，我们最终决定切换到静态量化。通过 SDK 将各种参数进行变换和合并，单个 conv 算子可以完成最多支持4个算子的组合 conv + batchnorm + scale + relu。

静态量化降低了内存吞吐，这也是我们放弃动态量化易用性的一个原因。任务的帧率是峰值算力、各算子算力、支持的算子种类三个因素复合作用的结果。以上技术已经用到了 ACU 硬件中，把百度 Valet Parking 产品的帧率在数量级上进行了提高。接下来，我们会陆续发布更多这样的“硬核”技术文章，让更多开发者们更加细致地了解 Apollo 自动驾驶背后的技术。