1. 项目缘起为什么非要用FPGA做目标跟踪先聊点背景。这几年嵌入式的目标跟踪需求越来越多小到一两个物体移动检测大到无人机跟拍、AGV小车导航几乎都能看到一个共同瓶颈处理器跑软件的模板匹配帧率上不去。举个我实际调试过的例子在一块主频600MHz的MCU上跑一个64x64模板、128x128搜索区域的SAD匹配全图滑动一次要几亿次绝对差运算单帧耗时300多毫秒所谓“实时跟踪”其实就是每秒两三次的幻灯片。这种体验放在工业视觉或运动控制场景里基本不可用。而FPGA的方案把这些绝对差运算全部拆成硬件流水线同一个时钟节拍里同时做几十路甚至上百路加法把计算量从“串行循环”变成“并行电路”。同样一组参数的SAD匹配FPGA能做到几十微秒一帧配合上帧间搜索范围预测稳稳跑出60fps以上的目标跟踪。所以这个项目标题里“FPGA”“SAD”“模板匹配”“目标跟踪”四个词是环环相扣的SAD是匹配策略模板匹配是把跟踪问题转成搜索问题FPGA是把搜索速度拉到实时的关键。这个项目适合两类人看。一类是刚入门FPGA图像处理、想找一个既有算法深度又有工程壳子的练手项目另一类是已经在用MCU做视觉、被算力卡住想换架构的工程师。我自己做的时候就强烈感觉到SAD模板匹配在FPGA上落地不只是把公式换成硬件代码那么简单里面牵扯到数据缓存、并行度折中、DDR带宽控制、跟踪稳定性每一个环节都有坑。这篇文章就把我踩过的坑和验证过的方案都摆出来尽量按工程实现的思路写清楚。2. SAD算法的硬件化思路先搞懂软件在算什么2.1 SAD的定义和数据流特征SAD全称Sum of Absolute Differences中文常叫绝对差值和。公式很直白把模板图像T和搜索区域中的候选块I做逐像素减法取绝对值再加总得到一个代价值。遍历整个搜索区域代价值最小的那个位置就是匹配结果。用数学语言表示对于模板大小为MxN、搜索图像某个候选位置(u,v)SAD值计算公式为SAD(u,v) Σ(i1 to M) Σ(j1 to N) |T(i,j) - I(ui, vj)|这个公式在CPU上实现就是一个三重循环——外层遍历搜索位置内层累加每个像素差。问题也出在这个三重循环上假设搜索区域是100x100像素模板是16x16那意味着要算100x10010000次候选位置的SAD值每个候选位置又涉及256次绝对差加累加总共是256万次运算。如果是30fps的视频流每秒钟就是7680万次纯运算。对CPU来说这个量级勉强能跑但已经占了大部分算力而且随着模板尺寸和搜索范围增长计算量是指数级膨胀的。但换一个角度看SAD算法天生是“数据并行”的——每个候选位置的运算互相独立不存在树状结构的先后依赖。这正好是FPGA的舒适区用组合逻辑加流水线把256次绝对差运算展平成硬件电路再用多路并行单元同时算多个候选位置计算时间就从“候选位置数乘以模板尺寸”压缩到“模板尺寸加上少量流水线开销”。2.2 搜索策略的选择全搜索还是三步搜索模板匹配的搜索策略直接决定了FPGA资源的用量和实现的复杂程度。全搜索Exhaustive Search最直观在搜索区域内按步长1逐像素滑窗计算每一个候选位置的SAD值找全局最小。优点是精度最高、实现简单缺点是运算量最大。另一种常见思路是三步搜索Three-Step Search或菱形搜索Diamond Search属于快速搜索算法。它通过局部的稀疏采样和逐步细化来压缩候选点数量。可是这类算法在FPGA里实现有一个比较恼人的问题候选点的位置是“动态跳变”的硬件数据流不好规划要么做成多轮迭代控制要么加复杂的取址逻辑。要不了多少资源但时序和面积都不好看。我最终选择了全搜索核心原因有两个。第一FPGA的并行性决定了全搜索的绝对计算量增加并不致命——我只需要把搜索区域的像素行缓存到片内BRAM然后用多路SAD计算单元把候选位置流水起来。第二SAD的代价函数在某些纹理环境下会有多个局部极小值快速搜索容易陷在错误位置上做目标跟踪最忌讳的就是“跟丢了”所以宁可多花一点资源换稳定性。2.3 模板更新的权衡跟踪场景和图像配准场景有个本质区别目标外观会变。旋转、尺度变化、遮挡、光照变化都会让固定模板慢慢失效。所以真正的目标跟踪系统里模板不可能只建一次还得做在线更新。但模板更新的实现分寸需要小心。更新频率太高模板会被错误匹配的噪声污染出现“模板漂移”问题更新频率太低又跟上目标的变化。我最后采用了一个较保守的策略生成两个模板——初始模板和动态模板。初始模板在第一帧手动锁定目标时提取全程保持不动动态模板每隔N帧从当前最佳匹配区域重新截取。最终输出的SAD代价值取两者之中的较小值相当于同时保留了“最开始的形象”和“最近的样子”实测下来比单一模板稳很多。这个策略在FPGA里怎么落其实不复杂。初始模板存在一个BRAM里动态模板存在另一个BRAM里两路SAD计算单元并行跑最后用比较器取小即可。代价是动态模板需要额外的“写回控制”但我后面会说这个写回控制可以复用一个相当透明的DMA通道并不会把代码复杂度拉高太多。3. FPGA整体架构设计从视频输入到跟踪结果输出3.1 系统级数据流这个项目的整体数据流我把它画成一条清晰的主干道视频源输入 → 帧缓存/行缓存 → 搜索区域裁剪模块 → SAD计算阵列 → 最小代价比较器 → 目标坐标输出 → 跟踪结果显示块与块之间用FIFO或RAM总线衔接用一组valid/ready握手信号做跨时钟域处理。我选用的开发板是Xilinx Artix-7系列自带DDR3和HDMI接口摄像头走OV5640的DVP接口输出端接HDMI显示器把搜索框叠加到视频流上。你可能会问为什么中间要经过帧缓存不能直接把摄像头数据实时送到SAD计算模块吗确实可以但限制很大摄像头输出的像素是逐行扫描顺序而搜索区域的滑动需要随机访问“每一行任意位置”的数据。如果只有一个搜索区域那可能要等很多帧才能把所有候选位置扫完得不偿失。所以我的方案是先把完整一帧写到DDR3再从DDR3读出搜索窗口的数据这样跑完一帧大约需要两次DDR读写带宽压力完全可控。实测情况是720p分辨率的一帧大约是1280x720像素灰度图一个字节整帧才900KB左右。DDR3跑166MHz、32位数据位宽理论带宽在800MB/s上下读写两次约1.8MB每帧算上突发开销也就占用不到百分之十几的带宽。留给后续项目扩展的空间也够比如同时跑两路视频或加大模板尺寸。3.2 五大核心模块拆解整体架构的五个核心模块分别是视频输入模块负责接收OV5640或HDMI传入的像素数据完成RGB到YUV再到灰度图的转换输出一个灰度数据流和一个像素valid信号。这里我踩过一个坑忘记把摄像头的同步信号做跨时钟域处理导致偶尔出现整帧花屏。最后在输入侧挂了一级异步FIFO才彻底稳定下来。帧存储与读取模块负责把灰度帧写入DDR3同时响应SAD计算模块的读请求按行突发读出搜索窗口内的数据。这里最关键的参数是burst长度——我设置成64字节的一个burst这样每次DDR读事务的开销被摊薄效率会高很多。搜索区域裁剪模块根据上一帧的目标坐标为中心生成一个以该点为中心、大小可配的搜索窗口并把它当前窗口覆盖的行数据缓存到一组行缓冲BRAM。这部分是整个系统最核心的数据通路因为SAD计算单元每个时钟都要同时读取模板像素和候选窗口像素行缓冲的深度需要和模板宽度对齐。SAD计算阵列由多个并行SAD核心组成每个核心负责一个候选位置的全部累加。我用的是16个并行核心每个核心内部又有4路部分和流水线整体相当于每时钟周期能输出16个候选位置的等价计算量。生成16x16模板在128x128搜索区域的匹配结果实测耗时在1.2ms以下帧率余量很大。最小代价比较器把16个SAD核心的结果并行送入一个树形比较器选出最小值和对应坐标再交给跟踪控制模块。如果候选位置的最小代价大于某个阈值说明当前帧的匹配置信度太低——可能是遮挡或剧烈形变这时跟踪状态机会切换到“重搜索模式”。3.3 模块间接口与握手设计FPGA项目的维护难度随着时间的推移通常会变得很大主要源于模块间接口缺乏统一规范。这个项目里我强制给所有模块定义了一套规则每个输出端口都带valid信号说明数据有效每个输入端口带ready信号说明接收方当前可以接收数据当二者同时有效时表示一拍握手成功。如果有模块暂时没法接收数据ready拉低之后发送方会自动暂停不会丢数据。这套规则最大的好处是可以在调试时对任意两个模块之间插入一个chipscope观察窗口。比如怀疑SAD计算模块输入速率不够直接看它的tvalid和tready波形能立刻判断是上游没送数据还是下游没接收。接口宽度上我踩过一个选择纠结灰度像素用8位SAD阵列内部的累加器用多少位每个候选窗口累加256个8位绝对值差理论最大值是255×2566528017位就能装下。但考虑到累加器位宽过低可能引入溢出问题最终我统一用了20位多出的3位用于中间结果冗余反正BRAM位宽资源也不差这几比特换来的是不用操心底层溢出和后续算法扩展。4. SAD计算阵列的流水线实现细节4.1 数据缓存与行列寻址控制在FPGA上做SAD最难受的不是加法逻辑而是怎么把像素数据安排得让加法器“吃得饱、不饿着”。模板和候选窗口需要同时读取多个像素而这些像素在存储介质里往往是不连续的——内存器件最怕随机读。我的做法是把搜索窗口按“行条带”结构缓存。具体来说在DDR3的帧缓冲里搜索窗口覆盖K行每次把连续的K行全部读到一组行FIFO里。每个新像素进来时最老的一行被丢弃新的像素写入当前行。这样行FIFO里任何时候都保存着“以当前行为底的K行数据”而每个SAD计算核心需要的那K行候选窗口只是这些FIFO行的“滑动子窗口”。读出来的时候再按模板列宽度做一个移位寄存器链每时钟移出一个窗口列。如果你对图像处理存储不熟可以把这个行FIFO想象成一根倾斜的传送带水果像素一个一个排好队往前走而工人SAD计算单元只看眼前固定的一小段带子。带子移动一次工人就换一批“候选样本”这就是滑动窗口的硬件版。模板数据则预先加载到一个双端口BRAM读端口1供模板块读取写端口1供跟踪控制模块更新。因为读取模式是固定的顺序遍历所以BRAM的读时序极其规整不会出现随机访问性能退化。4.2 SAD核心的乘法省略与优化SAD的核心运算是绝对差但在FPGA里做减法再取绝对值其实要小心仿真和综合工具的处理。如果直接写abs(a-b)不同的综合器可能会生成不同的电路结构有时候还会嵌入一个条件选择器面积和延时都很差。我建议手动拆开if (pixel_ref pixel_search) diff pixel_ref - pixel_search; else diff pixel_search - pixel_ref;这明明是个简单操作但手写之后综合工具能识别出一个减法器加一个多路选择器延时会比隐藏abs好不少。你可以把这个优化理解成“给综合工具一张清晰的地图”而不是让它自己去猜你这符号什么意思。每路SAD核心内部我把模板尺寸16x16分成四个4x16的条带每个条带用一棵加法树完成累加最后再把四条支路的和加起来。这样做的目的是压缩关键路径如果一口气把256个像素差全部串联累加组合逻辑的延时已经超过时钟周期时序收敛会非常痛苦。分层之后每个部分拥有单独的处理能力关键路径基本被限制在一个条带内。4.3 并行度与帧率、资源利用率的折中并行度是我在资源约束下不断权衡的一个核心指标。并行度太高了资源爆炸、布线拥塞太低了帧率上不去。以我的Artix-7 35T为例片上有大约20K个CLB等效逻辑单元约33KDSP48数量90个BRAM块总共50块每块36Kb。SAD计算阵列如果开16路并行核心每个核心内部4条加法树总体的加法器硬件规模大约在1000个LUT左右因为绝对差只需要加法和比较器不需要乘法器。再加上行缓存、控制逻辑、视频通路整体LUT占用率大约在42%BRAM用到28块左右DDR控制器的IP也占掉一部分资源。这个资源量不挤留了余量给调试逻辑和后续加卡尔曼滤波。如果你手头板子资源很紧张比如只有几千个LUT的小规模FPGA那也有办法缩减把模板缩小到8x8并行度降到8路。代价是匹配精度下降对于轻微形变的目标还扛得住但对严重遮挡和高相似度背景就很难受了。帧率的理论计算公式T (搜索窗口的列数 × 模板列数) / 每时钟能处理的候选位置数 流水线延迟。以搜索窗口128x128、模板16x16、每时钟并行处理16个候选位置为例大约需要1024个时钟完成全窗口扫描。在150MHz的时钟频率下折算时间约为6.8us加上行缓存加载和帧间切换单帧匹配时间大约在1ms左右跑30fps的视频输入绰绰有余。而如果同一搜索窗口大小改成320x240单帧匹配时间大约会上升到4ms这时还能勉强维持实时性但已经比较吃紧了。所以项目的瓶颈和选题方向一致——瓶颈不在“算得多快”而是在“喂得够不够快”。4.4 时序收敛的关键路径优化SAD阵列的时序收敛是整个工程里最磨人的部分。如果你直接把256路绝对差接成一条加法链子综合工具给出的最大时钟频率通常只有60~80MHz完全不够看。我的优化策略分三层第一层是上面提到的手动分层的加法树每层插入一个流水线寄存器把长链条切断成4~5级时钟频率可以上到150MHz以上。第二层是把绝对差模块的输出打一拍输入端也用寄存器打一拍让组合逻辑的输入输出都“贴边”时序裕量会明显改善。这个操作在代码层面其实就是几个always块的事情但效果立竿见影。第三层是Vivado的综合和布局策略调整。在implement阶段打开“Performance Explore”的策略并添加两条时钟约束跑不出来的时候试一下把SAD阵列的物理位置约束到靠近DDR控制器的地方减少布线延时。我的经验是时钟频率目标设在180MHz比较合理再往上面追要耗费大量时间收益却不明显。5. 工程集成与实验验证从仿真到上板5.1 与FMC接口通信的接线设计处理器这边我用了一块STM32H743通过FMC总线与FPGA通信效果非常好。也就是热词里常出现的“stm32h743和fpga实现fmc通信”这个总线结构其实非常适合“ARM当大脑、FPGA当算力”的异构架构——STM32负责协议解析、跟踪结果后处理、通信上报FPGA专注做图像预处理和SAD匹配。接线要点先把关键信号列清楚FMC数据线16根D[15:0]地址线若干根片选、读使能、写使能再加用于帧同步的中断线。如果后续我选用的板子是7系列FPGA用Bank 500/501接3.3V电平而STM32的FMC引脚也是3.3V电平基本兼容。唯一要特别注意的是信号完整性问题FMC总线速率通常几十兆赫兹排线过长会带来振铃我建议PCB走线不要超过5厘米如果只能用杜邦线就把FMC时钟降到10MHz以下比较安全。5.2 FMC寄存器映射与状态机设计通信的实质是把FPGA内部几个关键寄存器暴露给STM32访问。我的映射表大致如下地址偏移方向含义0x00读目标坐标X16bit0x04读目标坐标Y16bit0x08读当前帧SAD最小代价值20bit0x0C读系统状态锁定/重搜/失锁0x10写模板更新使能0x14写搜索窗口大小配置0x18写匹配阈值配置STM32侧的操作流程很简单——每次检测到FPGA的中断信号一帧匹配完成就通过FMC发起一次突发读把0x00到0x0C的连续地址一次性读回来然后做坐标输出或者卡尔曼滤波预测。FMC读操作本身直接映射到FPGA的寄存器阵列只需要一个简单的decode逻辑和一组同步寄存器。5.3 vivado工程实现与板级验证工程我用了Vivado 2021.2Verilog为主中间用了两个Xilinx官方IPDDR3控制器MIG和Video Timing Controller。整个工程的RTL结构在综合后大概有10个模块代码量约2500行。逻辑设计相对直接最花时间的地方反而在调试上。上板验证我分了三步走。第一步是纯输入验证——直接给FPGA喂一条带已知坐标目标的灰度图DDR里预写入同一帧数据检查SAD输出坐标是否正确。第二步是动态视频验证——接上OV5640摄像头目标用手持一个高对比度的玩具观察搜索框是否跟随。第三步是ARM联动验证——STM32通过FMC读写FPGA寄存器并在串口打印坐标轨迹。测试结果做了一张记录表其中我最满意的一组数据是720p 30fps情况下模板尺寸32x32、搜索窗口128x128FPGA的SAD匹配单帧耗时大约2.1ms搜索框跟随误差控制在3个像素以内占用的LUT资源约43%BRAM 28块。对比纯软件跑同一组参数的耗时加速比大约在150倍左右。6. 卡尔曼滤波的引入坐标平滑与预测6.1 为什么纯SAD匹配还不够稳SAD匹配每帧只输出一个坐标但这个坐标不是绝对平滑的。光照抖动、图像噪声、目标快速运动带来的动态模糊都会让搜索框在小范围内跳来跳去。如果你在显示端叠加一个搜索框这种抖动会特别明显感觉不是跟踪而是“颤抖”。另外一个更严重的问题是快速运动目标的丢帧问题。当目标在两帧之间的位移大于搜索窗口的覆盖范围时SAD匹配直接找不到最优了系统失锁。纯SAD算法无法处理这种情况必须引入运动预测。6.2 卡尔曼滤波器在FPGA里的定点化处理卡尔曼滤波器的经典公式网上到处都有这里不重复推导重点讲FPGA定点化实现。卡尔曼滤波器核心涉及矩阵乘法和协方差更新分别是加法和乘法运算——FPGA有DSP48可用但在高帧率下做浮点太奢侈。所以我全部做了定点化。状态量定义为1维位置和1维速度甚至不用矩阵写法展开成标量方程即可预测 x_pred x_est v_est * dt v_pred v_est P_pred P_est Q更新 K P_pred / (P_pred R) x_est x_pred K * (z - x_pred) P_est (1 - K) * P_pred其中z是当前帧SAD输出的测量坐标。定点化时位置单位取像素速度单位取像素/帧协方差用Q4.12格式乘法用DSP48处理除法用移位和查表近似。这套公式在FPGA里实现起来不到五百行代码却能显著改善跟踪稳定性。6.3 卡尔曼输出与搜索范围自适应的联动加入卡尔曼滤波后SAD搜索窗口不再固定而是根据预测速度和上一帧位置自动调整。比如预测的目标位置是(x_pred, y_pred)那么搜索窗口中心就设在(x_pred, y_pred)搜索半径根据速度大小动态调整速度越快半径越大预留足够的搜索裕量。这个联动在工程上是一个实质性的性能提升手段它一方面让搜索区域“跟着目标走”另一方面通过缩小搜索区域来降低计算量。实测下来固定搜索窗口128x128时CPU资源占用大约43%而自适应搜索窗口约80x80资源占用能降到28%左右同时失锁率还不到原来的三分之一。7. 调试踩坑实录七个高频问题速查7.1 OV5640配置寄存器反复失效老生常谈但老有人踩坑OV5640的初始化序列必须用I2C逐条写入每条寄存器写入后要插入延时。我一开始图快把几百条配置写到一个连续数组里频率调很快摄像头就间歇性不出图。后来在每条写操作之间加了大约100us延时瞬间稳定。7.2 灰度转换后的偏色和对比度问题RGB转灰度我用的是经典公式Y 0.299R 0.587G 0.114B。硬件实现时系数移位近似后会出现轻微偏色跟踪问题还不大但叠加显示框时颜色容易和背景融合。解决办法是加法树实现而不是直接用乘法器否则综合出的DSP数量会多到肉疼。7.3 FMC读回来全为零或全为FFMC通信最常见问题是数据线和地址线的映射错位多半是原理图上标号和FPGA引脚约束没对齐。检查思路很简单STM32写一个0x55到某个寄存器FPGA这边用ILA抓FPGA内部信号如果FPGA里看到了0x55而不是0x00或0xFF说明数据线是对的再写几个不同地址的数据验证地址线。7.4 FPGA内部寄存器的复位时序问题FPGA内的寄存器上电默认值不定而STM32上电后可能立即发起FMC读导致读回来的状态全是不定值。这个问题的根因是复位电路没有hold住。我加了一个上电复位延时计数器让FPGA在配置完成后再额外延迟20ms才释放全局复位状态寄存器全部赋初值。问题立即消失。7.5 模板更新导致搜索框移偏动态模板更新如果直接每帧都更新搜索框会被噪声带跑。这是模板漂移问题。我最后的策略是只有当当前帧的最小SAD值比历史平均值低20%以上时才用小块逐步更新动态模板同时初始模板保持不动。这样既跟上变化又不至于过度污染。7.6 DDR读写带宽不足的表现高分辨率下偶尔会出现匹配结果滞后一整帧的错觉实际上是DDR带宽占满了。排查方法是通过MIG的状态计数器看bandwidth utilization我实测720p单路灰度视频读写只占不到15%但如果同时加了OSD叠加和缩放模块占用率会冲上40%。优化方法是把OSD和缩放合并成一趟读取不要每加一个模块就多读一遍整帧。7.7 Vivado综合后时钟频率上不去这问题基本逃不开“关键路径在哪”的疑问。用report_timing_summary看WNS最差负时序裕量WNS为负的那条路径就是瓶颈。常见解法是回读代码检查有没有在组合逻辑里串了太多运算符尤其是多层嵌套的加法或条件判断。我的SAD累加器第一版就是嵌套了三层条件判断回读后发现关键路径几乎全在那一小段上后来改成分级流水线一次解决。8. 优化扩展方向从SAD到更高级的跟踪策略8.1 基于BISS-C接口的高速编码器数据融合如果你的目标跟踪是在运动平台上做的比如云台、AGV那么目标在图像里的位置变化里其实混合了平台自身的姿态变化和目标的真实移动。这种情况下引入编码器反馈可以大幅提升跟踪稳定性。热词里提到的“FPGA BISS-C”就是指用FPGA的IO高速解码BISS-C协议编码器数据然后直接和视觉坐标做融合。FPGA在这里的优势是BISS-C时钟频率能跑到10MHz以上数据延迟极低能做到真正的实时闭环。8.2 Zynq软核方案与纯FPGA方案的取舍部分项目会引入Zynq处理器在PL端做SAD算法PS端跑Linux系统和上层视觉库。好处是开发灵活、调试方便缺点是需要处理PL-PS之间的地址映射和数据搬运逻辑复杂度会显著增加。如果只是要求“SAD模板匹配卡尔曼滤波”我觉得纯FPGA方案更可控毕竟整个数据流都在硬件里打转一个时钟一个位置的状态机不容易出现软件卡死拖后腿的情况。8.3 面向PCIe的高速视觉采集卡扩展往更大规模走这个SAD匹配核完全可以作为一块PCIe视频采集卡上的算子单元。热词里的“FPGA PCIe RC例子”就是指FPGA做Root Complex主动发起DMA写操作把SAD匹配结果、目标坐标、甚至原始帧数据直接写到上位机内存。我自己在一个工业检测项目里试过这个方向思路也是大致相同的。上了PCIe之后跟踪结果可以以极低延迟送入主机做历史轨迹记录和数据分析整个系统就从“嵌入式单机跟踪”升级为“机台级智能视觉模块”。9. 最后分享一点个人经验做完这个项目再回看最大的感受是SAD模板匹配算法本身非常简单但把一个简单算法在FPGA上做到稳定、高效、可维护考的是对整个数据流和资源分配的通盘理解。模板匹配只是把候选窗口和模板做减法求和真正的价值在于你愿意为每一路像素设计多少并行度、为每一帧搜索分配多大搜索窗口更在于目标会变化时你用什么策略让匹配结果不漂移、不丢失。如果你是从零开始起步我的建议是不要一开始就追求大模板大搜索框。先用16x16模板、64x64搜索区域跑通全流程把SAD核心做出来把和STM32的通信链路打通然后再逐渐加并行度和搜索范围。这个项目真正的门槛不是那一堆加法器而是你把SAD当成一个“硬件组件”来思考的习惯——它的实时性来自电路级并行它的稳定性来自状态机控制和预测滤波不是单纯改几个参数就能解决的。后续如果你想扩展路径也很清晰增加BISS-C接口融合、升级成Zynq软硬协同、或者做PCIe采集卡都是在现有SAD核心上做的增量开发。但一切扩展都依赖于你的基础框架是否扎实至少对我来说把SAD在FPGA上做到这个程度之后再回去看那些复杂的视频算法会少很多畏惧感。 基于FPGA的SAD模板匹配实时目标跟踪系统设计与实现
1. 项目缘起为什么非要用FPGA做目标跟踪先聊点背景。这几年嵌入式的目标跟踪需求越来越多小到一两个物体移动检测大到无人机跟拍、AGV小车导航几乎都能看到一个共同瓶颈处理器跑软件的模板匹配帧率上不去。举个我实际调试过的例子在一块主频600MHz的MCU上跑一个64x64模板、128x128搜索区域的SAD匹配全图滑动一次要几亿次绝对差运算单帧耗时300多毫秒所谓“实时跟踪”其实就是每秒两三次的幻灯片。这种体验放在工业视觉或运动控制场景里基本不可用。而FPGA的方案把这些绝对差运算全部拆成硬件流水线同一个时钟节拍里同时做几十路甚至上百路加法把计算量从“串行循环”变成“并行电路”。同样一组参数的SAD匹配FPGA能做到几十微秒一帧配合上帧间搜索范围预测稳稳跑出60fps以上的目标跟踪。所以这个项目标题里“FPGA”“SAD”“模板匹配”“目标跟踪”四个词是环环相扣的SAD是匹配策略模板匹配是把跟踪问题转成搜索问题FPGA是把搜索速度拉到实时的关键。这个项目适合两类人看。一类是刚入门FPGA图像处理、想找一个既有算法深度又有工程壳子的练手项目另一类是已经在用MCU做视觉、被算力卡住想换架构的工程师。我自己做的时候就强烈感觉到SAD模板匹配在FPGA上落地不只是把公式换成硬件代码那么简单里面牵扯到数据缓存、并行度折中、DDR带宽控制、跟踪稳定性每一个环节都有坑。这篇文章就把我踩过的坑和验证过的方案都摆出来尽量按工程实现的思路写清楚。2. SAD算法的硬件化思路先搞懂软件在算什么2.1 SAD的定义和数据流特征SAD全称Sum of Absolute Differences中文常叫绝对差值和。公式很直白把模板图像T和搜索区域中的候选块I做逐像素减法取绝对值再加总得到一个代价值。遍历整个搜索区域代价值最小的那个位置就是匹配结果。用数学语言表示对于模板大小为MxN、搜索图像某个候选位置(u,v)SAD值计算公式为SAD(u,v) Σ(i1 to M) Σ(j1 to N) |T(i,j) - I(ui, vj)|这个公式在CPU上实现就是一个三重循环——外层遍历搜索位置内层累加每个像素差。问题也出在这个三重循环上假设搜索区域是100x100像素模板是16x16那意味着要算100x10010000次候选位置的SAD值每个候选位置又涉及256次绝对差加累加总共是256万次运算。如果是30fps的视频流每秒钟就是7680万次纯运算。对CPU来说这个量级勉强能跑但已经占了大部分算力而且随着模板尺寸和搜索范围增长计算量是指数级膨胀的。但换一个角度看SAD算法天生是“数据并行”的——每个候选位置的运算互相独立不存在树状结构的先后依赖。这正好是FPGA的舒适区用组合逻辑加流水线把256次绝对差运算展平成硬件电路再用多路并行单元同时算多个候选位置计算时间就从“候选位置数乘以模板尺寸”压缩到“模板尺寸加上少量流水线开销”。2.2 搜索策略的选择全搜索还是三步搜索模板匹配的搜索策略直接决定了FPGA资源的用量和实现的复杂程度。全搜索Exhaustive Search最直观在搜索区域内按步长1逐像素滑窗计算每一个候选位置的SAD值找全局最小。优点是精度最高、实现简单缺点是运算量最大。另一种常见思路是三步搜索Three-Step Search或菱形搜索Diamond Search属于快速搜索算法。它通过局部的稀疏采样和逐步细化来压缩候选点数量。可是这类算法在FPGA里实现有一个比较恼人的问题候选点的位置是“动态跳变”的硬件数据流不好规划要么做成多轮迭代控制要么加复杂的取址逻辑。要不了多少资源但时序和面积都不好看。我最终选择了全搜索核心原因有两个。第一FPGA的并行性决定了全搜索的绝对计算量增加并不致命——我只需要把搜索区域的像素行缓存到片内BRAM然后用多路SAD计算单元把候选位置流水起来。第二SAD的代价函数在某些纹理环境下会有多个局部极小值快速搜索容易陷在错误位置上做目标跟踪最忌讳的就是“跟丢了”所以宁可多花一点资源换稳定性。2.3 模板更新的权衡跟踪场景和图像配准场景有个本质区别目标外观会变。旋转、尺度变化、遮挡、光照变化都会让固定模板慢慢失效。所以真正的目标跟踪系统里模板不可能只建一次还得做在线更新。但模板更新的实现分寸需要小心。更新频率太高模板会被错误匹配的噪声污染出现“模板漂移”问题更新频率太低又跟上目标的变化。我最后采用了一个较保守的策略生成两个模板——初始模板和动态模板。初始模板在第一帧手动锁定目标时提取全程保持不动动态模板每隔N帧从当前最佳匹配区域重新截取。最终输出的SAD代价值取两者之中的较小值相当于同时保留了“最开始的形象”和“最近的样子”实测下来比单一模板稳很多。这个策略在FPGA里怎么落其实不复杂。初始模板存在一个BRAM里动态模板存在另一个BRAM里两路SAD计算单元并行跑最后用比较器取小即可。代价是动态模板需要额外的“写回控制”但我后面会说这个写回控制可以复用一个相当透明的DMA通道并不会把代码复杂度拉高太多。3. FPGA整体架构设计从视频输入到跟踪结果输出3.1 系统级数据流这个项目的整体数据流我把它画成一条清晰的主干道视频源输入 → 帧缓存/行缓存 → 搜索区域裁剪模块 → SAD计算阵列 → 最小代价比较器 → 目标坐标输出 → 跟踪结果显示块与块之间用FIFO或RAM总线衔接用一组valid/ready握手信号做跨时钟域处理。我选用的开发板是Xilinx Artix-7系列自带DDR3和HDMI接口摄像头走OV5640的DVP接口输出端接HDMI显示器把搜索框叠加到视频流上。你可能会问为什么中间要经过帧缓存不能直接把摄像头数据实时送到SAD计算模块吗确实可以但限制很大摄像头输出的像素是逐行扫描顺序而搜索区域的滑动需要随机访问“每一行任意位置”的数据。如果只有一个搜索区域那可能要等很多帧才能把所有候选位置扫完得不偿失。所以我的方案是先把完整一帧写到DDR3再从DDR3读出搜索窗口的数据这样跑完一帧大约需要两次DDR读写带宽压力完全可控。实测情况是720p分辨率的一帧大约是1280x720像素灰度图一个字节整帧才900KB左右。DDR3跑166MHz、32位数据位宽理论带宽在800MB/s上下读写两次约1.8MB每帧算上突发开销也就占用不到百分之十几的带宽。留给后续项目扩展的空间也够比如同时跑两路视频或加大模板尺寸。3.2 五大核心模块拆解整体架构的五个核心模块分别是视频输入模块负责接收OV5640或HDMI传入的像素数据完成RGB到YUV再到灰度图的转换输出一个灰度数据流和一个像素valid信号。这里我踩过一个坑忘记把摄像头的同步信号做跨时钟域处理导致偶尔出现整帧花屏。最后在输入侧挂了一级异步FIFO才彻底稳定下来。帧存储与读取模块负责把灰度帧写入DDR3同时响应SAD计算模块的读请求按行突发读出搜索窗口内的数据。这里最关键的参数是burst长度——我设置成64字节的一个burst这样每次DDR读事务的开销被摊薄效率会高很多。搜索区域裁剪模块根据上一帧的目标坐标为中心生成一个以该点为中心、大小可配的搜索窗口并把它当前窗口覆盖的行数据缓存到一组行缓冲BRAM。这部分是整个系统最核心的数据通路因为SAD计算单元每个时钟都要同时读取模板像素和候选窗口像素行缓冲的深度需要和模板宽度对齐。SAD计算阵列由多个并行SAD核心组成每个核心负责一个候选位置的全部累加。我用的是16个并行核心每个核心内部又有4路部分和流水线整体相当于每时钟周期能输出16个候选位置的等价计算量。生成16x16模板在128x128搜索区域的匹配结果实测耗时在1.2ms以下帧率余量很大。最小代价比较器把16个SAD核心的结果并行送入一个树形比较器选出最小值和对应坐标再交给跟踪控制模块。如果候选位置的最小代价大于某个阈值说明当前帧的匹配置信度太低——可能是遮挡或剧烈形变这时跟踪状态机会切换到“重搜索模式”。3.3 模块间接口与握手设计FPGA项目的维护难度随着时间的推移通常会变得很大主要源于模块间接口缺乏统一规范。这个项目里我强制给所有模块定义了一套规则每个输出端口都带valid信号说明数据有效每个输入端口带ready信号说明接收方当前可以接收数据当二者同时有效时表示一拍握手成功。如果有模块暂时没法接收数据ready拉低之后发送方会自动暂停不会丢数据。这套规则最大的好处是可以在调试时对任意两个模块之间插入一个chipscope观察窗口。比如怀疑SAD计算模块输入速率不够直接看它的tvalid和tready波形能立刻判断是上游没送数据还是下游没接收。接口宽度上我踩过一个选择纠结灰度像素用8位SAD阵列内部的累加器用多少位每个候选窗口累加256个8位绝对值差理论最大值是255×2566528017位就能装下。但考虑到累加器位宽过低可能引入溢出问题最终我统一用了20位多出的3位用于中间结果冗余反正BRAM位宽资源也不差这几比特换来的是不用操心底层溢出和后续算法扩展。4. SAD计算阵列的流水线实现细节4.1 数据缓存与行列寻址控制在FPGA上做SAD最难受的不是加法逻辑而是怎么把像素数据安排得让加法器“吃得饱、不饿着”。模板和候选窗口需要同时读取多个像素而这些像素在存储介质里往往是不连续的——内存器件最怕随机读。我的做法是把搜索窗口按“行条带”结构缓存。具体来说在DDR3的帧缓冲里搜索窗口覆盖K行每次把连续的K行全部读到一组行FIFO里。每个新像素进来时最老的一行被丢弃新的像素写入当前行。这样行FIFO里任何时候都保存着“以当前行为底的K行数据”而每个SAD计算核心需要的那K行候选窗口只是这些FIFO行的“滑动子窗口”。读出来的时候再按模板列宽度做一个移位寄存器链每时钟移出一个窗口列。如果你对图像处理存储不熟可以把这个行FIFO想象成一根倾斜的传送带水果像素一个一个排好队往前走而工人SAD计算单元只看眼前固定的一小段带子。带子移动一次工人就换一批“候选样本”这就是滑动窗口的硬件版。模板数据则预先加载到一个双端口BRAM读端口1供模板块读取写端口1供跟踪控制模块更新。因为读取模式是固定的顺序遍历所以BRAM的读时序极其规整不会出现随机访问性能退化。4.2 SAD核心的乘法省略与优化SAD的核心运算是绝对差但在FPGA里做减法再取绝对值其实要小心仿真和综合工具的处理。如果直接写abs(a-b)不同的综合器可能会生成不同的电路结构有时候还会嵌入一个条件选择器面积和延时都很差。我建议手动拆开if (pixel_ref pixel_search) diff pixel_ref - pixel_search; else diff pixel_search - pixel_ref;这明明是个简单操作但手写之后综合工具能识别出一个减法器加一个多路选择器延时会比隐藏abs好不少。你可以把这个优化理解成“给综合工具一张清晰的地图”而不是让它自己去猜你这符号什么意思。每路SAD核心内部我把模板尺寸16x16分成四个4x16的条带每个条带用一棵加法树完成累加最后再把四条支路的和加起来。这样做的目的是压缩关键路径如果一口气把256个像素差全部串联累加组合逻辑的延时已经超过时钟周期时序收敛会非常痛苦。分层之后每个部分拥有单独的处理能力关键路径基本被限制在一个条带内。4.3 并行度与帧率、资源利用率的折中并行度是我在资源约束下不断权衡的一个核心指标。并行度太高了资源爆炸、布线拥塞太低了帧率上不去。以我的Artix-7 35T为例片上有大约20K个CLB等效逻辑单元约33KDSP48数量90个BRAM块总共50块每块36Kb。SAD计算阵列如果开16路并行核心每个核心内部4条加法树总体的加法器硬件规模大约在1000个LUT左右因为绝对差只需要加法和比较器不需要乘法器。再加上行缓存、控制逻辑、视频通路整体LUT占用率大约在42%BRAM用到28块左右DDR控制器的IP也占掉一部分资源。这个资源量不挤留了余量给调试逻辑和后续加卡尔曼滤波。如果你手头板子资源很紧张比如只有几千个LUT的小规模FPGA那也有办法缩减把模板缩小到8x8并行度降到8路。代价是匹配精度下降对于轻微形变的目标还扛得住但对严重遮挡和高相似度背景就很难受了。帧率的理论计算公式T (搜索窗口的列数 × 模板列数) / 每时钟能处理的候选位置数 流水线延迟。以搜索窗口128x128、模板16x16、每时钟并行处理16个候选位置为例大约需要1024个时钟完成全窗口扫描。在150MHz的时钟频率下折算时间约为6.8us加上行缓存加载和帧间切换单帧匹配时间大约在1ms左右跑30fps的视频输入绰绰有余。而如果同一搜索窗口大小改成320x240单帧匹配时间大约会上升到4ms这时还能勉强维持实时性但已经比较吃紧了。所以项目的瓶颈和选题方向一致——瓶颈不在“算得多快”而是在“喂得够不够快”。4.4 时序收敛的关键路径优化SAD阵列的时序收敛是整个工程里最磨人的部分。如果你直接把256路绝对差接成一条加法链子综合工具给出的最大时钟频率通常只有60~80MHz完全不够看。我的优化策略分三层第一层是上面提到的手动分层的加法树每层插入一个流水线寄存器把长链条切断成4~5级时钟频率可以上到150MHz以上。第二层是把绝对差模块的输出打一拍输入端也用寄存器打一拍让组合逻辑的输入输出都“贴边”时序裕量会明显改善。这个操作在代码层面其实就是几个always块的事情但效果立竿见影。第三层是Vivado的综合和布局策略调整。在implement阶段打开“Performance Explore”的策略并添加两条时钟约束跑不出来的时候试一下把SAD阵列的物理位置约束到靠近DDR控制器的地方减少布线延时。我的经验是时钟频率目标设在180MHz比较合理再往上面追要耗费大量时间收益却不明显。5. 工程集成与实验验证从仿真到上板5.1 与FMC接口通信的接线设计处理器这边我用了一块STM32H743通过FMC总线与FPGA通信效果非常好。也就是热词里常出现的“stm32h743和fpga实现fmc通信”这个总线结构其实非常适合“ARM当大脑、FPGA当算力”的异构架构——STM32负责协议解析、跟踪结果后处理、通信上报FPGA专注做图像预处理和SAD匹配。接线要点先把关键信号列清楚FMC数据线16根D[15:0]地址线若干根片选、读使能、写使能再加用于帧同步的中断线。如果后续我选用的板子是7系列FPGA用Bank 500/501接3.3V电平而STM32的FMC引脚也是3.3V电平基本兼容。唯一要特别注意的是信号完整性问题FMC总线速率通常几十兆赫兹排线过长会带来振铃我建议PCB走线不要超过5厘米如果只能用杜邦线就把FMC时钟降到10MHz以下比较安全。5.2 FMC寄存器映射与状态机设计通信的实质是把FPGA内部几个关键寄存器暴露给STM32访问。我的映射表大致如下地址偏移方向含义0x00读目标坐标X16bit0x04读目标坐标Y16bit0x08读当前帧SAD最小代价值20bit0x0C读系统状态锁定/重搜/失锁0x10写模板更新使能0x14写搜索窗口大小配置0x18写匹配阈值配置STM32侧的操作流程很简单——每次检测到FPGA的中断信号一帧匹配完成就通过FMC发起一次突发读把0x00到0x0C的连续地址一次性读回来然后做坐标输出或者卡尔曼滤波预测。FMC读操作本身直接映射到FPGA的寄存器阵列只需要一个简单的decode逻辑和一组同步寄存器。5.3 vivado工程实现与板级验证工程我用了Vivado 2021.2Verilog为主中间用了两个Xilinx官方IPDDR3控制器MIG和Video Timing Controller。整个工程的RTL结构在综合后大概有10个模块代码量约2500行。逻辑设计相对直接最花时间的地方反而在调试上。上板验证我分了三步走。第一步是纯输入验证——直接给FPGA喂一条带已知坐标目标的灰度图DDR里预写入同一帧数据检查SAD输出坐标是否正确。第二步是动态视频验证——接上OV5640摄像头目标用手持一个高对比度的玩具观察搜索框是否跟随。第三步是ARM联动验证——STM32通过FMC读写FPGA寄存器并在串口打印坐标轨迹。测试结果做了一张记录表其中我最满意的一组数据是720p 30fps情况下模板尺寸32x32、搜索窗口128x128FPGA的SAD匹配单帧耗时大约2.1ms搜索框跟随误差控制在3个像素以内占用的LUT资源约43%BRAM 28块。对比纯软件跑同一组参数的耗时加速比大约在150倍左右。6. 卡尔曼滤波的引入坐标平滑与预测6.1 为什么纯SAD匹配还不够稳SAD匹配每帧只输出一个坐标但这个坐标不是绝对平滑的。光照抖动、图像噪声、目标快速运动带来的动态模糊都会让搜索框在小范围内跳来跳去。如果你在显示端叠加一个搜索框这种抖动会特别明显感觉不是跟踪而是“颤抖”。另外一个更严重的问题是快速运动目标的丢帧问题。当目标在两帧之间的位移大于搜索窗口的覆盖范围时SAD匹配直接找不到最优了系统失锁。纯SAD算法无法处理这种情况必须引入运动预测。6.2 卡尔曼滤波器在FPGA里的定点化处理卡尔曼滤波器的经典公式网上到处都有这里不重复推导重点讲FPGA定点化实现。卡尔曼滤波器核心涉及矩阵乘法和协方差更新分别是加法和乘法运算——FPGA有DSP48可用但在高帧率下做浮点太奢侈。所以我全部做了定点化。状态量定义为1维位置和1维速度甚至不用矩阵写法展开成标量方程即可预测 x_pred x_est v_est * dt v_pred v_est P_pred P_est Q更新 K P_pred / (P_pred R) x_est x_pred K * (z - x_pred) P_est (1 - K) * P_pred其中z是当前帧SAD输出的测量坐标。定点化时位置单位取像素速度单位取像素/帧协方差用Q4.12格式乘法用DSP48处理除法用移位和查表近似。这套公式在FPGA里实现起来不到五百行代码却能显著改善跟踪稳定性。6.3 卡尔曼输出与搜索范围自适应的联动加入卡尔曼滤波后SAD搜索窗口不再固定而是根据预测速度和上一帧位置自动调整。比如预测的目标位置是(x_pred, y_pred)那么搜索窗口中心就设在(x_pred, y_pred)搜索半径根据速度大小动态调整速度越快半径越大预留足够的搜索裕量。这个联动在工程上是一个实质性的性能提升手段它一方面让搜索区域“跟着目标走”另一方面通过缩小搜索区域来降低计算量。实测下来固定搜索窗口128x128时CPU资源占用大约43%而自适应搜索窗口约80x80资源占用能降到28%左右同时失锁率还不到原来的三分之一。7. 调试踩坑实录七个高频问题速查7.1 OV5640配置寄存器反复失效老生常谈但老有人踩坑OV5640的初始化序列必须用I2C逐条写入每条寄存器写入后要插入延时。我一开始图快把几百条配置写到一个连续数组里频率调很快摄像头就间歇性不出图。后来在每条写操作之间加了大约100us延时瞬间稳定。7.2 灰度转换后的偏色和对比度问题RGB转灰度我用的是经典公式Y 0.299R 0.587G 0.114B。硬件实现时系数移位近似后会出现轻微偏色跟踪问题还不大但叠加显示框时颜色容易和背景融合。解决办法是加法树实现而不是直接用乘法器否则综合出的DSP数量会多到肉疼。7.3 FMC读回来全为零或全为FFMC通信最常见问题是数据线和地址线的映射错位多半是原理图上标号和FPGA引脚约束没对齐。检查思路很简单STM32写一个0x55到某个寄存器FPGA这边用ILA抓FPGA内部信号如果FPGA里看到了0x55而不是0x00或0xFF说明数据线是对的再写几个不同地址的数据验证地址线。7.4 FPGA内部寄存器的复位时序问题FPGA内的寄存器上电默认值不定而STM32上电后可能立即发起FMC读导致读回来的状态全是不定值。这个问题的根因是复位电路没有hold住。我加了一个上电复位延时计数器让FPGA在配置完成后再额外延迟20ms才释放全局复位状态寄存器全部赋初值。问题立即消失。7.5 模板更新导致搜索框移偏动态模板更新如果直接每帧都更新搜索框会被噪声带跑。这是模板漂移问题。我最后的策略是只有当当前帧的最小SAD值比历史平均值低20%以上时才用小块逐步更新动态模板同时初始模板保持不动。这样既跟上变化又不至于过度污染。7.6 DDR读写带宽不足的表现高分辨率下偶尔会出现匹配结果滞后一整帧的错觉实际上是DDR带宽占满了。排查方法是通过MIG的状态计数器看bandwidth utilization我实测720p单路灰度视频读写只占不到15%但如果同时加了OSD叠加和缩放模块占用率会冲上40%。优化方法是把OSD和缩放合并成一趟读取不要每加一个模块就多读一遍整帧。7.7 Vivado综合后时钟频率上不去这问题基本逃不开“关键路径在哪”的疑问。用report_timing_summary看WNS最差负时序裕量WNS为负的那条路径就是瓶颈。常见解法是回读代码检查有没有在组合逻辑里串了太多运算符尤其是多层嵌套的加法或条件判断。我的SAD累加器第一版就是嵌套了三层条件判断回读后发现关键路径几乎全在那一小段上后来改成分级流水线一次解决。8. 优化扩展方向从SAD到更高级的跟踪策略8.1 基于BISS-C接口的高速编码器数据融合如果你的目标跟踪是在运动平台上做的比如云台、AGV那么目标在图像里的位置变化里其实混合了平台自身的姿态变化和目标的真实移动。这种情况下引入编码器反馈可以大幅提升跟踪稳定性。热词里提到的“FPGA BISS-C”就是指用FPGA的IO高速解码BISS-C协议编码器数据然后直接和视觉坐标做融合。FPGA在这里的优势是BISS-C时钟频率能跑到10MHz以上数据延迟极低能做到真正的实时闭环。8.2 Zynq软核方案与纯FPGA方案的取舍部分项目会引入Zynq处理器在PL端做SAD算法PS端跑Linux系统和上层视觉库。好处是开发灵活、调试方便缺点是需要处理PL-PS之间的地址映射和数据搬运逻辑复杂度会显著增加。如果只是要求“SAD模板匹配卡尔曼滤波”我觉得纯FPGA方案更可控毕竟整个数据流都在硬件里打转一个时钟一个位置的状态机不容易出现软件卡死拖后腿的情况。8.3 面向PCIe的高速视觉采集卡扩展往更大规模走这个SAD匹配核完全可以作为一块PCIe视频采集卡上的算子单元。热词里的“FPGA PCIe RC例子”就是指FPGA做Root Complex主动发起DMA写操作把SAD匹配结果、目标坐标、甚至原始帧数据直接写到上位机内存。我自己在一个工业检测项目里试过这个方向思路也是大致相同的。上了PCIe之后跟踪结果可以以极低延迟送入主机做历史轨迹记录和数据分析整个系统就从“嵌入式单机跟踪”升级为“机台级智能视觉模块”。9. 最后分享一点个人经验做完这个项目再回看最大的感受是SAD模板匹配算法本身非常简单但把一个简单算法在FPGA上做到稳定、高效、可维护考的是对整个数据流和资源分配的通盘理解。模板匹配只是把候选窗口和模板做减法求和真正的价值在于你愿意为每一路像素设计多少并行度、为每一帧搜索分配多大搜索窗口更在于目标会变化时你用什么策略让匹配结果不漂移、不丢失。如果你是从零开始起步我的建议是不要一开始就追求大模板大搜索框。先用16x16模板、64x64搜索区域跑通全流程把SAD核心做出来把和STM32的通信链路打通然后再逐渐加并行度和搜索范围。这个项目真正的门槛不是那一堆加法器而是你把SAD当成一个“硬件组件”来思考的习惯——它的实时性来自电路级并行它的稳定性来自状态机控制和预测滤波不是单纯改几个参数就能解决的。后续如果你想扩展路径也很清晰增加BISS-C接口融合、升级成Zynq软硬协同、或者做PCIe采集卡都是在现有SAD核心上做的增量开发。但一切扩展都依赖于你的基础框架是否扎实至少对我来说把SAD在FPGA上做到这个程度之后再回去看那些复杂的视频算法会少很多畏惧感。