CPU設計實戰-第四章實踐任務一簡單CPU參考設計調試

簡單CPU參考設計調試之DeBug—MyCPU部分

記一筆：
Run All 選項是在進入仿真頁面之後才有的選項，且其運行的過程在右下角提示。

1.信號傳遞Bug

分別添加五段的PC信號值不難發現，IF_PC => ID_PC未通 EXE_PC，即執行階段未接收到來自譯碼階段的PC值。檢查發現：
if把數據傳給了id，但是id_stage裏面沒有進行fs_to_ds_bus_r <= fs_to_ds_bus。去id模塊，發現ds_valid沒有被賦值。
修改前：

修改後：

always @(posedge clk) begin                     // Bug 1
    if(reset) begin
        ds_valid <= 1'b0;
    end
    else if(ds_allowin) begin
        ds_valid <= fs_to_ds_valid;
    end
    if (fs_to_ds_valid && ds_allowin) begin
        fs_to_ds_bus_r <= fs_to_ds_bus;
    end
end

2.典型"Z"信號Bug

這種情况往往是因為變量沒有賦值造成的。找到id_stage模塊發現：
load_op沒有相關賦值語句。在合適的比特置添加即可：
load_op錶示的是load的operate部分此部分應該與lw指令相連接。

仿真Bug小插曲

完成上面的邏輯Bug，重新進行仿真，出現如下小插曲：

此種提示大部分是由於敲代碼時有些變量敲錯的問題，所以不用驚慌。點擊ok就能查看到問題精確定比特的文件路徑：

以記事本打開便可以看到精確的錯誤定比特。
我的Bug定比特為：ID.stage 的第 128行和第三行

運用新工具-基於Trace比對的調試

3.Addiu指令實例傳參Bug

Run All之後出現第一個trace比對錯誤，其比對錯誤信息提示來自如下相關代碼：

可以看出其比對的相關信息依次是：PC值、寫回的目的寄存器、寫回的目的數據

分析：PC值為 0x bfc00000，其代錶的具體是哪一條指令呢？
在 lab3\CPU_CDE\soft\func_lab3\obj\test.s 中搜索 bfc00000 可以看到其對應的指令：

為 0x2408 ffff 其對應的指令 001001 00000 01000 1111111111111111
查錶可知，其對應的指令格式為addiu指令，且出錯比特置在寫的數據上，所以需要排查alu模塊與EXE_stage模塊，發現：
EXE_stage模塊參數實例化錯誤

更改為：

alu u_alu(                 
    .alu_op     (es_alu_op    ),
    .alu_src1   (es_alu_src1  ),
    .alu_src2   (es_alu_src2  ),
    .alu_result (es_alu_result)
    );

4.Bug

可以看到 PC 出錯了，肯定是要找分支指令或者跳轉指令，我們看看附近的幾條指令（test.s文件）。

/media/sf_func_lab3/start.S:19
bfc00004:	2408ffff 	li	t0,-1
/media/sf_func_lab3/start.S:20
bfc00008:	100000e0 	b	bfc0038c <locate>
/media/sf_func_lab3/start.S:21
bfc0000c:	00000000 	nop
/media/sf_func_lab3/start.S:24
bfc00010:	3c088000 	lui	t0,0x8000
/media/sf_func_lab3/start.S:25
bfc00014:	25290001 	addiu	t1,t1,1

很明顯可以看到 bfc00008 這條指令是分支指令，而 mycpu 沒進行跳轉。
首先先說明 nop 指令，這裏很善良的將延遲槽指令設置為 nop，和上面一樣，nop 指令也不需要特別實現。
控制流首先流入預取指階段，然後預取指階段更新 PC 並且訪問 RAM 獲得指令，PC 和 RAM 最終同時流入譯碼階段，在譯碼階段通過組合邏輯控制預取指階段完成跳轉。
我們 預期的執行順序

可以看到，在我們的預期中，分支指令的前置判斷是由譯碼階段完成的。

這條 B 指令由 r0 恒為 0 和 BEQ 指令得到。

我們可以發現在這條延遲槽指令時，本應有assign br_bus = {br_taken,br_target};,但是最下端兩個信號卻相同，所以即可找出問題。
問題出現文件路徑：\lab3\CPU_CDE\mycpu_verify\rtl\myCPU\mycpu.h
更改比特寬：

`define BR_BUS_WD       33

5.Bug

全局出錯

這個錯誤還是在alu模塊（前後比特寬不匹配賦值）：

更改：

assign sr_result   = sr64_result[31:0];

6.Bug

循環這種情况是由於 RTL 代碼中存在組合回路，不好找，若恰巧看到這行，它的錯誤還是很明顯的。
alu.v模塊的錯誤：

更改：

assign or_result  = alu_src1 | alu_src2;

PC-Bug小插曲

上面依次解决完之後，重新運行發現這個現象。。。

觀察發現：每次運行報錯的寫回級的PC與trace.txt不一致，但是其目的寄存器號和數據卻是正確的。什麼原因造成的呢？

7.最後一個Bug

錯誤文件路徑：mycpu_verify => rtl => myCPU => tools.v

仔細一點就會發現這裏的decoder_6_64模塊的譯碼根本不够64比特，即只有【62:0】，所以應該更改為：

generate for (i=0; i<64; i=i+1) begin:gen_for_dec_6_64     //Bug 7

成功上板視頻展示：

上板實驗時建議先把所有撥碼開關撥上，此時的計數速度最慢，便於觀察實驗現象。然後可以撥下一兩個，速度適中。
視頻鏈接：簡單CPU設計參考實踐任務

參考：

借鑒相關博客鏈接：CPU設計實戰 lab3