FPGA图像处理实战：SAD模板匹配硬件加速架构设计全解析

开头直接从实际迭代经验切入，论速讲完为什么SAD和FPGA是绝配，自然带出全文章节。

1. 为什么SAD模板匹配是FPGA图像处理最容易上手、也最能出成果的方向

做FPGA图像处理这几年，我一直有个观点：模板匹配里的SAD算法，是硬件加速性价比最高的入门项目之一。原因很简单——它算法逻辑非常直白，几乎不涉及复杂的状态机跳转，主要工作就是"算绝对差、做累加"；而这两件事恰好是FPGA最擅长的并行流水线操作。把一张1920x1080的灰度图在纯软件上做全图模板匹配，用普通CPU可能要几十毫秒甚至上百毫秒，而FPGA一旦把流水线架起来，即便跑在只有100MHz的时钟下，延迟也能压到微秒级往返，帧率轻松超百。把这个项目吃透，等于同时打通了图像前处理、DSP运算、时序约束、资源优化这几条主线，后续再做光流、卷积网络加速，思路基本是相通的。

有人可能会问，现在深度学习目标检测这么火，为什么还要回来研究SAD这种"老古董"？实际工程项目里，很多场景根本用不起大模型。比如高速产线上的工件定位、巡线小车的目标跟随、显微镜载物台上的细胞追踪，这些场景对延迟极其敏感，而且大多不需要识别目标类别，只要"锁定某个已知外观的物体，持续报出它的坐标"就够了。SAD模板匹配在这种场景下有两个不可替代的优势：一是无需训练，给定一张模板图就能开工；二是行为完全可预测，不会像神经网络那样出现难以排查的偶发漏检。FPGA把这事做成硬件逻辑后，功耗通常只有几瓦，很适合嵌入到工业设备里。

这篇文章我打算从算法原理讲起，但重点放在硬件架构推导上。很多人拿到SAD题目后第一反应是"我会写C语言，把它翻译成Verilog不就行了"，结果一动手就卡住——双边循环在硬件里怎么展开？窗口数据从哪来？累加器为什么总是差一拍？这些都是纯软件思维解决不了的问题。接下来我会按照实际工程推进的顺序，把行缓存、滑动窗、加法树、时序估算这些东西挨个拆开讲清楚，每部分都有可直接照搬的硬件结构和计算式。最后再聊几个我在调试中真实踩过的坑，以及从"能跑"到"跑得稳"的进阶策略。

2. SAD的数学本质，以及它对硬件设计提出的三个核心要求

2.1 差分累加运算为什么天然适合并行化

SAD的全称是Sum of Absolute Differences，中文叫绝对差值和。它的数学定义非常简洁：给定一个大小为M行N列的模板T，以及图像中某个候选位置(x,y)处同样大小的窗口像素块I，二者之间的SAD值就是：

SAD(x,y) = Σ(i=0~M-1) Σ(j=0~N-1) | I(x+i, y+j) - T(i,j) |

这个值越小，说明候选窗口与模板越相似。目标跟踪的思路就是：在上一帧目标位置周围开一个搜索区域，遍历其中每个候选位置，算出各自的SAD值，找最小值所在的位置作为当前帧的目标位置。

从硬件角度看，这个公式描述了M×N次独立的减法、取绝对值、累加操作。所有减法之间没有任何数据依赖，理论上M×N个减法器可以同时开工，这就是并行性的来源。但并行不是无限并行的，它能并行到什么程度，完全取决于"窗口数据以什么方式送到运算单元面前"，这就引出了硬件设计的一系列问题。

2.2 穷举搜索的计算量到底有多大：一个必须提前做的心算

