Vivado 2019.2 环境下 LoongArch 单周期CPU调试实录：从6个典型Bug到成功上板

Vivado 2019.2环境下LoongArch单周期CPU调试实战：六个关键Bug分析与解决方案

在数字逻辑与计算机体系结构的学习过程中，单周期CPU的设计与实现是一个极具挑战性又充满成就感的实践环节。特别是当我们将目光投向国产指令集架构LoongArch时，这种实践不仅能够加深对CPU工作原理的理解，还能让我们接触到前沿的国产技术生态。本文将以Vivado 2019.2为开发环境，详细剖析一个20条指令的LoongArch单周期CPU实现过程中遇到的六个典型Bug，分享从发现问题到成功上板的完整调试历程。

对于初学者而言，单周期CPU看似简单，但在实际调试过程中往往会遇到各种意料之外的问题。波形分析、信号追踪、功能验证这些看似基础的操作，却需要开发者具备敏锐的观察力和系统性的调试思维。本文不仅会展示最终的解决方案，更重要的是会还原当时的调试思路，帮助读者建立自己的问题排查方法论。

1. 实验环境搭建与工程初始化

在开始调试之前，确保开发环境正确配置是后续所有工作的基础。本次实验使用的是Vivado 2019.2版本，这是经过验证与实验材料最兼容的版本。虽然更高版本的Vivado也能工作，但需要特别注意IP核的升级问题。

实验环境主要包含以下几个关键部分：

• mycpu_env：实验包根目录，包含所有源代码和验证环境
• myCPU：CPU核心实现代码目录
• gettrace：生成参考trace的Vivado工程
• soc_verify：SoC级验证工程，用于最终上板验证

环境配置关键步骤：

1. 修改mycpu_env/func/include/test_config.h，选择exp6的配置
2. 打开gettrace工程(mycpu_env/gettrace/gettrace.xpr)，运行仿真生成golden_trace.txt
3. 在soc_verify/soc_dram/run_vivado/目录下创建或打开验证工程
4. 对工程中的inst_ram进行重新定制

注意：如果直接从实验包exp6.zip开始，可以跳过部分配置步骤，但务必检查环境完整性。

一个常见的环境问题是IP核版本不兼容。当使用高于Vivado 2019.2的版本时，会遇到如下错误提示：

[IP_Flow 19-5107] Failed to generate the IP 'inst_ram'. Please check '.../inst_ram/inst_ram.log' for details.

解决方法是通过Tcl控制台执行IP核升级命令：

upgrade_ip [get_ips inst_ram]

2. 调试方法论与波形分析技巧

在硬件设计中，仿真波形是我们观察CPU内部状态的最重要窗口。有效的波形分析能够快速定位问题所在，而盲目的代码修改往往事倍功半。下面分享几个实用的波形分析技巧：

信号分组与标记：

将相关信号分组显示可以大幅提高分析效率。例如，在Vivado Waveform窗口中：

• 将PC相关信号(pc, nextpc, seq_pc)分为一组
• 将指令译码信号(op_31_26, inst_add_w等)分为一组
• 将流水线控制信号(br_taken, valid等)分为一组

关键触发条件设置：

在复杂的仿真中，合理设置触发条件可以快速定位问题出现的时间点。例如：

