2026年FPGA大赛企业命题要求用高云GW5A做端侧AI推理，队伍只有三个人，算法、RTL、文档怎么分工才不被评委说「像三个人各做各的」？

先对齐一个前提：你们是第一次参赛、三个人技能都比较初级，那么最大的风险不是分工不细，而是接口没定死就开始各干各的。我的建议是前两周别急着写代码，先花两三天把三件事钉下来：模型侧确定YOLOv5n的量化方案（一般是int8，PTQ先跑通）、每一层的输入输出张量形状和数据类型；RTL侧确定卷积和池化的流水线划分、片上缓存大小、AXI/AXI-Stream的位宽和握手时序；文档侧把这些直接写成一份接口约定表，谁改谁签字。这份表就是防止『三个人各做各的』的唯一凭据，评委答辩时看到你有版本化的接口文档，印象会完全不一样。

对齐节点我建议每周一次固定接口会，但别开成汇报会，就干一件事：拿当周的真实数据跑一次小端到端，哪怕只是第一层卷积从Python导出权重、RTL仿真出结果、文档记录误差。越早暴露位宽截断、量化误差、握手反压这些问题越好。提交前两周必须做全流程联调，留出至少三天纯debug，不要指望最后拼一把。

另外一个容易忽略的维度是风险备份：算法同学要准备一个『降级版』模型（比如输入分辨率砍一半或换更小的backbone），万一GW5A资源或时序顶不住，能快速切换；RTL同学要保证每级流水线可单独仿真验证。你们现在模型量化用的是官方工具链还是自己写的导出脚本？这个会直接影响接口约定的粒度。

我按一条主线说：把三个人拧成一股绳的关键，是让『数据』而不是『人』成为交接物。你们现在最怕的是各做各的，本质是每个人手里都有一份只有自己懂的中间产物——Python里的模型、Verilog里的模块、Word里的文档。破局办法是定义一条贯穿三人的数据链：算法同学产出量化后的权重文件和逐层的golden数据（输入张量、期望输出），RTL同学拿这份golden数据做仿真比对，文档同学记录每一层的位宽、误差和资源占用。这样一来，任何一个人进度落后，另外两个人立刻能看见，因为数据对不上。

具体节奏上，赛前两周到提交前可以这样切：第一周把YOLOv5n的骨干网络先跑通一层到两层的端到端，别贪多，Focus层或第一个Conv能对齐就说明链路通了；第二周扩展到完整backbone，同时RTL开始接AXI接口、文档同步整理资源功耗表。每周固定一次接口对齐会，但会议产出必须是更新后的接口文档和一份联调记录，否则就是空谈。提交前一周做端到端联调，重点看量化误差是否在可接受范围、时序是否收敛。

这里有个取舍要提前想清楚：高云GW5A的资源相对有限，YOLOv5n全量部署很可能吃紧，常见做法是先用小分辨率输入或裁剪通道数跑通demo，再逐步加回去。别一上来就追求完整精度，先保证『能跑、能演示、误差可控』，再谈优化。你们现在有没有定下输入分辨率和目标帧率？这两个数会直接决定RTL的流水线深度和缓存策略。

三个人最怕的不是分工不清，是接口没写死。先让算法把每层张量的形状和位宽列成表，RTL照着表写，文档就负责维护这张表并每周对一次，比开十次会都管用。

先泼一点冷水：评委说「各做各的」，往往不是因为你们分工不细，而是因为答辩时三个人讲的是三套东西——算法讲mAP，RTL讲LUT，文档讲进度，中间没有一条共同的证据链。所以分工的重点不是把活切成三块，而是让三个人的产出能互相对上。我建议按「模型—接口—验证」三条线走，但真正的粘合剂是验证。

具体说，算法同学的核心交付不是「跑通了YOLOv5n」，而是量化后的权重文件加一份逐层golden数据：每层的输入张量、输出张量、位宽、缩放因子。这份东西RTL同学能直接拿去当testbench的期望值，文档同学能直接抄进设计说明，一份产出服务两个人，这才叫协作。RTL同学的重点是先把第一层卷积的流水线和数据位宽定死，别急着铺满整个backbone，因为位宽和握手协议一旦定错，后面全要返工。文档同学别只当记录员，让他维护那张接口表并负责每次对齐会的结论落地，谁改了位宽谁在表上留痕。

时间上，赛前两周到提交前，第一周只求端到端打通一层，Python导出权重、RTL仿真出结果、文档记录误差，这一层通了，链路就活了。第二周再扩到完整backbone，同时接AXI。提交前一周必须留出联调时间，别把集成压到最后三天，这是新手队最常见的翻车点。每周固定一次对齐会是必要的，但别开成汇报会，就干一件事：拿当周真实数据跑一次小比对，对不上就当场定位是谁的问题。

顺带提醒，高云GW5A的资源和工具链特性要早点摸，综合报告里的资源占用最好每周记一次，答辩时这条曲线比任何PPT都有说服力。你们现在算法同学的量化方案定了吗，是PTQ还是打算上QAT？这个会直接影响第一周能不能跑通。

先说个容易被忽略的维度：评委说『各做各的』，很多时候不是分工问题，而是三个人对『完成』的定义不一样。算法觉得模型跑通mAP达标就完了，RTL觉得仿真波形对就完了，文档觉得字数够了就完了——三套标准，自然像三个项目。所以你们赛前两周第一件事不是分任务，是三个人一起把『什么叫做完』写成一张验收清单，比如第一层卷积要求Python导出权重、RTL仿真输出与golden误差在1个LSB内、文档记录该层位宽与资源占用，三条全绿才算这一层完成。这张清单本身就是最好的分工说明书。

具体到三条线：算法同学别只交『能跑的模型』，要交量化后的权重文件加逐层golden数据，这是RTL的testbench输入，也是文档的素材来源，一份产出喂两个人。RTL同学先把第一层卷积的流水线和数据位宽钉死，别急着铺满backbone，位宽和握手协议定错后面全返工。文档同学别当记录员，让他维护那张接口约定表，谁改谁签字，答辩时版本化的接口文档比十页PPT管用。

对齐节点建议每周一次，但别开成汇报会，就干一件事：拿当周真实数据跑一次小端到端，哪怕只有第一层。越早暴露量化截断和握手时序问题越好。提交前一周必须整体联调，别留到最后三天。

顺便问一句，你们现在模型侧是打算PTQ还是QAT，这个选择会直接影响算法同学前两周的时间分配。

三个人分工，我的建议是按『模型—接口—验证』切，但重点说接口这条，因为你们最怕的拼不起来，八成会死在接口上。

算法同学的核心交付物不是模型本身，是一张表：每一层的输入输出张量形状、数据类型、量化缩放因子，加上量化后的权重文件。这张表给RTL当仿真期望值，给文档当设计说明，一份东西服务两个人，这才叫协作。RTL同学拿到表之后，先把第一层卷积的流水线和位宽定死，AXI-Stream的握手时序提前和算法对清楚，别自己闷头写。文档同学负责维护这张表，每周更新一次版本。

每周固定一次接口对齐会，但只对数据不对进度，谁的数和表对不上谁改。提交前一周做端到端联调。

你们现在这张层间数据表有人开始写了吗？