2026年了，FPGA大赛国赛评委到底看中什么？纯功能实现和资源利用率哪个更占优势？

先说结论：功能完整是及格线，资源利用率是加分项，但这俩不是二选一。评委看的是你这个设计整体像不像一个'正经工程'，而不是作业。LUT 85%、BRAM 90% 这个数字，说实话在国赛里不算好看，但也不是致命伤——前提是你得能讲清楚为什么这么高。比如你为了并行度牺牲了资源，或者算法本身就这么复杂，那评委能理解。最怕的是资源高、时序还差，或者你根本说不清这些 LUT 花在哪了。

我的建议是：先别急着优化资源，把功能稳定性和演示流程打磨到极致。现场演示才是权重最高的环节，一个流畅的、能应对突发状况的 demo，比你在报告里写'我节省了 20% LUT'有用得多。然后，拿一周时间做个资源优化尝试，主要看 BRAM 能不能降下来——90% 的 BRAM 在工程上很危险，稍微加点数据就爆了，评委如果问'你这板子换个大点的场景怎么办'你就尴尬了。常见做法是查一下有没有重复例化的模块，或者把缓存策略改成乒乓结构，一般能降 10-20%。

另外，工程规范性千万别忽略。代码注释、模块划分、文档里的设计思路图，这些是评委快速判断你'懂不懂行'的捷径。你资源利用率不好看，但如果代码结构清晰、文档写得明白，评委反而会觉得你诚实且有潜力。相反，功能全但代码一团乱麻，第一轮就被刷了。至于创新性，别硬凑，把现有功能做扎实比啥都强。

最后问一句：你们用的啥器件？如果是低端系列的 BRAM 本来就小，那 90% 其实还算合理，跟评委解释清楚就行。

沿着一条线说吧：评委的真实心态。

国赛评委大多是高校老师加企业工程师混编，他们看作品的第一眼不是'这功能牛不牛'，而是'这学生有没有工程思维'。功能完整只是入场券，真正拉开差距的，是你遇到资源瓶颈时怎么决策。LUT 85%、BRAM 90% 这个状态，其实暴露了一个信号——你很可能是在功能全部搭完后才回头看资源，而不是在设计过程中就带着资源预算去做架构。这恰恰是工程实践和课程设计的核心区别。

评委心里有个默认的'设计流程'：先定算法和接口，估算资源，再选实现策略。你如果能在答辩里主动说'我最初预估 BRAM 要 95%，后来通过把查找表改成哈希索引降到了 90%，虽然还有优化空间，但考虑到时序余量，我选择了保持现状'，这比单纯说'我资源用得有点高'强十倍。因为你在展示决策过程，而不是结果数字。

那到底要不要死磕资源优化？我的看法是：如果时序已经收敛，就别大动了。BRAM 90% 意味着你已经用得很满，这时候盲目优化很可能引入时序问题，或者把代码改出 bug，反而得不偿失。国赛的评审时间有限，评委不会真的逐行看你的利用率报告，他们更相信现场演示和你的口头表达。你只需要准备一个'为什么资源偏高但合理'的故事——比如你的设计处理的是高分辨率视频流，缓存需求本身就大，这个理由没人能挑错。

但有一条线必须守住：工程规范性。文档里有没有写明模块接口、时序约束文件有没有注释、代码里有没有魔法数字。这些是评委能快速翻到的东西，也是他们判断'这队是不是只会调板子'的依据。我见过不少功能很强但文档稀烂的队伍，最后只拿省奖，就是因为答辩时评委问'你这段状态机为什么这么写'答不上来。

所以，你的优先级应该是：先保证演示万无一失，再花两个晚上把文档和注释补完，最后有余力才碰资源优化。别本末倒置。另外提醒一句，BRAM 90% 如果跑满负荷时出现偶发错误，那才是真麻烦——最好拿仿真多压几轮边界情况。你们这作品是跑实时数据还是离线处理的？这决定了 BRAM 压力到底能不能缓一缓。

功能永远是爹，资源利用率是儿子。你功能稳了，85% LUT 就只是个数字；你功能崩了，30% 利用率也没人看你。先把 demo 练到闭眼能跑，再去想怎么省那几块 BRAM 吧。

功能是门票，资源是加分项，但门票没过检票口，加分项就是零。先把 demo 练到闭眼能跑，再回头抠 BRAM 吧。

功能完整性和资源利用率，评委确实都看，但看的顺序不一样。我参加过两届，也帮老师做过评审助理，个人感觉评委的评分逻辑像漏斗：第一层是功能能不能跑、演示顺不顺，这层过不了，后面全是白搭；第二层才是资源、时序、文档这些工程细节。你 LUT 85%、BRAM 90%，在漏斗第二层里属于「扣分项」但不是「淘汰项」。真正让评委皱眉的，是资源高同时时序还收敛不住，或者你根本说不出这些资源花在哪。所以我建议你把精力按这个顺序排：先把 demo 做成「无论评委怎么问都能流利演示」的程度，包括准备一两个故障预案；然后花两三天把 BRAM 从 90% 往下降一点，因为 BRAM 逼近极限在工程上意味着你后续加功能、改参数很容易爆，评委懂这个；最后才是写文档和整理代码注释。答辩时主动说一句「我评估过 BRAM 进一步压缩的收益和时序风险，选择了当前折中」，这比单纯报数字有用得多。另外提醒一个常见误区：别为了降资源牺牲并行度或算法精度，那属于捡芝麻丢西瓜。评委更愿意看到一个「资源略高但理由充分」的设计，而不是「资源好看但功能缩水」的作业。你们现在这个状态，其实离获奖就差一层「工程叙事」——把设计决策过程讲清楚，比堆优化技巧更打动人。对了，你们用的器件型号是什么？不同系列的 BRAM 硬核比例差别挺大，这会影响评委对 90% 这个数字的容忍度。

个人感觉，评委最烦的不是资源高，而是「说不清」。你们现在 LUT 85%、BRAM 90%，如果能当场画出资源分布饼图，指出哪块算法吃了多少、为什么必须这样，评委反而会觉得你有工程意识。怕的是你支支吾吾说「就这样吧」，那才显得像课程设计。建议你们把综合报告里的资源明细导出来，对照代码逐块标注用途，答辩前自己先演练一遍「为什么 BRAM 这么高」——哪怕理由只是「数据位宽大、缓存深度深」，也比说不出强。另外，时序余量记得看一眼，如果 setup 还留了 20% 以上，资源高一点完全有底气。你们时序收敛情况怎么样？这决定了资源优化要不要优先做。