TKE_TOP_SHARED_TKETSC0_0 register access delay from SPE

[andrea.pascolini]

Hello,

I am getting an unexpected delay when accessing the shared 32-bit TSC 31.25 MHz clock timestamp from SPE.

This is my test code:

for (i = 0; i < 16; i++) {
    times[i] = tegra_tke_get_tsc32();
}

printf("average time acq [ns] %lu\n", (times[15] - times[0]) / 15 * 32);     

Last multiply operation converts counter ticks to nanoseconds (31.25MHz TSC clock, 32 ns)

From this, I get an average access delay ~700ns. Can it be considered normal for SPE?
My current application requires spin-based sub-microsecond delay, so a low access time is mandatory to achieve good delay granularity and predictability. I am not allowed to use interrupt based strategies (timers).
Before TSC, I tried spinning on AON timers, but their counter register is not listed in technical reference, so seems there is no way to read it.
TSC lower 32 bit word would be an optimal choice, if I could avoid that huge blocking access time. I guess DMA is not an option here (no suitable option for DMA read)?

To confirm this poor time performance in accessing shared resources from SPE, I tried a similar test code to get an AON GPIO input value by gpio_get_value API: in this case the average delay is ~3us (yes, microseconds), definitely too much, considering it is really blocking the caller task

Am I maybe missing something?

Thanks in advance

Andrea

[jachen]

Hello, Andrea:
You result is reasonable.
SPE R5 is something like a MCU, which is not so powerful.
The key point (MCU on FreeRTOS) is that the delay is very stable. You can test for several times and the difference among delays should be within sub-nanosecond.
You may have to introduce other algorithms to compensate the delay.

br
ChenJian