So we could drop these statements: " - Main memory must be protected with SECDED-ECC. - All cache structures must be protected. - single-bit errors must be detected and corrected. - multi-bit

The intent of the platform spec is hardware-software interoperability. I agree that dictating RAS hardware features is not within the scope of the platform spec. However, we do want standards for RAS

I wouldn't view platform mandates of this sort as teaching, but as establishing a baseline that system integrators can depend on - by guiding the hardware developers as to what that expected baseline

I agree. I think the RAS ISA would want to be about standardized error logging and reporting but not mandate what errors are detected/corrected and how they are corrected or contained. For example,

This was just trying to mandate a basic requirement and not go as far as requiring protection of all RAM-based structures - which some may view as overreach. Conversely I can understand that some

Totally agree that the term "cache structure" is ambigous and variety of caches may be built. How caches are built should also be transparent to the ISA, software, and the platform in general. Like

This seems like a toothless and qualitative mandate since no FIT requirements are specified. It can be a suggestion, although it's just a qualitative suggestion. It's essentially just saying "don't

Will be glad to. Yes, that sounds good. regards ved

Thanks Ved. Minor nits below. Would you be OK to send out a patch to the mailing list for these 3 changes and then subsequently a PR to the platform git on github? Let me know if you need any help

We should have a table with dependencies for SBI extensions. E.g. SBI Time only required if sstc is not present SBI IPI/RFENCE is only required if IMSIC or SSWI is not present I will send a patch

Thanks. Yes. Could I suggest: "Cache structures must be protected to address the Failure-in-time (FIT) requirements. The protection mechanisms may included single-bit/multi-bit error detection and/or

Agree. The intent here was to mandate a minimal set of memory protection features for server class platforms. It is not a violation of the platform spec to have something better. As per the

Yes, as per our agreement during the Platform HSC meeting several weeks back, the plan is to make the OS-A Embedded and OS-A Server as individual platforms without any relationship to each

The current text/organization is going to change (as discussed in previous meetings). The Server platform will be a separate platform independent of the Base platform because some of the requirements

Hi Anup Yes, that was my conclusion that "software interrupt" here was used to mean an IPI. I think clearing this up would be helpful. Yes, however the Server is additived to the base as written.

I was thinking along the lines of how Greg was thinking here. Agree. Agree. regards ved

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

Hi Ved, Please see comments inline below ... Regards, Anup The RISC-V Privileged v1.12 defines MTIME and MTIMECMP as platform specific memory-mapped registers in "Section 3.2

Greetings All! 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

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