FPGA大赛现场答辩被评委问代码是不是自己写的，怎么证明项目真实性和个人贡献？

说白了评委不是要抓你抄袭，是要确认你会不会用这套流程。仿真波形、时序报告、实物照片都只是佐证，真正有说服力的是你当场改一个参数重新编译给他看，比如把时钟频率从50M改成75M，或者把某个模块的位宽调一下，你能说出哪几条路径会变紧、哪里可能时序违例，这事就过去了。别背稿，就讲你自己踩过的坑。你要是真只调过没深究，那今天回去把代码里每个always块的作用都准备一遍吧。

我去年省赛也被这么问过，当时我直接说：这个工程里我负责的是图像预处理和DDR3读写调度两块，参考了正点原子的开源例程，但把原来轮询式读写改成了带优先级仲裁的，原因是原版在连续帧写入时会丢行。然后我掏出笔记本现场把testbench里注入两帧不同尺寸的图像，跑完波形给评委看读写仲裁在哪一拍切换的。他们接着问时序约束怎么设的，我就把xdc里两个跨时钟域的处理指出来。其实评委想听的是你对自己代码的边界有没有意识——哪段是参考的、哪段是你改的、改完有什么代价。你越主动划清楚，他们越觉得你诚实。最怕的是支支吾吾说全是自己写的，反而会被追问到细节上穿帮。建议答辩前把工程里每个非你手写的IP或源码列个清单，想好每处你做了什么修改，哪怕只是改了参数也算。

给你说个我们组的真实案例。当时队友被问代码是不是抄的，他二话没说，把开发板上的按键按了一下，让LED流水灯速度变快，然后说：这里我把原来查表法的分频器改成了状态机，因为查表法在频率切换时会有毛刺，示波器能看出来，不信现场量。评委还真让他量了，波形干净，这事就翻篇了。所以证明材料不是越多越好，而是要有因果链——仿真波形证明功能对，时序报告证明能跑，实物演示证明你碰过硬件，但最关键是你能说出某个设计选择的理由，以及如果不用这个方案会出什么问题。反过来有个风险你要注意：千万别把所有代码都揽成自己从零写的，现在评委见多识广，一眼看出是开源改的还硬撑，印象分会更差。我建议你准备一张表，左边列参考来源，右边列你做的改动和动机，比如把FIFO深度从512改成1024是因为实测丢包，或者把双口RAM换成BRAM是因为LUT不够。你要是能现场改个模块参数然后重新综合看资源报告变化，那基本没人再质疑。另外如果项目是组队的，提前想清楚每个人负责哪块，被问到就说：这个模块是队友写的，我只负责接口联调，具体内部逻辑我可以大概讲但细节需要他补充——这种坦诚反而显得团队真实。你现在的工程里，有没有哪个模块是你改动最大、最能把原理讲透的？挑那个当主武器就行。