纯Verilog脉动阵列加速车牌识别：FPGA端到端延迟压至5毫秒

做车牌识别项目，最头疼的往往不是算法本身，而是延迟。我们接到的需求很明确：从摄像头采集到车牌号输出，端到端要压到20毫秒以内。团队最初在嵌入式SoC上跑深度学习方案，可无论怎么裁剪模型、做算子融合，在主流Cortex-A系列处理器上检测加识别总延迟都在50毫秒上下徘徊，高负载时甚至能飙到上百毫秒。后来我把目光转向FPGA，干脆用纯Verilog搭了一个脉动卷积阵列加速器，把检测和识别两套网络都跑在上面，先后在Xilinx和紫光同创两家的FPGA上完成了部署。实测单帧车牌识别的端到端延迟可以控制在5毫秒以内，比传统方案快了一个量级。

这篇文章会完整复盘整个项目的技术路线，从脉动阵列的架构选型、纯Verilog实现细节，到车牌检测识别网络在FPGA上如何落地，再到Xilinx和紫光同创两个工具链的移植踩坑过程。无论你是想做通用卷积加速，还是正打算在国产FPGA上跑图像识别应用，这份实战记录应该都能给你一些可复用的参考。

1. 项目概述与整体思路拆解

1.1 为什么选纯Verilog而不是HLS或ZYNQ

动手之前先做个方案选择题。市面上主流的FPGA加速方案无非三条路：HLS高层综合、基于ZYNQ的ARM+FPGA异构SoC、纯RTL实现。HLS确实开发效率高，但做出来的卷积加速器延迟和资源可控性不太理想，综合工具生成的流水线有时会出现莫名其妙的突发延迟，对于一个要压缩到极致延迟的项目来说，不太敢冒这个险。

ZYNQ方案在嵌入式和Linux生态上有优势，但车牌识别这个场景对CPU算力要求并不高，算法的主要工作量集中在卷积计算上，这部分恰恰是FPGA逻辑资源的强项。引入ARM反倒增加了系统复杂度，还要处理PS和PL之间的数据搬运开销和Linux调度抖动，对硬实时性反而是一种伤害。

纯Verilog方案的优势在于可控性最强。时钟周期级的时序行为完全掌握在手里，所有模块的延迟都是确定的，没有工具生成的额外调度不确定性。另一个好处是可移植性极强——不依赖Xilinx或紫光同创的任何独家IP，同一份RTL代码可以无缝在两个平台间切换，这在国产化替代的需求背景下尤其重要。

1.2 系统架构与延迟目标拆解

整个车牌识别加速器由四大块组成：图像预处理模块、脉动卷积阵列核心、车牌检测网络、车牌字符识别网络。其中检测和识别两个网络共用同一个脉动阵列硬件，通过切换片上的权重存储来复用计算单元，这比例化两套独立的卷积引擎要节省将近一半的DSP和BRAM资源。

延迟预算拆分下来是这样的：图像预处理约1毫秒（主要是行缓冲带来的行延迟），检测网络前向推理约2毫秒，识别网络（车牌区域裁剪后的小图）约1.5毫秒，加上输出后处理和UART发送结果约0.5毫秒，总计约5毫秒。这个时间预算比客户要求的20毫秒红线宽裕得多，实测也能稳定在5毫秒以内，如果对检测网络再做一次通道剪枝甚至能压进3毫秒。

一个被很多人忽视的关键设计是流式处理思路。传统方案是等一帧图像完全存入DDR后再开始处理，光这步存储和读取就要消耗好几毫秒。我们的设计直接让图像数据按行流式进入FPGA，预处理和第一层卷积在数据还在进入的时候就已经开始工作。这样算下来，首帧结果的延迟约等于“图像最后一行到达时间 + 网络流水线深度延迟”，而不是“整帧接收时间 + 整帧处理时间”，这是超低延迟的核心来源。

1.3 为什么脉动阵列适合这个场景

