FPGA实战：用Verilog实现RISC-V单周期CPU完整指南

把CPU跑在FPGA上这件事，我一直觉得是数字设计里最值得亲手做一遍的训练。很多人一听到CPU就联想到复杂的流水线、乱序执行、多层缓存，但其实最基础的RISC-V单周期实现，几百行Verilog就能点亮一块开发板，而且整个过程中你能完整经历指令集架构、数据通路搭建、控制信号生成、仿真验证到板级调试，把数字电路课程里学的知识真正串成一条线。这篇文章记录我自己基于Xilinx FPGA实现RISC-V单周期CPU的完整过程——从RV32I指令集的选择，到Verilog代码的分模块设计，再到Vivado里的仿真、约束与在线调试，最后附上可以直接用的Verilog代码。如果你是FPGA入门不久、想做一个像样的综合项目，或者正在学计算机组成原理、想把自己写的CPU代码跑在真实硬件上，这篇文章应该能帮你少走不少弯路。

1. 为什么是RISC-V单周期CPU：整体设计思路拆解

1.1 三个选型决定的底层逻辑

很多人第一次做CPU项目会在“用哪个指令集”“做几级流水”“选哪家FPGA”之间犹豫，我的建议是别犹豫，直接RISC-V的RV32I、单周期、Xilinx板子，三个决定都有非常具体的理由。

先说指令集。RISC-V的RV32I基础指令一共47条，去掉伪指令和不需要立马支持的系统指令后，真正需要硬件实现的核心指令大概30多条，单周期CPU完全可以覆盖。R型算术逻辑、I型立即数、S型存储、B型分支，再加上lui、auipc、jal、jalr，一条条对照着写进控制译码表就行，不存在任何专利和授权问题。相比MIPS或者ARM，RISC-V的官方手册riscv-spec开放获取，汇编工具链开源，网上资料多，这些在做项目时是实打实的优势。我当时写测试程序时直接用开源工具链把C代码交叉编译成RISC-V汇编，再手动转成机器码，省了无数手写指令的功夫。

然后是单周期。单周期CPU的意思是每条指令在一个时钟周期内走完取指、译码、执行、访存、写回的全流程，时钟周期不能短于最慢那条指令的完整路径延时。它的缺点很明确——性能不高，但作为教学和原型验证完全够用，好处更直接：控制逻辑是纯组合逻辑，没有任何数据冒险、控制冒险和流水线寄存器需要处理。我早年间第一次做CPU项目时直接选了5级流水，结果光是冒险处理就折腾了快半个月，后来做验证平台时老老实实回到单周期，结果新指令一小时内就能加进去跑通。先能跑通，再谈性能，这是做CPU项目最要紧的次序。

再说Xilinx。这里不是吹品牌，而是Vivado的生态确实对入门者友好：仿真器、综合工具、约束编辑器、ILA在线逻辑分析仪都在同一个环境里，全程不用跳出界面。Xilinx的BRAM推断也很成熟，指令存储器和数据存储器用reg数组一写，综合工具自动映射成BRAM，不需要手动调用IP核。对想先专注CPU逻辑的人来说，这能省掉最麻烦的存储器配置环节。选型上，Xilinx从Spartan到Artix、Kintex、Virtex资源跨度很大，入门级的Spartan-7或者Artix-7已经能轻松放下一个单周期CPU，甚至还能加上UART、I2C、数码管显示这些外设模块。

当然，板子还是要结合手里的硬件来定。如果你手里是其他厂商的FPGA也完全没有关系，核心设计思路完全一致，只需要把工程创建和约束文件换成对应平台的格式就行。

1.2 数据通路先画明白，Verilog只是翻译

写代码之前，我强烈建议先在纸上把数据通路图画出来。这张图画清楚了，Verilog其实就是在给这张图做逐段翻译。另外，Xilinx选型手册里对不同器件的逻辑资源、BRAM数量、DSP48数量都有详细列表，画图之前顺手查一下自己板子的资源，心里就有底了。