我们先算一笔账，你就明白硬件架构该怎么取舍了。假设图像尺寸是640x480，模板尺寸是32x32，搜索范围是目标可能出现的所有位置，那么候选位置约为(640-32+1)×(480-32+1)≈609×449≈27.3万个。每个候选位置要算32×32=1024次绝对差累加，总计算量约为2.8亿次加减运算。如果一秒钟处理25帧，那就是每秒70亿次运算。这个量级用通用MCU做实时处理完全没戏，用高性能DSP也得掂量掂量，但FPGA内部有成百上千个DSP Slice和LUT逻辑，只要带宽跟得上，拆成多路并行流水线，70亿次/秒并不夸张。

账面数字算完之后，硬件设计的目标也清晰了，归纳起来就是三个核心要求：

• 数据供给要连续：运算单元不能闲着等待数据，图像像素必须像流水一样源源不断送进来。这需要合理的缓存架构来配合。
• 滑动窗口要复用：相邻候选位置的窗口有大面积重叠，绝不能把每个窗口都当成独立的数据块去重复读取或重复计算，否则带宽和逻辑都会被白白浪费。
• 比较器与缓存要跟上：每个位置产生一个SAD值后，需要快速和当前最小值比较并更新。这个小模块看似不起眼，但在高速流水线下很容易成为时序瓶颈。

这三个要求就是后面所有硬件设计的出发点。接下来我用一款入门级FPGA（比如Xilinx Artix-7或者国产等效型号）作为参考平台，逐步展开架构设计。

3. 行缓存与滑动窗口：SAD硬件架构的第一块基石

3.1 图像按行扫描，模板匹配要按块处理——这个矛盾怎么解

摄像头或图像传感器输出的像素是逐行连续的：先完整输出第0行，再第1行，以此类推。但SAD运算需要的是以当前行为基准、向上取M-1行的正方形块数据。这意味着我们要把最近输入的M行数据先暂存起来，形成一个可同时读取M行、每行N个像素的"数据窗口"。这个结构在FPGA里就是行缓存。

行缓存的实现方式很经典：用M-1个FIFO或BRAM组成的移位链。新像素进来后写入第0个缓存，同时每个缓存的输出连接到下一级缓存输入，这样每一拍每个缓存输出端都对应着图像里不同行的同一列像素。时序关系上可以这样理解：

第k行像素输入 → 写缓存0 缓存0输出 → 缓存1输入（这是延迟了一行的数据） 缓存1输出 → 缓存2输入（这是延迟了两行的数据） ...

最终，在某个时钟周期，缓存0~M-2的输出端会同时呈现"当前输入像素、上一行同列像素、上上行同列像素……"共M-1个像素，再加上当前输入这一路，就凑齐了一个列方向上的M×1条带。行缓存设计里有两个容易出问题的细节：一是缓存深度必须恰好等于图像一行有效像素数，多一拍少一拍都会导致行错位；二是行有效信号（Line Valid）要跟着数据延迟对齐，否则你没法确定窗口数据哪个时刻是真正有效的。

3.2 一维条带如何扩展成二维窗口：三级缓存结构

行缓存只能给我们一列M个像素，但SAD需要M行N列。所以还需要在行缓存输出之后再接一组列方向的移位寄存器阵列，把时间上先后的M×1条带组合成M×N的二维窗口。具体做法是：

• 沿着行缓存链路设置M×N个寄存器（排成M行N列的矩阵）；
• 每个寄存器在时钟上升沿把相邻像素传递下去；
• 新到的列条带整体压入矩阵最右侧一列，整个矩阵向右平移一格。

这样持续N个时钟周期后，寄存器矩阵里就是完整的M×N窗口了。这个结构叫滑动窗口缓存（Sliding Window Buffer）。它和行缓存一起，构成了SAD引擎的数据前端。资源上需要M×N个寄存器，对32×32窗口来说就是1024个触发器，在一颗几十万逻辑单元的中端FPGA里完全不是负担。但如果你用的是非常小的FPGA，或者窗口开得特别大，也可以用BRAM来模拟移位寄存器，Xilinx在Vivado里有专门的SRL16原语和自动推断机制，可以让资源占用大幅下降。

这里有两条工程经验值得单独说：

