2026年电赛FPGA控制题，三人队伍里只有我会写Verilog，队友只会硬件和C，该怎么拆任务才不内耗？

先说一个很多人到赛场上才想明白的事：三个人里只有你会 Verilog，不代表 FPGA 的活都得你亲手敲完。真正的瓶颈往往不是写代码，而是「接口定不下来、队友不知道该给你什么」。所以第一步不是分模块，而是你花半天把系统框图钉死：FPGA 负责什么（比如多路 PWM、编码器计数、并口时序、高速采样），MCU 负责什么（比如人机交互、PID 主循环、屏显），两者之间用什么协议（UART 还是 SPI）、帧格式长什么样、谁主动谁被动。这张纸定下来，队友的活才能并行。

然后拆任务要顺着「谁能独立验证」来切，不是顺着「谁写哪段代码」。焊板子的那位，别只让他画 PCB，让他负责电源树、接口电平和上电时序，并且提前做一块最小系统板先把 FPGA 下载、时钟、复位跑通，这样你后面调试不会卡在硬件低级问题上。写 C 的队友，让他把 MCU 侧的通信解析、命令下发、上位机或按键逻辑先做出来，用串口助手模拟 FPGA 的数据流就能自测，完全不依赖你的 RTL。你这边则集中火力做「FPGA 与外界的边界」：顶层接口、时钟域、状态机骨架。

关键取舍是：不要为了分工好看而把 FPGA 内部切成很多模块给不会 Verilog 的人。他们改不动，你还要花时间讲，反而更累。正确的做法是你把 RTL 做成「参数化 + 寄存器可配」的结构，队友通过 MCU 发命令来调参数，等于他们间接参与 FPGA 功能，而不用碰代码。比如 PWM 频率、占空比、计数阈值都做成寄存器，C 那边写个配置表，联调时改参数不用重新综合，这一点在电赛四天三夜里能救命。

备赛节奏上，建议倒推：赛前两周你必须有一个能跑通的「最小闭环」——FPGA 出波形或读数、MCU 收到、屏幕显示出来，哪怕功能很弱。有了这个骨架，赛题下来只是往里填算法和通道数。赛前一周专门练一次限时模拟，重点不是做难，而是练「接口改了怎么快速同步」。你 Verilog 只写过 UART 和 PWM 完全够用，控制类题目里大量是计数、比较、状态机，把这些写熟比追新 IP 更实在。

还有一个容易被忽略的点：每天收工前花十分钟同步一次接口变更，谁改了帧格式、谁改了引脚，写在一张共享文档里。内耗多半不是能力问题，是信息不同步。你们现在这个配置其实不算差，硬件、C、FPGA 各一人，只要边界清楚，是能打的。你们打算做哪类控制题，是电机还是电源方向？这会影响 FPGA 到底该扛多少实时性。

别把 FPGA 当成一个人的独角戏。让写 C 的队友负责 MCU 侧全部逻辑，你只暴露一组简单的寄存器读写接口给他，比如「写命令字 + 读数据」，协议定死，他就能自己调。画板子的队友先把最小系统和电源做好，再按你给的引脚约束画外围。你只做 FPGA 内部：时钟、状态机、PWM/计数这些核心，外围的慢速逻辑能挪到 MCU 就挪过去。这样三个人都有独立可验证的活，不用互相等。你们主控板是现成的还是自己画？

别硬拆 RTL 给不会的人，改成「你写 FPGA，他写 C 调参数」最省事。

先说一个容易被忽略的点：你现在最该防的不是队友不会 Verilog，而是三个人同时卡在「等对方」。控制类题目里 FPGA 通常管的是高频、并行的部分，比如多路 PWM、编码器正交解码、ADC 采样时序、高速并口协议；MCU 管的是慢速逻辑和决策，比如 PID 主循环、按键屏显、和上位机通信。这个界线一旦模糊，你就会不自觉地把 MCU 的活也揽过来，然后队友闲着，你还累死。