我的单周期数据通路按顺序可以分成这么几段：PC寄存器输出地址给指令存储器，取出的32位指令同时送给两个地方——控制单元译码生成所有控制信号，以及寄存器堆和立即数扩展模块。寄存器堆根据指令中的rs1、rs2读出两个操作数，立即数扩展模块按指令类型生成32位立即数，这两个来源经过一个由ALUSrc控制的二选一进入ALU。ALU的结果和读出的第二个数据经过MemToReg二选一，决定写回寄存器堆的数据来自ALU结果还是数据存储器。分支判断在ALU里完成比较，生成的结果送入控制单元，配合Branch和Jump信号生成PCSrc，控制PC的下一地址是PC+4还是跳转目标。

单周期CPU的关键路径通常就在这条链路上：PC到指令存储器，到寄存器堆读出，到ALU，再到数据存储器读取，最后写回寄存器堆。这说明一个时钟周期必须覆盖整条路径的延时，所以单周期CPU的时钟频率一般不会太高，在入门级板子上50MHz到100MHz已经算顶天了。这不是缺陷，而是单周期架构的固有特性，理解这点之后，后面做时序约束时就不会对着时序报告一头雾水。

模块划分上，我把整个设计拆成九个模块：pc、instruction_memory、register_file、alu、alu_decoder、main_decoder、immediate_extend、data_memory，以及顶层cpu_wrapper。控制单元拆成主译码器和ALU译码器两层，好处是主译码器只需要根据opcode和funct3、funct7输出少量信号，ALU的具体运算由alu_decoder根据ALUOp和funct3/funct7再细译码。这样设计之后，以后想加一条指令时，多数情况下只需要改main_decoder或者alu_decoder里的真值表，不用把整个控制逻辑翻个底朝天。

1.3 指令集裁剪：RV32I核心指令覆盖表

我实现的指令集以RV32I为基础，按功能分成几组：

• R型算术逻辑：add、sub、and、or、xor、sll、srl、sra、slt、sltu
• I型立即数：addi、andi、ori、xori、slli、srli、srai、slti、sltiu
• 访存指令：lw（I型）、sw（S型）
• 分支指令：beq、bne、blt、bge、bltu、bgeu
• 跳转指令：jal、jalr
• 高立即数指令：lui、auipc

这20多条指令已经能覆盖大部分简单C程序编译出来的汇编，配合RISC-V的伪指令，比如li、mv、ret，跑冒泡排序、斐波那契数列都绰绰有余。做CPU项目最忌讳一上来就想支持全部指令，先把基础指令跑通，后面再扩展M扩展（乘除法）就会顺手很多。

下面这个对照表是我在设计时反复要查的指令格式和立即数类型，建议你手头也放一份：

每条指令的funct3和funct7值在建译码表之前一定要对着官方手册逐个确认。我记得市面上有些教程把srai的funct7写错，照抄之后仿真时其他指令都正常，就是移位指令结果不对，最后逐位比对官方手册才找出问题。这类错误排查起来最费时间，所以从一开始就得养成对照手册的习惯。

2. Verilog核心模块逐段拆解与实现要点

2.1 PC与指令存储器：CPU的发动机和制导

PC模块是整个CPU的起点。它在时钟上升沿更新，复位时清零，正常情况下一拍加4，遇到分支或跳转时加载目标地址。具体实现时我用了下面这种写法：

module pc #(parameter WIDTH = 32) ( input wire clk, input wire rst_n, input wire PCSrc, input wire [WIDTH-1:0] jump_target, output reg [WIDTH-1:0] pc ); always @(posedge clk or negedge rst_n) begin if (!rst_n) pc <= 32'h0000_0000; else if (PCSrc) pc <= jump_target; else pc <= pc + 32'd4; end endmodule

这个模块本身很简单，但有一个细节值得注意：分支跳转的jump_target在单周期里由ALU计算得到，而jal指令的目标地址其实是PC+立即数，这一点在ALU的输入选择上要特别处理。我的做法是让alu_decoder额外输出一个JumpSrc选择信号，jal和jalr走专门的地址计算路径，而不是简单复用分支路径，虽然多了一点点硬件，但逻辑清晰很多。

指令存储器我用reg数组实现，初始时用$readmemh把十六进制指令文件加载进去，这样仿真和板级验证用的是同一份机器码。关键代码如下：

module instruction_memory #(parameter DEPTH = 256) ( input wire [31:0] addr, output reg [31:0] instr ); reg [31:0] mem [0:DEPTH-1]; initial begin $readmemh("asm/cpu_test.hex", mem); end always @(*) begin instr = mem[addr[31:2]]; // 按字索引，低2位丢弃 end endmodule