卷积计算本质上是大量的乘累加操作，在通用处理器上需要反复取指令、解码、访存，效率很低。脉动阵列的思路是把大量处理单元（PE）排列成规整的网格，数据在PE之间像血液一样有节奏地“脉动”流动，每个PE只和相邻的PE通信，避免全局总线的带宽瓶颈。

矩阵乘是脉动阵列最经典的加速场景。卷积操作通过im2col变换可以转换成矩阵乘，所以脉动阵列天然适合做CNN加速器。Google的TPU就是脉动阵列架构，这也从工业界印证了这类架构在卷积加速上的有效性。在FPGA上实现脉动阵列，PE之间只有相邻连线，布线压力小，可以跑出很高的工作频率，这对我们追求超低延迟的目标至关重要。

2. 脉动卷积阵列设计原理与架构选型

2.1 三种经典数据流模式的取舍

脉动阵列有几种经典的数据流组织方式，直接决定了硬件设计的走向。Weight Stationary（权值固定）、Output Stationary（输出固定）、Input Stationary（输入固定），这三者的共同点都是用空间换时间，把数据广播或流式移动与并行计算结合起来，区别在于哪个数据保持不动。

车牌识别网络属于典型的CNN，卷积核权重在整张图的推理过程中是固定不变的。Weight Stationary模式把权重预加载到每个PE的寄存器中，输入特征图数据从左到右流动，部分和从上到下流动，非常适合FPGA上的卷积加速。这种模式下权重只需加载一次，后续计算过程中不需要额外搬运权重，能有效降低片内存储带宽压力。实测下来在同样的PE阵列规模下，WS模式比输出固定模式的整体吞吐量高出约15%，代价是PE内部需要额外的权重复制控制逻辑和加载状态机。

2.2 PE阵列尺寸与片上存储规划

脉动阵列的尺寸选择是个系统工程，首先要看目标芯片的资源。我们在Xilinx Artix-7 XC7A35T上跑了资源评估，这个级别芯片大约有20800个LUT、41600个FF、50个BRAM（每个36Kb）和90个DSP48E1。单个PE如果使用FPGA硬核DSP做乘加，开销只有1个DSP加少量LUT和FF，16x16阵列总计需要256个DSP，这在XC7A35T上超过了资源上限。所以我最终选了12x8的阵列规模，共计96个PE，在DSP资源90个的约束下还要做微调——实际上最终用8x8阵列配合双时钟周期复用DSP的方案，用64个DSP就完成了8x64乘累加总量。

片上存储规划要匹配脉动阵列的吞吐需求。阵列每周期要消费64个输入激活数据和相应的部分和数据，如果全部依赖外部存储必然频繁卡顿。我用了BRAM搭建三级缓冲结构：输入行缓冲存放当前处理的数据行，权重缓冲存放当前层的卷积核参数，部分和缓冲累加中间结果。对于车牌识别这种小型网络，权重总量约60KB左右，使用FPGA的BRAM正好可以全部放在片上，彻底避开DDR带宽瓶颈。紫光同创Logos-2系列的BRAM容量与Artix-7接近，同一个设计移植后也不需要改动存储结构。

2.3 为什么选择INT8定点量化

模型量化是FPGA部署中一个绕不开的决策点。车牌识别网络原本在PyTorch上训练时用的是FP32浮点，直接拿到FPGA上算浮点会消耗大量LUT用于浮点运算单元，功耗和延迟都不可接受。业界主流方案是INT8量化，在精度损失可控的前提下大幅减少资源开销，这也是TensorRT和Xilinx DPU等方案普遍采用的路径。

我把权重和激活值从FP32量化到INT8，量化方式用的是最简单的均匀对称量化。实测在车牌字符识别任务上，INT8模型精度从FP32的97.2%下降到95.8%，下降幅度约1.4个百分点，完全在可接受范围内。这个精度损失主要来自激活值的饱和截断，解决办法是在量化校准阶段统计激活值的分布，选择合适的缩放因子，而不是简单按最大值缩放。具体操作用PyTorch的伪量化接口模拟INT8计算，收集训练集上激活值的min/max统计量，然后固定缩放因子导出权重。

