FPGA车牌识别实战：OV5640+HDMI纯硬件流水线方案

1. 项目缘起与整体方案拆解

1.1 为什么选FPGA做车牌识别，而不是树莓派或Jetson

这个项目最早来自一个很实际的需求：园区门口的道闸系统想换一套低延迟、不依赖云端、断网也能跑的识别方案。市面上现成的车牌识别一体机大多是ARM+NPU的路线，比如RK系列或者Jetson Nano，跑YOLO或者轻量级检测网络，识别率确实高，但有几个绕不开的问题：一是延迟不稳定，Linux调度加上USB摄像头采集，端到端经常在80到150毫秒之间抖动；二是功耗和散热，夏天户外机箱里跑久了容易降频；三是成本，带NPU的核心板加摄像头模组，批量下来也不便宜。

FPGA方案的核心优势在于流水线确定性延迟。从OV5640的DVP并口出像素，到HDMI输出识别结果，整条链路可以做成纯硬件流水线，每一帧的处理时间固定，不依赖操作系统调度。我实测下来，从sensor曝光到HDMI显示框选结果，延迟稳定在2到3帧，按60fps算就是33到50毫秒，这个数字对道闸场景完全够用。

选OV5640而不是MIPI摄像头，主要是接口友好度。OV5640支持DVP并口输出，8位或10位数据加PCLK、HREF、VSYNC，直接接FPGA的IO就行，不需要额外的MIPI接收IP核。MIPI虽然线少，但FPGA端要处理高速串行解串，对布局布线要求高，入门门槛陡增。OV5640的寄存器配置走SCCB（本质是I2C），Verilog写个状态机就能搞定，网上参考代码也多。

HDMI输出这块，我用的是RGB888转TMDS的经典方案。FPGA内部生成720p或者1080p的时序，把处理后的图像数据打包成TMDS差分信号，通过HDMI接口送到显示器。这里要注意，HDMI的TMDS编码不是简单的并串转换，要做8b/10b编码和直流平衡，Xilinx和Intel都有官方参考设计，但自己用Verilog撸一遍对理解协议帮助很大。

车牌识别算法本身，我没有上深度学习。原因很直接：FPGA上跑CNN要么用HLS写得很别扭，要么得外挂NPU，那就失去纯FPGA方案的意义了。我采用的是传统图像处理+形态学+字符模板匹配的路线，具体包括灰度化、Sobel边缘检测、颜色空间转换做蓝牌定位、投影法分割字符、最后用归一化互相关做字符识别。这套算法在FPGA上可以完全流水线化，资源占用可控，识别率在标准蓝牌上能到95%以上。

提示：这个项目适合有一定Verilog基础、想从点灯和UART进阶到图像处理的开发者。如果你连状态机和跨时钟域都没写过，建议先把基础打牢再上手，否则调试I2C和时序会非常痛苦。

1.2 系统框图与数据流设计

整个系统的数据流是这样的：OV5640上电后通过SCCB配置成720p、RGB565输出、30fps。DVP接口的8位数据在PCLK上升沿有效，HREF高电平期间是有效行，VSYNC下降沿表示一帧开始。FPGA端第一级是采集模块，把DVP时序转成标准的行场同步信号，同时做跨时钟域处理，把像素时钟域的数据搬到系统时钟域。

第二级是图像预处理。RGB565先转灰度，用经典的加权公式：Y = 0.299R + 0.587G + 0.114B。FPGA里不能直接浮点乘，我把它定点化成整数运算：Y = (77R + 150G + 29*B) >> 8。这个系数是2的8次方缩放后的近似值，误差在1个灰度级以内，肉眼看不出来。灰度图同时送两路：一路做Sobel边缘检测，一路做颜色筛选。

第三级是车牌定位。蓝牌的特点是蓝色背景、白色字符，在HSV空间里蓝色有明确的色调范围。但RGB转HSV在FPGA里开销大，我改用简化的RGB判据：B分量大于R和G，且B大于某个阈值，同时R和G的差值在一定范围内。这样能把蓝色区域粗筛出来，再用Sobel边缘做垂直纹理验证，排除纯蓝背景的干扰。

