Re: MTIME update frequency

Jonathan Behrens <behrensj@...>

On Fri, Nov 19, 2021 at 3:02 PM Ved Shanbhogue <ved@...> wrote:
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 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.

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.

Join to automatically receive all group messages.