Re: RISC-V ACLINT specification is now hosted on RISC-V GitHub


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?


Join { to automatically receive all group messages.