第四级是字符分割与识别。定位到车牌区域后，用水平投影找字符的上下边界，垂直投影找左右边界。投影法在FPGA里实现很自然，就是逐行逐列累加二值化后的像素。分割出7个字符后，每个字符归一化成32x64的点阵，和预存的模板做匹配。模板匹配用绝对差值和（SAD）而不是互相关，因为SAD只需要减法和累加，没有乘法，省DSP资源。

第五级是HDMI显示。原始图像和识别结果叠加，车牌位置画绿色矩形框，识别出的字符用点阵字库叠加在画面下方。HDMI时序生成器产生720p@60Hz的时序，像素数据从帧缓存里读出来，经过TMDS编码输出。

帧缓存这块有个坑：720p一帧是1280x720，RGB888就是2.7MB，片上BRAM肯定放不下。我的做法是只缓存处理后的二值图或者缩小后的灰度图，原始图像直接旁路到HDMI，识别结果用叠加的方式画上去。这样BRAM占用从2.7MB降到几百KB，用几块BRAM就能搞定。

2. 核心模块的Verilog实现细节

2.1 OV5640的SCCB配置与DVP采集时序

OV5640上电后不能直接出图，必须先通过SCCB写一堆寄存器。SCCB协议和I2C几乎一样，只是没有重复起始条件，读操作稍微不同。我用一个简单的状态机实现写时序：START -> 发送设备地址（0x78写）-> ACK -> 发送寄存器高字节 -> ACK -> 发送低字节 -> ACK -> STOP。每个bit在SCL低电平期间变化，高电平期间稳定。

寄存器配置我参考了正点原子的初始化序列，关键几项是：0x3103写0x11做软件复位，0x3017和0x3018配置时钟使能，0x3034到0x3037配置PLL，0x3808到0x380B设置输出尺寸1280x720，0x4300设置RGB565输出。整个序列大概200多个寄存器，我把它存成ROM，上电后顺序写一遍。

DVP采集的Verilog核心是边沿检测和跨时钟域。PCLK是摄像头输出的像素时钟，频率大概72MHz（720p@30fps）。系统时钟我用100MHz。跨时钟域不能直接打拍，我用的是异步FIFO，写端在PCLK域，读端在系统时钟域。FIFO深度不用太大，存几行就行，因为后续处理是流水线的，不会积压。

// DVP行有效信号同步示例 reg href_d1, href_d2; always @(posedge pclk) begin href_d1 <= href; href_d2 <= href_d1; end wire href_rise = href_d1 & ~href_d2; wire href_fall = ~href_d1 & href_d2;

VSYNC的处理类似，但要注意OV5640的VSYNC极性可以配置，我习惯用下降沿表示帧开始。每帧开始时复位行计数器，HREF上升沿开始写FIFO，下降沿结束一行。

注意：OV5640的PCLK在没配置好之前是不输出的，所以SCCB配置完成后要等一段时间再开始采集。我一般延时100ms，确保sensor稳定。

2.2 RGB565转灰度的定点数优化

RGB565是16位，R占5位、G占6位、B占5位。转灰度时要把它们扩展到8位再算。R和B左移3位，G左移2位，这样都是8位。然后套公式：

wire [7:0] r8 = {r5, r5[4:2]}; // 5位扩展到8位 wire [7:0] g8 = {g6, g6[5:4]}; // 6位扩展到8位 wire [7:0] b8 = {b5, b5[4:2]}; wire [15:0] y_temp = 77*r8 + 150*g8 + 29*b8; wire [7:0] y = y_temp[15:8]; // 右移8位

这里77、150、29是0.299、0.587、0.114乘以256后的近似值。误差分析：0.299256=76.544，取77；0.587256=150.272，取150；0.114*256=29.184，取29。总和256，保证亮度不偏移。实测和MATLAB的rgb2gray对比，最大误差2个灰度级，对后续处理没影响。

定点数在FPGA里的核心原则是能移位就不乘法，能加法就不移位。比如除以2就是右移1位，乘以3可以写成(x<<1)+x。Sobel算子的系数是1、2、1，直接用加法和移位搞定，不需要DSP。

2.3 Sobel边缘检测的流水线设计