纯Verilog实现定点乘加其实很简单，8bit乘以8bit得到16bit结果，然后在累加器中用32bit宽度的寄存器进行累加防止溢出。这里有个很关键但又容易踩坑的点：卷积层输出的偏置项是FP32训练的，量化后偏置要用更高的位宽表示，否则结果偏移会直接影响网络精度。我把偏置单独用16bit定点数存储，在累加完成后先加上偏置，再进行激活函数截断，得到的输出保持8bit供下一层消费。

3. 纯Verilog实现核心细节

3.1 顶层微架构与模块划分

整个加速器的顶层模块划分遵循“高内聚低耦合”原则，各模块用简单的握手信号交互，方便在白金验证平台Modelsim上做模块级仿真调试。顶层例化了预处理模块、脉动阵列计算核心、权重加载与存储控制、输出汇聚与激活模块、以及最外层的主控制状态机。

主控状态机是整个系统的“节拍器”，负责协调各模块的启动时序。初始上电后先进入权重加载阶段，从外部ROM把当前层卷积核写入PE阵列的权值寄存器；加载完成后切换到计算状态，输入数据按预定的时钟节拍流入阵列；当所有数据计算完毕，状态机进入输出收集阶段，从阵列底部把部分和取出，经激活处理后送入下一层或输出缓冲。状态机的状态跳转使用一段式写法，逻辑简单直观，排错起来也比较容易。

3.2 PE单元微架构与局部控制逻辑

PE单元是构成阵列的最基本计算单元，麻雀虽小五脏俱全。单个PE内部包含一个乘法器、一个累加器、几个数据寄存器以及控制数据流向的本地握手逻辑，核心代码结构如下：

module pe #( parameter DATA_WIDTH = 8, parameter ACC_WIDTH = 32 )( input wire clk, input wire rst_n, input wire [DATA_WIDTH-1:0] i_act, // 激活输入 input wire [DATA_WIDTH-1:0] i_wt, // 权重输入 input wire [ACC_WIDTH-1:0] i_acc, // 部分和输入 input wire i_valid, // 输入有效标志 input wire i_load, // 权重加载使能 output wire [DATA_WIDTH-1:0] o_act, // 激活输出 output reg [DATA_WIDTH-1:0] o_wt, // 权重输出 output reg [ACC_WIDTH-1:0] o_acc, // 部分和输出 output reg o_valid // 输出有效标志 ); reg [DATA_WIDTH-1:0] wt_reg; wire [ACC_WIDTH-1:0] product = i_act * wt_reg; always @(posedge clk or negedge rst_n) begin if (!rst_n) begin wt_reg <= {DATA_WIDTH{1'b0}}; o_acc <= {ACC_WIDTH{1'b0}}; o_valid <= 1'b0; end else begin if (i_load) begin wt_reg <= i_wt; end o_acc <= (i_valid) ? (i_acc + product) : i_acc; o_valid <= i_valid; end end assign o_act = i_act; assign o_wt = i_wt; endmodule

这段代码里有个容易被忽略的细节：组合逻辑输出的product为当前乘法的结果，而o_acc的累加实际使用的是wt_reg与i_act的组合逻辑乘积，由于i_act是寄存器输出路径上的信号，整个乘积在时序上天然对齐。换句话说PE内部不需要额外的数据对齐打拍。局部控制里i_load和i_valid是两条独立的通路，权重加载阶段计算使能信号必须拉低，避免加载权重期间误触发无效计算。这个模块经过综合后，在Xilinx上会映射到一个DSP48E1原语加少量LUT，在紫光同创上映射到对应的乘法器单元。

3.3 数据调度与流向控制

阵列的数据调度是整个设计中最考验功力的一环。以Weight Stationary模式为例，权重按列广播先写入各PE，然后输入激活数据从左上方以特定节奏注入阵列，每个时钟周期推进一个“斜对角线”的数据批次，这就是经典的脉动数据流时序。

