2026年FPGA大赛国赛答辩被问「你们的创新点写进论文了吗」，只有功能演示的队伍该怎么补技术增量？

先说个容易踩的坑：很多人把「技术增量」理解成必须发论文或申专利，其实评委问这句话，核心是想知道你有没有超出「把 demo 跑通」这个层次的思考。论文专利只是证据的一种，不是唯一。你们队的场景是视频拼接加人流统计，功能齐全但缺「为什么这么做」和「这么做比别的做法好在哪」。

比较实际的补法是两条腿走路。一条是横向对比表：跟去年获奖队或者常见方案比，在哪些指标上有可量化的差异，比如拼接路数、分辨率、帧率、资源占用、功耗、端到端延迟。注意别只列你们好的项，要诚实标出你们的短板，评委反而会觉得可信。另一条是挑一个你们真正动过手的模块，写成短技术报告，哪怕只有三四页。比如多路视频的帧同步你是怎么处理的，是丢帧对齐还是缓存重排，为什么选后者，实测抖动从多少降到多少。这种「一个点挖深」比泛泛的功能列表管用得多。

风险在于，如果你们的功能本来就是拿现成 IP 拼的，硬写「优化」容易露怯。这时候换个角度，写系统级的取舍：为什么选 GW5A 而不是更高端的器件，成本、功耗、供货周期上怎么权衡的。工程增量不一定是算法创新，架构选型的理由也是增量。

你们现在离答辩还有多久，模块级的实测数据还留得住吗？

先给个提醒：别把「技术增量」直接等同于论文专利，评委那句话更想听的是你有没有超出跑通 demo 的层次。你们多路拼接加人流统计，功能齐但缺「为什么这么选、比别人好在哪」。补法我建议两条腿走：一是横向对比表，跟常见方案和往年队伍比拼接路数、分辨率、帧率、资源占用、功耗、端到端延迟，记得诚实标出你们差的项，反而可信。二是挑一个你们真动过手的点写短报告，三四页就够，比如多路帧同步你是丢帧对齐还是缓存重排，为什么，实测抖动从多少降到多少。一个点挖深，胜过罗列十个功能。风险是时间不够时两头都做浅了，那就先保报告，因为答辩追问几乎都围着它转。你们现在离国赛还有多久，答辩 PPT 是已经定稿了还是能大改？

答辩被问这一句，其实暴露的是整条技术叙事链缺了一环。功能演示证明的是「能做出来」，技术增量要证明的是「在什么约束下、做了什么取舍、代价换来了什么收益」。这两件事的举证方式完全不同，前者靠跑，后者靠数据和对比。

所以先想清楚你们系统里最硬的那个约束是什么。多路视频拼接加 AI 统计，瓶颈通常不在算法本身，而在带宽和缓存。高云 GW5A 这类器件片上 BRAM、DSP、外部 DDR 带宽都是有限的，四路 1080p 进来，拼接写回再送 AI 推理，中间任何一次跨时钟域搬运都可能成为延迟主因。如果你们当时真的调过某一级 FIFO 深度、改过 AXI 突发长度、或者把某段处理从 DDR 往返改成片内流水，那这就是天然的增量素材。把它写成「问题—候选方案—选择依据—实测数据」四段，比一份泛泛的功能清单有说服力得多。

对比表当然也要，但它是配角。它的作用是给评委一个坐标系，让他们三秒钟知道你们在哪个量级。做表时注意两点：指标要可复现，别写「性能提升明显」这种没法验证的话；对比对象要选得诚实，跟去年获奖队比可以，但更要跟公开的经典方案比，否则评委会觉得你在自说自话。

再说个容易忽略的：论文和专利是滞后的证据，答辩前现补基本来不及，但你可以补「可追溯的工作记录」——版本迭代日志、关键问题的调试过程、被否决的方案及原因。这些不是论文，却是工程增量的真实痕迹。评委见过的队伍多了，谁是真做过谁是在包装，几个追问就分得出来。一个点挖到底，比面面俱到更安全。你们那版拼接是走 DDR 缓存还是全片内流水，这个决定了报告往哪个方向写。

