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


Greg Favor
 

On Mon, Sep 13, 2021 at 12:49 PM Phil McCoy <pnm@...> wrote:
Was any consideration given to the possibility of defining stimecmp as a memory-mapped register (like mtimecmp) rather than a CSR?
Assuming that the timer will actually be implemented in a block outside of the CPU (e.g. the ACLINT), a memory-mapped register would be preferable for interfacing the CPU to the timer block.  Keep in mind that in most high-end (especially multi-processor) systems will have the timer in a separate clock domain from the CPU and CSRs (which seems to have been the key motivation for defining mtime/mtimecmp as memory-mapped registers rather than CSRs).

Paul's comment is correct.  The time, stimecmp, and vstimecmp registers are all CSRs within a hart; separate from the mtime register located typically somewhere that may not be nearby any or every hart.  Also keep in mind that the vstimecmp CSR will be context switched by a hypervisor.  And in some applications even the stimecmp CSR may be context switched some.  Whereas the memory-mapped mtimecmp would generally never be context switched.

If anything, during discussions about this extension, the question was raised in the other direction about also adding an mtimecmp CSR for consistency.  But that was a whole other discussion to be had - given that there is existing mtimecmp functionality and not a strong argument for changing that.
 
Also, just curious about the overall status of this extension.  It is mentioned in the RVA22 profile, which would suggest that the Sstc definition should be finalized soon if it isn't already.

Keep in mind that the Profile specs are very much still under development and won't be frozen til November.  While the Sstc extension is driving to get ratified by mid-November.

Greg

Join tech-privileged@lists.riscv.org to automatically receive all group messages.