1. Tech-Unixplatformspec
  2. Topics

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

Josh Scheid
 

> 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)?

-Josh
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).

Greg
Josh Scheid
 

On Thu, Jul 15, 2021 at 7:01 PM Greg Favor <gfavor@...> wrote:

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).


The optional 64-bit access option from HW would need to be communicated in discovery/DT.

-Josh
Anup Patel
 

Both MTIME and MTIMECMP are 64-bit wide registers from device perspective (i.e. from ACLINT specification perspective). The ACLINT specification does not mandate 32-bit or 64-bit accesses for RISC-V HARTs. This means by default software will assume 64-bit accesses on RV64 and 32-bit accesses on RV32. We can certainly have an optional boolean DT property “mtimer,64bit-access-not-supported” which will force software to use 32-bit accesses on RV64 system.

 

Regards,

Anup

 

From: Josh Scheid <jscheid@...>
Date: Saturday, 17 July 2021 at 12:02 AM
To: Greg Favor <gfavor@...>
Cc: Anup Patel <Anup.Patel@...>, "tech-aia@..." <tech-aia@...>, "tech-unixplatformspec@..." <tech-unixplatformspec@...>, Atish Patra <Atish.Patra@...>, Alistair Francis <Alistair.Francis@...>, Andrew Waterman <andrew@...>, John Hauser <jh.riscv@...>
Subject: Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

 

On Thu, Jul 15, 2021 at 7:01 PM Greg Favor <gfavor@...> wrote:

 

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).

 

 

The optional 64-bit access option from HW would need to be communicated in discovery/DT.

 

-Josh
Greg Favor
 

On Fri, Jul 16, 2021 at 8:43 PM Anup Patel <Anup.Patel@...> wrote:

Both MTIME and MTIMECMP are 64-bit wide registers from device perspective (i.e. from ACLINT specification perspective). The ACLINT specification does not mandate 32-bit or 64-bit accesses for RISC-V HARTs. This means by default software will assume 64-bit accesses on RV64 and 32-bit accesses on RV32. We can certainly have an optional boolean DT property “mtimer,64bit-access-not-supported” which will force software to use 32-bit accesses on RV64 system.


While these registers are architecturally 64-bit registers, in many systems they will be accessed over a simple 32-bit bus that doesn't support 64-bit accesses.  This will probably be true in many systems (for example some (or maybe most?) SiFive SoCs such as the FU540 SoC).  Who wants to spend the hardware on a 2x wide bus for negligible benefit.  Plus some common bus standards won't support both 32-bit and 64-bit accesses, which complicates mapping and accessing 32-bit registers over a bus that only supports 64-bit accesses.  (Use of a 32-bit bus will tend to be true in both embedded and even high-end systems.  In the latter case the main coherent bus may be quite wide and capable of multi-width accesses, but no one wants to impose the complexity of interfacing to that bus onto all the SoC devices that have memory-mapped registers and want to have the simplest possible bus standard to interface to.)

The point of what was suggested as a result of the email discussions with Andrew a year ago, is that support for the common case should be required (e.g. 32-bit accesses) and then have a DT property that says 64-bit accesses may also be used by software.

Greg
andrew@...
 



On Fri, Jul 16, 2021 at 9:12 PM Greg Favor <gfavor@...> wrote:
On Fri, Jul 16, 2021 at 8:43 PM Anup Patel <Anup.Patel@...> wrote:
















Both MTIME and MTIMECMP are 64-bit wide registers from device perspective (i.e. from ACLINT specification perspective). The ACLINT specification does not mandate 32-bit or 64-bit accesses for RISC-V

HARTs. This means by default software will assume 64-bit accesses on RV64 and 32-bit accesses on RV32. We can certainly have an optional boolean DT property “mtimer,64bit-access-not-supported” which will force software to use 32-bit accesses on RV64 system.


While these registers are architecturally 64-bit registers, in many systems they will be accessed over a simple 32-bit bus that doesn't support 64-bit accesses.  This will probably be true in many systems (for example some (or maybe most?) SiFive SoCs such as the FU540 SoC).