输入数据进入阵列的方式需要仔细设计。假设输入特征图是C通道的二维矩阵，需要先把图像数据按行展开成一维向量，再按卷积窗口进行切分重组。我在预处理模块里做了一个专门的im2col缓冲，它实际上是一个双口BRAM加一套地址生成逻辑，按滑动步长读取像素并组装成矩阵乘的一行。地址生成器采用计数器实现，起始地址和跳转步长可配置，不同尺寸的输入特征图只需修改配置寄存器，不需要重新综合。这样设计的好处是检测网络和识别网络虽然输入尺寸差异很大，但共用的脉动阵列核心完全不用改，只需配置相应的im2col参数。

部分和的流动方向是垂直向下。每个PE把本地的乘加结果往下传，下一行的PE再加上自己计算的乘积，最终在阵列底行得到该输出通道的完整累加结果。这里有一个数据对齐的隐含要求：由于每个PE计算完一行数据的时间不同，部分和在垂直方向的流动天然带有流水延迟，底行输出时需要做一个对齐修正。我在底行追加了一个深度等于阵列行数的移位寄存器链，把先到的部分和打拍到统一节拍再输出，这个修正逻辑在功能仿真时很容易被漏掉，但实际综合后若缺失会导致输出数据错位，识别结果完全错乱。

3.4 跨时钟域与异步FIFO

系统里的图像输入时钟和阵列计算时钟并不完全同源。外部摄像头传感器输出像素时钟通常是24MHz或25MHz，而脉动阵列工作时钟在100MHz以上，两者之间必须做跨时钟域处理。图像数据跨时钟域的常规手段包括打拍同步和异步FIFO握手。对于一行像素数据，我用异步FIFO做缓冲，写侧用像素时钟，读侧用计算时钟，这样既能保证数据不丢失，又能在两端速率不完全匹配时天然解耦。

异步FIFO的实现要注意格雷码指针同步的安全性问题。读指针写入侧需要经过两级同步器同步后与写侧指针比较，写指针同理。同步器存在两拍延迟，导致满空判断有滞后，因此FIFO深度要留足余量，避免出现写满或读空边沿判断不及时导致的错误。我最终选了参数化的异步FIFO IP，深度设为2048，同时把算法级的数据突发长度控制在512以内，确保最坏情况下也不会触发溢出水线。

用计数器实现帧内行同步信号，每收到一行的行结束标志就更新行号计数器，同时触发地址生成器的下一行起始地址更新。这个看似不起眼的模块，实际调试中出过不少Bug，最典型的是首行数据到来时行号还没加1，导致整帧图像第一行被跳过，车牌区域恰好落在首行附近时偶发性识别不出号码。后来把行同步的解码状态机和像素数据对齐加上握手信号，确保行号稳定后再允许数据写入FIFO，问题才解决。

4. 车牌检测与识别算法的FPGA落地

4.1 算法选型与模型压缩

车牌识别任务包含两个子任务：定位车牌区域和识别车牌上的字符。定位用轻量目标检测网络，识别用分类网络，这两者在计算模式上高度重叠，可以共用同一套脉动阵列硬件。检测网络我选用了自研的小型卷积网络，结构类似Tiny YOLO但层数更少：三层卷积加一层全连接，输出7x7网格每个点上的目标置信度、类别概率和框坐标回归量。训练时在公开的车牌数据集加上自己采集的路侧视频帧，标注后做数据增强训练。

模型参数量要控制在FPGA片上存储能容纳的范围内。检测网络约35KB权重，识别网络约25KB权重，两张网络加起来约60KB，使用两个BRAM块组就能存下。为了进一步降低部署风险，我对权重做了8bit量化，并用K-means聚类做了权值压缩，聚类数设置为32，每个权重只存4bit聚类索引，查表恢复出实际权值。这个技巧把片上权重存储压力又减半，最终只占用了约30KB的BRAM资源。

