So there is an assumption here that somehow time is broadcast and not the clock.

For an implementation that does clock broadcast this requirement requires having a shadow time that counts while software visible time is frozen. All that complexity may be totally justified but is not obvious why . Besides if the time does not stop for a shared implementation of mtime then this does not seem like is something fundamentally required for debug.

Regards

Ved

On Tue, Dec 21, 2021 at 4:45 AM Greg Favor <gfavor@...> wrote:

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