基于PYNQ-Z2的YOLOv2 FPGA硬件加速实战：Vivado HLS与Jupyter Notebook全流程

1. 项目缘起与整体设计思路

1.1 为什么要在PYNQ-Z2上折腾YOLOv2硬件加速

YOLOv2 作为一个经典的单阶段目标检测网络，在 2017 年提出来的时候，主打的就是“快”。它把检测问题直接建模成回归问题，一次前向传播就能输出所有目标的边界框和类别，不像两阶段检测那样需要单独的区域建议网络。这个特性让它在嵌入式端特别有吸引力——因为嵌入式场景最怕的就是延迟不可控。

但问题也很直接：YOLOv2 的骨干网络是 Darknet-19，19 层卷积加若干池化，参数量大概 5000 万级别，浮点运算量在几十 GFLOPs 量级。如果直接在 PYNQ-Z2 的 ARM Cortex-A9 上跑纯软件推理，一帧 416×416 的图，几秒甚至十几秒才能出结果，完全没法用。

所以思路就变成了：把计算最密集的卷积层丢给 FPGA 做硬件加速，ARM 只负责调度、预处理和后处理。PYNQ-Z2 这块板子恰好适合干这个事——Zynq-7020 芯片里有 220 个 DSP48E1 切片、4.9Mb BRAM、以及 85K 逻辑单元，虽然不算富裕，但跑一个精简版 YOLOv2 的卷积加速是够用的。更重要的是 PYNQ 框架把 Jupyter Notebook 直接搬到了板子上，你可以在浏览器里写 Python 调用 FPGA 的 overlay，调试效率比传统 Vivado SDK 那种“编译-下载-看串口”的循环高太多了。

这个项目的核心目标就是：用 Vivado HLS 把 YOLOv2 的卷积层综合成硬件 IP，通过 PYNQ overlay 加载到 FPGA 上，然后在 Jupyter Notebook 里用 Python 完成从图像输入到检测结果输出的完整流程。适合有数字电路基础、想入门 FPGA 加速的开发者，也适合做嵌入式 AI 部署的工程师参考。

1.2 整体架构怎么切分软硬件

软硬件划分是这个项目最关键的设计决策。我当时的划分原则很简单：计算密集且规则的部分给 FPGA，控制密集且不规则的部分留给 ARM。

具体来说，YOLOv2 的计算量分布大概是这样的：卷积层占了 99% 以上的乘加运算，池化层和 BN 层计算量小但访存频繁，而最后的区域解码、非极大值抑制（NMS）这些后处理逻辑复杂、分支多，不适合硬件流水线。

所以最终的架构是：

• PL 端（FPGA）：负责卷积层、BN 融合后的乘加、LeakyReLU 激活、最大池化。这些操作数据流规整，可以做成流水线。
• PS 端（ARM）：负责图像预处理（缩放、归一化）、层间调度、内存管理、后处理（解码边界框、NMS、绘制结果）。

数据交互通过 AXI4 总线。权重和特征图放在 DDR 里，PL 通过 AXI Master 接口读取。PYNQ 框架提供了pynq.Overlay和allocate这样的 API，让你在 Python 里直接操作物理内存和寄存器，不用写内核驱动。

这里有个经验：不要把所有权重都塞进 BRAM。YOLOv2 的权重加起来好几兆字节，Zynq-7020 的 BRAM 总共才 4.9Mb，根本放不下。我的做法是权重放 DDR，PL 每次计算时按需读取，用 AXI 的突发传输来掩盖延迟。特征图同理，中间层的 feature map 也放 DDR，只有当前计算需要的那一小块 tile 缓存在片上 BRAM 里。

1.3 为什么选 Vivado HLS 而不是手写 RTL

这个问题我被问过很多次。手写 Verilog 当然能榨出更高的性能，但代价是开发周期长、调试困难、参数化困难。YOLOv2 有 19 层卷积，每层的通道数、卷积核大小、步长都不一样，如果手写 RTL，光是写状态机就能把人逼疯。

Vivado HLS 的优势在于：你用 C/C++ 描述算法，加 pragma 指导综合，工具自动帮你生成流水线、展开循环、分配 BRAM 和 DSP。对于卷积这种规则计算，HLS 的综合质量已经相当不错了。而且改参数特别方便——比如想把并行度从 8 改成 16，改个宏定义重新综合就行，不用重写代码。

当然 HLS 也有坑，后面会详细说。但总体而言，对于这个项目的复杂度，HLS 是性价比最高的选择。

