Run code from ram improve the performances?

[Paolo Andreuzza]

Hallo.

In other mcu (not ARM) i’ve worked in the past, there were possibe to move some parts of time critical code to ram, and run them from there to get the best performance, since the flash mamory access were slower then the ram access.

In STM32 mcu this tecnique gives real advantages in performance?

I've seen that some STM32 mcu (but not all) have specific hardware to improve flash access speed (ART Accelerator...), om these platform, running code from ram improves even more the performances or is not a good idea?

In particular, In STM32G070, that seems to don't have any specific hardware for flash management, running code from ram does improve significantly the performances, or is it not worth?

Thank you in advance.

Paolo

[berendi]

If the flash is operating with wait states, then yes, it would improve performance. No idea how much, it is a typical YMMV. Look up FLASH read access latency in the reference manual.

Consider other ways to increase code performance, like enabling link time optimization, or rewriting general library functions to handle only your use case instead.

[RMcCa]

I experimented with this on a F730, comparing using the ART accelerator vs. Copying and running time-critical routines​ from ITCM ram. It didn't make any significant difference, i suspect that the ART accelerator works pretty well making flash access about as fast as the tightly coupled memory. From this i concluded that the main intent of the 16k of IT

[RMcCa]

.... 16k of ITCM ram is for custom bootloaders.

[berendi]

It would depend on the type of workload. E.g. having the vector table and ISR in ITCM might improve interrupt latency by a few cycles, but it would not matter at all if the ISR then calls a HAL interrupt handler with 600+ cycles overhead.

And the point of the question is that the STM32G0 series has no ART.

[Paolo Andreuzza]

This is the point.

The STM32L475 datasheet says: Core: Arm® 32-bit Cortex®-M4 CPU with FPU, Adaptive real-time accelerator (ART Accelerator™) allowing 0-wait-state execution

from Flash memory.

But my G0 doesn't have ART accelerator, so in addition to activating all the optimizations at compiling time, I should also run the critical code from the ram, am I correct?

[TDK]

>  I should also run the critical code from the ram, am I correct?

Only you are going to be able to answer that. It will increase the speed of execution, but at the cost of using up RAM. Measure performance when running from flash and from RAM and decide which is better. It will also be code dependent.

[Paolo Andreuzza]

Thank you, guys.

So could we say that where the ART Accelerator is not present, the execution of code from the ram memory it improves the performance, to the detriment of the occupation of the memory itself? Therefore it will be necessary to make the appropriate assessments for the choice of the best solution

[Tesla DeLorean]

I haven't reviewed the G0, not using it here, but historically with ST's CM0(+) designs the increase in wait state at 24 or 32 MHz is quite detrimental to code execution.

A CM0 at 24 MHz with zero wait states will outperform, a CM0 at 25 MHz with one wait state. You'd have to clock faster to find the break-even point.

So yes in this case migrating critical code to RAM, including the vector table, can help. If you can run at 48 or 64 MHz from RAM, I'd probably do that.

ST's implementations tend to be RAM poor.

[waclawek.jan]

You can't transfer conclusions from a ~100MHz Cortex-M4 (yet alone M7) to a ~50MHz Cortex-M0+ with a quite different architecture, entirely different port structure, within an entirely different bus and peripherals set.

As said above, benchmark your application.

JW

[waclawek.jan]

Let's put it in this way: in the CM0/CM0+, the processor has one single port for all accesses to all memories, so contrary to CM3/4/7, there's no room for any parallelism (hence no penalties for cases where that parallelism is not fully utilized). Accesses to RAM are (presumably) always single-cycle, so there's no way execution from RAM would be slower than execution from FLASH. OTOH, the 'L0 and 'G0 both have implemented measures on the FLASH interface to mitigate somewhat the impact of waitstates (prefetch/buffers/caches).

So, code from FLASH will most probably run somewhat slower than from RAM, and the difference may be dramatic and may be also small, depending on the particular code (assuming the buffers/caches/prefetch are not switched off, of course). Whether this benefit outweighs the drawback (RAM consumption, additional code to copy/run from RAM) is upon the user to judge.

JW

[Terry Greeniaus]

I'm just looking at RM0454 (STM32G0x0) and it seems to have most of the flash acceleration... Section "3.3.5 FLASH memory acceleration" talks about instruction prefetch and also about cache memory. It's not quite as powerful as say the STM32G4 ART, but for certain types of code it should help a lot vs. those wait states. Like others have said, benchmark it. It looks like FLASH_ACR.ICEN=1 is set by default at boot, but that you will need to set FLASH_ACR.PRFTEN=1 manually.