2026年，全国大学生集成电路创新创业大赛（集创赛）选‘RISC-V CPU设计’赛题，团队如何分工？侧重乱序执行还是低功耗优化？

从经验来看，2026年集创赛RISC-V赛题评委确实很看重创新点与系统完整性，但更关键的是你们团队能力与赛题难度的匹配度。你们三个人分别擅长Verilog、C/编译器、UVM验证，这个配置其实很适合做‘乱序执行’方向，因为乱序执行的核心在于控制逻辑的复杂性和验证的完备性，而低功耗优化更多需要后端和物理设计经验，你们缺少这块。建议侧重乱序执行，但不要贪大求全，可以聚焦‘部分乱序’或者‘简单乱序引擎+性能计数器’这种创新点，这样既能体现深度又能在有限时间内完成。分工上，不要按流水线阶段分，容易接口混乱。推荐按模块分工：让懂Verilog的同学负责核心执行单元（包括保留站、重排序缓冲区等），懂C的同学负责编译器适配和测试程序编写，懂UVM的同学负责验证环境和覆盖率收集。三人每周至少碰两次接口定义，否则乱序控制逻辑很容易出bug。另外注意，低功耗优化在集创赛往往需要功耗分析工具支持，如果学校没有EDA工具授权，选这个方向会很吃亏。

我去年带过一个类似队伍，最后拿了分区二等奖，说点实在的。你们这个配置，做乱序执行可能有点吃力，因为乱序需要很强的微架构理解，而且验证周期很长，三个人未必够。反而‘低功耗优化’方向更适合你们：懂Verilog的可以优化关键路径的功耗，懂C的可以做软件层面的功耗管理（比如动态电压频率调整的驱动），懂UVM的可以搭建功耗感知验证环境。而且低功耗方向评委容易给高分，因为RISC-V本身在物联网市场很火，创新点可以落在‘自适应功耗管理’或‘门控时钟树优化’上，这些比单纯跑分更有意义。分工建议按功能分：一个负责前端（取指译码的功耗优化），一个负责后端（执行访存的低功耗设计），一个负责验证与功耗评估。但要注意，低功耗设计必须要有数据支撑，比如用PrimeTime PX或者开源工具做功耗对比，否则评委可能觉得只是‘纸面优化’。如果学校没有工具，建议借邻近实验室的或者用开源SimPoints做近似分析。

你们的问题本质上是‘求稳还是求炫’，但我觉得两者可以结合。我建议选‘乱序执行’作为主线，但把低功耗思路作为加分项嵌入进去，比如在乱序引擎中增加‘功耗感知的发射逻辑’。这样既有高性能的亮点，又有低功耗的创新切口，评委看到‘兼顾性能与能效’的思维会很认可。分工上，我强烈建议按‘前后端分离’的思路：让懂Verilog的同学做乱序控制逻辑和数据通路，懂C的同学做测试程序与性能分析（比如跑Dhrystone和CoreMark），懂UVM的同学做验证并顺便负责功耗评估脚本。这样每人有独立输出，但接口集中在‘乱序发射队列’和‘功耗监控模块’上。一个坑是：乱序执行中寄存器重命名和分支预测最容易出bug，一定要在中期验收前把这两部分验证搞定。另外建议用Chisel或SpinalHDL写核心模块，比纯Verilog省力，但你们如果Verilog熟不转也行。最后，集创赛评委喜欢看到‘作品能在FPGA上跑通’，所以哪怕乱序只实现简单版本，也要确保能在Xilinx或Altera板子上上电跑demo，这点比理论创新更关键。

我觉得你们三位的基础挺互补的，先别急着定方向，而是先看看你们手头的开发板资源。如果用的是便宜点的FPGA（比如Artix-7或者Cyclone IV），资源有限，硬上乱序执行大概率会因为面积太大而跑不动，最后流片或者演示时容易翻车。低功耗优化在集成度不高的FPGA上也难出明显效果，评委可能觉得不痛不痒。真正让评委眼前一亮的是完整性和创新点，比如你们把乱序执行里的寄存器重命名算法简化一下，用更少的LUT实现，再配合你们懂编译器的同学做动态指令调度优化，这样既有性能提升又有工程巧思。分工上我建议别按流水线阶段切，那样耦合太强，一个人卡住全队等。按模块分更好——让擅长Verilog的同学主攻执行单元和转发逻辑，这是乱序的核心；懂C编译器的同学负责写测试程序和指令调度，顺便搭一个简单的ISS（指令集模拟器）做功能验证；会UVM的同学负责搭建一个完整的验证环境，覆盖所有异常和中断场景。这样每个人都能发挥长处，而且验证和开发能并行跑，效率高。最后提醒一句，不管选哪个方向，一定要留出至少两周做系统集成和文档，很多队死在最后没时间联调。

说实话，你们三个人里有两个明显偏数字前端和验证，一个偏软件，这配置做乱序执行很吃力。乱序执行涉及复杂的scoreboard、ROB（重排序缓冲）、保留站，光懂Verilog不够，还得深刻理解微架构和时序收敛，你们时间就几个月，很可能做不完。我更建议你们走低功耗优化方向，因为这个赛题评委打分时常常看的是功耗效率和面积利用率，而不是纯性能。你们可以把一个五级顺序流水线做扎实，然后在门控时钟、操作数隔离、动态电压频率调整这些点上做文章。懂C的同学可以设计一些低功耗指令序列，比如在空闲时插入WFI指令，让CPU进入休眠模式。会UVM的同学可以写功耗感知的测试用例，验证不同场景下的功耗下降比例。这样既有数据支撑，又能体现系统思维。分工上，我建议让Verilog好的同学负责前端流水线和低功耗控制逻辑，懂C的同学负责写benchmark和功耗分析脚本，会UVM的同学负责搭建验证平台并做功耗翻转率分析。注意别贪多，把基础流水线做稳定，再在每个模块上加一两个低功耗功能，比如写回阶段的操作数隔离，这样评委问起来你都能讲清楚原理和实现。

我是去年集创赛RISC-V赛题的参赛者，曾经也纠结过你们这个问题。我的建议是：别纯粹按性能或功耗来选，而是看你们能展现的‘完整度’。评委最烦那种只跑个Dhrystone就交差的队伍，他们想看你们有无异常处理、中断支持、总线接口和简单的操作系统移植。所以你们如果做乱序执行，很可能最后连异常都来不及处理，分数反而不高。倒不如做一个顺序双发射CPU，这样既有一定性能提升，又有余力把Cache、TLB和总线接口做全，再让懂C的同学移植一个FreeRTOS或者RT-Thread，让会UVM的同学验证所有特权级切换场景。这样你们既有技术深度（双发射和动态分支预测），又有系统广度（操作系统和验证覆盖率），评委打分时很吃香。分工上我推荐一种混合方式：前两周三个人一起把架构文档写清楚，明确指令集子集和特权等级，然后第一人负责取指和译码阶段以及分支预测，第二人负责执行和访存阶段以及Cache控制器，第三人专门做验证环境和中断异常处理逻辑。每周末做一次集成联调，用git管理代码。最后强调一点，一定要在提交前两周用上开源的RISC-V测试框架比如riscv-tests，跑通所有基本指令和异常用例，否则现场演示时崩了就很尴尬。