这里补充一下为什么不用现成的开源车牌识别方案。主流的开源方案多基于大模型或需要在GPU上跑，在资源紧张的FPGA上部署要么模型裁剪太狠精度崩掉，要么硬件资源不够实现不了。自己针对FPGA资源定制一个小网络，控制网络的层数、通道数和输入分辨率，整个链条的主动权都在自己手里。

4.2 预处理流水线的硬件化改造

车牌图像预处理通常包含RGB转灰度、高斯滤波降噪、边缘检测、二值化四个环节。在Python里这些都是逐像素遍历的循环，到了Verilog全部改成行流式流水线处理，每来一个像素输出一个像素的处理结果，几乎不产生额外延迟。

RGB转灰度用的公式是Y = 0.299R + 0.587G + 0.114B。FPGA里直接实现浮点乘法很浪费，所以我用移位加近似实现：乘0.299近似为右移2位加右移4位加更小项，乘0.587近似为右移1位加右移3位，乘0.114近似为右移3位加右移4位加右移5位。这个近似方案把浮点乘法全部转成移位和加法，每个像素只需几个时钟周期，实测转换精度误差小于1%，肉眼看不出区别。

高斯滤波用3x3窗口，需要缓存两行像素数据。我用了两个独立的行延迟FIFO链，逐行滑动窗口，当第三个像素到达时窗口内的9个像素同时就绪。这里要注意窗口边缘的数据填充方式，图像边缘的像素没有完整邻域，做边缘像素特殊处理不复用滤波器原始数据，而是在窗口不完整时直接旁路输出原始灰度值，避免滤波后边缘出现黑线影响后续检测。二值化则更简单，一个比较器搞定，阈值根据场景设定为固定值，也可以在运行时通过UART动态配置。

4.3 从PyTorch模型到Verilog权重文件

算法工程师训练好的PyTorch模型和FPGA工程师需要的Verilog初始化文件之间，需要一座桥。这个桥是Python脚本：加载PyTorch模型的state_dict，提取每一层的权重和偏置，做量化处理和权重重排，最后生成COE或HEX格式文件供FPGA的ROM初始化。权重重排这一步很多人会忽略，但实际上至关重要。脉动阵列要求权重按PE排列顺序预加载，也就是第m行第n列的PE里要放第m个输出通道和第n个输入通道对应的卷积核值，这个排列顺序和PyTorch默认存储格式（out_channels, in_channels, k_h, k_w）不一致，必须通过Python脚本做一次维度交换和转置，然后按特定顺序展开成线性数组。

COE文件用文本格式就够用，每行一个十六进制数。需要注意的有两点：第一，COE文件在Xilinx和紫光同创的工具里都能直接用于ROM初始化，跨平台的一致性很好；第二，权重值量化后必须限定在-128到127范围内，超出部分直接截断，不能取模回绕，否则会引入极大的误差。量化脚本里我特意加了范围检查，一旦发现超出范围就打印告警并自动重新校准缩放因子。

检测网络输出的边界框坐标和置信度还需要做后处理。在FPGA上做完整的非极大值抑制太奢侈，因为排序算法需要大量比较器和存储。我简化成只取置信度最高的一个候选框，因为车牌场景通常每帧只有一块车牌，这个简化在实践中完全够用。候选框坐标换算成实际图像坐标后传给字符识别模块做裁剪，裁剪操作本质上就是一个带偏移量的数据读取，从原图缓存里按坐标区域把像素读出来，送到识别网络输入缓冲。

5. Xilinx和紫光同创双平台部署实战

5.1 通用化Verilog的代码风格约束

写一份代码在两个工具链上跑通，比想象中要讲究。Xilinx Vivado对语法检查相对宽松，一些不规范的写法也能综合通过；但紫光同创Pango Design Suite（PDS）对某些语法和设计规则会更严格。为了让代码具备良好的可移植性，我在编码阶段就定了一些死规矩：避免使用延迟控制语法如#5方式，只在仿真文件中使用；明确标注所有位宽，绝不依赖隐式扩展；避免使用锁存器，所有always块中的变量都要完整赋值，条件不满足时保持或赋默认值；state寄存器统一使用参数化编码，不依赖厂家特定的状态机综合工具。

