2026年了，FPGA大赛国赛评委到底看中什么？功能完整和工程规范哪个更重要？

其实评委打分是分阶段的，作品评审看功能完成度和创新点，答辩环节才重点看工程素养。你想想，评委一天看几十个队，功能都差不多的前提下，谁文档清晰、代码整洁、能快速讲明白设计架构，谁就更容易被记住。最后两周建议做个优先级排序：先保证核心功能在极端条件下不崩，这是底线；然后花三到五天整理一份精简版设计文档，重点写清模块划分、接口定义和关键时序约束；代码注释不用逐行写，但每个模块头部和关键状态机必须交代清楚。测试报告也别堆数据，挑两三个能体现你调试能力的case写透。答辩时能主动说出'我踩过什么坑、怎么定位的'，比单纯报性能数字强得多。

拿过国赛的过来人说实话，评委看中的东西分两层：硬指标是功能完整性和创新点，软指标才是工程规范，但软指标往往在分数胶着时起决定作用。你们现在功能打磨得差不多了，那就别盲目追求性能优化了——性能提升有边际递减效应，最后两周可能只能提升百分之几，但文档和代码规范如果一团糟，答辩时被评委追问几句就露馅。我见过一个队，功能很强但代码全是单字母变量，文档就两张截图，结果答辩被问'这个模块的时序约束怎么设的'直接卡壳，最后分数反而不如一个功能稍弱但讲得头头是道的队。建议你们做个快速自测：让一个没参与项目的同学看你们代码和文档，十分钟内能不能理解整体架构？如果能，说明规范够用；如果不能，那就别犹豫，立刻投入整理。另外有个小技巧，测试覆盖率不用追求数字，但一定要有一份能说明'我测过哪些边界情况'的清单，答辩时主动展示，评委印象分会明显提升。最后一周留一天做模拟答辩，让队友互相问刁钻问题，这比再调一版代码值钱多了。

你们这情况我太熟了，最后两周最怕的就是两头都想抓结果两头都稀松。个人建议：功能只要不崩，就别再动了，把精力全砸在规范上。原因很简单，评委看功能是看'有没有'，看规范是看'像不像工程师做的'。你们功能都打磨得差不多了，那说明'有没有'这关过了，接下来拼的就是'像不像'。文档不用写多厚，但一定要有模块框图、接口说明、关键时序分析和测试结论，这四样东西能让评委快速建立信任感。代码注释别追求每行都有，但每个模块头部、每个状态机、每个跨时钟域处理的地方，必须写清楚为什么这么做。另外提醒一句，答辩时千万别只说'我们功能很强'，要主动引导评委看你们的设计思路，比如'这里我们用了乒乓缓存来避免数据冲突，原因是……'，这种话一出口，评委就知道你们是真做过工程的。最后，别忘了一件事：把代码里的调试逻辑和打印信息清理干净，见过太多队因为代码里残留一堆`$display`被扣印象分的。你们现在还剩两周，按这个顺序来：先花两天整理代码结构和注释，再花三天写文档和测试报告，最后留一天模拟答辩，肯定来得及。

个人感觉你俩现在纠结的点有点偏了。评委不是拿一个公式算权重，功能60分规范40分这样给你加，而是先看功能过不过关，过关了再看你像不像个正经做工程的队伍。最后两周，性能再往上抠的性价比其实很低，比如你时序从2.1ns优化到1.9ns，数字好看但评委未必感知得到；但你要是在答辩时拿出一份时序约束说明，把跨时钟域的处理讲清楚，那个印象分是实打实的。建议你们做个最小可行动作：先把代码里的TODO和临时调试分支清掉，每个模块头部写五到十行注释说明输入输出和设计意图，状态机一定要画个转移图放进文档里。这些加起来一天半就能搞定，但效果立竿见影。另外测试报告别光贴波形截图，挑一个你们实际踩过的坑，比如亚稳态或者位宽截断，写清楚现象、定位过程、怎么修，评委最吃这一套。至于功能，只要核心场景不崩、边界情况能自圆其说，就别再动了。你们现在最该警惕的是答辩时被问住，比如评委指着某个信号问为什么这么接，你支支吾吾说当时试出来的——那之前所有功能分都会被怀疑。所以最后一周每天抽半小时互相模拟答辩，专门挑自己模块里最不自信的地方问。你们现在文档大概写到什么程度了？是基本空白还是已经有框架了？