When does it make sense to use OCRAM?

[mjbcswitzerland]

Hi All

I am wondering when OCRAM makes sense to use.

If I have my interrupt vectors and code in ITC and data, stack and heap in DTC I find that they operate at core clock rate and don't have any strange effects due to caching. The on chip peripherals (like ENET) can work with buffers in DTC and I can also do memory to memory using DMA.

Therefore OCRAM is not needed and can be disabled (allowing max. ITC and DTC).

When would OCRAM make sense to use? [I have read something about DMA in low power modes being necessary or better with OCRAM but didn't see any details about why]. I have read AN12077 ("Using the i.MX RT FlexRAM") but it doesn't really compare the limitations between the three types.

Is there a side-by-side list of advantages, disadvantages and limitations of the memory types?

Regards

Mark

[ahollom]

Hello Jeremy,

The original poster, Mark, mentioned that he already runs his code from ITCM and allocates all the data the program requires inside the DTCM, so his question (a very good one) was - why would you want to put something in OCRAM when it can be in DTCM?

The TCM can be configured as ITCM, DTCM and OCRAM, and these all reside on the same piece of FlexRAM, so allocating OCRAM results in a smaller amount remaining to be allocated to ITCM and DTCM, thus reducing their potential size. Since everything in FlexRAM, whether it be ITCM, DTCM or OCRAM, is directly accessed by the CPU, thus bypassing the processor's caches, then why would you want to put anything into OCRAM when it can be put into DTCM?

I might be missing something fundamental, which I trust you will explain.

[ahollom]

Having expanded my testing to include placing the data segment into OCRAM (it was in DTCM), I was surprised that turning the processor's data cache off caused execution to slow. I, and presumably Mark, had assumed that being a part of FlexRAM that it would communicate directly with the CPU, bypassing its caches, but this is not the case.

Looking at figure 1 in AN12042, "Using the i.MXRT L1 Cache", it shows a purple line from OCRAM to SIM_M7 (bus fabric interconnect), which is I assume the path data to/from OCRAM takes between it and the CPU (I had previously assumed the two blue arrows to ITCM/DTCM also applied to OCRAM, but this is clearly not the case).

If you turn off the data cache, then OCRAM is around 65% faster than SDRAM in one benchmark test and a massive 257% faster in another. Similarly DTCM is 19% and 279% faster than OCRAM in the same two tests respectively. With the data cache enabled, performance between OCRAM and DTCM is almost identical.

Since OCRAM is slower than DTCM, then that's even more reason to prefer DTCM over OCRAM. However, in AN12077, "Using the i.MX RT FlexRAM", it mentions that OCRAM cannot be sized to 0 kB due to boot ROM code requirements (64 kB is the minimum), so it might make sense to use it post-boot for application data of some sort.

[mjbcswitzerland]

Hi Andrew

OCRAM can be set to a minimum of 64k by the eFUSEs since the Boot ROM requires 64k to operate.

My strategy is however to configure the FlexRAM dynamically at run time and not use eFUSEs, in order to fully deactivate OCRAM when possible.
If I remember correctly this worked on a 256k FlexRAM part - see RAM and Cache section of https://www.utasker.com/docs/iMX/i.MX_RT_1021_uTasker.pdf

which shows the concept that was (hopefully correctly) verified during initial investigations.

I am however a little behind schedule on completing this so can't confirm 100% today.
Since OCRAM is 32 bit wide and its bus is 1/4 the speed of the 64 bit wide ITCM/DTCM it is naturally slower.
Originally I was wondering where the advantages lie in using it (and some complications ensuring cache synchronisation when DMA is used) and I haven't a practical reason to use it just yet, but maybe will find one with time.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[mjbcswitzerland]

Hi All

Update:
I have been using exclusively ITC and DTC (OCRAM disabled) by dynamically configuring the the FlexRAM at board initialisation and can confirm that it operates as expected (at the bottom are the shifts from default eFuse settings on i.MX RT 1011 and i.MX RT 1021 (128k and 256k examples) which also allow shuffling the banks and "retaining stack data", which allows doing fairly easily it in nested sub-routines using stack located variables.

The only really weird thing that I found during the work was when I did it only an i.MX RT 1015, which should have 128k RAM like the 1011. I found it in fact has 256k RAM and 8 banks (just like the 1021) so had to reconfigure like the 1021 to get it working...

The data sheets:

[this is either wrong or my chip is an exception...]

i.MX RT 1011 default memory (default eFuse setting)

Reconfigured for ITM/DTM use:

i.MX RT 1011 default memory (default eFuse setting) [and i.MX RT 1015!!!!]

Reconfigured for ITM/DTM use:

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

P.S. I will ask about the i.MX RT 1015 RAM size in a separate post.

[jeremyzhou]

Hi Mark,

Thank you for your interest in NXP Semiconductor products and
for the opportunity to serve you.
In general, the OCRAM is used to store local variables, stack and heap.
The I/DTCM (FlexRAM banks configured as TCM) is accessed directly by CPU core, bypasses the L1 cache. Therefore, put the critical code and data into the TCM is recommended, like the vector table.
And the attachment presents more information about the memory type and attribute, it may give you an insight into the FlexRAM.

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------