1.4 Jupyter Notebook 在其中的角色

PYNQ 最大的创新就是把 Jupyter Notebook 跑在了板子上。你不需要在 PC 上装一堆交叉编译工具链，直接在浏览器里访问板子的 IP，就能写 Python 代码、调用 FPGA overlay、看中间结果。

这对调试太重要了。传统 FPGA 开发，你想看个中间特征图的值，得先存到 DDR，再通过串口或者以太网传出来，麻烦得要命。而在 Jupyter 里，overlay 的输入输出都是 numpy array，你可以直接plt.imshow()看特征图，或者打印数值分布。调试效率至少提升三倍。

而且 Notebook 天然适合做实验记录。每一层的输出、每一组参数的效果，都可以留在 cell 里，方便对比。我整个项目做下来，Notebook 里积累了上百个 cell，后来整理成了一套完整的推理流程。

2. 核心细节解析与实操要点

2.1 YOLOv2 网络结构的硬件友好化改造

原版 YOLOv2 有一些对硬件不太友好的设计，直接搬上去会很难受。我在动手之前先做了几处改造：

第一，BN 层融合进卷积。训练时 BN 是独立的一层，但推理时 BN 就是个线性变换，完全可以把它和前面的卷积权重合并。具体做法是：对于卷积输出y = W*x + b，BN 做的是y' = gamma * (y - mean) / sqrt(var + eps) + beta，把这两个式子合并，得到新的权重W' = W * gamma / sqrt(var + eps)，新的偏置b' = (b - mean) * gamma / sqrt(var + eps) + beta。这样推理时就只剩卷积加激活，省掉了一整层的计算和访存。

第二，LeakyReLU 用硬件实现。LeakyReLU 是x > 0 ? x : 0.1*x，这个在硬件里很好做——判断符号位，如果是负数就乘以 0.1。0.1 可以近似成1/8 + 1/16 + 1/128这种移位相加，避免用乘法器。

第三，池化层用最大池化。YOLOv2 用的是 2×2 步长 2 的最大池化，这个在硬件里就是比较四个数取最大，非常简单。但要注意池化后的数据要重新排列，因为硬件流水线是按行输出的，池化需要跨行比较，得加个行缓冲。

第四，去掉最后的 region 层。原版 YOLOv2 最后有个 region 层做解码，这个逻辑太复杂，不适合硬件。我把它挪到 PS 端用 Python 做，PL 只输出原始的特征图。

改造后的网络结构大概是：19 个卷积层（BN 已融合），5 个最大池化层，最后输出 13×13×425 的特征图（对应 13×13 个网格，每个网格 5 个 anchor，每个 anchor 25 个值：4 个坐标 + 1 个置信度 + 20 个类别概率）。

2.2 Vivado HLS 卷积 IP 的设计要点

卷积 IP 是整个项目的核心，我花了最多时间在这上面。设计目标是在 150MHz 时钟下，单层卷积的吞吐率尽量高，同时资源占用不超过 Zynq-7020 的预算。

并行度设计。卷积的并行有三个维度可以展开：输出通道并行、输出像素并行、输入通道并行。我最终选的是输出通道 8 并行、输入通道 8 并行、输出像素 1 个。为什么这么选？因为 Zynq-7020 有 220 个 DSP，每个 DSP 做一次乘加。如果输出通道 8 并行、输入通道 8 并行，那就是 64 个乘法器同时工作，占 64 个 DSP，留出余量给其他逻辑。输出像素如果也并行，DSP 就不够用了。

数据复用。卷积最大的优化空间在数据复用。一个 3×3 的卷积核，在滑动过程中，相邻输出像素会共享大量输入数据。我在 HLS 里用了 line buffer 来缓存输入行，这样每个输入像素只需要从 DDR 读一次，就能被多个输出像素复用。权重则缓存在 BRAM 里，因为权重在不同输出像素间是完全复用的。

流水线设计。HLS 的#pragma HLS PIPELINE是关键。我把内层的输入通道循环做了 pipeline，II（Initiation Interval）设成 1，意味着每个时钟周期都能启动一次乘加。但要注意，pipeline 的深度不能太深，否则 BRAM 的读写冲突会导致 II 达不到 1。我实测下来，输入通道循环 pipeline 后，配合 line buffer，II 能稳定在 1。

