2026年FPGA大赛国一学长分享：从选题到答辩的完整避坑指南，哪些坑最容易踩？

关于选题的坑，我当年差点死在「想搞个大新闻」上。我们组最初想做一个基于FPGA的实时视频拼接+目标检测，觉得这样既有视觉冲击又有算法深度。结果评估的时候发现，单是视频输入接口的时序约束就要调两周，更别提把YOLO压缩到片上。后来指导老师一句话点醒我：FPGA大赛评委更看重「完成度」和「工程合理性」，不是看标题多炫。具体来说，选题前先做三件事：第一，查清你手里板子的逻辑单元、DSP slice、BRAM上限，然后按70%利用率倒推算法规模；第二，去GitHub搜往年同类型开源项目，看别人用了多少行代码、多少时钟周期；第三，给自己设一个硬截止时间——比如开赛第6周必须出完整功能原型，否则立刻降级方案。答辩时被问倒几乎不可避免，但有个技巧：遇到不会的问题，先承认「这一点我们确实没有深入验证」，然后立刻转到你们做了充分验证的部分，比如「不过我们在资源利用率上做了对比测试，这是结果」。千万别硬扛，评委见过太多编数据的人。另外，时间分配上，我建议前1/3时间死磕核心功能，中间1/3留给接口和异常处理，最后1/3用来写文档、调展示demo、模拟答辩。很多人最后一周还在改代码，结果报告写不完，直接扣分。你们现在用的什么开发板？不同的芯片资源差异很大，选题策略要跟着变。

从工程角度看，FPGA大赛本质上是一场「约束下的最优解」竞赛，而不是学术创新比赛。很多人踩坑是因为把做毕设的思路带进来了——毕设可以花半年调一个模块，但大赛只有三个月，你必须在「功能完整」和「性能极致」之间做取舍。我自己的经验是：先画一张「功能依赖图」，把每个子模块的输入输出、依赖关系、可复用性标出来。比如你要做数字信号处理，FFT模块是很多后续算法的前提，那就优先把FFT调通并做成IP核，后面所有东西都基于这个IP核搭建。这样即使最后时间不够，你也有一个可演示的子系统。另一个常见误区是忽视「接口稳定性」。很多人花大量精力优化核心算法，结果在答辩前三天发现HDMI输出有毛刺，或者UART通信丢包，这种低级问题在评委眼里比算法不优更致命。解决方案很简单：从第一天起就把输入输出接口的测试用例写好，每周跑一遍回归测试。答辩准备方面，有一个容易被忽略的点：评委很喜欢问「你用了什么方法验证你的结果正确性」。如果你只说「仿真波形看起来对」，那基本就凉了。正确做法是准备一个「对比表」，比如把FPGA计算结果和Matlab golden model的结果逐点对比，显示误差范围。最后说一句，别把答辩PPT做成代码展示会。评委想看的是「你遇到了什么工程问题、怎么分析的、最终怎么解决」，而不是你写了多少行Verilog。如果你们能把一个时序不满足的问题从RTL修改到布局布线约束调整的过程讲清楚，比列十个技术指标都管用。你们目前选定的方向大概涉及多少时钟频率？这个数字直接影响时序收敛的难度，决定你们要不要提前留两周专门跑STA。

我去年带过一组大二的学生做大赛，他们踩的坑挺有代表性的。选题阶段最容易犯的错是把「看起来能做」和「实际能做完」划等号。比如有人想用FPGA做实时手势识别，听起来很酷，但一算资源：单是摄像头采集+色彩空间转换就要吃掉30%的LUT，再把训练好的CNN量化到片上，DSP slice直接超了。我的建议是：拿到板子后第一周别急着写代码，先跑一遍官方例程，把片上资源的具体数字记下来，然后按「核心算法占50%、接口与缓存占30%、调试与冗余留20%」来倒推选题规模。另一个容易忽略的点是「数据流的连续性」——很多新手做数字信号处理时只测了单帧数据，没考虑连续流场景下的FIFO溢出或时序违例，结果联调时画面撕裂。解决方法是：在RTL仿真阶段就引入「最坏情况数据注入」，比如模拟连续三帧数据间隔只有两个时钟的情况，看看你的乒乓操作能不能扛住。答辩时被问倒很正常，但有个技巧：遇到不懂的，先承认「这个方向我们确实没深入验证」，然后立刻转到你们做得比较扎实的部分，比如「但我们针对XX场景做了三组对比测试，结果如下……」。评委其实更看重你承认局限之后的补救思路，而不是硬撑。你们现在大概到哪个阶段了？选题定了吗？