• 行缓存数量与模板行数严格对应：模板是32行，行缓存层级就是31级（或31个FIFO），加当前像素行正好32。不要为了省BRAM牺牲行数，否则窗口底部会混入错误行数据。
• 行列两个维度的数据移位方向必须与坐标方向一致：很多第一次做的人会在这里绕晕，到最后调试时发现SAD值不对，其实就是Y方向上下颠倒或者X方向左右镜像。我的习惯是在RTL里给每个窗口像素寄存器都用window[row][col]这种二维数组命名，仿真波形里一眼就能看出对应位置。

3.3 模板缓存：别忽略这个看似不起眼的跨时钟域设计

模板T在硬件里也占用M×N个寄存器，数值在开始跟踪前由上位机或软核写入。这里出现了第一个需要仔细处理的问题：模板数据不是跟着视频流同步走的，它来自另一个时钟域或总线域。如果你直接把模板寄存器组放在像素时钟域里用异步信号去写，很容易出现亚稳态，导致模板中某个像素值偶尔被写成随机数，SAD结果自然会间歇性异常。

稳妥做法是双缓存结构：外部总线先把模板写入一块"影子RAM"，等到帧同步信号（Frame Sync）到来时，用一个时钟周期把影子RAM的数据整体搬到运算用的模板寄存器组。这样既保证了模板更新的原子性，又避免了跨时钟域写冲突。这个细节看起来很小，但在实际项目中，模板加载不稳定恰恰是SAD匹配结果飘忽不定的一个隐形元凶。

4. 并行差分加加窗累加：SAD引擎高效计算的核心架构设计

4.1 一列之差：如何把每像素一次计算压到每个周期输出一个SAD值

数学上看，SAD每个候选位置要做M×N次减法和累加。最容易想到的硬件做法是：窗口每移动一个像素，就重新算一遍整个M×N窗口的绝对差和。这样每输出一个SAD值需要M×N个时钟周期，扫描整帧要几千万个周期，实时性完全无从谈起。

真正高性能的做法是利用滑动窗口的行间、列间重叠关系，把计算量摊薄到每个周期只算"新进入窗口的那一列"。

具体分两步：

第一步，差分行缓存。窗口里每个像素和模板对应像素的绝对差可以先算出来，得到M行、每行N个"绝对差值"。这M×N个差值，逐行做N点加法，得到M行各自的"行差分和"。这一操作在硬件里是M条并行的加法链。

第二步，列向加窗累加。行差分和序列沿Y方向滑动，每次窗口位置Y变化时，新窗口的行差分和 = 旧窗口的行差分和 - 顶部移出的行值 + 底部新进入的行值。这一步本质上是滑动和问题，在硬件里用加法器和寄存器就能实现。

这样一来，每来一个新像素列，只需计算新列与模板列的M个绝对差，再做一次滑动更新，就能输出一个新的SAD值。一个像素的计算代价从M×N次降低到M次加减，输出节拍也从M×N个周期压到1个周期。这就是纯软件算法和硬件流式架构在思维上的最大不同：软件总在重复计算重叠区域，而硬件把重叠区域的计算结果"寄存"起来反复利用。

4.2 加法树与流水线：让M×N个减法器不闲置的关键

窗口一列进入后，M个绝对差是怎么变成"行差分和"的？答案是加法树。我们假定8位灰度图像，模板也是8位，绝对差结果为8位（0~255）。8个8位数相加，结果最大2040，需要11位；16个相加最大4080，至少12位。一般来说，M=16或32时，一级加法树用两两相加，3到5个流水级就能出结果，每一级都要把中间结果打拍到寄存器里，避免组合逻辑延迟过长。

这里有个很容易被新人忽略的点：加法树每一级的位宽要随数据增大而增加。8位+8位会得到9位结果，9位+9位得到10位。如果你图省事统一用8位寄存器存加法树中间结果，数值一超过255就会截断出错，SAD值变得毫无意义。我的习惯是先用一个小的Python脚本或Excel按模板尺寸把每级位宽算清楚，再动手写RTL，绝不在写代码时凭感觉估位宽。