答辩被问到“论文或专利”，很多人第一反应是慌了，觉得自己缺一张证书。但评委真正想确认的其实是另一件事：你们这套系统里，有没有哪个环节是你们自己想明白、并且能说清楚取舍的。功能演示只证明“能跑”，技术增量要证明“为什么这么跑、代价是什么”。这两件事的举证材料不一样。

对高云 GW5A 这种器件来说，多路视频拼接加 AI 人流统计，最硬的那道坎几乎一定在数据通路上，而不是在算法本身。四路 1080p 进来，拼接要写回，AI 要读，中间任何一次 DDR 往返、跨时钟域搬运、FIFO 深度没配好，都会把端到端延迟顶上去。GW5A 的 BRAM、DSP、外部存储带宽都是有限的，你们当时一定在某个地方做过妥协——比如为了省 BRAM 把行缓存拆了，或者为了凑带宽把某级处理改成片内流水。这些妥协就是最天然的增量素材。

所以补法不是去堆一张大而全的清单，而是挑一个你们真动过手、真测过数的点，写成“问题—候选方案—为什么选它—实测数据”这条线。比如多路帧同步，你们是丢帧对齐还是缓存重排？为什么？实测抖动从多少降到多少？一个点写到这个深度，比列十个功能管用得多。

对比表可以做，但要诚实。跟去年获奖队比拼接路数、分辨率、帧率、资源占用、功耗、延迟，把你们差的项也标出来，评委反而信。最怕的是表里全是优势项，一看就是凑的。

时间紧的话，先保那份单点技术报告，因为答辩追问基本都围着它转。你们现在离答辩还有多久，PPT 是还能大改还是已经定稿了？

别把“技术增量”想成必须发论文。你们真正缺的，是把一个工程决策讲成一条因果链。

找系统里最卡的那一环，通常是多路拼接的帧同步或者 DDR 带宽。回忆一下：当初为什么选缓存重排而不是丢帧对齐？FIFO 深度调过没有？AXI 突发长度改过没有？只要有一处你们调过、测过，就把它写成短报告——背景、备选方案、选择理由、实测数据，三四页足够。

指标对比表可以当附件，但别当主菜。主菜是那个“我们改了 X，延迟从 A 降到 B”的故事。答辩时评委追问的也一定是这个点，而不是你列了多少功能。

你们那块板子上，DDR 带宽和 BRAM 哪个先成了瓶颈？

先别急着去补论文，你们被问到的其实不是「有没有论文」，而是「有没有一个讲得清来龙去脉的技术决策」。这两个东西的举证材料完全不同，前者要的是文档，后者要的是一条因果链。

我建议你把答辩前的时间压在一条主线上：找出你们系统里最硬的那个约束，然后把它从头到尾讲透。四路 1080p 进 GW5A，拼接要写回、AI 要读，数据通路上的 DDR 带宽和片内 BRAM 几乎一定是你们真正的瓶颈，算法本身反而不是。回忆一下当时你们在哪里做过妥协：是为了省钱把行缓存拆成几段？还是为了凑带宽把某级处理从 DDR 往返改成片内流水？是 FIFO 深度调过一轮才不丢帧？只要有一处你们真的动手改过、并且测过前后差异，那就是最天然的技术增量素材。

把它写成一条链：原来的做法是什么，卡在哪里，你们试过哪几种方案，最后选了哪个，代价是什么，实测指标从多少变到多少。三四页就够，别写成功能说明书。评委追问的一定是这条链中间的某个环节，而不是你列了多少个模块。指标对比表可以当附件，但别当主菜——它证明的是「你和别人不一样」，不能证明「你想明白了」。

还有个容易踩的坑：很多人觉得没发论文就没增量，于是硬凑一份专利或投个水会。其实评委看的是你有没有超出「跑通 demo」的层次，论文只是证据的一种。你手上有实测数据、有取舍记录，比一张证书更能撑住追问。

你们当时调得最狠的是哪一级，DDR 还是片内缓存？