On Wed, Nov 17, 2021 at 09:15:55AM -0800, Greg Favor wrote:

On Wed, Nov 17, 2021 at 5:09 AM Ved Shanbhogue <ved@...> wrote:

So synchronizing time between hart, dies or multiple sockets is an
engineering problem. The architecture should not restrict the
implementation to achieve the 1ns resolution. Synchronizing such counters
even at much higher frequencies has been acheived in several
implementations.

I find Lamport's paper
http://lamport.azurewebsites.net/pubs/time-clocks.pdf is a good reference
on this topic of time, clocks and ordering of events in a distributed
system. The goal of such synchronization would be for the the system to
acheive the property that - if an event a occurs before event b then a
should happen at an earlier time than b. If that needs bounding to 1 tick
or bounding to the latency of a fastest hart-to-hart transfer should be an
engineering problem.

I agree that there are established time synchronization techniques,
although where they are used today, they don't achieve or try to achieve
1ns accuracy.

Taking a constrained example within a single die and if one avoids trying
to synchronize time across all harts in the die by simply distributing time
to all harts in a tightly balanced manner (so as to satisfy the
synchronization requirement), doing even that to less than 1ns of accuracy
can be challenging in the face of any async boundary crossings (especially
if one has more than one crossing from mtime out to all the hart's time),
in the face of dynamic power management (DVFS) of cores and non-core, and
in the face of other little engineering details. Although not impossible.

One technique some use in higher-end designs is to interpolate or up-sample
from a timebase to a higher resolution and update rate - for where ns and
sub-ns resolution is needed for certain purposes (without needing sub-1ns
accuracy across harts). This avoids needing to do tight synchronization or
distribution of the timebase itself to such high resolution and update rate.

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.

Besides harts, some systems would also want to ensure time synchronization between harts and accelerators and PCIe - e.g. support precision time measurement (PTM), time sensitive networking for automotive/industrial/financial apps, etc.

regards
ved