To have a meaningful H-extension support, both OS/A-base and OS/A-server platforms must comply with additional requirements for H-extension. Signed-off-by: Anup Patel <anup.patel@...> ---

Hi All, The next platform HSC meeting is scheduled on Mon July 26th at 8AM PST. Here are the details: Agenda and minutes kept on the github

There are few ISA level requirements/strong recommendations that platform should follow. Create an new subsection to contain all these requirements. Move the user-level requirements from user.doc to

Makes sense. I will update the patch. Thanks. -- Regards, Atish

The way we are viewing this from the PrivArch side is that the ISA spec lays out the legal options, and in this document, we constrain the optionality. Following that pattern, we should generally

ok. I will update it. Just a suggestion: Is it better to say what must be supported rather what is not and be more verbose? Something like this: Platforms is allowed to operate only in little-endian

Thanks for adding this. For systems that support little-endian, the ISA spec already requires that mstatus.MBE be reset to 0. Furthermore, the ISA spec does not permit hardwiring SBE or UBE to a

There are few ISA level requirements/strong recommendations that platform should follow. Create an new subsection to contain all these requirements. Move the user-level requirements from user.doc to

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

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

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

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

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

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

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

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

This patch adds requirements for mapping PCIe interrupts to AIA. Signed-off-by: Mayuresh Chitale <mchitale@...> --- riscv-platform-spec.adoc | 23 +++++++++++++++++++++-- 1 file

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

> 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

I was already planning to, so definitely yes. Greg