Clarify that mtime -> time has propagation delay

[aswaterman]

No description provided.

[pdonahue-ventana]

accesses to mtime may be reordered with respect to accesses to time or timeh, unless otherwise ordered by e.g. a FENCE instruction.

So if I do:

• load from mtime
• fence
• csrr time

then can time see an earlier value than mtime? The answer would presumably be no based on the "unless" clause which forces them to be "ordered" (which presumably doesn't mean that things are required to be microarchitecturally ordered but are allowed to be architecturally reordered). Everything after the comma in that sentence seems like a problem in an implementation where mtime is distributed to the time CSR via a different channel than mtime load values are returned to the hart.

[kasanovic]

Yes, the implementation has to ensure that any post-FENCE access to the time CSR will see the same or later value than that returned by a pre-FENCE memory instruction. This does impose a constraint on the implementation. It is more likely that software will depend on fast CSR access than fast memory access to time values, so a simple implementation could choose to be conservative/slow on the memory read path.

[pdonahue-ventana]

The architecture says: "However, FENCE does not order observations of events made by an external device using any other signaling mechanism." I take this to mean that (before this PR) FENCE does not guarantee the order between:

• load from mtime vs. CSR read of time
• load from an interrupt controller vs. CSR read of mip or of IMSIC state that is affected by that interrupt controller state

This PR seems to add a new requirement only for the first case.

If there is going to be a new architectural requirement that these things are ordered (as your reply says) then I think that this needs broader discussion and buy-in. If it is meant to only require that the microarchitecture needs to do the load before doing the CSR read with no particular requirements on the values seen then I think that (1) the requirement is pointless and (2) it misleads the reader into thinking that there is an architectural ordering requirement.

Practically speaking, I wonder if software mixes reads of mtime and time anyway. Due to the sentence I quoted above, I have assumed that upon (rare) writes to mtime, software would subsequently poll time until the update is seen (rather than fencing). After that, all reads would just be from time. If that's true, there's no need to have this new requirement.

[aswaterman]

After discussing this again in the ARC meeting, we've revised our proposal to clarify that there's an mtime -> time propagation delay.

[pdonahue-ventana]

Perfect. Thanks.