还有一个隐蔽的坑出现在时钟资源的使用上。Xilinx平台上常用的MMCM时钟管理原语和紫光同创的时钟管理单元在接口名称和配置方式上有差异，直接例化会产生移植性问题。我的做法是封装了一个简单的clock_gen模块，在外层分别做不同平台的例化适配，内层逻辑只使用统一提供的clk、locked和rst_n信号。这样平台相关的代码被隔离在一个单独的小模块里，其余90%的工程代码无需修改即可在两个工程中复用。

5.2 Xilinx片上验证与Vivado时序收敛

Xilinx平台用的芯片是Artix-7 XC7A35T，开发环境是Vivado 2019.1版本。工程建立后，综合实现的时序收敛是最大的挑战。脉动阵列工作在100MHz时钟下，约束文件里要正确声明主时钟、生成时钟和输入输出延迟。一个容易被遗漏的点是FPGA输入管脚数据与像素时钟的相位关系，必须通过set_input_delay约束来描述外部摄像头数据到达时间和时钟沿之间的相对延迟，否则实现工具可能得出悲观的时序结果，导致设计在板上无法稳定运行。

时序分析报告里有两条关键路径值得关注：一条是PE内部乘积信号接入累加寄存器的路径，另一条是权重加载信号在所有PE之间广播的扇出路径。PE内部路径经过乘法器后达到累加器，在DSP硬核内部有时序优化可以轻松满足；但权重加载信号的扇出特别大，会消耗较多布线资源。解决办法是把权重加载变成多级流水线式，每行PE的加载使能信号打拍传递，而不是从单一信号直接扇出到所有PE，这样虽然每次权重加载会多花几个周期，但换来了更紧凑的时序收敛。

芯片上调试用的是Vivado内置的ILA逻辑分析仪IP。在线调试时把识别结果有效标志、置信度数值和最终输出字符的ASCII码抓出来观察，对照仿真波形逐帧比对。这里有个经验：ILA采样深度尽量设置在4096以上，因为图像流水线的一次完整推理会产生大量中间数据，采样深度不够常常抓不到真正出问题的那个周期，调试效率很低。

5.3 紫光同创PDS移植与资源适配

紫光同创的平台用的是Logos-2系列FPGA，开发环境是PDS。一个工程从Xilinx迁移到紫光同创，如果代码从一开始就遵循可移植性约束，改动量会非常小，基本只需要新建工程、添加源文件、编写约束文件三件事。PDS的约束语法和Vivado的XDC有差异，但好在两者都遵循业界通用的SDF和SDC风格，时钟约束和引脚约束的基本写法能直接迁移，引脚位置约束需要根据紫光同创开发板的原理图重新分配。

移植中比较麻烦的是原语适配和IP核重建。Xilinx的对应DSP原语在紫光同创里名称和配置接口完全不同，但好在我没有在代码里手工例化厂家DSP原语，而是让综合工具自动推断乘法器和加法器，这部分实现细节由工具自行映射，对应用层透明。异步FIFO和BRAM初始化功能在紫光同创上通过其IP核配置工具重新生成，初始化数据文件沿用之前生成的COE文件，配置界面差别不大，照着配就行。

时序约束在PDS中需要重新校准。两家的器件内部布线延迟模型不同，时序收敛结果也不一样。实际上紫光同创Logos-2在相同100MHz约束下，时序余量比Artix-7紧一些，设计里部分组合逻辑路径需要做优化。我把预处理模块里高斯滤波的三级流水线又加深了一级，把每个算术操作之间插入额外的寄存器来切断长路径，时序问题才彻底缓解。

5.4 双平台性能对比与实测数据

两套平台最终都在板上跑通了端到端车牌识别，性能数据对比如下：

