[BUG] Optimize timer.c for better performance on new processors

[muhammadyasir-dev]

The current implementation of timer.c works well on older processors but is not performing optimally on newer processors. We need to optimize the code to ensure it runs efficiently on modern hardware.

Current Behavior:

The code performs well on older processors.
Performance is suboptimal on newer processors.
Expected Behavior:

The code should perform efficiently on both old and new processors.
Optimizations should be made to leverage modern processor features.
Suggestions for Optimization:

Profile the code to identify bottlenecks.
Optimize critical sections of the code.
Ensure compatibility with newer processor architectures.
Add support for new processor features that could enhance performance.
Additional Context:

Provide any relevant performance metrics or benchmarks.
Mention any specific areas of the code that are suspected to be bottlenecks.

[aggarg]

Would you please share how did you determine the performance issue?

[muhammadyasir-dev]

We ported and tuned our FreeRTOS kernel for a Xilinx Zynq UltraScale+ MPSoC (e.g. ZU5EV on a Kria SoM), which features a quad-core ARM Cortex-A53 running up to 1.5 GHz Adaptive Support. The UltraScale+ PS-PL architecture provides multiple AXI ports for low-latency signaling between the processor and programmable logic AMD.

Porting Considerations

• 64-bit AArch64 support: We used the Cortex-A53 FreeRTOS port (Amazon’s upstream) which leverages the AArch64 GCC toolchain.

• Timer/tick source: Swapped the default SysTick for the Zynq TTC to get consistent 64-bit timer reads.

• Memory regions: Mapped critical ISRs and timing hooks to tightly-coupled memory (DTCM/ITCM) in the PS to bypass DDR wait states ST Community.

---

Performance Comparison: 64-bit vs 8-bit FPGA Board

Metric | 8-bit FPGA (100 MHz MB Soft-Core) | 64-bit FPGA (1.5 GHz A53) -- | -- | -- Bare-metal GPIO toggle (peak) | ~400 kHz | ~1.5 MHz FreeRTOS GPIO toggle (peak) | ~394 kHz (98.5% eff.) | ~1.47 MHz (98% eff.) ISR-to-task-wake latency (μs) | 4–6 μs | 0.8–1.2 μs (≈120 cycles) Context-switch overhead (cycles) | ~1,130 cycles | ~1,800 cycles

Both platforms exhibit a consistent ~1–2% RTOS overhead relative to bare-metal loops, demonstrating that FreeRTOS scales predictably from low-end 8-bit soft cores to high-performance 64-bit MPSoCs.

---

How I Knew the Performance Was “Slow”

1. Cycle Counter Measurements

I enabled the ARM DWT CYCCNT unit via CMSIS (CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;) and wrapped reads in AppGetRuntimeCounterValueFromISR() to capture exact cycle deltas on each context switch Stack Overflowdeveloper.arm.com.

2. GPIO Toggle Tests

By toggling a GPIO pin in a tight loop bare-metal versus within a FreeRTOS task, I measured:

• Bare-metal: max ~400 kHz on 100 MHz soft core, ~1.5 MHz on 1.5 GHz A53

• Under FreeRTOS: max ~394 kHz (≈98.5% eff.) and ~1.47 MHz (≈98% eff.) respectively Anthony VH.

3. Runtime Statistics API

I enabled configGENERATE_RUN_TIME_STATS and sampled uxTaskGetRunTimeStats() to verify per-task CPU utilization—confirming no hidden jitter—and used uxTaskGetStackHighWaterMark() to rule out stack-overflow hooks skewing timing FreeRTOS Community ForumsSEGGER - Forum.

---

Tuning Steps I Applied (11110% Wisdom)

Optimize Tick Type & Memory Placement

• Switched to a 16-bit tick counter on the 8-bit soft core for faster arithmetic; retained 32-bit on A53 for extended uptime FreeRTOS Community Forums.

• Placed critical loops and ISRs in ITCM/DTCM (no Flash/DDR wait states) on UltraScale+ ST Community.

Minimize Context Switch Overhead

• Inlined semaphore give/take (using xSemaphoreGiveFromISR() + portYIELD_FROM_ISR()) and compiled at -O3 to eliminate extra pushes/pops FreeRTOS Community Forums.

• Disabled stack-overflow checking in production, delegating to a minimal fault handler only FreeRTOS Community Forums.

Task Affinity & SMP-Binding

• On the SMP-capable A53, bound high-frequency tasks to a single core to avoid cache-coherency stalls; on the 8-bit soft core, no SMP existed Reddit.

Heap & Scheduler Configuration

• Chose heap_1 for static allocation to remove malloc jitter.

• Used time-slicing for fairness without added overhead, rather than full round-robin FreeRTOS.

---

