2026年，FPGA大赛做实时视频去雾，暗通道先验算法在PL侧实现时BRAM不够用怎么办？

先说一下你们现在最直接的瓶颈：暗通道先验里透射率计算和导向滤波，按教科书写法全是整帧图存下来再算，BRAM 当然不够。我前年带学生做类似项目，1280×720 分辨率，全帧存直接吃掉 4 个 36Kb BRAM 的 60% 以上。核心思路就一个：把「帧级处理」拆成「行级流水」甚至「像素级流水」。

透射率计算那块，你们可以放弃全局最小值的做法，改成滑动窗口求局部最小值。窗口大小比如 15×15，用行缓存（Line Buffer）存 15 行数据，每进来一个新像素就更新窗口内的最小值。这样 BRAM 只占 15 行，而不是一帧。乘加器也不用每个窗口配一套，共享一个乘加器轮流算不同通道的最小值，代价是多几个流水拍数，但 DSP 和 BRAM 都省下来了。

导向滤波更麻烦，但你们大赛如果只要求实时去雾效果不要求数学严格，直接用均值滤波近似导向滤波。均值滤波本身可以用积分图算，积分图同样用行缓存维护局部和，不需要全帧积分。具体做法：维护一个滑动窗口内的像素和与像素平方和，窗口滑动时用减法剔除旧像素、加法加入新像素，这样每时钟出一个滤波结果，BRAM 开销从几千个降到一个 Line Buffer 加几个寄存器。

分块处理其实也值得试，但要注意分块边界伪影。我建议你们先按行流水走通透射率计算，再评估 BRAM 剩余量决定导向滤波是近似还是降分辨率。如果必须保留严格导向滤波，就把导向滤波的半径缩小到 3×3 甚至 2×2，BRAM 占用能降一个数量级。

对了，你们目标分辨率是多少？如果 1080p 的话，行缓冲长度会压 BRAM，可能需要考虑 DDR 缓存一部分中间数据，但那样会引入延迟抖动。先试 720p 以下把架构调通再去冲高分辨率比较现实。

BRAM 不够就上 Line Buffer 呗，透射率用滑动窗口算，导向滤波用均值滤波近似，别整全帧存。比赛嘛，效果差不多就行，资源省下来才是王道。

决赛圈资源不够是常态，别想着硬怼全帧存。你们透射率计算那块，把全局最小值改成 15×15 滑动窗口，用行缓存维护窗口数据，BRAM 占用直接降到十几行。导向滤波更简单，均值滤波近似一下，每时钟出一结果，Line Buffer 加几个 DSP 搞定。记得把乘加器复用起来，多个通道共享一套。如果还差一点，把分辨率降一档或者窗口缩小到 7×7，视觉效果损失不大但资源压力小很多。先跑通再优化，别一开始就追求完美。

除了楼里提到的行缓存和滑动窗口，我想提醒一个容易被忽略的点：你们用的暗通道先验版本是不是带soft matting的？那个东西在PL里做基本是自找麻烦，BRAM再多也不够。比赛的话，导向滤波直接换成均值滤波近似，效果人眼几乎看不出差异，但资源占用从几十个BRAM降到两三个。另外，透射率计算的乘加器复用你们可以这样设计：用一个计数器控制通道切换，R/G/B三通道轮流算，中间插几个空拍做流水对齐，这样DSP只用一套。还有一个风险要注意——Zynq的BRAM有36Kb和18Kb两种，layout时尽量把小的留给Line Buffer，大的留给系数表或查找表，不然布局时容易浪费。你们现在用的是什么开发板？不同板子的BRAM数量差很多，如果已经选了资源最紧的型号，可能还得考虑把分辨率从1080p降到720p。

你们遇到的BRAM瓶颈，本质上是把算法从PC端往FPGA移植时，没有做数据流重映射。暗通道先验在Matlab里写，最自然的就是把整帧图读到矩阵里算，但FPGA擅长的是流水线，不是随机寻址。我建议你们换个思路：不要去想怎么把帧存省下来，而是想怎么让数据流起来。透射率计算那个滑动窗口，15×15的窗口，用15个Line Buffer加一个比较树，每个时钟都能出一个结果，BRAM只占15行数据，不到全帧的2%。导向滤波更简单，你们比赛大概率不需要严格数学推导的结果，用均值滤波近似导向滤波，只需要一个5×5的Line Buffer加几个加法器，连除法都用移位代替，整个模块的BRAM开销可以控制在5个以内。乘加器复用那边，我见过有人把三通道的透射率计算做成状态机，每3个时钟出一组结果，DSP占用从3个降到1个，代价是延迟多了几个时钟周期，但对于视频流来说根本不算事。还有一个你们可能没想到的优化点：暗通道先验里那个最小值滤波，可以用局部直方图法做，BRAM换一点逻辑资源，但尺寸大的窗口下反而更省。你们先确定一下目标帧率是多少？如果只是30fps，很多地方可以放慢时钟频率来节省资源，比如把乘加器做成多拍流水，频率降到100MHz以下，BRAM和DSP的压力都会小很多。