Sobel需要3x3的窗口，所以要先做行缓存。我用两个BRAM存前两行，当前行直接进来，三个行数据拼成3x3窗口。行缓存的宽度是图像宽度1280，深度是2，每个像素8位。

窗口生成后，Gx和Gy的计算是：

// Gx = (p00 + 2*p01 + p02) - (p20 + 2*p21 + p22) // Gy = (p00 + 2*p10 + p20) - (p02 + 2*p12 + p22) wire [9:0] gx = (p00 + {p01,1'b0} + p02) - (p20 + {p21,1'b0} + p22); wire [9:0] gy = (p00 + {p10,1'b0} + p20) - (p02 + {p12,1'b0} + p22);

注意这里用10位有符号数，因为结果可能是负的。最后取绝对值相加得到梯度幅值：|Gx| + |Gy|。这个近似比平方根省资源，效果差不多。

流水线设计上，行缓存读出需要1个周期，窗口计算1个周期，梯度计算1个周期，阈值比较1个周期，总共4级流水。每级之间用寄存器打拍，保证时序收敛。

实操心得：Sobel的阈值不要设死，我做成可调的寄存器，通过UART或者拨码开关改。不同光照下最佳阈值差别很大，固定值在阴天和晴天表现天差地别。

2.4 蓝牌定位的颜色判据与形态学处理

蓝牌的蓝色在RGB空间大概是R=50~100，G=80~130，B=150~255。我用的判据是：

