On Tue, Dec 21, 2021 at 12:22 AM Allen Baum <allen.baum@...> wrote:

What you describe sounds very implementation dependent; I had always imagined that mtime would not be broadcast, but an mtime count enable bit would be, to keep the local copy synched.

That has its own issues of course (synching at reset, whenever mtime is written, and whenever stoptime is released) - though they're all the same mechanism, and can reuse whatever is used for reading mtime.

And also re-sync'ing when coming out of deeper power management sleep states.

The mechanism for software reading mtime is memory-mapped register reads; ditto for trap-and-emulate of hardware reads of the time CSR; and "hardware broadcast" of mtime to time otherwise.  Obviously only the latter time CSR implementation has to deal with resync issues.  While some systems may be able to avoid having any and all reasons for needing occasional time resync, many systems for one or more reasons will need occasional time resync.

I've seen many people (including ARM time distribution IP) do a hybrid between just sending an "increment" pulse and broadcasting a full 64-bit value - that supports periodic full resync while using just a small number of wires to also communicate the increments.  (One can potentially squeeze this down to two wires, although designs I've seen don't go that far.)

Greg