以32×32模板为例，32路8位绝对差，加法树分为5级：32→16→8→4→2→1。每级寄存器位宽建议分别为9、10、11、12、13位。最后得到的一个"列方向差分和"最大就是32×255=8160，用14位寄存器存放，后面滑动累加时再用带符号数或补码处理加减即可。

4.3 加窗累加器：用四级寄存器组把相邻SAD值的计算量复用起来

列向滑动窗口的累加器设计是SAD引擎的灵魂，我单独把它画成结构说明。假设行方向窗口宽度为N，我们用N个寄存器line_sum[0..N-1]分别保存"当前SAD窗口里第j列对应的列差分和"。每次来一个新列，实际流程是：

1. 新列进入后，算出新列的列差分和new_col_sum，送入累加器；
2. 把它写入line_sum数组里新位置，同时读出最老的那个old_col_sum（它对应从窗口右侧滑出的那一列）；
3. 计算sad_current = sad_previous - old_col_sum + new_col_sum。

如果把sad_current再打一拍寄存，就能保证每个周期稳定输出一个有效的SAD值。这个累加器实际上就是4个寄存器组：old_col_sum、new_col_sum、sad_previous、sad_current。它们的位宽从14位一路扩展到最终SAD值位宽，32×32模板最大值就是32×32×255=261120，需要18位。很多人在这一步又忘了扩位，导致SAD值在高相似区域出现"平的假谷底"，排查起来相当隐蔽。

流水线节奏上，从"新列进入窗口"到"sad_current更新完成"，大约需要加法树的流水级数+2拍的延迟。只要保证外部输入像素速率低于这个节拍上限，整个引擎可以做到每个时钟周期输出一个候选位置的SAD值，没有任何气泡。

4.4 为什么端点位置会出现"半个窗口"：边界处理策略

滑动窗口沿图像移动时，窗口中心靠近图像左上、右下等边界时，窗口的一部分会越过图像范围。硬件上这时行缓存或窗口寄存器里读到的数据可能是无效填充值，也可能混入上一行残留。处理办法通常有三种：

• 限制候选区域：只搜索距离边界至少半个模板尺寸的范围。实现最简单，也够用，缺点是最边缘的目标会漏掉，但工程上目标大概率不会卡在画面最边上。
• 边界像素复制或补零：把越界部分用边缘像素或0填充。这么做SAD值在边界附近会虚高，可能出现假最小点，需要后级加一个"边界有效标志"来屏蔽无效最小值。
• 输出带有效标志：不做数据修正，只把越界位置的比较器使能信号拉低，让它不参与最佳匹配竞争。我推荐这种做法，逻辑开销极小且最稳。

从搜索区域角度来看，FPGA实现全图穷举SAD没有一个统一的"正确"做法，它取决于帧率要求。如果搜索区域缩小到目标周围64×64窗口，单帧计算量只有约4096个候选位置（32×32模板），那就算完全不做加窗复用，硬算也能在几万周期内完成。这样也引出了一个重要思路：在硬件里做运动估计时，往往用小范围搜索+上一帧位置引导，而不是全图穷举。这是后话，第7节展开讲。

5. 从"能算"到"算得快"：搜索区域、帧率与资源三者如何权衡

5.1 实测帧率：用公式给自己一个明确预期

SAD引擎完成一帧搜索的总周期数约等于扫描的有效像素数。如果搜索区域为W_sw×H_sw（单位是像素），则大约需要W_sw×H_sw + 流水线填满周期数个时钟。帧率就可以估算为：

FPS ≈ f_clk ÷ (W_sw × H_sw)