这里有一个时序上的取舍：如果读地址用组合逻辑直接索引，综合工具倾向于把存储器推断成分布式RAM（LUTRAM），好处是同一个周期就能拿到指令，但占用查找表资源较多；如果读地址寄存器化，就能用上真正的BRAM，但会引入一拍读延迟。单周期CPU要求同一周期完成取指，所以我选择前者，先保证教学逻辑清晰。实际上256×32bit的指令存储器用LUTRAM实现，几百个LUT对现代FPGA来说根本不算事。

2.2 寄存器堆与ALU：读写路径的关键取舍

寄存器堆实现32个32位寄存器，x0硬连线为0。两个读端口组合输出，一个写端口在时钟上升沿写入，写地址为0时自动忽略写入，这是RISC-V规范里的硬性要求。

module register_file ( input wire clk, input wire RegWrite, input wire [4:0] rs1, input wire [4:0] rs2, input wire [4:0] rd, input wire [31:0] wdata, output wire [31:0] rdata1, output wire [31:0] rdata2 ); reg [31:0] regs [0:31]; assign rdata1 = (rs1 == 0) ? 32'b0 : regs[rs1]; assign rdata2 = (rs2 == 0) ? 32'b0 : regs[rs2]; always @(posedge clk) begin if (RegWrite && (rd != 0)) regs[rd] <= wdata; end endmodule

写回数据来自ALU结果还是数据存储器，由MemToReg信号控制，这个选择在顶层模块里用二选一实现。个人经验是：寄存器堆不要怕用行为级写法，Vivado会把它合理地映射到分布式RAM或者寄存器堆，关键是x0的写保护一定要做，否则后面跑分支指令时寄存器被意外改写，排查起来极其痛苦。

ALU实现上，加减、逻辑、移位、比较都要覆盖。比较指令slt和sltu输出1位的比较结果，我在这里直接把32位的比较结果赋值给Zero信号，分支判断逻辑再根据指令类型组合出最终的分支条件。

module alu ( input wire [31:0] a, input wire [31:0] b, input wire [3:0] alu_ctrl, output reg [31:0] result, output wire zero ); always @(*) begin case (alu_ctrl) 4'b0000: result = a + b; 4'b0001: result = a - b; 4'b0010: result = a & b; 4'b0011: result = a | b; 4'b0100: result = a ^ b; 4'b0101: result = a << b[4:0]; 4'b0110: result = a >> b[4:0]; 4'b0111: result = $signed(a) >>> b[4:0]; 4'b1000: result = ($signed(a) < $signed(b)) ? 32'b1 : 32'b0; 4'b1001: result = (a < b) ? 32'b1 : 32'b0; default: result = 32'b0; endcase end assign zero = (result == 32'b0); endmodule

这里有两个容易踩坑的细节。一是sra算术右移必须用$signed(a) >>> b这种写法，否则综合工具可能推断成逻辑右移；二是slt和sltu的比较是有符号数和无符号数的区别，对应到代码里就是$signed(a) < $signed(b)与a < b，这两条特别容易写混。我的调试习惯是写完ALU先单独写一个小的testbench验证所有运算结果，确认无误后再接进CPU整体流程。

2.3 控制单元与立即数扩展：译码表的完整性与扩展规则

控制单元是整个CPU最核心的组合逻辑模块，我把主译码器和ALU译码器分开写。主译码器根据opcode判断指令类型，输出RegWrite、ALUSrc、MemWrite、MemRead、MemToReg、Branch、Jump、ALUOp等控制信号。ALU译码器再根据ALUOp和funct3、funct7细化出最终的ALU运算控制字。这样分层之后，每张真值表都短小清晰，不容易出错。

主译码器的核心判断依据是RISC-V各指令的opcode字段：

我第一次写这张表时漏了sw的RegWrite，导致仿真时存储指令一直写不进数据存储器，寄存器堆的波形看起来又一切正常，排查了很久。所以在这里特别提醒：控制信号真值表一定要逐条指令对着官方指令手册核对，不要凭感觉填。

