Clarify constraints on [m]time resolution and synchronization

[aswaterman]

Following are some notes from the ARC minutes, courtesy @gfavor:

• The current normative Unpriv text specifies strong constraints on 'time' values, e.g. the 'time' CSR increments by one with each tick of the real-time clock at a known discoverable frequency, and 'time' must be synchronized across harts to within one ulp. For example, for a 1 GHz 'time' tick frequency this would require a very tight 1ns synchronization between harts.
• Then there is a non-normative "as-if" note expressing that as long as software cannot discern a more than one ulp difference between two hart's time values, then the synchronization requirement can be considered as satisfied.
• The question is then whether an implementation can, for example, have a 1 GHz 'time' counter (i.e. with a 1ns one ulp resolution) that is only updated at, say 100 MHz, with increments by 10 ulp's. Literally this violates the normative text. But is it ok IF software cannot successfully observe this violation - which ties back to the "as-if" text in the spec.
• The net conclusion by the ARC, to strike a pragmatic balance, is that this would be ok within the context of the current spec. With emphasis that software also must never observe 'time' across harts as ever going backwards.
• A platform spec can then, for example, specify the apparent 'time/mtime' tick frequency (e.g. 1 GHz) and also a minimum frequency (e.g. 100 MHz) at which software is guaranteed to observe updated time values. Software may read time more frequently, but it should only observe monotonic values and it should observe a new value at least once every 10 ns (corresponding to the 100 MHz in this example).
  • Note that this is different from specifying a minimum update frequency in that this focuses on a minimum rate at which new values can be observed by software.

[andreiw]

de72062 removed the text without any indication why.

[andreiw]

@gfavor

[gfavor]

@aswaterman Can you comment on the appropriateness of having eliminated the two paragraphs of text in (de72062) explaining/clarifying the intended meaning of the mtime synchronization requirement? Was this intentional (for what reason), or was this accidental (as the commit description suggests as a possibility)?

Arguably this text is unnecessary and all readers should be able to accurately interpet the remaining "synchronization requirement" text properly, and this is two paragraphs of clarification, but given the topic in question, it seems like completely removing this text is undesirable and leaves it tpo readers to "get it right".

[aswaterman]

The text was inadvertently removed when resolving merge conflicts that arose from #1215. I've created a PR to restore it, #1833. Luckily, it is non-normative text, so the blast radius is quite small.

Thanks for bringing this to our attention, @andreiw.