Re: MTIME update frequency

Greg Favor

On Fri, Nov 19, 2021 at 7:36 AM Darius Rad <darius@...> wrote:
The current requirement effectively forces implementations to have a 100
MHz clock.  If the resolution is changed to 1 ns, that becomes a 1 GHz
clock that implementations are forced to have. 

The resolution requirement (whether =10ns or <=10ns) doesn't force a 100 or 100+ MHz clock.  Only the >=10 MHz update rate forces a 10 MHz clock - which is a pretty modest requirement for OS-A-class systems.  (As a side-note, most any DDR interface or high-speed I/O interface (e.g. USB, SATA, PCIe/NVMe) will want significant clock frequencies supplied to them.)
Either way, this violates
the Platform Policy that says platforms should not mandate performance, but
certainly the higher clock rate is more of a burden.

Platforms shouldn't mandate specific software execution performance requirements, but a platform spec may - in the interest of ensuring functionality doesn't have horrible performance - choose to mandate certain qualitative things.  For example, a  more application domain-targeted platform may choose to disallow trapping and emulating of all misaligned data accesses.  (The "Embedded" platform, as a rather basic very "broad" platform, doesn't do this.)

In contrast, mandating that a system has certain hardware capabilities, like a RISC-V standard interrupt controller with at least X number of priorities, or time with some minimum resolution and update rate, is ensuring a form of functionality.  For example, an Automotive or Mobile platform may be unhappy if the update rate and resolution are only 10 ms / 100 Hz.


Join to automatically receive all group messages.