立即数扩展模块看起来简单，实际容易出错的点全在符号扩展的位宽选取上。I型立即数是inst[31:20]整体符号扩展，S型立即数要注意它的立即数被拆成inst[31:25]和inst[11:7]两段，B型立即数更特殊，它是inst[31]、inst[7]、inst[30:25]、inst[11:8]的组合，而且最低位永远是0，因为RISC-V的分支地址是2字节对齐的。J型立即数的拼接方式也容易错。我的建议是每个类型的扩展都单独写注释，然后交叉验证。

2.4 数据存储器与顶层模块：单周期最后的拼图

数据存储器结构和指令存储器类似，只是多了一个写使能端口。我在实现时把它做成单端口RAM，时钟上升沿写入，读取用组合逻辑，这样可以保证lw指令在同一周期拿到数据，不破坏单周期的时序假设。

module data_memory #(parameter DEPTH = 256) ( input wire clk, input wire MemWrite, input wire MemRead, input wire [31:0] addr, input wire [31:0] wdata, output reg [31:0] rdata ); reg [31:0] mem [0:DEPTH-1]; always @(posedge clk) begin if (MemWrite) mem[addr[31:2]] <= wdata; end always @(*) begin if (MemRead) rdata = mem[addr[31:2]]; else rdata = 32'b0; end endmodule

顶层模块要做的就是把前面所有子模块按数据通路的顺序连起来。这里的关键是PCSrc信号的生成逻辑：分支跳转条件是Branch信号有效并且ALU的比较条件满足，或者Jump信号有效。我用一个简单的组合逻辑区分三种来源：

assign branch_taken = branch && alu_zero; // beq等 assign jump_taken = jump; assign PCSrc = branch_taken || jump_taken;

attention是要注意blt这样比较小于的分支不能用alu_zero直接判断，需要在ALU里把比较结果直接拉出来。我的做法是让ALU额外输出一个b_lt信号，用于B型指令的分支判断，避免对zero信号的语义造成混淆。

3. 在Xilinx FPGA上完成仿真、约束与板级验证

3.1 Vivado工程创建与器件选型

工程创建阶段，我先根据手里的板子确定器件型号。如果你手上是入门级开发板，比如Artix-7系列的xc7a35t，选择正确的封装和速度等级后，在Vivado里新建RTL工程，目标语言选Verilog，器件型号选对就行。在创建过程中，Vivado会要求选择仿真语言和源文件类型，因为我使用的是纯Verilog，选默认的Verilog即可。

添加源文件时，我会额外建一个专门的目录结构，把RTL源码、testbench、约束文件、汇编代码分开存放。这个习惯看起来琐碎，但等你的工程文件增加到几十个的时候就会庆幸当初做了分类。我的目录结构大概是这样：

cpu_riscv/ ├── rtl/ # 所有verilog源代码 │ ├── pc.v │ ├── instruction_memory.v │ ├── register_file.v │ ├── alu.v │ ├── alu_decoder.v │ ├── main_decoder.v │ ├── immediate_extend.v │ ├── data_memory.v │ └── cpu_wrapper.v ├── sim/ # testbench ├── asm/ # 汇编/十六进制指令文件 ├── constr/ # xdc约束文件 └── bit/ # 生成的比特流

器件选型上我再说一句：Xilinx的选型手册里有不同器件的逻辑单元、BRAM、DSP48、时钟资源对比表，做这个项目之前可以先查一下自己板子的BMRA数量和LUT数量。单周期CPU加上数据存储器、指令存储器，总共占用的资源大概在几百到一千个LUT左右，所以几乎任何一块入门级板子都能放下，不必为资源担心。

3.2 testbench设计：仿真验证的三个关键技巧

testbench是整个验证流程的起点，我习惯把仿真分成三个层次：先单独验证每个子模块，再验证整体CPU执行一条已知指令，最后加载一段真实程序跑完整流程。

单个子模块的验证，重点关注边界条件。以ALU为例，我会把有符号加法、无符号比较、移位边界这些情况全部覆盖一遍，宁可多写几条测试用例也不让bug流到下一层。整体CPU验证时，我选择的第一个测试程序通常是一个从地址0开始的简单加法序列，每执行一条指令后用$display打印寄存器的值，对照手工计算的结果。

