Notion of a Global Clock

[wallento]

We need a flexible way to have a global clock to send timestamps with the trace events.

Proposal: (Re-)Use a global time stamp provider as in OpTiMSoC, but allow to register slice it for better distribution on the chip. Each module then gets a parameter TIMESTAMP_DELAY, that can be read as a configuration register by the software and timestamps are accordingly adjusted.

[wsong83]

How accurate is this clock or time stamp?
There is a time CSR defined as the wall clock which is shared by all cores.
It works like a RTC.
However, the update of this time CSR is not frequent.
What I understand RISC-V suggests automatic update in every 100ns to even 1us.
Then it is also possible to deliberately read (with delay overhead) the remote RTC and update local time CSR when reading this CSR (using the CSR read instruction).
The local timecmp interrupt is compared against local time rather than the remote RTC value.
Is this the same clock you want?

[imphil]

For debug, we don't want wall-clock time, so the "timestamp" in all tracing applications is just a counter. Its main purpose is to order trace events and to correlate them across distributed units (cores). The quality (i.e. frequency) of the timestamp then determines how good you can do this correlation.

Regarding Stefans question, I'm not sure if it makes more sense to just use a global clock and do the counting in the modules itself. Then you only need to ensure a synchronous reset and don't need to distribute a multi-bit "timestamp bus" across the chip.

[imphil]

But let me double-check how others (coresight) solves that.

[wallento]

That's probably a tradeoff.

Maybe we step back to the original problem:

• We need to correlate trace events to each other.
• Each timestamp of an event does not necessarily have to be the "global timestamp", instead it is only r
  required to be able to reconstruct the "global timestamp" from all trace events

The second one implies that there is the possibility to wrap around the counter(s) responsible for the global timestamp and/or don't include full timestamps but deltas or similar in the trace event.

Philipp is right, we have at least two options:

• Have a global timestamp counter that is distributed over the chip and may be registered during distribution if necessary. The question is how many registers are necessary
  • Alternatively it is possible to count time locally. Then you have the count register which trades off with the global distribution registers, but also need at least an adder and mux in each module

Regarding the CPU wall clok you mention, @wsong83: I think it may make sense to trace this one also from time to time, maybe via the System Control Module

[asb]

Stefan/Philipp, could you perhaps elaborate on the requirements here a little. Is the ultimate desire that events coming from all processors can be accurately globally ordered?

Just to think out loud a little (and relate it to what I do know about): Each core obviously has a cycle counter - this could of course change based on frequency changes, though I know a monotonically increasing counter with fixed frequency has been suggested for RISC-V before. But cores might come out of reset in different cycles meaning the counters would need adjusting for use as a global order. Does the frequency of the clock need to match the frequency of the CPU core or can you rely on trace events from the same core being delivered in-order over the network to preserve ordering from a single core?

Are techniques like vector clocks from the software world ever applied here?