2026年电赛FPGA赛道队伍三个人，怎么在赛前一个月用「模块负责人制」把UART、ADC、FFT三条线并行推进不互相等？

先说结论：一个月三个人做三条线，真正卡人的往往不是模块本身，而是接口没冻结就开始各写各的。我的建议是头三天只干一件事，三个人坐一起把顶层框图和握手协议定下来，写成一张纸的接口文档，颗粒度到这几个程度就够了：每个模块的输入输出位宽和时钟域、valid/ready 还是 enable/done 这类握手方式、数据什么时候有效、出错或者溢出怎么处理。别追求文档漂亮，能贴墙上让三个人指着吵架就行。

然后才是并行。通信那位先把 UART 收发跑通，用假数据自发自收；采集那位用固定激励灌进 ADC 模型和缓存，保证 FIFO 不溢出；算法那位用 MATLAB 或 Python 生成一组已知输入输出的点，先做仿真对拍。注意这里有个常见坑：三个人都等顶层，结果谁也不敢先动。替代做法是各自写一个简单的 wrapper 仿真环境，不依赖别人的模块。

联调节点固定成每周一次上板，哪怕只联两条线也要联，别攒到最后。风险在于算法线最容易超时，如果到第三周 FFT 还没收敛，就先用查找表或者简化的定点方案兜底，保证整体能演示。另外提醒一句，第一次打电赛别把三个人都压在算法上，通信和采集的稳定性往往才是拿分基础。你们现在定好谁当接口owner了吗？这个人得负责最后顶层集成，不能三个人都只扫自家门前雪。

带过两届队伍，说点实在的。模块负责人制能不能落地，关键不在分工表，而在「谁有权改接口」这件事上。你们三个人都会写Verilog但没做过系统级项目，最大的隐患是每个人心里对接口的理解不一样，等到联调才发现位宽对不上、握手时序错开一个周期，这种返工最伤士气。所以我的主线建议是：接口先行不是走个形式，而是要指定一个人当接口owner，所有接口变更必须经他点头并同步给另外两人，接口文档就写在一个共享文档里，改一次记一次。

具体到三条线，通信外设那条相对独立，UART 可以最早跑通，建议第一周就让他把收发和简单的命令解析做完，用假数据自测；采集与缓存这条依赖器件型号和采样率，得先把 ADC 的时序和 FIFO 深度算清楚，用固定激励在仿真里灌满看会不会溢出；算法流水线最容易拖，FFT 定点化、蝶形运算的位宽增长、流水线级数这些都得提前定，别指望最后一周调出来。这里有个取舍：与其三个人都去啃算法，不如让算法那位先用 MATLAB 生成一组已知输入输出的测试向量，仿真对拍通过再上板，这样联调时至少有个可信的参照。

每周联调要固定时间，比如周六下午，哪怕只联两条线也联，目的是尽早暴露接口问题。我见过太多队伍把联调攒到最后三天，结果发现握手协议理解不一致，三个人互相甩锅。异常处理也要写进文档，比如 FIFO 满的时候是丢数据还是反压，UART 收到非法命令怎么回，这些不写清楚，集成时一定扯皮。

最后说个心态问题：一个月时间其实很紧，别追求三条线都做到完美，先保证能演示的闭环。算法线如果到第三周还没收敛，果断用简化方案兜底，别死磕。你们现在三个人里有没有人愿意当这个接口owner？这个角色比写模块更重要。

