Re: Fast-track "stimecmp / vstimecmp" extension proposal

Greg Favor

On Mon, Sep 13, 2021 at 5:07 PM Phil McCoy <pnm@...> wrote:
> 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.

The time CSR is an actual CSR.  It is a "shadow" in the sense that time values in mtime eventually appear in the time CSR.  You can imagine they are always equal, but the architecture allows for there to be a delay between when a value appears in mtime and when it appears in the time CSR.
. . .
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.

Yes, an implementation can trap accesses to the time CSR and emulate them, or an implementation can convert the CSR accesses to memory reads of the mtime register.  But the time CSR itself is architecturally a CSR within a hart.  Whether actually implemented within the hart, or trapped and emulated, or transparently "emulated" by hardware.
. . .
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.

stimecmp is compared against time, and vstimecmp is compared against (time+htimedelta).  These and time can all be physically implemented in the hart, or they can all be trapped and emulated (in conjunction with suitable hardware outside the hart), or all "emulated" by hardware.  All implementation approaches are accommodated.  While low-end designs may take one of the latter implementation approaches, it is expected that higher end designs will physically implement time within the hart (as is done in most all ARM and x86 designs).  Most of the past proposals from the RV community for Sstc-like functionality have all been for having CSRs and, in one case, also introducing an mtimecmp CSR.



Join to automatically receive all group messages.