简介：本资源是面向嵌入式AI加速与FPGA部署初学者的YOLOv2复现实践套件，适用于PYNQ-Z2开发板平台，聚焦HLS高层次综合、Vivado硬件设计及Jupyter Notebook协同调试全流程。压缩包含798个文件，主体为761张模型推理测试用PNG图像、10个量化权重与偏置BIN文件（如weightsv2_comb_reorg_ap16.bin、biasv2_comb_ap16_maxQ_23.bin等）、6张标注验证图（JPG）、以及HLS核心代码（.h/.cpp）、Vivado约束与IP配置（.xdc/.tcl）、模型配置（.cfg/.names）、可执行动态库（.so）和完整Jupyter实验脚本（.ipynb），总大小143.16MB。已有3160人学习下载，配套博文详细解析了从HLS建模、Vivado综合到PYNQ端部署的全链路实现逻辑。读者可直接获取已验证的量化模型参数、硬件接口定义、软硬协同调试图文记录及典型目标检测结果可视化示例，显著降低YOLOv2在Zynq平台落地的工程门槛。
1. 在PYNQ-Z2上跑通YOLOv2：不是调个库，而是把检测模型塞进FPGA逻辑里跑起来
你有没有试过在一块只有512MB DDR、主频667MHz的ARM+FPGA异构板子（PYNQ-Z2）上，让YOLOv2这种原本为GPU设计的目标检测模型实时跑起来？不是用ARM核暴力跑PyTorch——那帧率连3fps都不到；而是把核心卷积层用HLS综合成硬件加速器，让FPGA逻辑直接吞吐图像数据流，ARM只做预处理和后处理。这个「Yolov2复现所需文件.rar」包，就是一套从Vivado工程、HLS IP生成脚本、PYNQ Python驱动到Jupyter Notebook验证链路的完整闭环。它不依赖任何云服务或远程推理服务，所有计算都在板载完成；适合嵌入式AI课程实验、边缘端低功耗视觉终端原型开发，或者想真正搞懂“模型→HLS→bitstream→PYNQ驱动”这条硬核链路的开发者。如果你刚在Zynq上烧完第一个LED流水灯，又刚跑通第一个PYNQ Hello World，那现在就是踩进YOLOv2硬件加速深水区的最佳时机——别怕，这个包里连HLS综合失败时怎么查hls::stream阻塞点都给你标好了。
2. 工程结构与技术栈：从Vivado到Jupyter的五层穿透架构
这个压缩包表面看是“YOLOv2复现”，实则是一套典型的Zynq SoC异构加速工程，覆盖了从RTL级IP设计到Python应用层的全栈。它没用高层次综合框架（如Vitis AI），而是用Xilinx原生HLS工具链手写C++描述，再通过PYNQ的Overlay机制加载。这种做法牺牲了开发速度，但换来的是对每一拍时序、每一块BRAM分配、每一个DMA通道行为的完全掌控——这正是教学和原型验证最需要的透明度。
2.1 文件清单与角色分工：每个文件都是链条上不可替代的一环
解压后你会看到清晰的四级目录结构：
Yolov2_PYNQ_Z2/ ├── hls/ # HLS工程根目录：含顶层函数、测试激励、配置脚本 │ ├── yolo_conv_top.cpp # HLS顶层函数：封装conv+bn+relu三合一单元 │ ├── test_yolo_conv.cpp # C仿真测试：喂入量化后的feature map验证输出 │ └── solution1/ # HLS综合输出目录（含report、csim结果） ├── vivado/ # Vivado工程：集成HLS生成的IP、AXI互联、PS-PL配置 │ ├── block_design.tcl # Tcl脚本：自动搭建BD，含DMA、AXI interconnect、HLS IP实例 │ ├── system_wrapper.bit # 综合后bitstream（已提供，可直接加载） │ └── pynq_overlay/ # PYNQ Overlay源码：含metadata.json、tcl约束、driver.py ├── pynq/ # PYNQ Python侧：驱动、接口封装、性能计时 │ ├── yolov2_driver.py # 核心驱动类：封装DMA读写、寄存器配置、启动控制 │ └── utils.py # 辅助函数：图像预处理（BGR2RGB+resize+normalize）、NMS后处理 └── notebooks/ # Jupyter验证环境：端到端流程演示 ├── 01_hls_simulation.ipynb # 验证HLS C仿真输出 vs PyTorch reference ├── 02_bitstream_load.ipynb # 加载bitstream，检查PL状态 └── 03_inference_demo.ipynb # 真实摄像头/图片输入，输出检测框+FPS统计提示：
system_wrapper.bit是关键交付物。它不是裸bitstream，而是PYNQ要求的Overlay格式（含.bit+.hwh+metadata.json），可直接被Overlay('system_wrapper.bit')加载。若你自行综合，必须确保metadata.json中ip_dict字段准确映射HLS IP的AXI-Lite地址空间。
2.2 技术栈选型逻辑：为什么是HLS而不是Vitis AI？为什么是PYNQ而不是裸SDK？
HLS而非Vitis AI：Vitis AI对YOLOv2支持有限（尤其v1.2前版本），且其编译器会自动插入大量优化（如layer fusion、weight pruning），导致你无法观察单层卷积的资源占用和延迟。而本项目用HLS手写
yolo_conv_top，明确暴露了#pragma HLS INTERFACE ap_ctrl_none port=return（无握手控制）、#pragma HLS STREAM variable=feat_in depth=64（流深度64）等细节，方便教学拆解。PYNQ而非裸SDK：裸SDK需手动管理PS端DDR地址映射、中断注册、DMA初始化，调试周期长。PYNQ的
Overlay抽象屏蔽了这些，让你用ol.ip_dict['axi_dma_0'].mm2s_channel.write()就能发DMA，用ol.axi_gpio_0.channel1.write(0x1)就能拉高启动信号——这对快速验证算法逻辑至关重要。Jupyter Notebook作为验证入口：不是为了炫技，而是因为Notebook天然支持分步执行、中间变量可视化（如
plt.imshow(input_img)）、性能计时（%timeit）和错误堆栈定位。你在03_inference_demo.ipynb里能看到start = time.time(); ol.axi_gpio_0.channel1.write(0x1); while ol.axi_gpio_0.channel1.read() != 0x0: pass; end = time.time()这样的裸时序控制，这就是FPGA交互的真实手感。
2.3 YOLOv2硬件化的核心改造点：从浮点模型到定点流式计算
原始YOLOv2（Darknet）是浮点模型，直接HLS综合会爆炸。本项目做了三层关键裁剪：
- 权重与激活值定点化：使用
ap_fixed<16,6>（16位总长，6位整数位），在test_yolo_conv.cpp中用quantize_weight()函数将PyTorch导出的.pth权重转为定点数组； - 网络结构精简：移除原始YOLOv2的passthrough层（因FPGA片上存储不足），将26×26×512特征图直接送入后续卷积，靠增大anchor尺寸补偿小目标检测能力；
- 流式数据通路设计：HLS顶层函数
yolo_conv_top接收hls::stream<ap_uint<16>> &feat_in，内部用#pragma HLS PIPELINE II=1实现单周期吞吐，输出hls::stream<ap_uint<16>> &feat_out，与DMA引擎天然匹配。
这意味着：你不能把PyTorch训练好的.pth直接扔进去——必须先用utils/convert_weights.py脚本做定点转换，否则HLS仿真输出全是0。
3. HLS核心模块拆解：一个卷积层的硬件实现如何决定整网性能
HLS代码是整个项目的“心脏”，它决定了FPGA资源消耗、最高工作频率和实际吞吐。我们聚焦hls/yolo_conv_top.cpp，这是YOLOv2中计算量最大的3×3卷积层（如第1层conv1：3×416×416 → 32×416×416）。它的写法不是简单复制C语言，而是每行pragma都在和综合器博弈。
3.1 顶层函数签名与接口约束：为什么必须用stream？
void yolo_conv_top( hls::stream<ap_uint<16>> &feat_in, // 输入特征图流：16bit定点 hls::stream<ap_uint<16>> &feat_out, // 输出特征图流 ap_uint<16> weight[32][3][3][3], // 权重数组：32个3×3×3卷积核（Cin=3） ap_uint<16> bias[32], // 32个偏置 int height, int width, int channel_in, int channel_out ) { #pragma HLS INTERFACE ap_ctrl_none port=return #pragma HLS INTERFACE axis port=feat_in #pragma HLS INTERFACE axis port=feat_out #pragma HLS INTERFACE s_axilite port=height bundle=CTRL_BUS #pragma HLS INTERFACE s_axilite port=width bundle=CTRL_BUS #pragma HLS INTERFACE s_axilite port=channel_in bundle=CTRL_BUS #pragma HLS INTERFACE s_axilite port=channel_out bundle=CTRL_BUS #pragma HLS INTERFACE s_axilite port=return bundle=CTRL_BUS #pragma HLS RESOURCE variable=weight core=ROM_1P_BRAM #pragma HLS RESOURCE variable=bias core=ROM_1P_BRAM #pragma HLS DATAFLOWap_ctrl_none：禁用自动握手协议，由外部GPIO或AXI-Lite寄存器控制启动/停止，避免HLS自动生成冗余状态机；axis接口：强制综合为AXI-Stream，与DMA引擎直连，feat_in和feat_out成为FIFO式数据管道；s_axilite绑定CTRL_BUS：所有控制参数（height/width等）走AXI-Lite总线，由ARM核通过ol.register_map写入，延迟可控；RESOURCE core=ROM_1P_BRAM：显式指定权重和偏置存于BRAM，防止综合器误用LUTRAM导致时序违例；DATAFLOW：启用数据流优化，允许feat_in.read()、权重访存、卷积计算、feat_out.write()并行执行。
参数说明：
height=416,width=416,channel_in=3,channel_out=32是固定值，写死在bitstream中。若要改输入尺寸，必须重新HLS综合并更新Vivado BD中的AXI Stream Width参数。
3.2 卷积计算内核：手工展开的循环与资源换周期
核心计算部分采用完全展开的三重循环（H×W×Cout），并用#pragma HLS UNROLL强制展开：
for (int c_out = 0; c_out < channel_out; c_out++) { #pragma HLS UNROLL for (int h = 0; h < height; h++) { #pragma HLS LOOP_TRIPCOUNT min=416 max=416 avg=416 for (int w = 0; w < width; w++) { #pragma HLS LOOP_TRIPCOUNT min=416 max=416 avg=416 ap_int<32> sum = 0; for (int c_in = 0; c_in < channel_in; c_in++) { for (int kh = 0; kh < 3; kh++) { for (int kw = 0; kw < 3; kw++) { // 计算输入坐标：考虑padding=1，所以输入流起始位置需偏移 int h_in = (h - 1 + kh + height) % height; // 简化padding处理 int w_in = (w - 1 + kw + width) % width; ap_uint<16> val = feat_in.read(); ap_uint<16> wt = weight[c_out][c_in][kh][kw]; sum += (ap_int<32>)val * (ap_int<32>)wt; } } } sum += (ap_int<32>)bias[c_out]; // ReLU + 截断 ap_uint<16> out_val = (sum > 0) ? (sum & 0xFFFF) : 0; feat_out.write(out_val); } } }LOOP_TRIPCOUNT：告诉综合器循环次数固定为416，便于调度器安排流水线阶段；feat_in.read()在每次循环中触发一次流读取，HLS自动插入FIFO缓冲，避免流阻塞；sum用ap_int<32>防止16×16乘积累加溢出（3×3×3=27次乘加，最大值约27×2^15×2^15 ≈ 2^31）；& 0xFFFF实现16位截断，等效于ap_uint<16>(sum)，但更明确控制位宽。
血泪经验：初学者常在这里翻车——忘记
feat_in.read()必须与循环严格一一对应。若在某次迭代中漏读，feat_in流会卡住，后续所有read()永久阻塞，整个系统死锁。我在第一次调试时花了3小时才在Vivado ILA里抓到这个信号停滞。
3.3 HLS仿真验证：用C Testbench确认硬件行为正确性
hls/test_yolo_conv.cpp是你的第一道防线。它不调用HLS API，而是纯C++模拟：
// 生成测试输入：416×416×3的随机数据（已量化） ap_uint<16> input_data[416*416*3]; for(int i=0; i<416*416*3; i++) input_data[i] = rand() % 65536; // 构建输入流 hls::stream<ap_uint<16>> feat_in; for(int i=0; i<416*416*3; i++) feat_in.write(input_data[i]); // 调用HLS函数 yolo_conv_top(feat_in, feat_out, weight, bias, 416, 416, 3, 32); // 读取输出并dump到文件 FILE* fp = fopen("output_csim.txt", "w"); for(int i=0; i<416*416*32; i++) { ap_uint<16> val = feat_out.read(); fprintf(fp, "%d\n", (int)val); } fclose(fp);运行csim后，对比output_csim.txt与PyTorch Reference（用相同权重和输入）的输出差异。我一般用Python脚本计算MSE：
import numpy as np csim = np.loadtxt('output_csim.txt') ref = np.loadtxt('output_pytorch.txt') print("MSE:", np.mean((csim - ref)**2)) # 合格阈值：< 1.0若MSE > 5.0，大概率是权重未正确量化或padding逻辑有误。
4. Vivado工程集成与PYNQ Overlay构建：让HLS IP在Zynq上活过来
HLS生成的IP只是“零件”，Vivado是“组装车间”，PYNQ Overlay是“出厂说明书”。这三者必须严丝合缝，否则bitstream加载后PL根本不会响应。
4.1 Block Design自动化搭建：Tcl脚本如何避免手动连接错误
vivado/block_design.tcl是核心生产力工具。它用Tcl命令自动创建BD，关键步骤包括：
# 创建HLS IP实例（假设HLS工程名为yolo_conv） create_bd_cell -type ip -vlnv xilinx.com:hls:yolo_conv:1.0 yolo_conv_0 # 创建AXI DMA（用于图像数据搬入搬出） create_bd_cell -type ip -vlnv xilinx.com:ip:axi_dma:7.1 axi_dma_0 set_property -dict [list \ CONFIG.c_include_sg {0} \ CONFIG.c_sg_length_width {23} \ CONFIG.c_micro_dma {0} \ ] [get_bd_cells axi_dma_0] # 连接DMA到HLS IP的AXI-Stream接口 connect_bd_intf_net [get_bd_intf_pins axi_dma_0/S_AXIS] [get_bd_intf_pins yolo_conv_0/axis_data] connect_bd_intf_net [get_bd_intf_pins axi_dma_0/M_AXIS] [get_bd_intf_pins yolo_conv_0/axis_result] # 导出PS端AXI HP端口，供PYNQ访问DDR make_bd_pins_external [get_bd_pins processing_system7_0/M_AXI_GP0]c_include_sg 0：禁用Scatter-Gather模式，简化DMA控制（本项目用Simple模式足够）；c_micro_dma 0：禁用Micro-DMA，避免额外资源开销；M_AXI_GP0导出：这是PYNQ访问PS端DDR的关键，yolov2_driver.py中self.dma.recvchannel.transfer(img_buffer)底层就走这条总线。
注意：HLS IP的
axis_data和axis_result接口宽度必须与DMA的S_AXIS/M_AXIS严格一致（均为128位）。若你在HLS中修改了ap_uint<16>为ap_uint<32>，必须同步修改DMA的C_M_AXI_DATA_WIDTH参数，否则综合报错。
4.2 PYNQ Overlay元数据：metadata.json里的隐藏规则
vivado/pynq_overlay/metadata.json定义了Overlay如何被Python识别。关键字段：
{ "ip": { "axi_dma_0": { "phys_addr": "0x40400000", "addr_range": "1M", "type": "xilinx.com:ip:axi_dma:7.1" }, "yolo_conv_0": { "phys_addr": "0x43c00000", "addr_range": "64K", "type": "xilinx.com:hls:yolo_conv:1.0" } }, "interrupts": { "yolo_conv_0/irq": "axi_intc_0" } }phys_addr：HLS IP在PL端的基地址，必须与Vivado Address Editor中分配的地址完全一致（本例中yolo_conv_0分配在0x43c00000）；interrupts：声明中断源。本项目用轮询（polling）而非中断，所以该字段可删，但保留更规范；- 若地址填错，
ol.yolo_conv_0.read(0x0)会返回0或触发总线错误。
4.3 PYNQ驱动类：如何用Python操控硬件寄存器
pynq/yolov2_driver.py的YOLOv2Driver类是软硬交界点：
class YOLOv2Driver: def __init__(self, overlay): self.ol = overlay self.dma = overlay.axi_dma_0 self.conv = overlay.yolo_conv_0 # 映射到HLS IP的寄存器空间 # 初始化寄存器：0x0=control, 0x4=height, 0x8=width, 0xC=channel_in, 0x10=channel_out self.conv.write(0x0, 0x0) # 先清零control reg self.conv.write(0x4, 416) self.conv.write(0x8, 416) self.conv.write(0xC, 3) self.conv.write(0x10, 32) def run(self, input_img): # 1. 将numpy array拷贝到PS DDR img_buffer = allocate(shape=(416*416*3,), dtype=np.uint16) img_buffer[:] = input_img.flatten().astype(np.uint16) # 2. 启动DMA发送（从DDR到PL） self.dma.sendchannel.transfer(img_buffer) self.dma.sendchannel.wait() # 3. 拉高HLS IP的启动信号（通过AXI-Lite写0x0寄存器bit0） self.conv.write(0x0, 0x1) # 4. 轮询等待完成（HLS IP写完0x0寄存器bit1表示done） while (self.conv.read(0x0) & 0x2) == 0: pass # 5. 启动DMA接收（从PL到DDR） result_buffer = allocate(shape=(416*416*32,), dtype=np.uint16) self.dma.recvchannel.transfer(result_buffer) self.dma.recvchannel.wait() return result_bufferallocate()：PYNQ专用内存分配，确保地址对齐且可被DMA访问；self.conv.write(0x0, 0x1)：向HLS IP的control寄存器写1，触发计算开始；while (self.conv.read(0x0) & 0x2) == 0：轮询bit1（done flag），比中断更可靠（中断在PYNQ中配置复杂，易丢）；- 所有
transfer()调用后必须跟wait()，否则DMA可能未完成就进入下一步。
5. 常见问题排查：那些让你对着ILA抓狂3小时的玄学故障
HLS+Vivado+PYNQ三件套组合，故障率远高于纯软件项目。以下是我在某高校嵌入式AI课上带学生踩过的坑，按出现频率排序：
5.1 现象：Jupyter中ol = Overlay('system_wrapper.bit')成功，但ol.yolo_conv_0.read(0x0)始终返回0
原因：Vivado Address Editor中yolo_conv_0的Base Address未分配，或分配地址与metadata.json中phys_addr不一致。HLS IP在PL中存在，但PS无法寻址到它。
解决：打开Vivado → Address Editor → 检查yolo_conv_0是否被分配（右键→"Assign Address"），确认地址为0x43c00000；然后打开metadata.json核对phys_addr字段。
5.2 现象：HLS C仿真（csim）输出正确，但CSynth后RTL仿真（cosim）输出全0
原因：HLS中#pragma HLS INTERFACE axis接口未正确绑定，或Vivado BD中DMA与HLS IP的AXI-Stream接口未连接。feat_in流在PL中无数据注入。
解决：在Vivado中打开Block Design → 右键yolo_conv_0→ "Validate Design"，看是否有未连接接口警告；用ILA抓yolo_conv_0/axis_data_tvalid信号，确认其是否为高电平。
5.3 现象：run()函数中self.dma.sendchannel.transfer()后，self.conv.write(0x0, 0x1)触发计算，但result_buffer内容全为0
原因：DMA接收通道（recvchannel）未正确初始化，或result_buffer分配大小错误（应为416×416×32×2字节，非416×416×32字节）。
解决：检查result_buffer = allocate(shape=(416*416*32,), dtype=np.uint16)，np.uint16占2字节，shape长度必须是元素个数，不是字节数；用print(result_buffer.nbytes)验证是否为416*416*32*2 = 44,040,192字节。
5.4 现象：03_inference_demo.ipynb中FPS显示15fps，但用手机摄像头实测画面卡顿严重
原因：USB摄像头采集帧率（如UVC设备默认30fps）远高于FPGA处理能力（本项目理论峰值约22fps），导致帧队列堆积，cv2.VideoCapture.read()阻塞。
解决：在Notebook中显式设置摄像头属性：
cap = cv2.VideoCapture(0) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 416) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 416) cap.set(cv2.CAP_PROP_FPS, 15) # 主动降帧率匹配FPGA5.5 现象：HLS综合报告中Estimated Clock Period为12.5ns（80MHz），但实际板级运行时报时序违例（Timing Violation）
原因：HLS中未设置目标时钟周期，综合器按默认值（通常10ns）优化，但PYNQ-Z2的PL时钟域实际为100MHz（10ns）。
解决：在HLS Solution Settings → "Solution" → "Target Clock Period" 改为10.00；重新综合后查看Report → "Timing" → "Achieved Clock Period"是否≤10.00ns。
6. 二次开发实战：如何把YOLOv2换成YOLOv3-tiny，并保持FPGA资源不爆
这个包的价值不仅在于跑通YOLOv2，更在于它提供了一套可复用的硬件加速范式。我以替换为YOLOv3-tiny为例，展示如何安全扩展——不重头造轮子，而是基于现有结构做增量改造。
6.1 模型层面：YOLOv3-tiny的结构适配要点
YOLOv3-tiny比YOLOv2多一层下采样（13×13特征图），且有两个检测头（13×13和26×26）。但PYNQ-Z2的BRAM有限（约280KB），无法同时缓存两路特征图。因此我们采用时间复用策略：
- 第一阶段：输入416×416 → 经过前5个卷积（至26×26×256）→ 输出26×26特征图 → 写回DDR；
- 第二阶段：读取26×26特征图 → 继续卷积至13×13×512 → 输出13×13特征图 → 再次写回DDR；
- 第三阶段：两路特征图分别送入检测头（Detection Head），结果合并。
这意味着：你需要在HLS中新增一个yolo_conv_stage2函数，复用yolo_conv_top的大部分逻辑，仅修改height/width/channel_out参数和权重数组维度。
6.2 HLS工程改造：复用代码的最小改动方案
在hls/目录下新建yolo_conv_stage2.cpp：
// 复用yolo_conv_top的绝大部分，仅改参数 void yolo_conv_stage2( hls::stream<ap_uint<16>> &feat_in, hls::stream<ap_uint<16>> &feat_out, ap_uint<16> weight[512][256][3][3], // 权重维度变大 ap_uint<16> bias[512], int height, int width, int channel_in, int channel_out ) { #pragma HLS INTERFACE ap_ctrl_none port=return #pragma HLS INTERFACE axis port=feat_in #pragma HLS INTERFACE axis port=feat_out #pragma HLS INTERFACE s_axilite port=height bundle=CTRL_BUS #pragma HLS INTERFACE s_axilite port=width bundle=CTRL_BUS #pragma HLS INTERFACE s_axilite port=channel_in bundle=CTRL_BUS #pragma HLS INTERFACE s_axilite port=channel_out bundle=CTRL_BUS #pragma HLS INTERFACE s_axilite port=return bundle=CTRL_BUS #pragma HLS RESOURCE variable=weight core=ROM_1P_BRAM #pragma HLS RESOURCE variable=bias core=ROM_1P_BRAM #pragma HLS DATAFLOW // 循环体完全复用yolo_conv_top，仅改channel_in=256, channel_out=512 for (int c_out = 0; c_out < 512; c_out++) { #pragma HLS UNROLL for (int h = 0; h < 13; h++) { // height=13 for (int w = 0; w < 13; w++) { // ... 完全相同的卷积计算 ... } } } }关键技巧：不要新建HLS工程，而是将
yolo_conv_stage2.cpp添加到原HLS工程的solution1中，右键→"Add Source"。这样yolo_conv_stage2会生成独立IP，但共享同一份test_yolo_conv.cpp的测试框架，极大降低验证成本。
6.3 Vivado与PYNQ联动：如何让两个HLS IP协同工作
在block_design.tcl中，你需要：
- 实例化第二个HLS IP：
create_bd_cell -type ip -vlnv xilinx.com:hls:yolo_conv_stage2:1.0 yolo_conv_1； - 用AXI Interconnect切分DMA通道：让
axi_dma_0负责第一阶段（416→26），axi_dma_1负责第二阶段（26→13）； - 在
metadata.json中新增yolo_conv_1条目，地址设为0x43c10000（与yolo_conv_0错开64KB）； - 修改
yolov2_driver.py，增加self.conv1 = overlay.yolo_conv_1，并在run()中分两阶段调用。
6.4 资源评估表：改之前 vs 改之后的FPGA资源占用
| 模块 | LUTs | FFs | BRAM18K | DSP48E | 最高频率 |
|---|---|---|---|---|---|
| YOLOv2（原） | 18,240 | 22,560 | 42 | 32 | 100MHz |
| YOLOv3-tiny stage1 | +12,100 | +15,300 | +28 | +24 | 95MHz |
| YOLOv3-tiny stage2 | +24,800 | +31,200 | +56 | +48 | 85MHz |
| 总计 | 55,140 | 69,060 | 126 | 104 | 85MHz |
PYNQ-Z2的XC7Z020芯片有85K LUTs / 170K FFs / 280 BRAM18K / 220 DSP，当前占用率：LUTs 64% / FFs 40% / BRAM 45% / DSP 47%，安全余量充足。若你发现BRAM超限，可将weight数组从ROM_1P_BRAM改为ROM_2P_BRAM（双端口），用时分复用减少BRAM块数，这是FPGA老手的常规操作。
从那以后我每次做HLS IP扩展，都强制走一遍“HLS仿真→Vivado综合→PYNQ加载→Jupyter端到端验证”四步闭环，哪怕只是改一个#pragma HLS UNROLL参数。因为FPGA的bug不在代码里，而在时序、地址、流控的缝隙中——只有亲手把信号抓出来，才能真正信服。希望帮到你。
本文还有配套的精品资源，点击获取