定点数量化。浮点运算在 FPGA 上太奢侈了。我把所有数据都量化成 16 位定点：8 位整数 + 8 位小数。为什么是 16 位而不是 8 位？因为 8 位定点在 YOLOv2 上精度损失太大，mAP 会掉十几个点。16 位定点实测下来，mAP 只掉 1-2 个点，完全可以接受。量化的时候要注意，权重的动态范围比激活值大，所以权重用 8 位整数 + 8 位小数，激活值用 4 位整数 + 12 位小数，这样能更好地利用位宽。

2.3 PYNQ overlay 的封装与 Python 接口设计

HLS 综合出来的 IP 不能直接给 Python 用，需要包装成一个 PYNQ overlay。这个过程在 Vivado 里完成：把 HLS IP 加到 Block Design 里，连上 Zynq PS 的 AXI 接口，分配地址，然后生成 bitstream 和 hwh 文件。

地址分配要注意。每个 IP 的寄存器空间要分配独立的地址段，避免冲突。我一般给每个卷积 IP 分配 64KB 的地址空间，足够放控制寄存器和少量缓存。权重和特征图的 DDR 地址则通过 AXI Master 接口访问，需要在 Python 里用pynq.allocate分配连续物理内存。

Python 接口设计。PYNQ 的 overlay 加载后，每个 IP 会暴露成 Python 对象，你可以直接读写它的寄存器。我封装了一个ConvLayer类，把寄存器操作、DMA 传输、同步等待都包进去，上层只需要调用conv_layer.forward(input_array)就行。这样 Notebook 里的代码就很干净。

DMA 的使用。大数据传输一定要用 DMA，不要用 MMIO 逐字读写。PYNQ 提供了pynq.lib.dma.DMA类，可以配置传输方向和长度。我实测下来，DMA 传输 1MB 数据大概几十微秒，而 MMIO 逐字读写要几毫秒，差了两个数量级。

2.4 Jupyter Notebook 环境配置与常见坑

PYNQ-Z2 出厂自带的 PYNQ 镜像里就有 Jupyter Notebook，但版本可能比较老。我建议刷最新的 PYNQ 2.7 或 3.0 镜像，Python 版本和库都更新一些。

Jupyter Notebook 打不开怎么办？这是最常见的问题。首先确认板子的 IP 地址，PYNQ 默认是 192.168.2.99，如果你的 PC 不在同一网段，肯定打不开。把 PC 的网卡设成 192.168.2.1，子网掩码 255.255.255.0，然后用网线直连板子。如果还是打不开，检查板子的 ETH 灯是否亮，或者用串口连上去看启动日志。

Jupyter Notebook 单元格执行代码没有任何反应？这个通常是内核挂了。PYNQ 的 Jupyter 内核如果加载了有问题的 overlay，可能会崩溃。解决办法是重启内核（菜单里 Kernel -> Restart），或者重启板子。如果频繁出现，检查你的 overlay 是不是资源超了，或者 DMA 传输越界了。

运行 Jupyter Notebook 出现 ImportError: DLL load failed while importing rpds？这个错误一般出现在 Windows 上装 Jupyter 的时候，是rpds-py这个包的 C 扩展没编译好。解决办法是装预编译的 wheel：pip install --only-binary :all: rpds-py。如果还不行，装个 Visual C++ Redistributable 试试。

Jupyter Notebook 代码自动补齐怎么配？默认的 Jupyter 没有自动补齐，可以装jupyter-contrib-nbextensions，然后启用Hinterland扩展。或者用jupyterlab，它自带 LSP 支持，补齐体验更好。

Jupyter Notebook 怎么生成 markdown 目录语法？在 markdown cell 里用[TOC]就行，Jupyter 会自动根据标题生成目录。但要注意，这个只在 notebook 渲染时有效，导出成 HTML 后可能失效。

3. 实操过程与核心环节实现

3.1 开发环境搭建与工程创建

先说环境。我用的工具链是 Vivado 2019.1 + Vivado HLS 2019.1 + PYNQ 2.7 镜像。为什么用 2019.1 而不是更新的版本？因为 PYNQ 2.7 的 overlay 和 2019.1 的 bitstream 兼容性最好，用 2020 以后的版本可能会遇到 hwh 文件格式不匹配的问题。

第一步，创建 Vivado HLS 工程。打开 Vivado HLS，新建工程，选 Zynq-7020 对应的器件xc7z020clg400-1。时钟周期设 6.67ns，对应 150MHz。这个频率是权衡后的结果——再高的话时序很难收敛，再低的话性能不够。

第二步，写卷积的 C++ 代码。核心函数签名是这样的：

