2026年FPGA大赛，用国产FPGA做实时红外热成像测温，非均匀校正和坏点替换模块怎么用BRAM最少？求具体架构

先别急着上分布式RAM，你大概率会掉进另一个坑。高云这些国产片子，LUT资源一般比BRAM宽裕，但分布式RAM做14bit×N深度的查找表，综合后LUT消耗会非常夸张，而且时序容易崩。我建议先算一笔账：两点校正无非是Y = K×X + B，K和B各一张表，坏点坐标一张表，你先看看探测器分辨率到底多大，比如384×288，那就是11万个点，K和B各按16bit算就是110K×2×2 = 440KB，这确实不是小数目。但坏点表其实没必要存坐标，你可以存一张1bit的掩码图，同样分辨率下只有55KB，而且坏点替换用中值滤波确实能省掉查表，但中值滤波要开3×3窗口，BRAM反而要多用几块做行缓存，个人感觉不划算。更实际的办法是：校正系数别用16bit，K可以压到12bit甚至10bit，B用14bit，坏点掩码用1bit，这样总量能砍掉三成以上；另外高云片子一般有MIPI或LVDS接口，你可以把系数表放到外部SPI Flash里，上电后按行流水加载，只缓存当前行需要的系数，这样BRAM只用双缓冲一行就够了，代价是启动时间变长几百毫秒，但测温产品一般能接受。你们现在BRAM具体爆了多少？是容量不够还是块数不够？这决定了是走压缩还是走外部存储的路子。

说个更系统点的思路，别只盯着压缩系数表。红外热成像的两点校正本质上是逐像素做一次乘加运算，但探测器数据是14bit，你其实可以换一种存储组织方式：把K和B合并成一个24bit的打包字，按像素地址连续存放，这样读的时候一次BRAM读一个打包字，省掉两表分别寻址的地址译码开销，块数能省一半。坏点替换这块，中值滤波不是唯一解，而且中值滤波在硬件上要排序，3×3窗口至少需要三行数据缓存，消耗的BRAM可能比坏点表本身还多，除非你改用邻域均值或者直接复制相邻有效像素，后者只需要一个像素延迟，几乎不占额外存储。另外有个关键点你们可能忽略了：坏点掩码可以不用单独存，直接在两点校正的K表里做标记，比如把坏点位置的K值设成全0，B值设成0，然后在流水线里加一个判断，K==0且B==0就视为坏点，走替换逻辑，这样坏点表就彻底省掉了。这个做法在工业相机里很常见，缺点是坏点如果恰好校正系数算出来是0，会误判，但概率极低，而且你可以把K值预留一个特殊编码，比如0xFFF表示坏点，反正K值范围不可能用到满量程。资源对比上，我建议你们先按这个方案估一下：打包字24bit×110K = 330KB，BRAM块数大概在15到20块之间，高云的中端片子应该够用；如果还不够，再把系数按行压缩，每行存一个偏移量，行内系数用差分编码，坏点多的行差分值大，坏点少的行差分值小，这样能再压一半，但解码逻辑会复杂不少，需要权衡一下开发时间。你们现在用的高云具体是哪个型号？如果是小容量片子，可能还得考虑把校正拆成两段流水，第一段用粗表，第二段用细表，但那是另一个话题了。

坏点表直接换成1bit掩码，K表砍到12bit，B表14bit，BRAM基本就够了吧。中值滤波省了查表但多烧行缓存，不划算。先跑一遍资源报告再说。

个人感觉你们现在最该做的不是纠结用分布式RAM还是BRAM，而是先把数据流和存储粒度拆清楚。红外探测器14bit，两点校正本质是Y=KX+B，K和B两张表，坏点表一张。很多人一上来就按全分辨率存系数，384×288就是11万个点，K和B各16bit，两张表加起来440KB，BRAM当然爆。但实际工程里，探测器出厂校正后系数变化很平滑，相邻像素的K值差异很小，你完全可以按8×8或16×8的块做压缩：每块只存一个基准K和一个增量表，增量用4bit或6bit，这样存储量直接砍到原来三分之一还多。坏点更简单，别存坐标，存一张1bit掩码，分辨率相同也就55KB，而且可以并进K表——坏点位置的K设0、B设0，流水线里判一下两个都为零就走替换。坏点替换别用中值滤波，那玩意要三行缓存，BRAM消耗比坏点表还大，用邻域均值或者直接复制左边有效像素，延迟一个周期就够。你们先跑一下高云的云编译，把实际LUT和BRAM占用拉出来，再决定要不要上分布式RAM。我个人经验，高云小片子LUT比BRAM宽裕，但分布式RAM做14bit深度查表时序容易崩，不如把系数表砍到12bit+14bit，BRAM用打包字连续存，读一次取一个24bit，省掉双表寻址。先算清这个账，再谈架构。另外问一句，你们探测器分辨率到底多大？如果是320×240或者更小的，其实BRAM没那么紧张。

换个思路，别盯着压缩系数表。两点校正的K和B其实可以共用一块BRAM，用24bit打包字按像素地址连续存，读一次同时拿到K和B，省掉两表分别寻址的地址译码开销。坏点掩码不用单独存，直接在K表里标记，坏点位置K和B都写0，流水线加一个判断就走替换逻辑。坏点替换用邻域均值，别用中值滤波，后者要三行缓存，BRAM反而更多。你们先算一下分辨率，384×288的话，K砍到12bit、B用14bit，打包后每像素26bit，总共约105KB，高云的中等片子应该能塞下。先跑个资源报告，别猜。

既然你们还在备赛阶段，我多说一句容易被忽略的：BRAM 省下来不是终点，时序收敛才是。高云的中等片子 BRAM 本来就不算富裕，你就算把 K 和 B 打包成 24bit 一个字，坏点掩码并进 K 表，最后省到一百多 KB，听起来挺美，但综合后布局布线如果因为读写端口冲突导致频率上不去，测温实时性照样完蛋。我的建议是先把数据流画出来：探测器 14bit 进来，先过坏点判断还是先过两点校正？这个顺序直接决定你查表的时机。常见做法是先校正后替换，因为坏点本身 K、B 都是 0，乘出来是 0，再加个偏移量判断就行，这样流水线只要一级判断，不用额外缓存整帧。另外你们可以做个更狠的取舍：如果探测器出厂校正后系数确实平滑，别存全分辨率表，按 16×16 的块存基准值和增量，每块只存一份 K 基准和 4bit 增量，坏点掩码也按块压缩，这样 BRAM 占用能降到原来的四分之一左右。坏点替换用邻域均值，但注意边界像素的处理，别用 3×3 窗口，用十字邻域四个点求平均，只需要两行缓存，比三行省一块 BRAM。最后提醒一句：先跑个最小系统验证，比如 64×64 的分辨率，把整个链路跑通再放大，别一上来就啃全分辨率，备赛时间经不起这么耗。你们现在用的高云具体哪款片子，资源报告跑过没有？这个数据直接决定方案能不能落。