On Fri, Nov 19, 2021 at 03:46:19PM -0500, Darius Rad wrote:
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:The ISA specification also says:
On Fri, Nov 19, 2021 at 3:02 PM Ved Shanbhogue <ved@...> wrote:This states synchronized to one tick of the real-time clock. It does not
On Fri, Nov 19, 2021 at 12:42:13PM -0500, Jonathan Behrens wrote:The requirement seems to come from the Zicntr extension described in the
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
be not apart by more than 1. It does say the MTIME must always
units of 1. I do not think the specification mandates incrementing by
on each clock tick. Presently it says the tick - the update frequency
be 100 MHz or 10 MHz or somewhere in between. If the update frequency
MHz then the MTIME increment per clock must be 10. If the update
is 100 Mhz then MTIME increment per clock is 1. So is your concern is
I think the argument is that you technically violate the ISA spec if you
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
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
by 10, but the ISA requires mtime to differ by at most 1 at any givenWhich section of the specication should I look at for that requirement?
instant in time.
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.
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.
state it has to not differ by 1 count.
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.
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 and not the counter - which matches the ACLINT specification as well.
Hope authors of the specification should clarify if that was the intent.