RE: Instruction cache (I-Cache) using and user guide.

VadymS — Tue, 01 Dec 2020 12:11:10 GMT

Thanks! Clear enough!

RE: Instruction cache (I-Cache) using and user guide.

hmolesworth — Mon, 30 Nov 2020 17:52:24 GMT

Not an official answer, but maybe some useful tips. The cache has a private SRAM which is inaccessible by the user, likely 2k bytes. The NVMC must be ready before enabling the cache:

 // Enable cache and also enable hit/miss tracking
 while(NRF_NVMC->READY == 0) ;
 NRF_NVMC->ICACHECNF = 0x101;

Here I have enabled the hit/miss tracking counters as well as the cache, which are 2 non-resettable saturating counters which increment on every cache hit and miss. As the code executes it fills the cache (cache miss count++) until parts of the code in the cache execute from the private SRAM instead of FLASH (cache hit count++). If the code loop is bigger than the cache, then the cache starts reloading and (cache miss count++). If the code is small enough to fit in the private SRAM then (cache hit count++), ie optimum performance. However, if some interrupt then occurs then that interrupt will load the cache with new FLASH code as the interrupt executes (cache miss count++). If the total size of active interrupts and code loop fits in the cache, then back to maximum performance and no cache misses, but that is unlikely unless most interrupts are disabled for the duration of executing the test, which must be small and not call large functions. Executing Coremark tests via function calls might exceed the size of the cache, so maybe write some other tight loop and measure performance that way

Once the cache hit/miss registers reach max values there is no more useful information available without a reset. To display use something like this:

 NRF_LOG_INFO("Cache Enabled 0x%08X 0x%08X 0x%08X 0x%08X", NRF_NVMC->ICACHECNF, NRF_NVMC->IHIT, NRF_NVMC->IMISS, NRF_NVMC->CONFIG);
 NRF_LOG_FLUSH();

Cache SRAM consumes additional power, so when cache is enabled the power consumption goes up; however, FLASH code execution uses 2 wait states whereas SRAM code execution does not use wait states, so the loop code executes faster which can and usually does lead to overall lower power consumption as well as faster execution.