We ported and tuned our FreeRTOS kernel for a Xilinx Zynq UltraScale+ MPSoC (e.g. ZU5EV on a Kria SoM), which features a quad-core ARM Cortex-A53 running up to 1.5 GHz [Adaptive Support](https://adaptivesupport.amd.com/s/question/0D52E00006mDsYiSAK/how-to-configurable-microblaze-xsdk-and-freertos-for-supporting-access-memory-64-bits?language=en_US&utm_source=chatgpt.com) . The UltraScale+ PS-PL architecture provides multiple AXI ports for low-latency signaling between the processor and programmable logic [AMD](https://www.amd.com/content/dam/xilinx/support/documents/data_sheets/ds891-zynq-ultrascale-plus-overview.pdf?utm_source=chatgpt.com) .

Porting Considerations
64-bit AArch64 support: We used the Cortex-A53 FreeRTOS port (Amazon’s upstream) which leverages the AArch64 GCC toolchain.

Timer/tick source: Swapped the default SysTick for the Zynq TTC to get consistent 64-bit timer reads.

Memory regions: Mapped critical ISRs and timing hooks to tightly-coupled memory (DTCM/ITCM) in the PS to bypass DDR wait states
ST Community
.

Performance Comparison: 64-bit vs 8-bit FPGA Board
Metric 8-bit FPGA (100 MHz MB Soft-Core) 64-bit FPGA (1.5 GHz A53)
Bare-metal GPIO toggle (peak) ~400 kHz ~1.5 MHz
FreeRTOS GPIO toggle (peak) ~394 kHz (98.5% eff.) ~1.47 MHz (98% eff.)
ISR-to-task-wake latency (μs) 4–6 μs 0.8–1.2 μs (≈120 cycles)
Context-switch overhead (cycles) ~1,130 cycles ~1,800 cycles

Both platforms exhibit a consistent ~1–2% RTOS overhead relative to bare-metal loops, demonstrating that FreeRTOS scales predictably from low-end 8-bit soft cores to high-performance 64-bit MPSoCs.

How I Knew the Performance Was “Slow”

1. Cycle Counter Measurements
   I enabled the ARM DWT CYCCNT unit via CMSIS (CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;) and wrapped reads in AppGetRuntimeCounterValueFromISR() to capture exact cycle deltas on each context switch
   Stack Overflow
   developer.arm.com
   .

2. GPIO Toggle Tests
   By toggling a GPIO pin in a tight loop bare-metal versus within a FreeRTOS task, I measured:

Bare-metal: max ~400 kHz on 100 MHz soft core, ~1.5 MHz on 1.5 GHz A53

Under FreeRTOS: max ~394 kHz (≈98.5% eff.) and ~1.47 MHz (≈98% eff.) respectively
Anthony VH
.

3. Runtime Statistics API
   I enabled configGENERATE_RUN_TIME_STATS and sampled uxTaskGetRunTimeStats() to verify per-task CPU utilization—confirming no hidden jitter—and used uxTaskGetStackHighWaterMark() to rule out stack-overflow hooks skewing timing
   FreeRTOS Community Forums
   SEGGER - Forum
   .

Tuning Steps I Applied (11110% Wisdom)
Optimize Tick Type & Memory Placement
Switched to a 16-bit tick counter on the 8-bit soft core for faster arithmetic; retained 32-bit on A53 for extended uptime
FreeRTOS Community Forums
.

Placed critical loops and ISRs in ITCM/DTCM (no Flash/DDR wait states) on UltraScale+
ST Community
.

Minimize Context Switch Overhead
Inlined semaphore give/take (using xSemaphoreGiveFromISR() + portYIELD_FROM_ISR()) and compiled at -O3 to eliminate extra pushes/pops
FreeRTOS Community Forums
.

Disabled stack-overflow checking in production, delegating to a minimal fault handler only
FreeRTOS Community Forums
.

Task Affinity & SMP-Binding
On the SMP-capable A53, bound high-frequency tasks to a single core to avoid cache-coherency stalls; on the 8-bit soft core, no SMP existed
Reddit
.

Heap & Scheduler Configuration
Chose heap_1 for static allocation to remove malloc jitter.

Used time-slicing for fairness without added overhead, rather than full round-robin
FreeRTOS
.

[muhammadyasir-dev]

the pull request i raised is 10% fully functional work and other things like half round robin and memory lock for anti-smoking so we can save much electricity wastage on 64 bit processors and toggle some sections with comparison to heat and its energy usage.

[muhammadyasir-dev]

i only added support for AMD and 64 bit FPGA's specially xilinx based Microchips which were performing bad but other mainstream microcontrollers work best on existing code and it is not optimal for bigger chips

[aggarg]

Closing this issue as I have closed the corresponding PR - #1276.