Re: MTIME update frequency
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.