tech-unixplatformspec@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Topics Expanded Polls

Export Group Data

Between

and

Re: MTIME update frequency

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

By Ved Shanbhogue · #1537 ·

Re: [PATCH 1/6] Remove the machine mode requirements

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

By Darius Rad · #1536 ·

Re: [PATCH 6/6] Update the ISA requirement section

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

By Heinrich Schuchardt · #1535 ·

Re: [PATCH 5/6] Add more clarity about privilege mode optionality.

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

By Heinrich Schuchardt · #1534 ·

Re: [PATCH 4/6] Reduce the number of mandatory PMU events.

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

By Heinrich Schuchardt · #1533 ·

[PATCH 6/6] Update the ISA requirement section

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

By atishp@... · #1532 ·

[PATCH 5/6] Add more clarity about privilege mode optionality.

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

By atishp@... · #1531 ·

[PATCH 4/6] Reduce the number of mandatory PMU events.

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

By atishp@... · #1530 ·

[PATCH 3/6] Update PCIe section to reflect M-mode optionality

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

By atishp@... · #1529 ·

[PATCH 2/6] Specify M-mode protection content for platforms with M-mode

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

By atishp@... · #1528 ·

[PATCH 1/6] Remove the machine mode requirements

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

By atishp@... · #1527 ·

Re: MTIME update frequency

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

By Ved Shanbhogue · #1526 ·

Re: MTIME update frequency

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

By Darius Rad · #1525 ·

Re: MTIME update frequency

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

By Ved Shanbhogue · #1524 ·

Re: MTIME update frequency

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

By Darius Rad · #1523 ·

Re: MTIME update frequency

I am not disagreeing to that. regards ved

By Ved Shanbhogue · #1522 ·

Re: MTIME update frequency

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

By Greg Favor · #1521 ·

Re: MTIME update frequency

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

By Ved Shanbhogue · #1520 ·

Re: MTIME update frequency

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

By Greg Favor · #1519 ·

Re: MTIME update frequency

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

By Ved Shanbhogue · #1518 ·

321 - 340 of 1857

Home Hashtags Subgroups Terms