opensocdebug / osd-doc

Open Soc Debug Documentation, including the specification
http://www.opensocdebug.org
Other
1 stars 3 forks source link

Notion of a Global Clock #1

Open wallento opened 8 years ago

wallento commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

wallento commented 8 years ago

That's probably a tradeoff.

Maybe we step back to the original problem:

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:

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 commented 8 years ago

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?