Thanks Greg. This would be helpful to not prevent an implementation to engineer a solution but does not force an implementation to do so. I think this makes sense. Totally agree. regards ved

Absolutely. I was only suggesting a 1ns resolution and not a 1ns update rate.

Literally, such a "loosely synchronized" implementation would not be compliant with RISC-V architecture and its tight synchronization requirement. As Darius noted (below), that is just one way to

Note that ARM SBSA did not mandate a 1 GHz update rate; it only mandated a 1ns resolution - and explicitly acknowledged that updates may be at a lower rate using counter scaling. Greg

I took the opportunity to raise this with Andrew and Krste (who authored the text in question) as to the intended and proper reading of the following arch spec text: Before summarizing their response,

Fixed. Thanks.

My bad. Fixed it.

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