[Bug Report] Architectural state updates for REM/REMUW instructions are misattributed to incorrect PCs in trace logs

[YzhDDDing]

Description

Hello, we found that, in Rocket Core, REM/REMUW are executed asynchronously by the divider unit. We have identified an issue in the trace logging mechanism where the side effects (register writeback) of these instructions are not correctly associated with their originating Program Counter (PC).

While these instructions retire in-order, the logger prints a placeholder (0xXXXXXXXXXXXXXXXX) at the time of retirement. However, when the asynchronous operation finally completes, the result is printed on the log line of whatever instruction happens to be retiring at that cycle. This creates a causality violation in the trace, making it appear as though an unrelated instruction modified the register.

Evidence

The following trace snippet demonstrates the misattribution during a REMUW operation:

1. The initiating REMUW instruction (PC: 0x800002ce):

3 0x000800002ce (0x02d9783b) x16 p16 0xXXXXXXXXXXXXXXXX

The result for x16 is unknown at this point because the divider is busy.

2. The incorrect attribution at a later PC (0x800002ec):

3 0x000800002ec (0x00143807) x16 0x0000000000000000

At PC 0x2ec (which is actually an fld instruction), the log incorrectly reports that x16 was updated to 0.

Impact:

• Trace Ambiguity: It is impossible to reconstruct a precise architectural state from the logs, especially when traps or exceptions occur between the issue and completion of a REM instruction.
• Verification Complexity: Verification teams must implement complex workarounds to "guess" which previous instruction a delayed writeback belongs to.

Minimal Assembly Code for Reproducing

li x18, 0x0
li x13, 0x17
li x16, 0x1dc52a8a
remuw x16, x18, x13
fcvt.d.l f14, x19, rtz
csrrs x19, fflags, x0
fcvt.s.lu f14, x18, rup
csrrs x13, fflags, x0
li x8, 2415919033
fld f16, 1(x8)

Attachment File

We have attached program.dump, program.elf, trace log, program.S in program.zip for reproducing.