再看一次昨天的數據
這不對阿
OOO 怎麼沒有比較快

/workspace/rtl/build/rtl/rtl_dual_inorder_tests
6: [PASS] queued ALU work behind multiply [normal] rtl_cycles=63 systemc_cycles=63 retired=8
...
/workspace/rtl/build/rtl/rtl_dual_ooo_tests
7: [PASS] queued ALU work behind multiply [normal] rtl_cycles=63 systemc_cycles=63 retired=8

複習一下我們的 test case

addi x1,x0,6
addi x2,x0,7
mul  x3,x1,x2
add  x4,x3,x0
addi x5,x0,1
addi x6,x0,2
addi x7,x0,3
addi x8,x0,4

然後觀察 pipeline 走向來看看問題在哪

好的，抓到了
原來不是 execution 的問題
是卡在 retire

我們可以看到在下面 mul 執行的時候
alu 真的有在執行 addi 指令
比昨天看到的 alu 被占用的時間點早很多
只是在最後還是得要 in order retire
在這個情況下最後的執行時間跟 dual issue in order cpu 是一樣的
所以我們加了一組新的 test case
讓 in order 會因為 dependency 被 stall
跟 OoO 可以從執行時間上看出區別

addi x1,x0,6
addi x2,x0,7
mul  x3,x1,x2
add  x4,x3,x0
addi x5,x0,1
addi x6,x5,1
addi x7,x0,1
addi x8,x7,1

run log:

/workspace/rtl/build/rtl/rtl_single_inorder_tests
5: [PASS] queued ALU chain behind multiply [normal] rtl_cycles=71 systemc_cycles=71 retired=8
...
/workspace/rtl/build/rtl/rtl_dual_inorder_tests
6: [PASS] queued ALU chain behind multiply [normal] rtl_cycles=69 systemc_cycles=69 retired=8
...
/workspace/rtl/build/rtl/rtl_dual_ooo_tests
7: [PASS] queued ALU chain behind multiply [normal] rtl_cycles=63 systemc_cycles=63 retired=8

git link with tag: https://github.com/hsufit/TINY5_OOO/tree/ithome2026_D18