举个例子，摄像头输出1280×720分辨率，跟踪目标模板64×64，搜索区域限定在128×128，像素时钟100MHz，那么实测算出的帧率上限约100MHz÷16384≈6100FPS。实际加上行有效间隙、帧消隐、模板加载等开销，至少也能到几千帧每秒。这个帧率是纯软件方案望尘莫及的。但如果你非要全图穷举，搜索区域接近1280×720≈92万个位置，那帧率就只剩100MHz÷92万≈108FPS，也不算慢，但此时模板并行度、窗口缓存位宽都会成为瓶颈。所以先明确搜索策略，再定硬件规模是很有必要的。

5.2 减小搜索区域的工程技巧：上一帧位置引导+环形缓冲

既然全图穷举消耗大，那工程上常见的做法就是以目标上一帧位置为中心，划定一个有限搜索窗，例如64×64或128×128。这个思路说起来简单，但硬件上有个隐藏难题：摄像头是逐行扫描的，目标在第100行时，第200行像素还没到；等第200行到了，第100行数据早被行缓存移出去了。如果你只在"当前输入帧"上挖搜索窗，就必然要等整帧存完再处理，这又需要帧缓存，BRAM压力一下就上去了。

务实方案有两种：

• 环形帧缓存：用一片外部DDR或大容量BRAM存整帧，SAD搜索时按需读取搜索窗内像素。这一方案的优点是灵活，缺点是外部存储带宽会成为新的瓶颈，多花不少时序收敛的功夫。
• 分块交叠扫描：不让搜索区域跨越行缓存深度范围，而是把搜索窗设计成"跟随扫描行移动"的流式窗口。比如目标前一行在新输入行到来前刚被处理完，那窗口就可以立刻覆盖到目标附近区域，避免等整帧。这个实现稍微复杂，但在很多连续跟踪场景下非常实用——目标帧间位移通常不大，没必要花大力气做全帧缓存。

我个人经验是：第一次做这个项目时尽量选"上一帧引导+有限搜索窗+行缓存流式处理"的架构，省资源且帧率极高；后续再考虑扩展全帧搜索能力。这样才能快速看到"框住目标并实时输出坐标"的完整效果，建立起对硬件图像链路的全局感。

5.3 资源评估：一套具体数字供参考

下面是64×64模板、128×128搜索区域、8位灰度图、100MHz像素时钟条件下在Xilinx Artix-7 XC7A35T上的资源估算。这个型号非常常见，国内开发板也便宜。

如果你的FPGA资源比这少，可以缩小模板或搜索窗。搜索窗缩到64×64时，帧率还能翻倍，BRAM压力也小不少。资源评估的核心结论是：SAD模板匹配并不吃DSP乘法器，吃的是LUT逻辑和RAM带宽，选型时不必盲目追求带大量DSP的高端芯片。

6. 实测调试中逃不掉的那几个坑：时序、位宽、边界、对齐

6.1 行缓存与窗口数据的老大难：行对齐和有效信号延迟

这个坑我前后踩了两个晚上，最后是靠仿真波形才定位的。现象是SAD输出值整体偏小，尤其在图像纹理少的地方，最小值位置随机乱跳。原因出在行缓存输出数据和行有效信号没有对齐：行缓存本身有固定的延迟周期，如果你只是简单地把行有效信号打了一拍，而没有把列窗口同步移位逻辑的每一级都算进去，窗口里第0行的数据实际上是第-1行或第1行，整个窗口在纵向发生了错位，相似度自然全乱了。

解决思路非常机械但有效：给行同步信号（Line Valid）和帧同步信号（Frame Valid）建立与像素数据路径完全一致的延迟链。窗口寄存器组每向右移动一格，有效信号就跟着打一拍，直到它和第一个完整有效的SAD结果同时出现。这组延迟链的分支数，就是窗口列移位寄存器矩阵的总级数。我建议在仿真阶段就打印"有效信号+首个SAD值"对应的坐标，和软件参考结果比对，能提前暴露90%的对齐问题。

6.2 位宽截断是最隐蔽的"假谷底"制造者