All RV64 SiFive SoCs support 64-bit accesses to these registers.

The ISA spec implies, but does not explicitly state, that this is required: it gives code examples for accessing these registers in RV32. The spec would’ve mentioned RV64 systems that don’t support 64b accesses if it meant to admit that possibility.

  Who wants to spend the hardware on a 2x wide bus for negligible benefit.

While I agree, I view this as an almost orthogonal concern: bus width doesn’t set a limit on access width.

  Plus some common bus standards won't support both 32-bit and 64-bit accesses, which complicates mapping and accessing 32-bit registers over a bus that only supports 64-bit accesses.  (Use of a 32-bit bus will tend to be true in both embedded and even high-end systems.  In the latter case the main coherent bus may be quite wide and capable of multi-width accesses, but no one wants to impose the complexity of interfacing to that bus onto all the SoC devices that have memory-mapped registers and want to have the simplest possible bus standard to interface to.)

The point of what was suggested as a result of the email discussions with Andrew a year ago, is that support for the common case should be required (e.g. 32-bit accesses) and then have a DT property that says 64-bit accesses may also be used by software.

I have to admit I don’t recall that thread. Can you forward along a pointer?


Greg
Greg Favor
 

On Fri, Jul 16, 2021 at 9:31 PM Andrew Waterman <andrew@...> wrote:
  Who wants to spend the hardware on a 2x wide bus for negligible benefit.

While I agree, I view this as an almost orthogonal concern: bus width doesn’t set a limit on access width.

Common AMBA utility bus standards like the AXI-Lite buses don't support burst accesses - and hence the bus width does set the access width.  These bus standards are intended to be simple and sufficient for accessing memory-mapped registers.
 

The point of what was suggested as a result of the email discussions with Andrew a year ago, is that support for the common case should be required (e.g. 32-bit accesses) and then have a DT property that says 64-bit accesses may also be used by software.

I have to admit I don’t recall that thread. Can you forward along a pointer?

It was provided earlier in this email thread - which I'll forward to you in a minute.

Greg
 
Greg Favor
 

On Fri, Jul 16, 2021 at 10:10 PM Greg Favor <gfavor@...> wrote:
Common AMBA utility bus standards like the AXI-Lite buses don't support burst accesses - and hence the bus width does set the access width.  These bus standards are intended to be simple and sufficient for accessing memory-mapped registers.

Add to the list the popular APB bus standard used by many IPs for access to their memory-mapped registers.  It only supports up to 32-bit accesses.

Greg
Greg Favor
 

On Fri, Jul 16, 2021 at 10:19 PM Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...> wrote:
On Fri, Jul 16, 2021 at 10:10 PM Greg Favor <gfavor@...> wrote:
Common AMBA utility bus standards like the AXI-Lite buses don't support burst accesses - and hence the bus width does set the access width.  These bus standards are intended to be simple and sufficient for accessing memory-mapped registers.

Add to the list the popular APB bus standard used by many IPs for access to their memory-mapped registers.  It only supports up to 32-bit accesses.

In essence, is RV64 going to effectively outlaw ready use of common 32-bit "utility" AMBA bus standards in RV64 systems (especially since there will be a growing number of 64-bit memory-mapped registers defined by extensions this year and going forward)?

Greg


 
Greg Favor
 

On Fri, Jul 16, 2021 at 10:32 PM Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...> wrote:
In essence, is RV64 going to effectively outlaw ready use of common 32-bit "utility" AMBA bus standards in RV64 systems (especially since there will be a growing number of 64-bit memory-mapped registers defined by extensions this year and going forward)?

Lastly, before I shut up, ...

A key point in all this is that memory-mapped registers like MTIME/MTIMECMP will be very uncommon.  Most registers, even if logically defined as 64 bits wide, can be readily accessed by software using one or a pair of 32-bit accesses.

Especially since those 64-bit registers can only be accessed using 32-bit accesses in RV32 systems, arch definitions of such registers will be motivated to avoid causing complications for RV32 systems where at all possible.

Greg

 

1 - 10 of 10