两组数据比较接近，紫光同创因为频率低了一些延迟稍高但在可接受范围。功耗方面紫光同创略低，与其制程有关。实测数据说明一个道理：只要RTL写得好，国产FPGA在同一份逻辑电路上也能跑出和国际主流芯片非常接近的性能，这对于国产化项目选型是一个很有力的参考依据。

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

6.1 仿真正常但上板识别错误的定位方法

这次开发中遇到最头疼的问题是仿真波形完美，一上板就识别出错误字符。这类问题往往不是逻辑功能错误，而是物理实现引入的信号完整性问题。定位思路是从结果反推：先抓最终输出落在哪个字符上与预期不符，再往前推是识别网络的哪一层输出开始出错。用ILA逻辑分析仪抓取识别网络首层卷积输出，和Modelsim仿真波形对比，发现有几个像素位置的输出值异常偏低，最终定位到是输入数据的某个bit上存在电平不稳定的情况，追根溯源是摄像头数据跨时钟域同步时采样窗口刚好落在数据跳变的边沿上。

解决方案是在异步FIFO入口处对输入像素数据做一次额外的延迟对齐，让同步器在数据稳定后再采样。另外在PCB布局上给摄像头数据线并接了33欧姆串联电阻以减小反射，问题彻底消失。经验是仿真和上板的差异问题，优先怀疑跨时钟域和外部输入时序，这两个因素是软件仿真永远覆盖不到的空白地带。

6.2 紫光同创综合报错与处理记录

工程在Vivado上综合实现顺利，换到PDS上第一次综合就报错，提示某个多bit信号的赋值存在仿真和综合语义不一致的问题。具体代码里一段用于生成地址的语句在类型声明和数据位宽扩展上写得不严谨，Vivado的编译器自动做了隐式转换，而PDS的编译器更严格直接报错。这个问题的本质是代码可移植性没有做到位，我花了一个下午把工程里所有类似涉及位宽隐式扩展和截断的地方全部显式表示，用$clog2函数显式计算地址位宽，同时用位拼接语法显式声明数据宽度，之后再没出现过这类编译错误。

另一个常见的问题是PDS综合时对未使用信号的删除策略比Vivado激进，导致综合后的网表功能出现意外变化。解决方法是把用于仿真和调试的信号标记为综合属性保留，或者把这些信号接入一个虚拟输出端口，避免被工具优化掉。

6.3 常见问题速查表

6.4 调试效率提升技巧

最后分享几个提升整车验证效率的技巧。仿真层面，用SystemVerilog接口类封装数据激励生成器，写一个参数化的随机图像发生器，自动生成带噪声和不同光照条件的仿真图像序列，比手动一条条写testbench效率提升明显。板级验证层面，把已识别的字符结果通过UART同时输出到PC串口终端，这样可以实时观察长时间运行的稳定性，不用每次连接JTAG看ILA。

还有一个很有用的技巧，是把网络各层输出的统计量（均值、最大值、非零比例）通过调试接口定期上报。当网络精度异常时，查看哪一层的统计量偏离了预期，能迅速锁定问题层。这套方法在排查一个疑似累加器溢出的问题时发挥了很大作用——最终发现是输出通道累加器的位宽不够，部分通道累加和超过32bit上限发生了溢出，把位宽扩展到40bit后精度完全恢复。这个案例也说明，定点位宽设计不能只看理论最大值，要结合训练好的权重分布去估算，最稳妥的做法是写脚本统计每一层真实输出的动态范围来定累加器位宽，而不是靠猜。

做FPGA加速器，我最大的感受是时序和资源的平衡永远在动态变化中。脉动阵列写出来后，看似一个简单的PE单元，真正调通双平台部署前后花了大半年，踩过很多坑也积累了不少经验。如果你也在做类似的项目，建议从一开始就坚持代码可移植性原则，严格遵守位宽和时序规范。这样即便中途更换目标平台，也不会推倒重来。这个内容后续还可以这样扩展：加入多帧图像流水线并行，让间隔帧的图像在阵列中重叠处理，吞吐量可以再翻一倍，延迟还有继续压缩的空间。