On Fri, Nov 19, 2021 at 12:42:13PM -0500, Jonathan Behrens wrote:
>On Fri, Nov 19, 2021 at 12:27 PM Greg Favor <gfavor@...> wrote:
>
>> 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 mandates incrementing by one
>>> on each clock tick. Presently it says the tick - the update frequency - can
>>> be 100 MHz or 10 MHz or somewhere in between. If the update frequency is 10
>>> MHz then the MTIME increment per clock must be 10. If the update frequency
>>> is 100 Mhz then MTIME increment per clock is 1. So is your concern is that
>>> an adder that adds 10 to MTIME per clock tick is hard?
>>
>>
>> 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.)
>>
>
>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 mtime by +10.
>During the tiny duration between the updates on the two cores mtime differs
>by 10, but the ISA requires mtime to differ by at most 1 at any given
>instant in time.
>
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 die, all must satisfy the RISC-V architectural requirement that all the MTIME registers with respect to each other, and all the per-HART time CSRs with respect to each other, are synchronized to within one MTIME tick (or MTIME update period)." And this requires synchronized to within one MTIME update
period - not the value of MTIME be not different by more than one.

The execution environment should provide a means of determining the period of the real-time counter (seconds/tick). The period must be constant. The real-time clocks of all harts in a single user application should be synchronized to within one tick of the real-time clock. The environment should provide a means to determine the accuracy of the clock.