2026年FPGA大赛备赛只剩三周，做实时视频去雾，暗通道先验算法在国产FPGA上BRAM不够用，有哪些快速优化策略？

紫光同创的BRAM资源确实比Xilinx同级别器件紧张，尤其是暗通道先验这种需要多行长缓存的算法。三周时间不建议重写核心算法，但有几个优化方向可以立刻动手：第一，用分布式移位寄存器（SLR）替代部分行缓存。暗通道先验的透射率计算通常需要N行数据，比如7×7窗口至少需要3行缓存，而BRAM是按整行容量分配的，如果图像宽度是1920，一行1920x8bit就要15.36kbit，用BRAM会浪费很多。你可以把行缓存拆成两部分：前几行用BRAM，后面几行改用分布式移位寄存器，因为分布式SRAM是按slice内的LUT实现的，虽然占用LUT资源，但紫光同创的LUT相对充裕，代价是布线压力。第二，分时复用BRAM端口。BRAM真双端口可以同时读写，但暗通道先验的读写时序往往是非对称的——写入连续像素，读出则按窗口滑动。你可以把写入时钟调高到两倍像素时钟，比如像素时钟148.5MHz，BRAM写时钟设到297MHz，这样一块BRAM就能在写入新数据的同时读出旧数据，减少BRAM块数。具体做法是：用一个双口BRAM，写端口始终在写当前行，读端口在写入间隙读出历史行数据；注意读地址需要滞后写地址若干时钟周期，用计数器偏移实现。第三，压缩数据位宽。暗通道值取RGB三个通道的最小值，你可以在写入行缓存之前就完成求最小值，只存8bit灰度值而非24bit彩色，这样行缓存深度直接减到1/3。代价是后续透射率计算只能用灰度信息，但多数文献证明对去雾效果影响可接受。这三条按优先级做：先压缩位宽（改代码几行），再分时复用BRAM（改时钟和地址逻辑），最后才考虑分布式寄存器替代（涉及布局约束，调试时间最长）。另外提醒一句：比赛评审更看重功能完整性而非资源利用率，如果BRAM差一点，可以考虑把视频分辨率降到1024×768或者降低帧率到30fps，这是最省事的保底方案。你们用的是紫光同创哪个型号？如果是PGL25G以上，BRAM有100多块，暗通道7×7窗口一般60块左右够用，先确认一下是不是算法实现里有冗余缓存，比如存了多余的行数或者用了双倍缓冲。

别折腾移位寄存器了，来不及布线。直接降分辨率到800×600或者把帧率砍到25fps，BRAM占用能对半砍。比赛评审不会仔细看雾的纹理，功能跑通最重要。

说个不太常见的思路：暗通道先验的透射率计算本质是局部最小值滤波，你可以把行缓存改成乒乓缓冲加流水线重排。具体来说，只缓存两行数据，然后利用滑动窗口的行间重叠特性，把原本需要N行缓存的计算拆成逐行递推——每来一个新像素，只更新当前窗口的最小值，而不是重新算整个窗口。这样行缓存从N行降到2行，BRAM用量直接减少60%。缺点是逻辑复杂度上升，代码需要重构窗口更新逻辑，但三周时间写Verilog应该够。建议先做个仿真验证递推公式是否正确，再上板调时序。注意国产FPGA的LUT进位链延迟较大，递推比较器要加一级流水打拍，否则容易建立时间违例。你们现在是用纯Verilog还是HLS？如果是HLS，改起来更麻烦，建议直接手写RTL。

看到你是紫光同创的片子，我补充一个很多人忽略的细节：暗通道先验的行缓存需求其实和窗口大小、图像位宽强相关，但你们很可能被默认的8位灰度透射率图给坑了。透射率计算本身只需要一个最小值，但很多参考代码在行缓存里存的是整个像素的RGB数据，等于多用了两倍带宽。你可以这样优化：在进入行缓存之前，先对每个像素做一次RGB三通道取最小值，得到单通道的暗通道中间值，然后只缓存这个单通道数据。这样一行数据从24位降到8位，BRAM用量直接砍到原来的三分之一。代价是后续透射率计算需要从缓存里读出的已经是预处理过的暗通道值，但逻辑改动很小，三周完全来得及。另外紫光同创的PGL系列BRAM有硬件的字节写使能，你可以利用这个特性把单端口BRAM配置成伪双端口模式，写入和读取分别用不同的时钟域，这样就不用等读写交替，吞吐量能翻倍。注意写使能信号要严格按照手册时序来，否则容易误写。你们现在图像分辨率是多少？如果是1080p，单通道8位一行就要1920字节，BRAM最小块是18Kb能存两行多，但窗口一般要3行，所以至少需要两块BRAM。如果用了我的方法，两块BRAM就能搞定，原本可能要六块。建议优先验证这个预处理挪位置的思路，比加流水线重排简单得多。