> stimecmp is intentionally defined to compare against the time CSR
But time is just a pseudo-alias for the memory-mapped mtime register, right? Per the privileged ISA spec section 3.1.11 and 3.1.12:
The time CSR is a read-only shadow of the memory-mapped mtime register.
. . .
Implementations can convert reads of the time and timeh CSRs into loads to the memorymapped
mtime register, or emulate this functionality in M-mode software.
. . .
Because the time counter can be shared between multiple cores, it cannot be inhibited with
the mcountinhibit mechanism.
So, still we have the problem that the stimecmp CSR (which is presumably physically located in the CPU/hart) is being compared against a timer register that is physically located in a separate timer block that is likely to be physically distant from the CPU/hart and in a different clock and power domain.
This problem is described in a fair amount of detail in Section 3.2.1:
The timer facility is defined to use wall-clock time rather than a cycle counter to support modern
processors that run with a highly variable clock frequency to save energy through dynamic voltage
and frequency scaling.
Accurate real-time clocks (RTCs) are relatively expensive to provide (requiring a crystal
or MEMS oscillator) and have to run even when the rest of system is powered down, and so
there is usually only one in a system located in a different frequency/voltage domain from the
processors. Hence, the RTC must be shared by all the harts in a system and accesses to the RTC
will potentially incur the penalty of a voltage-level-shifter and clock-domain crossing. It is thus
more natural to expose mtime as a memory-mapped register than as a CSR.
Lower privilege levels do not have their own timecmp registers. Instead, machine-mode
software can implement any number of virtual timers on a hart by multiplexing the next timer
interrupt into the mtimecmp register.
Simple fixed-frequency systems can use a single clock for both cycle counting and wall-clock
It seems that a much more modular design would implement stimecmp registers as memory-mapped registers in the ACLINT block analogously to how the mtimecmp registers are defined and implemented.
> Also note that vstimecmp wants to compare to time as adjusted by the htimedelta CSR - which only exists within each hart.
Yes, this is a bit inconvenient. Trap & Emulate might be a sensible implementation for vstimecmp anyway.
Thanks again for your input on this question.