2026年集创赛FPGA赛道改成企业命题制，赛题里塞了DDR带宽和实时性硬指标，普通本科生队伍从哪下手才不至于开题就崩？

先说一个很多人开题就踩的坑：拿到企业命题后第一反应是去翻别人的开源工程，想找个类似的架构改改。这类题恰恰改不动，因为硬指标不是靠堆模块堆出来的，而是从系统指标反推出来的。

正确的顺序是先做指标分解。企业给的端到端吞吐和延迟，一定要拆到你每个子模块的时钟频率和数据位宽上。比如要求 1080p60 实时处理，那像素时钟大概 148.5MHz，你就要问自己：我的算法通路能不能在这个频率下单周期处理一个像素？如果算法本身要迭代几十次，那必须做并行展开或者流水线化，这时候 DDR 带宽就成了瓶颈——你每帧要读多少字节、写多少字节，乘以帧率，跟 DDR 理论带宽一对比，心里就有数了。这一步做完，你才知道哪些模块是真正卡脖子的。

接下来才是搭最小可运行链路。注意是最小，不是完整。输入源、DDR 读写、一个最简处理、输出显示，这条链路先跑通，哪怕处理逻辑只是把数据原样透传。这一步的意义在于把工具链、约束、时序、板级调试这些脏活提前暴露出来。很多队伍烂尾就是因为算法写得差不多了，结果发现 DDR 控制器配置不对、时序收不收敛，最后两周全耗在调通路上。

里程碑按周排的话，前两周死磕数据源和 DDR 读写，别嫌慢，这块打通后面才顺。第三到五周做核心算法通路，可以先功能正确再谈性能。第六到七周做时序收敛和实测，这时候才是真正对着硬指标调优的阶段。第八周写文档和答辩材料，别拖到最后三天。

还有个取舍：三个人不要都扑在算法上。让最稳的那个人专门负责链路和时序，另外两个人分算法模块，接口先定死。你们现在 DDR 没人碰过，建议队长自己先啃这块，因为它是最容易卡死整个项目的环节。你们板子上的 DDR 是哪一款，控制器是用的官方 MIG 还是自己写的？这个决定了前期要花多少时间。

先别急着找开源工程改，企业命题最怕的就是这个思路。硬指标题的本质是反向推理：给你一个端到端指标，你要自己把它拆成一层层可实现的子预算，而不是先有模块再祈祷它跑得够快。

拿实时性举例。假设命题要求某个分辨率下实时出图，你先算出像素时钟大概是多少兆，然后问自己一个问题：我这条算法通路，能不能在这个时钟下一个周期吐出一个像素？如果不能，差多少倍？差十倍就要么并行展开，要么把算法换成能流水的形式。这一步想清楚之前，写任何 RTL 都是浪费。

DDR 带宽也是同一个逻辑。别一上来就想着怎么把 AXI 接上去，先算账：每帧要读多少、写多少、乘以帧率，得到需要的字节带宽，再和 DDR 的理论带宽打个折对比。你会发现很多题目的瓶颈根本不在算法，而在访问模式——连续大块搬运和随机小块访问，实际能拿到的带宽能差好几倍。这个判断会直接决定你后面是走行缓存 + 突发传输，还是老老实实做乒乓缓冲。

顺序上我个人坚持先跑最小链路：一个最简输入源、一次 DDR 往返、一个能出结果的简单处理、一个能看到的输出。哪怕这个处理只是把像素取反，只要它端到端通了，你后面所有优化都是在这个骨架上做替换，而不是在黑洞里调。很多队伍烂尾就烂在算法模块写了三周，结果 DDR 读写还没验证过，最后发现时序和带宽全对不上。

里程碑按周卡比较现实。前两周别碰核心算法，就干数据源和 DDR 读写，把仿真波形和上板实测都跑通。第三到五周做核心算法通路，这时候允许性能不达标，先把功能对齐。第六到七周才是时序收敛和实测调优，这一步往往比想象中费时间，因为跨时钟域和布线拥塞会在综合后才暴露。第八周留给文档和答辩，别拖到最后三天。

三个人分工上，DDR 和时序收敛最好由同一个人盯，因为这两个是强耦合的；算法和验证可以拆开。你们队里大二那位写状态机没问题的话，正好去做数据搬运和握手协议，别让他去啃算法。

最后问一句：你们选的具体命题里，硬指标是偏吞吐还是偏延迟？这两个的拆解方式差别挺大的。

别先想架构，先拿纸算一遍像素时钟和 DDR 字节带宽，算完你就知道瓶颈在哪了。两个月的话，前两周只干数据源加 DDR 读写，功能通了再谈优化，不然必烂尾。你们选的题是卡吞吐还是卡延迟？