先泼点冷水：模块负责人制在三个人都没做过系统级项目的情况下，最容易变成「三个小作坊」。真正的风险不是分工不清，而是每个人对自己那块之外的东西没有判断力，联调时互相看不懂对方在干什么。所以我建议你们在接口冻结之外再加一个维度：轮值review。每周联调前，每人花半小时看另一个人的仿真波形和代码结构，不要求看懂细节，只要求能说出「你这个模块什么时候吐数据、吐多久、下游接不接得住」。这一步听起来浪费时间，但能逼着大家把边界条件想清楚，比如FIFO满的时候采集那边是丢数还是反压、UART收到非法命令是回错误码还是静默丢弃。替代做法也有：如果实在凑不齐时间，至少让接口owner在每周联调时口头过一遍本周接口有没有偷偷改动。另外提醒一句，算法线那位不要一上来就怼FFT全流程，先把定点化和位宽增长的仿真对拍做扎实，用Python生成几组已知输入输出，能对上再谈流水线。你们现在用的开发板是哪块，ADC是板载还是外挂模块？这会影响采集线的排期。

我把话说直白一点：一个月三条线，能不能并行，取决于你们愿不愿意接受「先丑后美」。很多队伍卡住，不是因为不会写模块，而是因为总想等顶层搭好、等别人接口定了再动手，结果一周过去谁都没跑通任何东西。正确的顺序其实反直觉——先让每个人在自己那块里造一个假世界。通信那位不需要等采集，直接用计数器产生假数据往UART里灌，自发自收能跑通就说明收发状态机没问题；采集那位不需要等算法，用一个简单的累加器当消费者，把ADC模型灌满看FIFO会不会溢出；算法那位更不需要等前面，用Python或MATLAB把一组输入输出存成文本，仿真时读进来对拍。这样三条线在第一周就能各自有可展示的成果，士气完全不一样。然后才是每周固定一次联调，联调的目标不是「一次接通」，而是「暴露接口差异」，每次联调后必须更新接口文档，把踩到的坑写进去。接口文档的颗粒度我觉得到这样就够了：每个端口的方向、位宽、时钟域；握手是valid/ready还是enable/done，数据在哪个周期有效；异常情况怎么处理，比如溢出、超时、非法命令。不用画漂亮的框图，能贴出来让三个人指着吵就行。最后补一句取舍：如果时间实在紧，算法线的优先级可以往后放一点，因为UART和采集是系统能跑起来的地基，FFT就算晚几天，只要接口对拍的数据准备好了，接进去很快。你们三个人里有没有人之前上过板调过时序，这个决定了联调阶段会不会被综合和约束拖住。

先说个容易被忽略的点：三个人都「会写点Verilog」和三个人能一起做系统，中间差的不是语法，而是对「时序契约」的共同理解。所以模块负责人制能不能救你们，取决于你们愿不愿意在动代码之前先花时间把契约写死。我的建议是把一个月切成三段：前三天只做接口，第一到第三周各自并行，第四周集中联调。

前三天别急着分谁写UART谁写FFT，先三个人一起在白板或共享文档上画顶层框图，然后逐个接口定四件事：位宽、时钟域、握手方式、异常行为。握手方式要明确是valid/ready还是enable/done，这决定了状态机怎么写；异常行为要明确FIFO满了是丢数还是反压、收到非法命令是回错误码还是静默丢，这一条不定清楚，联调时必吵架。文档颗粒度到「每个信号一行，写清方向、位宽、有效条件」就够了，别追求漂亮。

然后是并行的关键：每个人都要能独立跑仿真，不依赖别人的真实输出。通信那位用计数器造假数据自发自收；采集那位用固定激励灌ADC模型，看FIFO会不会溢出；算法那位用Python生成已知输入输出的文本，仿真时读进来对拍。这一步的本质是把「等别人」变成「等自己」，三条线第一周就该各自有能演示的东西。

联调节点固定成每周一次，但目标要改：不是「一次接通」，而是「暴露接口差异」。每次联调后必须回写接口文档，把踩到的坑记进去。

最后提醒一句取舍：一个月做三条完整线其实很紧，如果时间不够，宁可把FFT先做成小点数、能跑通流水线结构，也别追求全流程最优。你们现在ADC和FFT的器件型号和点数定了吗？这直接决定缓存深度和位宽规划。