Re: MTIME update frequency

Ved Shanbhogue

On Wed, Nov 17, 2021 at 10:28:40AM -0800, Greg Favor wrote:
On Wed, Nov 17, 2021 at 9:49 AM Ved Shanbhogue <ved@...> wrote:

Agree. Standard protocols like IEEE 1588 may also be used to acheive fine
synchronization with a distributed time. Having distributed but
synchronized time may avoid needing to send a large time bus across the die
and have to deal with issues you highlight such as async crossings,
spread-spectrum, dvfs, etc.
Just to clarify what I was trying to say: Whether distributing a large
time bus or a "smarter" small time bus - which are functionally equivalent
(and many designs I'm aware of do the latter), distributing that across
CDC's introduces the obvious timing uncertainty. If the receive side is
running at 1 GHz or 2GHz, then right there appears 1ns to 0.5ns of time
uncertainty/inaccuracy in a hart's final time value. Two CDC's (e.g. in
larger scale many-core designs) doubles that.

Leaving aside any CDC's, also keep in mind that even if the distribution of
time to each hart is synchronous and "perfectly" balanced (i.e. the exact
same number of clock cycles from mtime to each end point), ensuring that
the clock skew between these potentially far apart end points is sub-1ns is
impractical (especially in leading edge processes with long and highly
variable wire delays). Even mesh-based clock distribution schemes won't
achieve that.
I am not disagreeing to that.


Join to automatically receive all group messages.