On Fri, Nov 19, 2021 at 02:32:45PM -0600, Vedvyas Shanbhogue wrote:

On Fri, Nov 19, 2021 at 03:27:40PM -0500, Jonathan Behrens wrote:

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.

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

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 seconds/tick, then 1 count (1
LSB) is 1 tick.