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.

regards
ved