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:

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.)

Please read what I said. I said it *effectively* forces an implementation
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.

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.)

Could you please refer to the portion of the Platform Policy that you
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,
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.

Greg