void conv_layer( data_t* input, // 输入特征图 data_t* weight, // 权重 data_t* bias, // 偏置 data_t* output, // 输出特征图 int in_ch, // 输入通道数 int out_ch, // 输出通道数 int in_h, // 输入高度 int in_w, // 输入宽度 int kernel_size, // 卷积核大小 int stride // 步长 );

data_t是 16 位定点类型，用ap_fixed<16,8>定义。

第三步，加 pragma。关键的 pragma 有这几个：

#pragma HLS INTERFACE m_axi port=input offset=slave bundle=gmem0 #pragma HLS INTERFACE m_axi port=weight offset=slave bundle=gmem1 #pragma HLS INTERFACE m_axi port=output offset=slave bundle=gmem2 #pragma HLS INTERFACE s_axilite port=return bundle=control

这样 input、weight、output 分别走三个 AXI Master 接口，控制寄存器走 AXI Lite。为什么要分三个接口？因为卷积计算时，读输入、读权重、写输出是同时进行的，如果共用一个 AXI 接口，带宽会成为瓶颈。

第四步，综合并导出 IP。综合完成后，Export RTL，选 Vivado IP 格式。导出的 IP 会包含 Verilog 源码、约束文件和一个 xci 文件。

3.2 Block Design 搭建与 bitstream 生成

HLS 导出的 IP 要放到 Vivado 的 Block Design 里才能用。

第一步，创建 Vivado 工程。器件同样选xc7z020clg400-1。添加 Zynq Processing System IP，配置 DDR 控制器、时钟、UART 等。这里要注意，PYNQ 镜像对 PS 的配置有特定要求，比如 UART 波特率是 115200，SD 卡启动等。如果你直接用 PYNQ 的 base overlay 改，可以省掉很多配置工作。

第二步，添加卷积 IP。把 HLS 导出的 IP 加到 Block Design 里，然后连 AXI 接口。每个卷积 IP 的 AXI Lite 接口连到 PS 的 M_AXI_GP0，AXI Master 接口连到 PS 的 S_AXI_HP0。如果有多个卷积 IP，可以用 AXI Interconnect 来共享接口。

第三步，分配地址。在 Address Editor 里给每个 IP 分配地址段。我一般从 0x43C00000 开始，每个 IP 占 64KB。地址分配好后，Python 里就能通过这个地址访问寄存器。

第四步，生成 bitstream。综合、实现、生成 bitstream，整个过程大概 20-30 分钟。生成后会得到.bit文件和.hwh文件，这两个文件要一起放到 PYNQ 板子上。

3.3 PYNQ overlay 加载与 Python 驱动编写

板子启动后，通过 Jupyter Notebook 上传.bit和.hwh文件，然后加载 overlay：

from pynq import Overlay overlay = Overlay('/home/xilinx/yolov2.bit')

加载后，overlay 里的 IP 会暴露成属性，比如overlay.conv_layer_1。你可以直接读写它的寄存器：

conv1 = overlay.conv_layer_1 conv1.register_map.in_ch = 3 conv1.register_map.out_ch = 32 conv1.register_map.in_h = 416 conv1.register_map.in_w = 416

内存分配。输入、权重、输出都要分配连续物理内存：

from pynq import allocate import numpy as np input_buf = allocate(shape=(3, 416, 416), dtype=np.float16) weight_buf = allocate(shape=(32, 3, 3, 3), dtype=np.float16) output_buf = allocate(shape=(32, 416, 416), dtype=np.float16)

allocate返回的是ContiguousArray，它的physical_address属性就是物理地址，可以直接写到 IP 的寄存器里。

启动计算。把物理地址写到 IP 的寄存器，然后启动：

conv1.register_map.input_addr = input_buf.physical_address conv1.register_map.weight_addr = weight_buf.physical_address conv1.register_map.output_addr = output_buf.physical_address conv1.register_map.start = 1 while conv1.register_map.done == 0: pass

这个轮询等待的方式最简单，但效率不高。更好的做法是用中断，但 PYNQ 的中断配置稍微麻烦一点，后面再说。

3.4 完整推理流程的 Notebook 实现

整个推理流程在 Notebook 里分成几个 cell：

Cell 1：加载 overlay 和权重。权重是从 Darknet 的 weights 文件里读出来的，需要先做 BN 融合和量化。我写了个 Python 脚本，把浮点权重转成 16 位定点，然后存成 numpy array。

Cell 2：图像预处理。读入一张图，缩放到 416×416，归一化到 [0,1]，然后转成 16 位定点。这里要注意，YOLOv2 的输入是 RGB 还是 BGR？Darknet 用的是 BGR，但 OpenCV 读进来是 BGR，所以不用转。如果你用 PIL 读，是 RGB，要转一下。

Cell 3：逐层推理。用一个循环遍历所有层，每层调用对应的卷积 IP。这里要注意层间的数据依赖——有些层需要上一层的输出作为输入，所以要等上一层算完才能启动下一层。我用了双缓冲来 overlap 计算和传输，但实现起来比较复杂，后面细说。

Cell 4：后处理。PL 输出的是 13×13×425 的原始特征图，需要解码成边界框。解码逻辑是：每个网格预测 5 个 anchor，每个 anchor 有 4 个坐标偏移、1 个置信度、20 个类别概率。坐标要经过 sigmoid 和 anchor 解码，然后做 NMS。

Cell 5：可视化。用 matplotlib 把检测框画到原图上。

3.5 性能实测与瓶颈分析

实测下来，单层卷积的耗时大概是这样的：3×3 卷积，输入 416×416×3，输出 416×416×32，耗时约 8ms。整个 YOLOv2 跑下来，大概 200ms 一帧，也就是 5 FPS。这个性能不算高，但比纯 ARM 软件推理的 2-3 秒已经快了十倍以上。

瓶颈在哪？我分析下来主要是三个：

第一，DDR 带宽。Zynq-7020 的 DDR 带宽理论上是 4.2GB/s，但实际能用到 2GB/s 就不错了。卷积计算时，读输入、读权重、写输出都要走 DDR，带宽很容易打满。解决办法是增加片上缓存，减少 DDR 访问。我后来把部分权重缓存在 BRAM 里，性能提升了大概 15%。

第二，AXI 接口的延迟。每次 DMA 传输都有启动延迟，如果传输的数据量小，延迟占比就很高。解决办法是合并传输，把多个小传输合并成一个大传输。

第三，流水线气泡。层与层之间需要同步，同步的时候流水线是空的。解决办法是用双缓冲，让下一层的输入传输和当前层的计算 overlap。这个我试过，能提升 20% 左右的性能，但代码复杂度增加不少。

4. 常见问题与排查技巧实录

4.1 HLS 综合报错与时序不收敛

问题一：综合时报 "Cannot find design unit" 或者 "Unknown type"。这个通常是头文件没包含对，或者数据类型定义有问题。检查ap_fixed.h有没有 include，data_t的定义是不是在函数之前。

问题二：时序不收敛，WNS 是负的。这是 HLS 最常见的问题。原因可能是组合逻辑太长，或者 pipeline 太深。解决办法：降低时钟频率（比如从 150MHz 降到 100MHz），或者把大循环拆成小循环，减少单周期的逻辑深度。我一开始用 200MHz，时序怎么都收敛不了，降到 150MHz 就稳了。

问题三：BRAM 不够用。Zynq-7020 的 BRAM 只有 4.9Mb，如果 line buffer 开太大，BRAM 会爆。解决办法：减小 line buffer 的深度，或者用 LUTRAM 代替 BRAM。LUTRAM 用的是逻辑资源，不占 BRAM，但容量小、功耗高。

问题四：DSP 不够用。如果并行度开太高，DSP 会不够。Zynq-7020 有 220 个 DSP，我的设计用了 64 个，还有余量。如果你开到 16 并行，就是 256 个 DSP，超了。解决办法：降低并行度，或者用 LUT 实现乘法（但性能会下降）。

4.2 PYNQ overlay 加载失败与 DMA 传输异常

问题一：overlay 加载时报 "Invalid bitstream"。这个通常是 bitstream 和 hwh 文件不匹配，或者 PYNQ 版本和 Vivado 版本不兼容。检查两个文件的生成时间是不是一致，PYNQ 镜像的版本是不是和 Vivado 版本匹配。

问题二：DMA 传输卡死。这个最让人头疼。原因可能是：传输长度超过了 buffer 大小，或者物理地址不对，或者 DMA 没配置对。排查方法：先用小数据量测试（比如 1KB），确认 DMA 能正常工作，再逐步加大数据量。另外，allocate分配的内存一定要是连续的，如果内存碎片化严重，可能会分配失败。

问题三：IP 寄存器读写没反应。检查地址分配对不对，AXI Lite 接口有没有连上。可以在 Vivado 的 Address Editor 里看地址映射，然后在 Python 里用overlay.ip_dict看 IP 的地址。

问题四：计算结果全是 0 或者全是随机值。这个通常是数据没传进去，或者量化参数不对。检查输入 buffer 的 physical_address 有没有正确写到寄存器，量化的时候有没有溢出。我遇到过权重全变成 0 的情况，后来发现是量化时把小数部分全截断了，改成四舍五入就好了。

4.3 Jupyter Notebook 使用中的典型故障

问题一：单元格执行代码没有任何反应。前面说过，通常是内核挂了。重启内核，或者重启板子。如果频繁出现，检查 overlay 是不是资源超了。

问题二：Jupyter Notebook 无法运行，报 "Kernel died"。这个可能是内存不够。PYNQ-Z2 只有 512MB DDR，如果分配了太大的 buffer，内存会爆。解决办法：减小 buffer 大小，或者及时释放不用的 buffer（用del加gc.collect()）。

问题三：Jupyter Notebook 打不开，浏览器显示连接超时。检查网络配置，确认 PC 和板子在同一网段。如果用的是 USB 转以太网，检查驱动有没有装好。

问题四：Jupyter Notebook 下载文件很慢。PYNQ 的 Jupyter 是通过以太网传输的，如果板子的网络配置不好，速度会很慢。可以试试用 SCP 或者 SFTP 传文件，比 Jupyter 的上传下载快。

4.4 精度损失与量化调优

问题一：量化后 mAP 掉太多。如果掉超过 5 个点，说明量化参数没调好。检查权重的动态范围，如果某些层的权重特别大或者特别小，可能需要单独调量化比例。我一般会统计每层权重的最大值和最小值，然后按层设置量化参数。

问题二：某些层的输出全是 0。这个通常是激活值量化时下溢了。16 位定点，如果小数部分只有 8 位，最小值就是 1/256，小于这个的数会变成 0。解决办法：增加小数部分的位宽，或者对激活值做动态缩放。

问题三：检测框位置偏移。这个可能是坐标解码的问题。YOLOv2 的坐标解码是x = (sigmoid(tx) + cx) * anchor_w，其中cx是网格的左上角坐标。检查一下cx和anchor_w有没有算对。

4.5 常见问题速查表

4.6 独家避坑经验

经验一：先跑通再优化。我一开始就想做双缓冲、多 IP 并行，结果调试了两周都没跑通。后来退回到最简单的单 IP 轮询方式，一天就跑通了。跑通之后再逐步加优化，每次只改一个地方，这样出问题容易定位。

经验二：用仿真验证 HLS 代码。HLS 的 C 仿真很快，几秒钟就能跑完。我每次改完代码，先用 C 仿真验证功能对不对，再综合。这样能省掉大量综合等待时间。

经验三：权重和特征图分开存。权重是只读的，特征图是读写的。如果混在一起，BRAM 的读写冲突会很严重。我把权重放 BRAM，特征图放 DDR，性能提升明显。

经验四：注意 AXI 的突发长度。AXI 的突发传输最长是 256 拍，如果一次传输超过 256 拍，会被拆成多次。我一般把传输长度设成 256 的整数倍，这样效率最高。

经验五：Jupyter 里及时释放内存。PYNQ-Z2 的内存很小，如果分配了 buffer 不释放，很快就会 OOM。我习惯在每个 cell 结束时用del释放不用的 buffer，然后gc.collect()。

经验六：用%time测性能。Jupyter 的%time魔法命令很方便，可以快速测每个 cell 的耗时。我一般会在关键 cell 里加%time，看看瓶颈在哪。

经验七：保存中间结果。调试的时候，把每层的输出存成 npy 文件，方便对比。如果某一层的结果不对，可以单独拿出来分析。

经验八：注意定点数的溢出。16 位定点，整数部分 8 位，最大值是 127。如果卷积累加的结果超过 127，就会溢出。我一般会在累加时用 32 位中间变量，最后再截断到 16 位。

这个项目做下来，最大的体会是：FPGA 加速不是简单的“把软件搬到硬件”，而是需要重新设计数据流和计算模式。软件里可以随便用的动态内存分配、递归、分支，在硬件里都是奢侈品。你得时刻想着数据怎么流动、怎么复用、怎么并行。但一旦跑通，那种性能提升的成就感是纯软件开发给不了的。后续我还想试试把 YOLOv3 或者更小的 YOLOv4-tiny 搬上去，看看能不能在保持精度的同时把帧率提到 15 FPS 以上。