Re: MTIME update frequency

Greg Favor

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.


Join to automatically receive all group messages.