前文反复强调位宽，是因为这确实是新手最容易犯、老手偶尔也会犯的错误。我遇到过一种情况：SAD值在某个平坦背景区域异常小，甚至逼近0，导致目标跟踪器突然跳到背景上去。排查到最后发现，加法树某一级位宽不足，绝对值差分和在高纹理区域发生了溢出截断，反而让原本应该很大的SAD值变小了。

这类问题用仿真不容易一眼看出来，因为波形上只是"数值变小了"，没有明显的错误标志。我的排查方法是用脚本算出一组已知图像的参考SAD值，存成文件，然后和FPGA仿真输出逐点比对。凡是差值不为零的位置，基本都能定位到具体的位宽截断或流水线节拍问题。比对不通过时，先把所有中间累加器的位宽都加宽2~3位重新仿真，如果差值消失，就说明原先位宽确实不够用。

6.3 搜索窗跨越行缓存边界时的数据空洞

采用流式行缓存结构时，如果目标快跑到图像最上方或最下方，搜索窗会越过行缓存能覆盖的范围，此时行缓存里读到的数据要么是旧帧残留，要么是无效数据。这个问题尤其容易在目标做快速纵向运动时爆发，表现是目标明明还在画面里，SAD最小值却卡在边界处不动。

解决方案是给搜索窗增加一个"有效性掩码"模块，该模块实时比较搜索窗纵坐标与行缓存实际覆盖的行范围，一旦越界就把该候选位置的比较器使能信号拉低。输出端只统计有效区域的SAD最小值，避免边界垃圾数据参与竞争。这样即使搜索窗部分越界，也不会导致跟踪点被拽到边界上去。

7. 从单点SAD到稳的目标跟踪：卡尔曼滤波、模板更新与多尺度策略

7.1 让SAD结果"干净"起来：为什么必须加位置滤波

SAD在每一帧独立计算最小位置，它只考虑"当前帧哪个位置最像模板"，完全不利用时间连续性。实际视频里目标外观会变化，光照会抖动，偶尔背景里还会出现和模板相似度同样高的干扰物。于是输出的目标坐标会夹杂大量随机跳变，跟踪框看起来一直在抖。

解决思路是在FPGA里加一个卡尔曼滤波器，把SAD输出的观测位置平滑成预测位置。卡尔曼滤波的硬件实现并不复杂：状态变量只有位置(x,y)和速度(vx,vy)四个维度，矩阵运算规模很小，用定点数实现即可，完全不需要浮点DSP。我在实际工程里的做法是：先用SAD在预测位置周围的小窗内搜索，再用卡尔曼对观测值做递推更新，两步交替进行。实测帧率几乎不受影响，但跟踪稳定性提升非常明显。

7.2 模板固定不变会跟丢：流式模板更新的硬件实现

模板匹配算法最大的弱点就是模板老旧。目标可能缓缓转动、缩放或改变姿态，如果模板一直是第一帧的样子，时间一长SAD最小值就不再准确落在目标中心，跟踪点会逐渐漂走。工程上通常采用加权更新策略：

T_new = (1-α) × T_old + α × T_current_match

其中T_current_match是当前帧匹配到的窗口像素，α一般在0.05~0.2之间取。α太小更新太慢跟不上形变，α太大又容易让模板被背景污染。硬件上这个公式相当于对每个像素做一次乘加，64×64模板就是4096路乘加，资源开销不小。折中方案是分时更新：不是每帧都更新全部像素，而是每帧只更新模板中的一行或一列，轮询一圈完成整体刷新。这样需要的乘加器数量大幅下降，模板仍然能平滑演进。

7.3 处理目标大小变化：图像金字塔与多尺度SAD

如果目标在跟踪过程中会明显靠近或远离摄像头，模板尺寸就不固定了。纯SAD用一个尺寸的模板去匹配缩放后的目标，效果往往欠佳。FPGA里做多尺度比PC上麻烦，但有一种轻量做法值得尝试：在做SAD之前，先对输入图像做二分之一降采样，得到低分辨率图像；低分辨率下先用较大的搜索窗粗定位，再用原分辨率做小范围精匹配。这样既解决了目标变小时模板过大的匹配失效问题，又不会显著占用额外资源。降采样可以用简单的2×2均值或抽取实现，BRAM开销不大。

