2026年FPGA大赛做实时视频去雾，暗通道先验算法在国产安路FPGA上BRAM不够用，怎么通过时分复用和行缓冲共享优化？

看到你用安路做暗通道先验去雾，BRAM爆了，这确实是国产FPGA平台上很常见的痛点。我先帮你理一下核心矛盾：暗通道先验算法里，暗通道图是对整帧图像每个像素取RGB三通道最小值，然后做最小值滤波得到，常规做法要存一帧完整的暗通道图，对BRAM容量压力巨大。你提到的时分复用和行缓冲共享，思路方向是对的。具体来说，我建议你放弃存一帧完整暗通道图的想法，转而用行缓冲+滑动窗口的流水线结构。暗通道的最小值滤波可以用一个3×3或5×5的窗口在图像上滑动，你只需要缓存若干行（比如3行或5行）的RGB原始像素数据，而不是一整帧的暗通道计算结果。在安路上，BRAM通常用来做行缓冲，每个BRAM可以配置成双端口RAM，同时写入当前行数据、读出前一行数据。你可以把行缓冲深度设为图像宽度，数量等于窗口高度，这样BRAM占用就只跟窗口大小有关，跟帧大小解耦。还有一个技巧：暗通道计算中，求RGB最小值这一步可以在数据进入行缓冲之前就完成，这样行缓冲里存的是单通道的灰度值，而不是RGB三通道，能再省三分之二的存储。时分复用方面，你可以把一帧图像分成多个水平条带（比如每64行一个条带），每个条带独立计算暗通道，条带之间用乒乓操作交替处理，这样需要的行缓冲数量不变，但BRAM的读写带宽利用率更高。注意条带边界处要做重叠处理，否则会出现拼接痕迹。安路FPGA的BRAM一般有18K和9K两种模式，你可以手动例化原语来精确控制每个BRAM的位宽和深度，避免工具自动推断浪费资源。另外，如果暗通道图还要用于后续的透射率估计和去雾计算，建议把透射率计算也集成到同一个流水级里，避免再存一次中间结果。你目前用的是哪个型号的安路芯片？具体BRAM总量是多少？这会影响行缓冲深度和条带大小的选择。

暗通道存整帧肯定爆BRAM，别想了。把3×3窗口的行缓冲做起来，RGB最小值提前算掉，行缓冲只存单通道，安路BRAM应该够用。边界重叠处理别忘了。

你这个问题我去年帮学生调过，安路FPGA的BRAM确实比Xilinx紧不少。核心思路就一条：把暗通道从帧级降到行级，用行缓冲替代帧缓冲。具体做法是，先把RGB三通道像素流转换成单通道最小值，然后送入一个深度为图像宽度、数量等于滤波窗口行数的行缓冲组。每个时钟周期，从行缓冲中取出一个窗口的数据，做最小值比较，输出就是该像素点的暗通道值。这样BRAM消耗只和图像宽度及窗口高度有关，跟图像高度无关。安路的话，建议把行缓冲用双端口BRAM实现，一个端口写当前行，一个端口读上一行数据，同时利用BRAM的字节写使能来节省位宽。如果窗口是5×5，需要缓存4行（另一行是当前行实时数据），每行宽度1920像素的话，用9K模式BRAM大概需要4个，一般够用。注意行缓冲的初始化和边界处理，首几行和最后几行的窗口补零或镜像，不然图像边缘会有黑框。你现在的视频分辨率是多少？如果超过1080p，可能还需要考虑把图像切割成左右两半分别处理，用两个BRAM组并行。

我猜你用的应该是安路的GW2A系列吧，BRAM总共就几十个，存一帧1080p的暗通道图确实直接爆掉。你提到的时分复用和行缓冲共享，其实核心就一句话：别存整帧，改存窗口。暗通道先验里最吃BRAM的是最小值滤波，常规做法是先算完整帧的RGB最小值再滤波，但这样中间结果就得一帧。换个思路，把RGB最小值计算和滤波合并成一个流水级，输入像素流过来先算三通道最小值，然后直接喂给一个3×3或5×5的行缓冲滑动窗口，每个时钟周期从窗口里取9个值做排序取最小，输出就是当前像素的暗通道值。这样行缓冲只需要存窗口高度减1行的像素，比如5×5窗口就存4行，每行宽度1920像素，单通道8bit，用BRAM配置成双端口，深度2048、位宽8，一个BRAM就能存一行，4个BRAM搞定，省下来的BRAM还能做后续的大气光估计和透射率计算。不过要注意一个坑：安路的BRAM字节写使能有些型号只支持8bit粒度，如果你像素位宽不是8的倍数，得做位宽对齐，不然写使能会浪费。另外边界处理建议用镜像模式，不然首几行会出黑边。你目前图像分辨率是多少？如果是4K的话行宽翻倍，BRAM还是紧，那就得考虑用分布式RAM做部分行缓存了。

行缓冲共享是正解，别存整帧暗通道图。把RGB最小值算在滤波前，行缓冲只存单通道，BRAM占用直接降到窗口行数。安路BRAM不够的话优先调大窗口吗？不一定，3×3效果够用就别硬上5×5。

你这个问题其实暴露了一个常见的备赛误区：很多人一上来就按Xilinx的官方参考设计思路走，直接套用帧级暗通道实现，然后发现安路BRAM不够才回来改。实际上国产FPGA资源紧凑，更适合从一开始就设计成纯流水的像素级处理。我的建议是重新划分算法流程：把暗通道先验拆成三级流水。第一级是RGB最小值计算，输入像素流进来，每个时钟周期比较R、G、B三个值，输出一个8bit最小值。第二级是行缓冲窗口，用N-1个BRAM（N是窗口行数）组成行缓冲组，每个BRAM深度等于图像宽度，宽度8bit。这里有个技巧：安路BRAM支持两个独立的读端口和写端口，你可以配置成伪双端口模式，写端口实时写入当前行的最小值，读端口滞后窗口行数-1行读出，这样只用N-1个BRAM就实现了N行数据的并行访问。第三级是窗口内最小值比较，把从行缓冲读出的N-1个像素和当前像素共N个值送入一个比较树，每个时钟周期输出一个暗通道值。这样整个处理链路只有几个时钟周期的延时，BRAM消耗只跟窗口大小有关，跟图像高度完全解耦。你提到的时分复用，其实在低分辨率或帧率要求不高时可以考虑：用一个BRAM分时存储多行数据，比如把1920×1080分成上下半场，每半场960行，但这样控制逻辑复杂，还容易丢帧，不太推荐比赛用。相比之下，行缓冲共享更稳定。还有一个容易忽略的点：暗通道先验里的大气光估计通常需要统计全图最亮的0.1%像素，这个如果用BRAM做统计，又是一大块开销。建议改用分块统计法，把图像分成16×16的块，每块只存最大值，最后聚合，这样统计用的BRAM也能省下来。你目前用的安路具体型号是什么？GW2A-18还是55？不同型号BRAM数量差一倍，优化策略侧重点不太一样。如果已经用了18K模式还爆，可以考虑把部分行缓冲换成分布式RAM，但注意查一下安路分布式RAM的时序，走线不好容易跑不到视频时钟。最后提醒一句：比赛作品里资源利用率最好留20%余量，不然综合布线时容易因为拥塞导致时序不收敛，到时候调起来比写代码还痛苦。