Code is slower executing from tightly-coupled (ITC) memory

[expertsleepers]

As an experiment, I tagged a fairly costly function with

__RAMFUNC(SRAM_ITC)

To my surprise, it ran about 10% slower. Could anyone share any insight on why that might be?

This is on an iMXRT1062, running from flash (XIP) if not running from ITC.

[Masmiseim]

Hello @expertsleepers,

does the code you execute from the ITCM call functions that are located in flash or SDRAM/OCRAM? These are now more expensive because the compiler inserts a veneer function.
When calling Std-Lib functions, it is also not quite obvious where they are located.

Regards

[expertsleepers · Accepted solution]

This was indeed it.

The full situation was:

• The code uses a lot of double precision maths.
• The project was set to use a single precision floating point ABI, and so was full of function calls instead of .f64 operations.
• When the code was put in ITCM every one of those function calls went through a veneer.

Having selected a double precision ABI, the function is now twice as fast and doesn't slow down when in ITCM. It doesn't get any faster either, but I'm sure there are more mundane reasons for that.

I find it odd that the project was created with the wrong ABI - it was created from a iMXRT1062 template.

This thread was useful regarding the FP ABI:

https://community.nxp.com/t5/i-MX-RT/FPU-Type-options-for-MCUXpresso-for-double-precision-floating/m...

[Masmiseim]

Hello @expertsleepers,

The FPU setting for all M7 cores of the iMXRT family should be FPv5-D16. The only exception is the iMXRT1011, here it must be FPv5-SP-D16.
For the M4 and M33 cores it is also FPv5-SP-D16.

The reason why it is not faster in the ITCM than when executing from the flash is that the function is probably so small that it fits completely into the cache.
However, if the code base increases in size, cache trashing occurs. This means that the speed at which the function is executed is no longer deterministic.

Regards

[expertsleepers]

Ah yes, it could be that.
Just to be clear, are function calls from ITC to other ITC functions still fast?

[Masmiseim]

Hello @expertsleepers,

If the function to be called is a maximum of four megabytes “away” in the address range, a direct jump “BL” can be used without veneer.

Regards

[Omar_Anguiano]

It is possible that the function has some routine that expects data contained on another memory inducing some wait states to the execution.

Best regards,
Omar

[expertsleepers]

But would that not also be true if the function was executing from flash?

The function accesses OC SRAM and external DRAM. Both will cause waits, I'm sure, but I can't see how that would make ITC slower than XIP.

[Juozas]

Interesting. Would you be able to provide a test case? I'd like to reproduce this behaviour.

[expertsleepers]

Unfortunately the code in question is part of a very large project. I'd have to try to isolate it into a fresh project - which of course may not exhibit the same behaviour. I'll post if I manage to create a small test case.

[Juozas]

I understand. Following this topic.