多尺度要命的地方在"尺度选择和模板金字塔更新"之间相互耦合：模板尺度变了，模板库里该匹配哪个尺寸就得多一层判断。如果目标尺度变化很慢，也可以直接用上一条的模板更新策略自然应对；只有尺度突变时才需要金字塔。这个取舍没有标准答案，完全取决于你的实际视频场景。

8. 从一个可跑通的Demo到一套完整可交付的目标跟踪系统

8.1 系统架构建议：摄像头输入、SAD引擎、坐标输出三件套

做FPGA图像处理项目，我最推荐的第一步是搭一个最小闭环系统，而不是一上来就写大而全的算法模块。最小闭环包含三部分：

• 图像采集接口：用OV5640或类似摄像头模组输出灰度或RGB565数据，通过I2C配置分辨率（推荐640×480或1280×720起跑）；
• SAD匹配引擎：本文前面讲的行缓存、滑动窗口、加法树、加窗累加器，全部以流水线方式接入；模板放在BRAM里，由外部（串口或按键）触发加载；
• 坐标输出与可视化：把SAD最小值坐标通过UART发到PC，同时叠加到HDMI或VGA显示的画面上，红色十字或矩形指示目标位置。

这个最小闭环跑通后，你验证算法、调参、排查问题的效率会高很多。我看到太多人一上来就想做完整的多目标、多尺度系统，结果写了三个月还在调RTL编译错误，热情全耗光了。先让一个光秃秃的目标在屏幕上被框起来，这个瞬间的正反馈，比什么都管用。

8.2 数据通路里应该用灰度图还是彩色图？

SAD对彩色图像一般直接转灰度计算。RGB565转8位灰度通常按加权公式：

gray = (R×77 + G×150 + B×29) >> 8

FPGA里这个公式用三个乘法器加一个移位器就能完成，也可以在采集端用简单的取G通道近似替代，效果损失不大。工程上没必要在入门阶段把色彩转换做得很复杂。另外，做SAD之前最好加一级中值滤波或简单均值滤波，去掉传感器噪声，不然噪声像素会让SAD表面出现大量毛刺，最小点位置抖动加剧。这一步的硬件成本也很低：3×3中值滤波用9个寄存器+排序网络就能实现。

8.3 上板调试三板斧：抓波形、比数值、看坐标

SAD这种纯数值计算的项目，上板调试最大的敌人是"黑盒感"——你只知道最终坐标对不对，不知道中间哪儿错了。我的调试流程从来都是三板斧：

1. ILA（集成逻辑分析仪）抓关键节点波形：重点看行缓存各级输出、窗口寄存器组的数据、加法树各级结果、sad_current波形。确认它们在同一时刻对应的是同一帧的同一块区域。
2. 把仿真结果导成文本和软件参考比对：用Python或MATLAB对同一张测试图、同一个模板求出SAD矩阵，和仿真波形导出的SAD值逐点比较。这一步能快速暴露位宽、对齐、边界类问题。
3. 上板打印坐标，连续跑几百帧观察稳定性：如果坐标在被测场景中抖动幅度超过预期，优先怀疑卡尔曼参数、模板更新率、搜索窗大小三者是否匹配。

这套流程虽然朴素，但足以解决90%以上的调试问题。最后一个经验是：修改任何一处RTL后，一定要重新跑一遍全量比对仿真，不要只跑单帧，否则很容易出现"这帧好了、下一帧又坏了"的回归问题。

如果按这个路径把项目走通，收获远比"会调一个SAD模块"大得多——你会同时掌握图像在FPGA里的行缓存流动方式、并行运算的流水化拆分技巧、以及"先搭闭环再优化细节"的工程节奏。这套能力后面不管去做光流追踪、特征匹配，还是更复杂的深度学习加速器，都是同样的底子。