比较实际的做法，是你先花半天把「接口契约」写死：FPGA 和 MCU 之间用 UART 还是 SPI，帧头帧尾怎么定，命令字和数据区各几位，谁主动谁被动，超时怎么处理。写 C 的队友只要拿到这份约定，就可以用串口助手或者 MCU 自己发假数据先把他的解析层调通，不需要等你的板子。焊板子的队友也别只让他画 PCB，让他先把最小系统板做出来：电源树、下载口、时钟、复位、LED 心跳，这四样跑通，你后面调试就不会被电源纹波或者晶振不起振这种低级问题拖住。

风险在于，你可能高估了自己能同时扛的模块数。Verilog 只写过 UART 和 PWM，说明你还没踩过时序收敛、跨时钟域、CDC 亚稳态这些坑。建议留一个「降级方案」：如果 FPGA 侧某个高速模块实在调不出来，能不能用 MCU 的定时器或者外部专用芯片顶上？比如编码器解码，STM32 的定时器编码器模式其实很好用，没必要非在 FPGA 里做。提前想好这个退路，比到时候通宵改 RTL 强。

备赛节奏上，个人感觉前两周别急着写主逻辑，先把三个人的最小可验证单元各自跑通：你跑通一个 PWM 加一个 UART 回环，队友跑通 MCU 收发和一块电源正常的板子，然后合联调。你们题目大概偏哪类控制，是电机还是电源类？这个会影响 FPGA 到底该留多少资源给并行逻辑。

其实你队友不是没用，是你没给他们能独立干的活。把接口协议先定死，写 C 的负责 MCU 侧全部收发和显示，焊板的负责电源加最小系统，你只留 FPGA 内部时序相关的部分，谁都不用等谁。

先把这个事实摆平：电赛控制题里，FPGA 真正吃力的地方往往不是代码量，而是「你一个人既是架构师又是唯一实现者」。所以拆任务的第一刀不该切代码，该切「不确定性」。你现在最不确定的是什么？是板子能不能按时回来、时钟和下载链路通不通、MCU 那边能不能稳定收发。这些东西不解决，你写再多 Verilog 也是空中楼阁。

我的建议是反过来做：先让焊板子的队友把「最小可运行系统」交出来，不是完整作品板，而是一块能上电、能下载、时钟能跑、复位可靠、至少引出一组 GPIO 和一路串口的小板。这件事他完全能独立干，也不需要懂 Verilog。你拿到这块板，才能安心调你的时序。

写 C 的那位，别让他「等你把 FPGA 做完再联调」。你先把 FPGA 和 MCU 之间的接口当成一份合同定死：用 UART 还是 SPI，波特率多少，帧头帧尾、命令字、数据长度、校验位、超时重发，全部写成一页纸。然后让他在 STM32 或者他熟悉的 MCU 上，用串口助手或者自己造数据，把解析层和显示层调通。他甚至可以先写一个假的 FPGA 模拟器，定时往串口发符合格式的包，这样他的代码在真板子来之前就已经能跑。

你自己这边，别贪多。控制类题目真正需要 FPGA 的，通常是高频并行那几件事：多路 PWM 同步输出、编码器正交解码、并口 ADC 采样时序、或者严格的触发逻辑。把这些做成几个独立模块，每个模块都配一个简单的 testbench，先仿真过再上板。你 Verilog 只写过 UART 和 PWM，那就从这两个出发，PWM 改成多路带死区，UART 改成带帧解析的状态机，能力是长出来的，不是等出来的。

节奏上，前两周别碰完整系统，就做三件事：最小系统板、接口协议文档、你自己的两个核心模块仿真通过。中间两周做联调，把 MCU 假数据和真 FPGA 对接，这时候你会发现大部分 bug 在协议层而不是 RTL。最后一周才做整机联调和指标优化。

你们现在手上有没有一块能用的开发板，还是打算从零画？这个决定你第一周的时间分配会完全不同。