2026年FPGA大赛备赛只剩一个月，做实时视频去雾算法在国产FPGA上BRAM不够用，除了分时复用还有哪些骚操作？

先别急着搞骚操作，把暗通道先验的窗口大小砍一刀试试。比如从15×15降到11×11，BRAM消耗能降一半左右，代价只是去雾效果稍微软一点，但比赛演示根本看不出。你时序过不了，大概率是分时复用后组合逻辑太深，不如直接压窗口配合行缓冲重排。高云的分布式RAM确实能救急，但注意它只能到几百bit深度，适合存小系数表或临时变量，别拿它当大块存储用。另外，检查一下你的暗通道求最小值是不是用全排序做的，换成双调排序或者流水线比较树，面积能省不少。你们现在还剩一个月，先做资源压减再调时序，别两头同时改，容易崩。追问：大赛指定的是高云哪款型号？不同系列的BRAM数量和分布差很多。

兄弟，BRAM爆了还硬要分时复用，时序崩是必然的，因为分时复用本质上是用时间换面积，但会引入大量MUX和状态机，国产FPGA的布线资源本来就紧，这么搞纯属给自己上刑。我去年做实时双路去雾踩过一模一样的坑，最后是这么解的：第一，把暗通道先验的透射率计算从整帧改成局部块更新，用行缓冲只存当前窗口所需的像素，深度压到窗口宽度加两行就能算，BRAM从48个砍到16个。第二，高云的分布式RAM确实能替代部分BRAM，但你要注意它的读写时序和BRAM不一样，得单独做同步处理，否则会出亚稳态。具体做法是：把导向滤波的系数表塞进分布式RAM，因为系数表是只读的而且深度小，正好对口。第三，还有个骚操作是复用BRAM的读写端口，暗通道求最小值用单端口BRAM就够了，你原来可能用了双端口，改成单端口面积再砍一半。但注意，单端口意味着不能同时读写，你要把流水线重排成读周期和写周期错开。最后劝一句，别在去雾算法上死磕最优效果，大赛评委更看重实时性和资源利用率，你把透射率精度从float砍到8bit定点，效果肉眼几乎看不出，资源能省一大截。你现在还剩一个月，优先把架构定下来，别再改算法细节了。追问：你们用高云的哪个开发环境？Gowin IDE对分布式RAM的推断支持很弱，有时候得手动例化原语。

说个冷门但实用的思路：把暗通道先验的全局大气光值改成固定值，别实时求。这样能省掉一块专门存大气光候选点的BRAM，代价是画面偏暗或偏亮时效果差一点，但比赛视频一般场景变化不大，评委根本注意不到。另外，行缓冲重排序这块我补一句，你可以在输入侧先做一次行列转置，把数据排列从逐行扫描改成块状扫描，这样窗口内像素的访问局部性更好，存储深度能从三行减到一行加少量缓存。高云的分布式RAM做这个转置缓存正好，深度不大但需要双端口。注意：转置操作本身会引入一行的延迟，但你做实时视频去雾本来就要求几帧延迟，这点代价可以接受。最后提醒一下，大赛前两周一定要留时间跑综合后的时序分析，别最后发现分布式RAM的路径延迟比BRAM大导致崩盘。如果时间实在不够，宁可牺牲去雾效果也要保时序，毕竟比赛是现场演示，卡顿比效果差更致命。这条就不追问了，你先把资源报表贴出来看看。

别光盯着存储结构改，看看算法本身有没有可砍的模块。暗通道先验里导向滤波那一步最吃BRAM，换成快速双边滤波或者直接盒式滤波加软抠图，存储需求能降70%。盒式滤波用移位累加实现，连乘法器都省了，高云的低端型号也能跑得很稳。代价是去雾边缘会有轻微光晕，但比赛演示时调低对比度就看不出来。你们要是已经写了导向滤波的RTL，别全删，改成只保留边缘保护力度最弱的那一路，效果差一点但资源省一大截。时间只剩一个月，别想着完美复现论文，能用就行。追问：你们现在用的高云哪款开发板？有些型号的BRAM是9K bits每块，有些是18K，确认一下单位以免算错。

一个月的时间，不建议在分时复用上死磕，那玩意儿时序崩了基本救不回来。我个人感觉，你们现在最该干的是重新审视算法里的存储粒度。暗通道先验里，窗口最小值计算、导向滤波这两块是BRAM大户。有个偏门但有效的做法：把窗口最小值计算从全精度改成近似计算。具体来说，不用存整个窗口的像素值去排序取最小，而是对窗口内的像素做降采样，比如只取窗口内隔行隔列的像素点算最小值，这样行缓冲深度直接降到原来的一半以下，BRAM用量砍半。代价是去雾效果会有轻微的马赛克感，但比赛演示时调低分辨率或者缩小显示窗口，评委根本看不出来。另外，导向滤波那边，别用完整的均值滤波，改成递归均值滤波，它只需要两个行缓冲，比传统均值滤波省一半存储。高云的分布式RAM可以塞递归滤波的系数表，因为深度小正好对口。注意，递归滤波的时序约束要单独设，不然容易因为反馈路径太长导致时序不过。最后提醒一下，你们现在还剩一个月，先拿一个最小系统跑通全流程，再慢慢优化效果，别想着一步到位。追问：你们现在用的是高云的哪个系列？晨熙还是小蜜蜂？不同系列的分布式RAM和BRAM比例差很多，这个信息能帮你更精确地算资源。