Did that address your concern? Should we update to supporting 1 ns resolution or not disallowing a 1 ns resolution?

Still doesn't provide standardization of functionality in U and VU modes. https://lists.riscv.org/g/tech-unixplatformspec/message/1479

Am 19. November 2021 01:09:34 MEZ schrieb atishp@...: It seems irrelevant if a library call is made or the syscall is invoked directly. A libc library may be used by some programs but will

Am 19. November 2021 01:09:33 MEZ schrieb atishp@...: Please, remove one 'only'. Best regards Heinrich

Am 19. November 2021 01:09:32 MEZ schrieb atishp@...: %s/Thue/The/ Best regards Heinrich

Some of the ISA requirement sections do not belong to a platform specification and can move to the profile specification. The fence.i recommendation belong to software section as it talks about a

The platform spec provides various choices for interrupt controller to be implemented in the platform. As M-mode is not a mandatory requirement any more and VS-mode is only required for platforms with

Last level cache and NUMA node cache events are not specific to per hart. Do not make them mandatory for per hart performance monitor events. Signed-off-by: Atish Patra <atishp@...> ---

Signed-off-by: Atish Patra <atishp@...> --- riscv-platform-spec.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/riscv-platform-spec.adoc

This version of the platform specification doesn't mandate M-mode requirements. However, it should specify M-mode access protection from lower privilege modes for platforms that do implement

As per the discussion in the mailing list, M-mode requirements should not be included in this version of the platform specification to allow platform vendors more flexibility in implementing

I agree. But that requirement is there already for a system that implements a 10 Mhz clock and has to suport 10ns resolution. If 10ns vs. 1ns is a really sticking point could we have two values

The specification says "synchronized to within one tick". If the time CSR is incremented one tick at a time, then, for every update, as long as one update propagates to all harts before the next

So an implementation that supports 100MHz clock would need to update the mtime by 10 on each tick to meet the 1ns granularity. In current spec a implementation that supports 10 MHz clock would need to

Considering the requirement that all time CSRs be synchronized to within 1 tick, setting a fixed resolution indirectly makes synchronization much more difficult for implementations that have a lower

I am not disagreeing to that. regards ved

Just to clarify what I was trying to say: Whether distributing a large time bus or a "smarter" small time bus - which are functionally equivalent (and many designs I'm aware of do the latter),

Agree. Standard protocols like IEEE 1588 may also be used to acheive fine synchronization with a distributed time. Having distributed but synchronized time may avoid needing to send a large time bus

I agree that there are established time synchronization techniques, although where they are used today, they don't achieve or try to achieve 1ns accuracy. Taking a constrained example within a single

So synchronizing time between hart, dies or multiple sockets is an engineering problem. The architecture should not restrict the implementation to achieve the 1ns resolution. Synchronizing such