Updating changelog Signed-off-by: Paul Donahue pdonahue@... --- changelog.adoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/changelog.adoc b/changelog.adoc index 7ec1b1f..cc69971

Adding myself to list of contributors. Signed-off-by: Paul Donahue pdonahue@... --- contributors.adoc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

At least at the platform level, the requirement of a single reference clock for all timers in a "system" (thus preventing first-order drift) may be a desirable requirement. -Josh

If you're interested in reading about pure software approaches to clock synchronization, I recommend looking at https://www.usenix.org/conference/nsdi18/presentation/geng. They focus on synchronizing

More recent ARM SBSA requires a 1 GHz counter resolution, but does not place any requirement on the actual measurable 'time" resolution (i.e. a minimum update frequency). So one can have 1 ns

One other issue with the "mtime" synchronization by SW approach is that this effectively places an upper limit on the achievable timer unit resolution. It'd be some equation based on the ordered

Note that the "update latency" between a write to "mtime" and a read of the hart-local "time" is unspecified. -Josh

Architecturally the 'time' CSR reads the same concept of "time" as the 'mtime' register. Simplistically the RDTIME pseudoinstruction reads what is in the 'mtime' register. One implementation is that

Hi, Minor comments: Should there be a mention that the user level "time" csr (0xC01) which is used by the rdtime pseudo-instruction will enable a read-only peek into the mtime register? Would this

Hi Josh, I have created a GitHub PR addressing your comments. Please check if you are okay with this. https://github.com/riscv/riscv-aclint/pull/2 Regards, Anup From: tech-aia@...

Hi Josh, Indeed, I missed adding text regarding verifying delta and ensuring that it is within bounds. Thanks for pointing. I was thinking that aclint_mtime_sync() function should return the

Alistair Francis <Alistair.Francis@...> 於 2021年5月26日 週三 下午6:57寫道： Alistair, I can understand your concern just like I have to the server extension. The inflexible spec may lead

Thanks for writing this up, Anup. In https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc#24-synchronizing-multiple-mtimer-devices, the SW algorithm should include verifying the

Yep that's great for Linux systems. I haven't seen any embedded systems besides SiFive that use the CLINT though. For example SweRVolf uses a specific system

Hi Alistair,

You have removed the original example, but not the original description. If we aren't supporting the adjancent addresses the paragraph above this should be removed. I still prefer to allow either

Hi All, The RISC-V ACLINT specification is now hosted on RISC-V GitHub page: https://github.com/riscv/riscv-aclint https://github.com/riscv/riscv-aclint/blob/master/riscv-aclint.adoc Please review

Hi Alistar, Please check if you are ok with v5 patch. Thanks Abner Anup Patel <anup.patel@...> 於 2021年5月25日 週二 下午4:25寫道：

From: Abner Chang <renba.chang@...> Signed-off-by: Abner Chang <renba.chang@...> --- contributors.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/contributors.adoc

From: Abner Chang <renba.chang@...> Initial description of PLIC CLINT section of Linux-2022 platform. On v5 commit, - Remove CLINT from platform spec - Require ACLINT on Linux2020 platform