[Bug] RAW Hazard: Forwarding logic failure between `lui` and `addi` sequence

[YzhDDDing]

Bug Description

I am performing differential testing using Spike as the golden model and have identified a data hazard issue in Kronos.

When an addi instruction immediately follows an lui instruction targeting the same register (a typical expansion of the li pseudo-instruction), Kronos fails to forward the result of lui to addi. Instead, addi consumes the stale value (old value) of the register from the instruction prior to lui.

Reproduction Case

# 1. Setup initial state (Resulting in x17 = 0x88a9ac76)
li x17, -3439103821988909962
# 2. The Failing Sequence (Target: x17 = 0xa061d7de)
li x17, 830734071731705822

Disassembly / Execution Trace: The second li instruction expands into lui + addi at runtime:

# Setup (Old Value)
0x24: addi x17, x17, -906     # x17 <= 0x88a9ac76

# The Buggy Sequence
0x28: lui  x17, 0xa061d       # Expected x17 <= 0xa061d000
0x2c: addi x17, x17, 2014     # Expected x17 <= 0xa061d000 + 2014

Observed Behavior (Kronos)

In the execution log, the addi at 0x2c calculates the result using the Old Value (0x88a9ac76) from PC 0x24, ignoring the update from 0x28.

[REG] pc=0x24 x17 <= 0x88a9ac76  <-- Old Value set here
[REG] pc=0x28 x17 <= 0xa061d000  <-- 'lui' executes
[REG] pc=0x2c x17 <= 0x88a9b454  <-- WRONG: Uses Old Value (0x88a9ac76 + 2014)

Expected Behavior (Spike)

Spike correctly forwards the result from lui to addi:

pc=0x28: x17 <= 0xa061d000
pc=0x2c: x17 <= 0xa061d7de     <-- CORRECT: Uses New Value (0xa061d000 + 2014)

Root Cause Analysis

The incorrect result 0x88a9b454 mathematically confirms a Read-After-Write (RAW) Hazard.

• Old Value (x17 at 0x24): 0x88a9ac76
• Immediate (addi at 0x2c): 0x000007de (2014)
• Kronos Result: 0x88a9b454
• $$\text{0x88a9ac76} + \text{0x7DE} = \textbf{0x88a9b454}$$

The pipeline failed to forward the result of lui (PC 0x28) from the EX/MEM stage to the addi (PC 0x2c) in the EX stage. The addi instruction read the stale value from the Register File.

[GabPGomes]

Hi @YzhDDDing! Are you working on RTL verification as well? I'd like to know more!

I've run into the same problem. I ran this code:
000001a4 <inst_2>:
1a4: ff000ab7 lui s5,0xff000
1a8: fffa8a93 addi s5,s5,-1 # feffffff <immx+0x442f252f>
1ac: ff000ab7 lui s5,0xff000
1b0: fffa8a93 addi s5,s5,-1 # feffffff <immx+0x442f252f>
1b4: 015a8ab3 add s5,s5,s5
1b8: 0151a423 sw s5,8(gp)

And the stale value was being used.

[YzhDDDing]

Hi @YzhDDDing! Are you working on RTL verification as well? I'd like to know more!

I've run into the same problem. I ran this code: 000001a4 <inst_2>: 1a4: ff000ab7 lui s5,0xff000 1a8: fffa8a93 addi s5,s5,-1 # feffffff <immx+0x442f252f> 1ac: ff000ab7 lui s5,0xff000 1b0: fffa8a93 addi s5,s5,-1 # feffffff <immx+0x442f252f> 1b4: 015a8ab3 add s5,s5,s5 1b8: 0151a423 sw s5,8(gp)

And the stale value was being used.

Hi @GabPGomes! I do some fuzzing works on finding RTL bugs.