Re: MTIME update frequency
On Fri, Nov 19, 2021 at 09:20:58AM -0800, Greg Favor wrote:
On Fri, Nov 19, 2021 at 7:36 AM Darius Rad <darius@...> wrote:Please read what I said. I said it *effectively* forces an implementationThe current requirement effectively forces implementations to have a 100
to have a 100 MHz clock.
With the current wording in the draft specification, multihart
implementations must do one of the following:
1. Provide a 100 MHz (or greater) clock and update the time register one
tick at a time, within one tick per the ISA specification.
2. With a clock between 10 MHz and 100 MHz, update the time register more
than one tick at a time, and provide extremely strict synchronization
between all harts to ensure that all harts see exactly the same value
at all times.
3. Ignore the specification, either by:
a. Not guaranteeing that all harts see time within one tick (violating
the ISA specification), or
b. Using a different timebase for the time register (violating the
current draft platform specification).
It is my opinion that (2) is an unreasonably burdensome, and that
implementations will be forced to choose (1) if they would like to adhere
to the specification. However, I think (3) will happen in practice.
Could you please refer to the portion of the Platform Policy that youEither way, this violatesPlatforms shouldn't mandate specific software execution performance
relied on for that interpretation? The Policy says "a Platform shall avoid
performance requirements or whether mechanisms have to be implemented in
hardware (i.e. if they can be emulated through trap-and-emulate).", which
seems to directly contradict what you are saying.
In contrast, mandating that a system has certain hardware capabilities,