从工程角度看，FPGA大赛本质上是一场「约束下的最优解」竞赛，而不是学术创新比赛。很多人踩坑是因为把做毕设的思路带进来了——毕设可以花半年调一个模块，但大赛只有三个月，你必须在「功能完整」和「性能极致」之间做取舍。我自己的经验是：先画一张「功能依赖图」，把每个子模块的输入输出、依赖关系、可复用性标出来。比如你要做数字信号处理，FFT模块是很多后续算法的前提，那就优先把FFT调通并做成IP核，后面所有东西都基于这个IP核搭建。这样即使最后时间不够，你也有一个可演示的子系统。另一个常见误区是忽视「接口稳定性」。很多人花大量精力优化核心算法，结果在答辩前三天发现HDMI输出有毛刺，或者UART通信丢包，这种低级问题在评委眼里比算法不优更致命。解决方案很简单：从第一天起就把输入输出接口的测试用例写好，每周跑一遍回归测试。再往深了说，答辩时评委问的问题往往不是真想知道你的算法细节，而是想测试你对系统瓶颈的理解。比如他问「为什么没用流水线结构」，其实是在考察你有没有考虑过面积和速度的折中。这时候你如果能给出具体的资源占用数据，比如「用了流水线LUT会多40%，但BRAM会省30%，考虑到我们板子BRAM是短板，所以选了面积换速度的方案」，比背论文公式效果好得多。最后提醒一句：文档和PPT里的波形图一定要用仿真截图，别自己画——评委一眼就能看出是不是真实数据。你们板子型号定了吗？不同厂家的工具链差异很大，比如Vivado和Quartus的时序约束写法就完全不同，这个最好早点确认。

说实话，看了你描述里提到「网上信息太杂」，我反而觉得你现在的状态比那些上来就搜代码的人好——至少你知道要先评估可行性。我最想提醒的一个坑是：很多人把「选题」和「写代码」割裂开了，觉得选题就是定个方向，后面再慢慢想细节。但FPGA大赛的选题本质上是在做「资源预算」，不是写论文题目。

具体来说，你可以试试这个方法：拿到板子后，先不写一行代码，而是用官方工具链把片上资源（LUT、FF、BRAM、DSP）的型号和数量记下来，然后去Xilinx或Altera的文档里查每个常用IP核（比如FFT、FIR、HDMI控制器）的资源占用估算值。接着，把你脑子里那个方案拆成「必须用硬件加速的核心模块」和「可以用软核或状态机凑合的辅助模块」，前者占资源大头，后者尽量复用官方例程。比如你想做实时图像滤波，核心是卷积计算，可能要用DSP slice；但图像缓存和帧同步完全可以用BRAM搭个简单乒乓结构，不用去追求什么高级架构。

另一个容易被忽视的点是「验证环境的搭建时间」。很多人以为写代码两周、调试两周、剩下时间优化——但现实往往是写代码一周，然后花三周调接口时序，因为仿真时没考虑真实信号抖动。我的习惯是：从第一版代码开始，就写一个「最坏情况测试激励」，比如让输入数据随机间隔、时钟抖动±5%，看看FIFO会不会溢出。这招能提前暴露80%的联调问题。

你目前是在校生还是已经工作了？不同背景在选题时侧重点会差很多，比如在职的可能更熟悉某一类接口，在校生则要考虑实验室的板卡型号和指导老师能投入的时间。