2026年电赛FPGA题用国产高云GW5A做「多路视频拼接+缩放」，队伍只有一块板，该怎么在资源不够时做取舍？

先说结论：优先砍路数，再砍分辨率，最后才动缩放算法。原因是电赛评委看演示最直观的是「你做了几路、拼出来画面稳不稳」，四路降到两路是肉眼可见的缩水，而 720p 降到 480p 只要显示器缩放得当，观感损失没那么刺眼。缩放算法从双线性退到最近邻，画质会糊，但架构还在，答辩时你能讲清楚取舍逻辑，反而是加分项。

具体做法：先把整个链路按「采集→帧缓存→缩放→拼接→输出」拆开，用高云自己的 IP 和综合报告看每一块到底吃掉多少 LUT/BRAM/DSP，别凭感觉估。常见情况是帧缓存和跨时钟域 FIFO 才是大头，缩放器反而不是瓶颈。找到真正的瓶颈再决定砍哪里。

另外只有一块板，一定要留出足够时间做「降级版本」并保证它能跑通，别把宝全押在全功能上最后演示翻车。你们现在综合报告里 BRAM 占用大概到多少了？

先想清楚评委在演示现场能看见什么：路数少一眼就看得出来，分辨率降一点只要输出时序和显示端配合好，观众未必察觉。所以我的排序是先保路数、再保帧率稳定，最后才动分辨率，缩放算法放最后考虑。很多队伍一上来就砍路数，结果四宫格变两分屏，画面冲击力直接掉一半。具体操作上，先把采集、缓存、缩放、拼接、输出各模块的综合资源拉出来对比，往往帧缓存和跨时钟域那块才是吃 BRAM 的大户，缩放器反而没那么夸张。找到真瓶颈再砍，别凭直觉。另外只有一块板，务必先跑通一个保守版本当保底，再往上加功能。你们现在几路摄像头、目标输出分辨率是多少？

先别急着砍参数，先搞清楚评委在答辩现场到底能看见什么。多路拼接这种题，最直观的观感是「几路画面同时在动、拼缝稳不稳、有没有撕裂」，分辨率只要不是低到肉眼糊成一片，观众和评委隔着投影仪其实分辨不太出来。所以我的排序是保路数优先，帧率稳定次之，分辨率再降，缩放算法放最后动。真正容易吃资源的往往不是缩放器，而是帧缓存和跨时钟域那几级 FIFO，你先把综合报告里 BRAM 和 DSP 的占用按模块列出来，找到真瓶颈再决定砍谁，别凭感觉一刀切。另外只有一块板，务必先做一个保守版本锁死能跑通，再往上叠功能。你们现在几路输入、目标输出分辨率定的是多少？

这个问题本质上是「演示效果」和「实现复杂度」之间的资源分配题，我按一条主线说：先定一个不可退让的演示底线，再往上做增量。

底线怎么定？假设评委看的是拼接路数、画面连续性、切换是否流畅，那路数就是硬指标，四路降到两路是肉眼可见的缩水，答辩时也很难圆回来。分辨率是软指标，720p 降到 480p 甚至更低，只要输出时序和显示端配合好、缩放插值别太糙，投影出来观感损失有限。缩放算法本身（双线性退最近邻）更多影响细节锐度，属于最后才动的档位。所以优先级大致是：路数 > 帧率稳定 > 分辨率 > 缩放算法质量。

但别把这条当教条，真正的判断依据是综合报告。把链路拆成采集、帧缓存、缩放、拼接、输出五段，逐段看 LUT/BRAM/DSP 消耗，常见情况是帧缓存和跨时钟域 FIFO 才是大户，缩放器反而没想象中夸张。如果瓶颈在帧缓存，那降分辨率比减路数更有效，因为它直接压小每帧的存储量；如果瓶颈在缩放器的行缓存和乘法器，那换算法或者分时复用才是正解。也就是说，先定位瓶颈，再套优先级，顺序反了就是白砍。

工程路径上，只有一块板意味着你没有并行试错的机会。稳妥做法是先跑通一个「两路 + 低分辨率 + 最近邻」的保底版本，把它固化下来当演示兜底，然后在这个基础上逐项加回功能，每加一项就重新看时序余量和资源余量，留出至少 15% 到 20% 的裕量给布线和后期修补。很多队伍翻车不是因为方案不够炫，而是最后一周还在改架构，时序收敛不了，演示当天黑屏。

还有个容易被忽略的点：答辩时你能把取舍逻辑讲清楚，本身就是加分项。评委问「为什么降分辨率不降路数」，你答得出资源瓶颈在哪、代价是什么，比闷头堆功能更有说服力。你们综合报告里现在最紧的是哪一类资源，BRAM 还是 DSP？

先把一个容易被忽略的点摆前面：评委在答辩现场看到的和你综合报告里看到的，是两套评价体系。综合报告里 BRAM 用掉 95% 是工程事实，但评委坐在投影前，看到的是「几路画面同时动、拼缝稳不稳、切换有没有黑屏撕裂」。所以资源取舍的第一原则不是「哪个模块吃得多就砍哪个」，而是「砍完之后演示效果掉多少」。这两件事经常不一致，你得先把它们对齐了再动手。

按这条主线往下推：路数是硬指标，因为它直接决定画面的信息密度，四宫格变两分屏，评委一眼就看得出来，答辩时也很难解释成「优化」。分辨率是软指标，720p 降到 480p，只要输出时序对、显示端缩放别太糙，投影出来观感损失有限，很多人根本分不出来。缩放算法更是最后才动的档位，双线性退到最近邻，画面会糊一点，但架构完整、你能把取舍逻辑讲清楚，反而是加分项。所以优先级我一般建议：路数 > 帧率稳定 > 分辨率 > 缩放算法质量。

但这条排序不能当教条用，真正的判断依据在综合报告里。把链路拆成采集、帧缓存、缩放、拼接、输出五段，逐段看 LUT/BRAM/DSP 消耗。常见情况是帧缓存和跨时钟域 FIFO 才是大户，缩放器反而没想象中那么夸张。如果你发现瓶颈在帧缓存，那砍分辨率比砍路数更有效，因为缓存深度和带宽都跟着降；如果瓶颈在拼接逻辑的 LUT，那减路数才是正解。先定位真瓶颈，再决定砍谁，别凭直觉一刀切。

还有一点只有一块板的队伍特别要注意：留一个「降级版本」当保底。全功能版本跑不通的时候，你能在十分钟内切到保守配置，演示不至于翻车。这个保底版本最好在中期就锁死、验证过、别再动它。

你们现在综合报告里 BRAM 和 DSP 各占到多少了？这个数字出来，砍哪块其实就清楚了。