第三个层次是加载真实程序。这里推荐一个技巧：先用GNU工具链把C程序编译成RISC-V汇编，再用objdump反汇编得到机器码，配合一个简单的Python脚本把机器码转换成$readmemh需要的hex文件。这样构造测试程序的速度比手写指令快得多，而且能验证CPU对真实编译产物的兼容性。我第一次这么做时，发现编译器优化后的代码会用到一些我没实现的伪指令，也是在这个阶段暴露出来的。

testbench里还应该加上一个仿真结束计数器，防止程序跑飞之后仿真永远不结束。我的做法是在顶层实例化一个周期计数器，当执行到特定地址的结束指令时，用$finish终止仿真。

3.3 约束文件与ILA在线调试：让CPU在板上跑起来

仿真通过之后，下一步就是上板。约束文件里最核心的是时钟和复位引脚，如果板载时钟是50MHz，直接在XDC里写：

create_clock -period 20.000 -name sys_clk [get_ports clk] set_property PACKAGE_PIN N16 [get_ports clk] set_property IOSTANDARD LVCMOS33 [get_ports clk]

复位按键和LED输出引脚也一并约束。综合、实现、生成比特流之后，用Vivado的Hardware Manager下载到板子。如果一切正常，复位之后LED应该显示寄存器堆某个寄存器里的值，比如让一个寄存器自增后输出到LED，就能直观看到CPU在跑。

板级调试时，ILA（Integrated Logic Analyzer）是排查问题最强大的工具。在Vivado里添加ILA IP核，把PC、指令、关键控制信号、ALU结果接到探针上，触发条件设成PC等于某个特定值，就能捕捉到指令执行的完整波形。我调试时最常用的触发条件是指令地址等于测试程序的结束地址，这样仿真结束时CPU停滞，ILA捕到的最后一段波形就是程序执行最关键的部分。曾经遇到过仿真全通过、板上LED却完全没反应的情况，最后就是靠ILA发现复位释放后时钟根本没有翻转，原因是复位按键的默认电平是低有效，我反着接了一拍。

3.4 演示内容与扩展方向

验证程序我选的是冒泡排序加数码管显示。先把一组乱序数据放在数据存储器里，CPU执行排序，最后把结果写到输出地址映射的寄存器，由数码管驱动模块显示。这里涉及一个小的地址映射技巧：在数据存储器的地址空间里划出一段专门留给外设，比如0x100表示数码管段码寄存器，0x104表示位选寄存器，CPU执行sw指令写这些地址，相当于通过存储映射控制外设。

如果还想进一步，可以加一个UART模块把排序结果输出到PC串口终端，或者在FPGA里用ILA抓取完整个排序过程的波形，这些扩展都建立在已有CPU正确运行的基础上。每一类外设的接入方式都不同，但这正是一个综合项目最有价值的地方——你不是在跑一个孤立的CPU，而是在做一个小型SoC的雏形。

4. 调试实录：常见问题与排查方法速查

4.1 指令执行结果不对：先从三行排查法开始

仿真波形里指令执行结果错误时，我有一套固定的排查逻辑，总结下来就是“三行排查法”：先看PC是否按预期递增或跳转，再看取出的指令是否等于预期机器码，最后看控制信号和寄存器写入值是否符合这条指令的语义。

第一步看PC。如果PC在分支处没有跳转，问题大概率出在分支条件判断或者PCSrc信号上；如果PC出现非4字节对齐的地址值，往往说明跳转目标计算有误。第二步看指令，把取出的32位数据拆成opcode、funct3、rs1、rs2、rd、立即数这几个字段，对照反汇编结果确认取指无误。最后一步看寄存器堆写入，重点确认RegWrite和MemToReg阶段是否按预期工作，这一步能筛掉大部分控制信号组合错误。

在这个排查流程里，我最常发现的问题其实都不是复杂逻辑错误，而是立即数扩展的位宽错误和控制信号的漏配。比如srai指令的立即数需要把shamt位段单独提取并符号扩展，很多人直接复用I型立即数的扩展逻辑，结果高位置成一串1，把整个移位量变成很大的数，最后结果完全不对。这类问题有一个共性：单条指令单独跑没问题，一旦前后指令序列变化就会暴露，所以排查时一定要构造多指令序列的测试程序。

4.2 Vivado环境与License相关的连串问题

Vivado的安装和使用过程中，环境问题和技术问题一样多，这里记录几个高频坑。

