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.