From f44e4fa741bed0d3aacb994b564e3ad594db5df9 Mon Sep 17 00:00:00 2001 From: Andrew Waterman Date: Mon, 29 Jan 2024 23:02:41 -0800 Subject: Add clarifying non-normative comments about [m]time Text contributed by @gfavor --- src/counters.adoc | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'src/counters.adoc') diff --git a/src/counters.adoc b/src/counters.adoc index cf646c6..2011386 100644 --- a/src/counters.adoc +++ b/src/counters.adoc @@ -147,6 +147,22 @@ As with other architectural mandates, it suffices to appear "as if" harts are synchronized to within one tick of the real-time clock, i.e., software is unable to observe that there is a greater delta between the real-time clock values observed on two harts. + +If, for example, the real-time clock increments at a frequency of 1 GHz, then +all harts must appear to be synchronized to within 1 nsec. +But it is also acceptable for this example implementation to only update the +real-time clock at, say, a frequency of 100 MHz with increments of 10 ticks. +As long as software cannot observe this seeming violation of the above +synchronization requirement, and software always observes time across harts to +be monotonically nondecreasing, then this implementation is compliant. + +A platform spec may then, for example, specify an apparent real-time clock +tick frequency (e.g. 1 GHz) and also a minimum update frequency (e.g. 100 MHz) +at which updated time values are guaranteed to be observable by software. +Software may read time more frequently, but it should only observe +monotonically nondecreasing values and it should observe a new value at least +once every 10 ns (corresponding to the 100 MHz update frequency in this +example). ==== The RDINSTRET pseudoinstruction reads the low XLEN bits of the `instret` CSR, which counts the number of instructions retired by this -- cgit v1.1