Re: MTIME update frequency

Jonathan Behrens <behrensj@...>

Adding more configuration options increases complexity. Under the current draft, if software wants an interrupt 1ms in the future it can set mtimecmp to the value of mtime plus 100,000. If we make the resolution of mtime vary between systems, then we have to do a bunch more specification and implementation work to pipe that information around. Based on Greg's message it sounds like that may be happening, but I also see the appeal of just picking the extremely simple option that works well enough for everyone's case (even if it isn't some people's top pick)


On Tue, Nov 16, 2021 at 12:17 PM Vedvyas Shanbhogue via <> wrote:
So do we agree that the platform specification must not treat a
implementation that has MTIME update frequency higher than 100 MHz as

Removing this upper bound does not of course force any implementation
to implement anything higher than 100 MHz.

Please suggest how to request this update?


On Fri, Nov 12, 2021 at 9:58 PM Vedvyas Shanbhogue via
<> wrote:
> On Fri, Nov 12, 2021 at 05:41:02PM -0800, Greg Favor wrote:
> >On Fri, Nov 12, 2021 at 5:09 PM Heinrich Schuchardt <xypron.glpk@...>
> >wrote:
> >
> >> > "The ACLINT MTIME update frequency (i.e. hardware clock) must be between
> >> > 10 MHz and 100 MHz, and updates must be strictly monotonic."
> >>
> >> The resolution of the mtime register is defined as 10 ns. The 100 MHz
> >> value is irrelevant and should be deleted from the spec.
> >>
> >
> >The intent of the wording is that the resolution is 10ns (as implied by the
> >max update frequency of 100 MHz).  But I agree that the current wording
> >should change to just directly state a 10ns resolution.
> >
> But why mandate that it cannot be finer resolytion than 10ns. I can see a requirement to say minimum of 10ns but whats the rationalet to say must not be better than 10ns?
> regards
> ved

Join to automatically receive all group messages.