1. Tech-Unixplatformspec
  2. Messages

Re: Platform specification questions

Greg Favor
 

On Sun, Dec 12, 2021 at 7:55 PM Anup Patel <anup@...> wrote:
On Mon, Dec 13, 2021 at 5:45 AM Vedvyas Shanbhogue <ved@...> wrote:
> Please help with the following questions about the OS-A/server extension:
> Section 2.1.4.1 - Timer support:
> Should the ACLINT MTIMER support should be optional or moved into the M-platform section or made optional for the server extension?

The RISC-V Privileged v1.12 defines MTIME and MTIMECMP as platform
specific memory-mapped registers in "Section 3.2 Machine-Level
Memory-Mapped Registers". This means the RISC-V platform specification
needs to standardize memory layout and arrangement of the MTIME and
MTIMECMP memory-mapped registers which is what ACLINT MTIMER
specification does.
 
Since, both OS-A platforms with M-mode and M platforms need ACLINT
MTIMER so I suggest that OS-A platforms should say "If M-mode is
implemented then ACLINT MTIMER should be supported ...".

Here's a response from a different angle.  MTIME matters to the SEE because it provides the timebase that is then seen by all harts in their 'time' CSRs (via the RDTIME pseudoinstruction).  But if the initial OS-A platform specs are going to drop any M-mode standardization/etc., then it seems like the thing to do - from the SEE and OS-A platform perspectives - is to abstract MTIME as just the "system timebase that propagates to all harts and is seen by S/HS/U mode software in the form of the 'time' CSR" (just as the Unpriv spec does in its own words).

Whatever would be said about MTIME and tick period constraints (e.g. a minimum tick period) would instead be expressed wrt this abstracted timebase - which the Unpriv spec refers to as "wall-clock real time that has passed from an arbitrary start time in the past. .... The execution environment should provide a means of determining the period of a counter tick (seconds/tick).  ...".

This separates out from the current OS-A platform specs the ACLINT MTIMER device as a standardized Machine-level implementation of the MTIME and MTIMECMP registers defined in the Priv spec.

Now, for systems that implement Priv 1.12 and the Sstc extension, and actually use the Sstc extension, then this can be the end of the story.

But for today's systems and for future systems that don't implement Sstc (unless all OS-A 2022 platform specs were to mandate Sstc support and eliminate any possibility of existing systems complying with at least the Embedded (i.e. old "Base") OS-A platform spec), they also need the SBI API that provides Supervisor timer functionality to S/HS mode (with M-mode using MTIME and MTIMECMP to provide that functionality).  While this is also an SEE interface, talking about this does start to sneak up on talking about MTIME.  But then again one could still abstract MTIME as the system timebase, and MTIMECMP as a timebase compare value.

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