I read them separately and I think the text carefully used "counter" and "clock" carefully for the first sentence and second sentence carefully. Placing the synchronization requirement on the clock

It seems that this comes down entirely to semantics of what a "tick" means in this context. If 1 tick = 1 count = 10ns then it violates the spec, whereas if 1 tick = 10 count = 100ns then it complies.

Please read what I said. I said it *effectively* forces an implementation to have a 100 MHz clock. With the current wording in the draft specification, multihart implementations must do one of the

The ISA specification also says: The execution environment should provide a means of determining the period of the real-time counter (seconds/tick). If the period of the counter is in units of

This states synchronized to one tick of the real-time clock. It does not state it has to not differ by 1 count. regards ved

The requirement seems to come from the Zicntr extension described in the base (unprivileged) spec. I'll let somebody else say whether incrementing mtime by +10 counts as 1 tick or 10 ticks.

Hi, The RISC-V international has recently established a ratification policy[1] for non-ISA specification as well. All of the non-ISA specifications (e.g SBI, psABI, ACLINT) will have to go through the

Which section of the specication should I look at for that requirement? The only requirement I could find is from ACLINT spec: "On a RISC-V platform with multiple MTIMER devices residing on the same

I think the argument is that you technically violate the ISA spec if you have two cores and you increment mtime on the first core by +10 then a fraction of a nanosecond later update the second core's

I largely agree. While the clock "tick" is one ulp, an update can increment time by, for example, 10 ticks. (The same is true in ARM SBSA/BSA/etc.) Greg

The resolution requirement (whether =10ns or <=10ns) doesn't force a 100 or 100+ MHz clock. Only the >=10 MHz update rate forces a 10 MHz clock - which is a pretty modest requirement for OS-A-class

The current specification says that the MTIME values seen by two HARTs to be not apart by more than 1. It does say the MTIME must always increment in units of 1. I do not think the specification

No, it does not address my concern. As you said, that requirement was already there, and my concern applies to the requirement as is, although increasing the resolution will exacerbate the

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