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

你们这个情况其实挺典型的：三个人按技能切，最后交上去必然是三个独立项目。评委看架构图的时候，找的是「数据从哪来、经过谁、变成什么、交给谁」这条线，而不是「谁会什么」。所以我的建议是改成按数据流切，而且要有一个明确的交接物。

具体点说，先定一个共同契约：输入分辨率、网络结构、每层的输出通道和位宽。这个契约由负责量化的人产出，就是一张逐层位宽表（每层输入输出 shape、定点 Q 格式、激活范围）。这张表就是你们的「接口文档」，RTL 那个人照着它写，而不是照着自己想象写。

然后第三人（你）不要只写文档，你要做的是联合仿真和回归测试。每周固定跑同一组测试向量：一张图进去，Python 端出一组中间层特征，RTL 仿真也出一组，逐层比对误差。谁的数对不上，谁去查。这样文档自然就是「怎么对齐的」而不是「我们做了什么」。

一个容易踩的坑：量化的人只给最终精度，不给中间层数据，RTL 那边就只能猜。反过来 RTL 为了好写偷偷改了位宽，量化那边也不知道。所以那张位宽表必须版本化，改一次记一次。

替代做法也有：如果时间紧，可以让量化的人兼任联合仿真的脚本，RTL 的人只管实现，你专注把对比结果画成图表放进报告。评委其实很吃「误差曲线 + 逐层对齐记录」这套。你们现在板子到手了吗，还是还在仿真阶段？

你们被批的核心不是分工方式，而是缺一个『交接物』。三个人各管一摊本身没错，错在算法那边交出来的东西是 Python 脚本和精度数字，RTL 那边拿到的是自己的想象，中间没有一张双方都要签字的纸。

我建议你们把交接物定成一张逐层位宽表：每层输入输出 shape、定点 Q 格式、激活范围、权重存储方式。这张表由做算法那个人产出，因为他最清楚量化误差从哪来。做 RTL 的人照着表写，遇到表里没写清楚的地方必须回头问，而不是自己拍脑袋定。

风险在于：如果算法那位只会训练不会量化，这张表他产不出来。那就先花两周补 QAT 和 PTQ 的基础，用 PyTorch 的量化工具跑一遍，把每层实际数值范围打出来。这是全队最该先啃的硬骨头，绕不过去。

举个具体场景：检测头输出的框坐标，如果你按 int8 存，小数位不够，框会跳。这种问题只有在位宽表里写清楚每个 tensor 的 Q 格式才可能提前发现，等 RTL 写完再对就来不及了。

你们现在板子定了吗，还是还在等开发环境搭起来？

先说评委为什么觉得像两个项目：你们交上去的是三份产物（训练脚本、RTL、文档），而不是一条链路。切分工之前先定一件事——谁负责产出那份「必须被下游签字确认」的东西。

建议把第一份硬产物定为逐层位宽表：每层输入输出 shape、定点 Q 格式、激活截断范围、权重存储方式、以及这一层允许的误差上限。做算法的人来写，因为量化误差从哪来只有他清楚；写不出来就说明量化这块还没做完，别急着往下走。RTL 那个人拿到表就照着写，遇到表里没定义的地方必须回头问，不许自己拍脑袋定。

一个容易踩的坑：表里只写位宽不写饱和/舍入策略。检测头输出的框坐标如果按 int8 存、小数位不够，框会来回跳，仿真看着对、上板就飘。所以表里最好带一列「该层数值实测范围」，用校准集跑出来的 min/max，而不是拍脑袋的 2 的幂次。

替代做法也提一句：如果算法那位完全没接触过量化，别硬扛，先花一两周用 PyTorch 跑通 PTQ，把每层实际数值范围打出来再填表，这比三个人一起开会扯架构图有用得多。

第三个人不要只写文档，去做联合仿真，每周同一组测试向量，Python 出中间层特征、RTL 仿真出对应结果，逐层比对。文档自然就成了「怎么对齐的」记录。

你们现在训练那位的量化基础到什么程度，是只做过 float 训练吗？这个直接决定第一周该干什么。

你们这个问题的根子不在分工表怎么写，而在『谁向谁负责』这条线没画出来。三个人按技能切，本质上是三个独立的交付物：一个交精度、一个交能跑的RTL、一个交文档，评委当然觉得是拼起来的。想让它咬合，得让其中一个人的输出变成另一个人无法绕过的输入。

我建议把这条链定成：量化定点化 → 逐层位宽表 → RTL实现 → 联合仿真回归。链条上每一环都有个硬产物，缺了下游就干不了活。

具体点说，做算法的那位不能只交训练脚本和mAP数字，他必须产出那张逐层位宽表。表里至少要有：每层输入输出shape、定点Q格式（几位整数几位小数）、激活的截断范围、权重怎么存、这一层允许的误差上限。为什么非得他写？因为量化误差从哪来只有他最清楚，激活值分布什么样、哪层敏感，写RTL的人是不知道的。

然后写RTL那位拿到表照着写，遇到表里没定义的地方必须回头问，不许自己拍脑袋。这一步是很多人翻车的地方——RTL工程师习惯了自己决定位宽、自己决定饱和策略，结果和算法那边对不上，仿真看着都对，上板就飘。

关于你负责的文档，我劝你别把它当成『记录我们做了什么』。文档应该是『我们怎么对齐的』。所以你的核心工作其实是联合仿真：每周固定跑同一组测试向量，一张图进去，Python端吐出中间层特征，RTL仿真也吐一组，逐层比误差。谁对不上谁去查。这个过程本身就会逼出很多接口定义的漏洞。

有个具体的坑值得提前说：检测头输出的框坐标，如果按int8存整数位不够，框会来回跳。这种问题在位宽表阶段就该标出来，而不是等上板才发现。所以表里最好带一列实测数值范围，用校准集跑出来的min/max，不是拍脑袋定的2的幂次。

至于高云GW5A这块板子，它的DSP和BRAM资源是有限的，定点方案在算法阶段就得考虑资源预算，不能训完再想怎么塞。你们可以先粗估一下每层的乘加量和权重存储量，看看哪几层必须做通道剪枝或者改成深度可分离。这个估算表也可以并进位宽表里，让两个人对着同一份数字讨论。

你们现在算法那位会量化工具链吗，还是只做过全精度训练？这个直接决定第一周该干什么。