Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

Greg Favor

On Thu, Jul 15, 2021 at 5:03 PM Josh Scheid <jscheid@...> wrote:
> The MTIME register is a 64-bit read-write register
Is the device required to allow only 64-bit accesses to these registers?  Can a device allow 32-bit accesses?  Can a device only support 32-bit accesses?  If only one size or the other, how will SW know (e.g., in DT)?

Here's the most salient part of a long email thread last year with Andrew about this question (I've annotated the latter part with people's initials to help make clear who is saying what):

On ... Andrew Waterman <andrew@...> wrote:
On Mon, Apr 20, 2020 at 2:38 PM Andrew Waterman <andrew@...> wrote:
On Mon, Apr 20, 2020 at 11:32 AM David Kruckemyer <dkruckemyer@...> wrote:
On Fri, Apr 17, 2020 at 7:31 PM Andrew Waterman <andrew@...> wrote:
On Fri, Apr 17, 2020 at 7:00 PM Greg Favor <gfavor@...> wrote:
The mtime and mtimecmp registers are defined as 64-bit memory-mapped registers.  The priv spec says that - in RV32 - mtimecmp can be written as a pair of 32-bit registers.  Since this was made specific to RV32, is there an intended implication in the spec that in RV64 the system must support atomic 64-bit accesses to these registers?  Or is it allowable for only non-atomic 64-bit accesses to be supported (i.e. a 64-bit access by a CPU is performed as two 32-bit accesses out in the SoC where mtime/mtimecmp are located)?

The spec strongly implies by omission that 64-bit accesses are atomic for RV64, in that it gives an unusually detailed RV32-specific code example to cope with non-atomicity, but mentions nothing of the sort for RV64.  I will add the additional sentence that makes this implication explicit.

Put differently, must RV64 software not assume that a 64-bit load/store will atomically read/write the register.  (Note: ARMv8 explicitly says software must not make such an atomicity assumption for accesses to memory-mapped 64-bit registers.)

In general, this depends on the peripheral and the platform.  We aren't trying to preclude interfacing with legacy devices and buses, so of course someg 64-bit accesses to some devices will either become non-atomic or signal some sort of error.  But it's really quite useful to be able to assume that 64-bit accesses are atomic when interfacing with more modern peripherals that use 64-bit addresses, so we definitely do not want to preclude that, either.

DK: Asking this slightly differently (I think) to clarify....

With respect to mtime/mtimecmp, does an RV64 processor place constraints on the platform, or can the platform place constraints on the RV64 processor? If the former, the implication is that the platform must provide a way for the RV64 processors to access the registers atomically with a 64b load or store. If the latter, the implication is that the platform can require the RV64 processor to access the registers non-atomically with 32b loads or stores, a la RV32.

AW: The second half of my answer was addressing the more general matter. For mtime and mtimecmp specifically, the spec is now clear: 

DK: So the only constraint is that when a 64b naturally-aligned access is made to mtime/mtimecmp, the access must be completed atomically if the platform allows 64b naturally-aligned accesses to those registers? A platform is still allowed to signal an error on such accesses and to force an RV64 processor to access those registers with 32b loads and stores, right?

AW: I think your interpretation of that sentence is accurate. FWIW, the insufficiently described Linux platform does assume such accesses are legal (more precisely, the various SBI implementations make that assumption).

On ... David Kruckemyer <dkruckemyer@...> wrote:

It appears that OpenSBI supports 32b accesses to the CLINT on an RV64 system (the CLINT is where mtime[cmp] live in an SiFive FU540 SOC.):

So, in short, we (the Platform specs) need to now address this issue (as Andrew touched on).  The platform spec should say, in some form, that on both RV32 and RV64 platforms the MTIME register may be accessed using a pair of 32-bit accesses - and should be done in the manner shown by the example code in the MTIME register section of the Priv Arch spec.

Also, the ACLINT spec should specify that the various registers (including MTIME) are (i.e. must be) accessible on both RV32 and RV64 systems using 32-bit accesses (and may also be accessible using 64-bit accesses on RV64 platforms)

Lastly, it seems like all this can just be said in the ACLINT spec.  The platform specs will automatically then inherit this as part of using ACLINT (or parts of ACLINT).


Join { to automatically receive all group messages.