首先是仿真License问题。我在测试工程时遇到过Vivado的仿真器直接报“failure to obtain a verilog simulation license”，排查后发现是环境变量里的License路径指向了旧版本，导致新版本Vivado拿到过期的License文件。解决方法是确认当前使用的Vivado版本对应的License文件路径，删除或更新旧的License路径配置。如果你用的是WebPACK免费License，要确保器件型号在免费支持范围内，比如Artix-7、Spartan-7系列都是支持的。

另一个高频问题是Xilinx下载器驱动。使用Platform Cable USB时，Windows经常提示“无法加载这个硬件的设备驱动”，这是因为Vivado自带的驱动没有正确安装。处理方法是进入Vivado安装目录下的数据文件夹，找到cable_drivers里的驱动安装脚本，手动以管理员身份运行，然后再连接下载器。这个问题不解决，板级验证根本没法开始。

还有一个我早期经常遇到的情况：综合实现都成功，但生成比特流时报错，提示端口连接错误或者时钟约束缺失。这类问题通常到Implementation的日志里查，多数的根源是XDC约束文件里没有定义时钟，或定义错误。所以一定要在综合之前就把时钟约束写好，哪怕只是一个周期值，也不要拖到实现阶段再补。

4.3 时序不收敛与时序封装相关

单周期CPU的时钟频率虽然不高，但一旦数据通路没优化到位，时序不收敛依旧会发生。首次实现时我跑100MHz约束，时序报告一片飘红，关键路径集中在“指令存储器读出 -> 寄存器堆读出 -> ALU -> 数据存储器读出 -> 写回寄存器堆”这条链路上。后来的做法是把时钟降到50MHz，再逐步优化组合逻辑的深度。

优化思路有几个方向：一是检查是否有多余的级联逻辑，比如把两个比较器串在一起实现复杂分支；二是确认ALU里的移位操作是否被综合成LUT链而不是专用电路；三是尽量让数据存储器的读路径直接使用组合逻辑，而不要插入额外的缓冲级。当你把关键路径上的组合逻辑层数压到10层以内时，50MHz基本可以稳定收敛。

4.4 板级现象正常但结果诡异：存储初始化的坑

板级验证时最常见的诡异问题就是：仿真一切正常，下载到板上后状态完全不对，LED乱闪或者一直不亮。我遇到过的一个典型案例是，指令存储器里用$readmemh加载了hex文件，仿真时文件路径相对testbench所在目录有效，综合后BRAM初始化却找不到文件，导致板上执行的指令全是大片的未知值。

解决方法是把hex文件路径写成绝对路径，或者在Vivado的综合设置里把Verilog宏定义指向正确目录。另外，如果你用Vivado的mem文件初始化选项，也要确认文件格式和地址映射是否正确。这类问题看起来简单，但排查成本极高，因为它不会在仿真阶段出现，只有上板才暴露，所以我的习惯是无论用哪种初始化方式，都会在testbench里加一个仿真检查，读取指令存储器前几条数据并打印出来，确认文件加载成功。

还有一个容易忽略的点是复位逻辑。如果你的复位是低有效，但板子上的按键默认输出高电平，就会出现复位信号一直无效、电路直接跑飞的现象。这个我在3.3里踩过，这里再强调一次：上板前先确认板子的按键/开关默认电平，把复位极性在顶层模块里处理正确，不要想当然。

4.5 问题排查速查表

我遇到过的问题远不止这几类，但大多数最后都能归到控制真值表、立即数扩展、复位极性、文件初始化这四大类里。把这四类问题预先在代码里用断言和打印机制提前拦截，整个调试过程会顺畅很多。

从零写一个能在FPGA上跑起来的RISC-V CPU，真正的收获不是那几页Verilog代码，而是建立起从指令集手册到数字电路实现之间的完整映射。我在这个项目里最深的体会是：凡是看起来“玄学”的问题，最后几乎都藏在最不起眼的细节里——一个符号扩展的位宽、一个默认电平的极性、一个综合后找不到的文件路径。把这些坑一个个踩平之后，你再去看流水线CPU、看SoC设计，理解的速度会完全不同。如果你也想动手试试，就按文章里的流程来：先画数据通路图，再分模块写Verilog，仿真通过了再上板，遇到问题就按速查表逐项排查。希望这篇记录能帮你顺利完成自己的第一个FPGA CPU项目。