Different CSR readback behavior observed when accessing `mip`

[GuMys-WanJS]

Description

While performing differential testing between Spike v1.1.1 and our RTL model,
we observed a discrepancy in the value of register x13 after executing the following instruction:

csrrwi x13, mip, 19

In Spike v1.1.1, the instruction produced:

x13 = 0x0000000000000080
mip = 0x0000000000000082

whereas the RTL model produced:

x13 = 0x0000000000000000
mip = 0x0000000000000002

This initially suggested that the RTL might be missing the MTIP bit update.
However, when we re-tested the same program using Spike v1.0.1,
we found that v1.0.1 produces exactly the same result as the RTL, namely x13 = 0 and mip = 0x02.

Trace in Spike v1.1.1:

core   0: 0x0000000080000434 (0x3449d6f3) csrrwi  a3, mip, 19
core   0: 3 0x0000000080000434 (0x3449d6f3) x13 0x0000000000000080 c777_mvip 0x0000000000000000 c836_mip 0x0000000000000082

Trace in Spike v1.0.1:

core   0: 0x0000000080000434 (0x3449d6f3) csrrwi  a3, mip, 19
3 0x0000000080000434 (0x3449d6f3) x13 0x0000000000000000 c836_mip 0x0000000000000002

This behavior difference between Spike 1.0.1 and 1.1.1 is confusing.
It seems that the CSR readback logic for mip was changed between versions.
We would like to confirm whether this interpretation aligns with the RISC-V privileged specification,
and whether the current behavior in Spike reflects the intended architectural semantics.

[aswaterman]

mip.MTIP is read-only via the CSR; it is only set whenever mtime >= mtimecmp. So, the CSR-write instruction is a red herring; this is really about the value of the CSR beforehand.

What's going on here is that mtime and mtimecmp are both reset to 0, and so mtime >= mtimecmp is true after reset.

So, there's no bug here, but I can't explain why the behavior is different from earlier versions.