从单周期到流水线：一个FPGA模型机课程设计的完整踩坑与填坑实录

从单周期到流水线：一个FPGA模型机课程设计的完整踩坑与填坑实录

去年夏天，当我第一次在Basys3开发板上看到自己设计的单周期CPU成功执行指令时，那种成就感至今难忘。但随之而来的流水线改造过程，却让我经历了无数个debug到凌晨的夜晚。这篇文章将完整记录我从零开始构建FPGA模型机的全过程，特别是那些教科书上不会告诉你的实战细节。

1. 单周期模型机：看似简单却暗藏玄机

选择单周期作为起点是明智的，但即便这个"简单"版本也让我栽了不少跟头。第一个重大教训是关于时钟信号的——我最初天真地以为直接使用板载100MHz时钟就能工作，结果仿真波形乱成一团。

1.1 时钟分频的必要性

通过示波器测量发现，未经分频的时钟导致信号建立时间不足。最终采用的解决方案是：

module clk_div( input clk_100MHz, output reg clk_CPU ); reg [31:0] count; always @(posedge clk_100MHz) begin count <= count + 1; clk_CPU <= (count == 0); // 约1.5Hz end endmodule

关键发现：在Basys3上，当分频至1-5Hz时，才能通过LED直观观察执行过程。太高频反而难以调试。

1.2 存储器初始化的坑

另一个耗时两天的问题是指令存储器初始化失败。Vivado默认不会将.coe文件包含进bitstream，必须手动设置：

set_property -name {MEMORY_INITIALIZATION_RADIX} -value {16} -objects [get_files inst_rom.coe] set_property -name {MEMORY_INITIALIZATION_VECTOR} -value [read_hex_file inst_rom.coe] -objects [get_files inst_rom.coe]

2. 流水线改造：数据冒险的七十二变

当单周期稳定运行后，我自信满满地开始流水线改造，却没想到遇到了更复杂的挑战。

2.1 基本流水线架构

五级流水线的典型结构如下表所示：

2.2 数据冒险处理方案对比

经过多次尝试，我总结了三种处理数据冒险的方法：

1. 插入气泡（Stall）

   • 实现简单但性能损失大
   • 适合初期调试阶段

2. 前递（Forwarding）

   • 需要额外比较电路
   • 可解决80%的数据相关

3. 指令调度

   • 需要编译器配合
   • 课程设计中难以实现

最终我的解决方案是组合使用前递和气泡：

// 前递控制逻辑示例 always @(*) begin if (EX_MEM_RegWrite && (EX_MEM_rd != 0) && (EX_MEM_rd == ID_EX_rs)) ForwardA = 2'b10; else if (MEM_WB_RegWrite && (MEM_WB_rd != 0) && (MEM_WB_rd == ID_EX_rs)) ForwardA = 2'b01; else ForwardA = 2'b00; end

3. 中断与异常：最难啃的骨头

实现中断异常处理时，我遇到了课程设计中最具挑战性的问题——精确异常。

3.1 异常处理状态机

经过多次重构，最终的状态机设计如下：

+-----------+ | Normal | +-----+-----+ | Exception v +-----------+ | Exception | +-----+-----+ | EPC Write v +-----------+ | Handler | +-----+-----+ | ERET v +-----------+ | Restore | +-----------+

3.2 关键代码片段

CP0寄存器的实现要点：

module CP0( input clk, rst, input [4:0] addr, input [31:0] data_in, input we, output [31:0] data_out, // 异常接口 input exception, input [31:0] bad_addr, input [5:0] cause ); reg [31:0] regs[31:0]; always @(posedge clk or posedge rst) begin if (rst) begin // 初始化代码... end else if (exception) begin regs[14] <= current_pc; // EPC regs[13] <= {cause, 26'b0}; // Cause regs[8] <= bad_addr; // BadVAddr end else if (we) begin regs[addr] <= data_in; end end assign data_out = regs[addr]; endmodule

4. 调试技巧：节省80%时间的经验

在整个开发过程中，我总结出几个极其有效的调试方法：

4.1 波形调试黄金法则

• 信号分组：按功能模块分组显示
• 颜色编码：数据通路用蓝色，控制信号用红色
• 标记关键周期：使用Vivado的marker功能

4.2 嵌入式逻辑分析仪（ILA）配置

在Vivado中设置ILA时，这些参数最实用：

create_debug_core u_ila_0 ila set_property C_DATA_DEPTH 1024 [get_debug_cores u_ila_0] set_property C_TRIGIN_EN false [get_debug_cores u_ila_0] set_property ALL_PROBE_SAME_MU true [get_debug_cores u_ila_0]

4.3 常见错误速查表

5. 性能优化：从能跑到跑得好

当基本功能实现后，我开始关注性能提升，这里有几个实用技巧：

5.1 时序约束关键点

我的.xdc文件中最重要的约束：

create_clock -period 10 [get_ports clk] set_input_delay -clock clk 2 [all_inputs] set_output_delay -clock clk 2 [all_outputs] set_max_delay -from [get_pins IF_ID/inst_reg[*]] -to [get_pins ID_EX/rs_reg[*]] 5

5.2 资源利用率对比

优化前后的资源使用情况：

6. 开发板实战：当仿真通过但板子不工作

最令人抓狂的时刻莫过于仿真完美通过，但下载到板子后毫无反应。经过多次尝试，我整理出以下检查清单：

1. 时钟检查

   • 用示波器测量实际时钟频率
   • 确认复位信号极性正确

2. IO约束验证

   • 核对.xdc文件中引脚分配
   • 检查电压标准设置

3. 供电问题排查

   • 测量各电源轨电压
   • 检查电流消耗是否异常

记得有一次，问题竟然出在USB线接触不良导致供电不足。这种硬件问题在纯软件仿真中完全不会出现。

7. 测试方案设计：构建自动化测试环境

手动测试效率太低，我最终搭建了一个自动化测试框架：

import cocotb from cocotb.clock import Clock from cocotb.triggers import RisingEdge @cocotb.test() async def test_add(dut): clock = Clock(dut.clk, 10, units="ns") cocotb.start_soon(clock.start()) dut.rst.value = 1 await RisingEdge(dut.clk) dut.rst.value = 0 # 写入测试程序 load_program(dut, "test/add.bin") # 检查结果 await RisingEdge(dut.clk) assert dut.reg_file[3].value == 5

这套测试方案后来帮我发现了多个隐蔽的边界条件bug。