wire is_blue = (b8 > 8'd120) && (b8 > r8 + 8'd30) && (b8 > g8 + 8'd20);

这个条件比HSV转换省太多资源，而且对光照变化有一定鲁棒性。粗筛出来的二值图会有噪点，需要形态学处理。我用的是先腐蚀后膨胀的开运算，去掉孤立噪点，再做先膨胀后腐蚀的闭运算，填补车牌内部的空洞。

形态学在FPGA里用3x3窗口的与或运算实现。腐蚀就是窗口内所有像素相与，膨胀是相或。为了流水线，腐蚀和膨胀各需要一行缓存，总共4个BRAM。开运算和闭运算串起来，就是4级形态学流水。

2.5 投影法字符分割的硬件实现

投影法分水平投影和垂直投影。水平投影是统计每一行白色像素的个数，垂直投影统计每一列。在FPGA里，我用累加器数组实现：每来一个像素，如果二值图是1，对应行的累加器加1，对应列的累加器加1。一帧结束后，累加器的值就是投影曲线。

找字符边界时，扫描投影曲线，找到连续非零区域的起止点。水平投影找到车牌的上下边界，垂直投影找到7个字符的左右边界。这里有个细节：中文车牌第一个字符是汉字，宽度和后面的字母数字不一样，分割时要单独处理。我的做法是先用垂直投影找到所有字符的粗略边界，然后根据宽度判断哪个是汉字，汉字单独送汉字模板库匹配。

投影法的Verilog核心是双口RAM，一个端口写累加，一个端口读结果。累加器位宽要够，1280列的投影最大是720，10位就够。

3. 完整实操流程与关键配置

3.1 硬件选型与电路连接要点

我用的开发板是Xilinx Artix-7系列的，具体型号不重要，关键是资源要够：至少50K逻辑单元、100个DSP、2MB以上的BRAM。OV5640模组买的是带DVP接口的，注意要选带晶振的版本，有些模组需要外部提供XCLK，接线麻烦。

HDMI输出用的是一个简单的电阻网络方案，不用专门的HDMI发送芯片。TMDS差分对用FPGA的LVDS引脚直接驱动，串联100欧姆电阻做阻抗匹配。这里要注意，HDMI的TMDS时钟是像素时钟的10倍，720p@60Hz的像素时钟是74.25MHz，TMDS时钟就是742.5MHz，Artix-7的LVDS引脚能跑到这个速度，但布局布线要小心，差分对要等长。

电源部分，OV5640需要2.8V和1.5V两路，开发板一般有现成的LDO。HDMI的5V供电直接从板子取，但要注意电流，HDMI接收端可能会拉低HPD信号，FPGA要能检测这个信号再决定是否输出。

注意：OV5640的DVP接口是3.3V电平，FPGA的IO bank要设成3.3V。如果bank电压不对，要么不工作，要么烧IO。

3.2 时钟树与复位策略

整个系统有四个时钟域：PCLK（72MHz）、系统时钟（100MHz）、HDMI像素时钟（74.25MHz）、SCCB时钟（100kHz）。我用一个MMCM生成系统时钟和HDMI时钟，PCLK直接从摄像头来，SCCB时钟用计数器分频。

复位策略上，异步复位同步释放是必须的。每个时钟域都要有自己的复位同步器，避免亚稳态。全局复位信号来自一个按键，经过消抖后送到各时钟域的同步器。

// 异步复位同步释放 reg [1:0] rst_sync; always @(posedge clk or posedge rst_async) begin if (rst_async) rst_sync <= 2'b00; else rst_sync <= {rst_sync[0], 1'b1}; end wire rst_n = rst_sync[1];

跨时钟域的数据传递，除了FIFO，控制信号用脉冲同步器或者握手协议。比如帧开始信号从PCLK域传到系统时钟域，我用一个toggle信号加边沿检测，比直接打拍可靠。

3.3 图像处理流水线的时序收敛

图像处理流水线跑在100MHz系统时钟下，每级处理一个像素。720p一行1280个像素，行时间是1280个周期，加上消隐大概1600个周期。一帧720行，总共约115万个周期，100MHz下是11.5毫秒，30fps的帧间隔是33毫秒，时间余量很大。

时序收敛的关键是减少组合逻辑级数。Sobel的梯度计算我拆成两级：第一级算Gx和Gy的部分和，第二级做减法。形态学的3x3窗口也是先算行和，再算列和。每级之间都打拍，保证关键路径不超过10ns。

BRAM的读写要注意读写冲突。行缓存用简单双口RAM，一个端口写当前行，一个端口读旧行，地址错开就不会冲突。如果实在冲突，可以加一个周期的等待，但会影响吞吐。

3.4 字符模板匹配的定点化实现

字符识别我用的是归一化互相关的简化版。每个字符归一化成32x64的二值图，模板也是32x64。匹配时逐像素做XNOR，统计相同像素的个数。这个操作在FPGA里就是位运算加累加，非常高效。

模板库我存了数字0-9、字母A-Z、以及常见汉字。汉字模板比较大，我单独用一个BRAM存。匹配时，输入字符和所有模板并行比较，取相似度最高的作为结果。并行比较的代价是资源，36个模板同时比较需要36个累加器，但Artix-7的DSP够用。

实操心得：模板匹配对字符切分的精度要求很高。如果切分时多切了一列或者少切了一列，匹配率会断崖式下降。我的做法是在切分后做质心对齐，把字符的质心移到模板的中心，这样对切分误差有一定容忍度。

4. 调试踩坑与问题排查实录

4.1 OV5640不出图的常见原因

第一次上电，HDMI显示全黑，用逻辑分析仪抓PCLK，发现根本没有时钟。排查下来是SCCB配置没成功。用示波器看SCL和SDA，发现SDA一直被拉低，说明从机没有应答。检查设备地址，OV5640的写地址是0x78，读地址是0x79，我一开始写成了0x7A，改过来就好了。

还有一种情况是PCLK有输出，但图像是花屏。这通常是数据位序反了。OV5640的DVP可以配置成高字节在前或者低字节在前，寄存器0x4300的低4位控制这个。我一开始没注意，RGB565的两个字节反了，颜色完全不对。

如果图像有但很暗，检查曝光寄存器。OV5640的自动曝光需要时间收敛，上电后前几帧可能很暗，等一两秒就好了。如果一直暗，可能是0x3500到0x3503的曝光设置不对。

4.2 HDMI无输出的排查思路

HDMI没输出，先看HPD信号。显示器通过HPD告诉源端它准备好了，如果HPD是低，FPGA不应该输出TMDS。我用一个LED指示HPD状态，发现插上显示器后HPD一直是低，换了一根HDMI线就好了，原来是线材的HPD针脚接触不良。

如果HPD正常但没图像，检查TMDS时钟。用示波器测差分对的共模电压，正常应该在3.3V左右。如果共模电压不对，可能是LVDS引脚的配置错了，要设成TMDS_33标准。

还有一种情况是图像有但颜色不对。HDMI的TMDS编码有8b/10b的直流平衡，如果编码器写错了，颜色会偏。我一开始忘了做异或还是同或的选择，HDMI规范要求根据前一个bit的直流平衡来决定，写错了颜色就反了。

4.3 图像处理中的典型问题速查

注意：SignalTap或者ILA是调试FPGA图像处理的利器，但会占用BRAM资源。如果BRAM紧张，可以只抓关键信号，比如行有效、帧有效、二值图输出。

4.4 资源占用与优化经验

整个系统在Artix-7 35T上跑，资源占用大概是：LUT 60%、FF 45%、BRAM 70%、DSP 30%。BRAM是瓶颈，因为行缓存和帧缓存占了大头。优化方向有几个：一是把灰度图从8位降到6位，BRAM省25%；二是行缓存用移位寄存器代替BRAM，但只适合窗口很小的场景；三是把模板匹配的模板存到外部Flash，用的时候加载到BRAM。

DSP主要用在Sobel的乘2和灰度转换的乘法。如果DSP不够，可以把乘2改成移位，灰度转换用分布式算法，用LUT代替乘法器。

功耗方面，Artix-7 35T在100MHz下大概0.5W，加上OV5640和HDMI驱动，整板不到1.5W。夏天户外机箱里加个小风扇就够了，不需要散热片。

5. 识别率提升与场景适配

5.1 光照变化的应对策略

车牌识别最怕光照不均。地库入口逆光、晴天正午过曝、晚上补光灯直射，都会让二值化效果崩掉。我的做法是加一个自适应阈值模块：统计当前帧的灰度直方图，取中位数作为阈值，而不是固定值。直方图统计在FPGA里用BRAM做累加器，256个bin，每帧清零一次。

如果光照变化太快，还可以做局部自适应，把图像分成16x16的小块，每块单独算阈值。但这样BRAM开销大，我一般只在高端型号上用。

5.2 车牌倾斜与透视校正

摄像头安装角度不对，车牌会有梯形畸变。简单的做法是只做水平校正，用Sobel的垂直边缘做Hough变换找倾斜角，然后旋转图像。Hough变换在FPGA里实现比较复杂，我用的简化版：统计每一行的边缘点位置，拟合直线求斜率。

如果倾斜不大（±10度以内），其实可以不做校正，模板匹配对小幅倾斜有一定容忍度。超过10度，识别率会明显下降，这时候要么调摄像头角度，要么上校正。

5.3 多车牌与运动模糊的处理

一帧里有多辆车，会有多个车牌区域。我的做法是连通域标记，把二值图里的连通区域找出来，每个区域单独做投影分割。连通域标记用两遍扫描法，第一遍记录等价对，第二遍合并。FPGA里用并查集实现，资源开销不大。

运动模糊是高速场景的问题。如果车开得快，车牌在曝光期间移动，图像会糊。解决办法是缩短曝光时间，但会变暗。OV5640支持自动曝光，但自动曝光在运动场景下反应慢。我一般手动设曝光，配合补光灯。

实操心得：识别率不是越高越好，要看场景。道闸场景车速慢，识别率95%够用；高速卡口要求99%以上，那就得上深度学习。FPGA方案的优势是确定性和低延迟，不是绝对识别率。

6. 后续扩展与个人体会

这套系统我前后调了大概两个月，从点灯到出图到识别，每一步都有坑。最大的体会是：FPGA图像处理的核心不是算法，是数据流。算法再牛，数据流设计不好，时序收敛不了，照样跑不起来。我一开始想把所有处理塞进一个always块，结果综合出来时序一塌糊涂，后来拆成流水线，每级打拍，问题就解决了。

后续可以扩展的方向有几个：一是加UART输出，把识别结果送到上位机或者道闸控制器；二是加SD卡存储，把识别记录和抓拍图存下来；三是上双目摄像头，做测距和车型识别。如果资源够，还可以把模板匹配换成轻量级CNN，用HLS写，识别率能再上一个台阶。

最后分享一个小技巧：调试图像处理时，先把HDMI直通做好，确保摄像头到显示器的链路是通的，再一级一级加处理模块。每加一级，用SignalTap抓一次，确认数据正确再继续。这样出问题容易定位，不会一锅粥。