when {/tb_top/u_mcu_top/pc == 32'h1c000100} { echo "Reached target PC" stop }

典型调试流程：

1. 观察PC值变化，确认指令取指是否正确
2. 检查指令译码信号，确认当前指令类型识别是否准确
3. 追踪数据通路，从寄存器读取到ALU操作再到写回
4. 对比golden_trace，定位首次出现差异的指令

在本次实验中，我们共发现了六个关键Bug，下面将逐一分析其现象、原因和解决方案。

3. 六个典型Bug的详细解析

3.1 调试端口连接错误

问题现象：在仿真过程中，发现debug_wb_pc等调试信号始终为0，无法正确反映CPU内部状态。

排查过程：

1. 检查波形，确认pc寄存器本身有正常变化，排除PC问题
2. 追踪debug_wb_pc信号路径，发现其直接连接pc寄存器
3. 对比模块端口定义，发现信号名称拼写错误

问题代码：

// 原错误代码 assign debug_wb_pc = pc; assign debug_wb_rf_we = {4{rf_we}}; assign debug_wb_rf_wnum = dest; assign debug_wb_rf_wdata = final_result;

问题根源：虽然代码看似正确，但实际上模块顶层端口定义中调试信号名称不一致，导致实际连接断开。

解决方案：统一调试信号命名，确保模块内外一致。修正后的连接：

assign debug_wb_pc = pc; assign debug_wb_rf_we = {4{rf_we}}; assign debug_wb_rf_wnum = dest; assign debug_wb_rf_wdata = final_result;

3.2 ALU操作数选择错误

问题现象：执行算术指令时结果不正确，特别是涉及立即数的指令如addi.w。

排查过程：

1. 追踪一条addi.w指令的执行过程
2. 检查ALU输入操作数alu_src1和alu_src2的值
3. 发现立即数没有正确传递到ALU

问题代码：

alu u_alu( .alu_op (alu_op), .alu_src1 (alu_src1), .alu_src2 (alu_src2), .alu_result (alu_result) );

问题根源：虽然ALU实例化正确，但alu_src2的选择逻辑存在问题，立即数没有正确参与运算。

解决方案：完善操作数选择逻辑，确保立即数能正确传递：

assign alu_src1 = src1_is_pc ? pc : rj_value; assign alu_src2 = src2_is_imm ? imm : rkd_value;

同时需要正确定义final_result信号：

wire [31:0] final_result; assign final_result = res_from_mem ? mem_result : alu_result;

3.3 寄存器堆写回使能错误

问题现象：bl指令执行后，链接寄存器r1没有正确更新。

**排查过程：

1. 观察bl指令执行时的gr_we信号
2. 发现bl指令时gr_we为0，导致写回被禁止
3. 检查gr_we生成逻辑

问题代码：

assign gr_we = ~inst_st_w & ~inst_beq & ~inst_bne & ~inst_b;

问题根源：bl指令需要将返回地址保存到r1寄存器，但当前逻辑将其排除在写回条件外。

解决方案：修改gr_we生成逻辑，保留bl指令的写回使能：

assign gr_we = ~inst_st_w & ~inst_beq & ~inst_bne & ~inst_b | inst_bl;

3.4 移位指令操作数错误

问题现象：slli.w等移位指令执行结果不符合预期。

排查过程：

1. 单步执行slli.w指令
2. 检查ALU内部的sll_result计算
3. 发现移位位数取自错误的位置

问题代码：

assign sll_result = alu_src1 << alu_src2;

问题根源：LoongArch的移位指令使用rk寄存器值作为移位位数，而当前实现直接使用了alu_src2。

解决方案：修正移位位数的选择逻辑：

assign sll_result = alu_src1 << alu_src2[4:0]; //rj << ui5

3.5 逻辑或运算实现错误

问题现象：or指令执行结果异常，与其他逻辑指令混淆。

排查过程：

1. 对比or、and、xor指令的执行波形
2. 发现or_result计算不正确
3. 检查ALU内部逻辑运算单元

问题代码：

assign or_result = alu_src1 | alu_src2;

问题根源：虽然代码看似正确，但实际在顶层alu_op信号连接时出现错位，导致or操作没有被正确激活。

解决方案：确保alu_op信号正确连接：

assign alu_op[ 6] = inst_or; // 确保op_or对应正确的位

3.6 移位指令符号扩展错误

问题现象：srai.w指令执行结果不正确，符号扩展失效。

排查过程：

1. 观察srai.w指令对负数的处理
2. 检查算术右移的实现逻辑
3. 发现符号扩展位选择错误

问题代码：

assign sr64_result = {{32{op_sra & alu_src1[31]}}, alu_src1[31:0]} >> alu_src2[4:0]; assign sr_result = sr64_result[31:0];

问题根源：算术右移需要在左端补符号位，但当前实现中符号位选择条件不完整。

解决方案：完善算术右移的符号扩展逻辑：

assign sr64_result = {{32{op_sra & alu_src1[31]}}, alu_src1[31:0]} >> alu_src2[4:0]; assign sr_result = sr64_result[31:0];

4. 上板验证与性能分析

在解决所有仿真问题后，最后一步是生成bitstream并上板验证。这一阶段可能会遇到新的问题，需要特别注意：

时序约束：单周期CPU的时钟频率通常不高，但仍需添加合理的时序约束：

create_clock -period 20 -name clk [get_ports clk]

上板调试技巧：

1. 使用ILA(Integrated Logic Analyzer)抓取实际运行信号
2. 逐步增加测试程序复杂度，从单条指令到完整程序
3. 利用串口输出调试信息，辅助定位问题

性能评估指标：

1. 最大工作频率
2. 关键路径分析
3. 资源利用率(LUT、FF、BRAM等)

在Xilinx Artix-7 FPGA上的实现结果示例：

经过上述调试过程，我们最终实现了一个功能完整的20条指令LoongArch单周期CPU。这个过程中积累的调试经验和方法论，对于后续学习更复杂的流水线CPU设计有着重要的参考价值。