<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>executing small applications from SRAM -- performance implications</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/127436/executing-small-applications-from-sram----performance-implications</link><description>i have small applications which can comfortably fit in as little as 32K of SRAM.... i have no issues with the mechanics of linking my program, as well as copying code from FLASH to SRAM at startup... once in SRAM, i generally don&amp;#39;t need the cache -- in</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Fri, 20 Mar 2026 09:48:21 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/127436/executing-small-applications-from-sram----performance-implications" /><item><title>RE: executing small applications from SRAM -- performance implications</title><link>https://devzone.nordicsemi.com/thread/563750?ContentTypeID=1</link><pubDate>Fri, 20 Mar 2026 09:48:21 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:26d0b850-75d5-4893-9189-3d775e6d888c</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;The RRAM (NVM) is automatically&amp;nbsp;powered down when not used. In the&amp;nbsp;scenario you describe I assume you are in practice executing the whole&amp;nbsp;coremark like test from cache, so RRAM has no practical effect an you are effectively comparing current consumption execution from Cache with execution from RAM, and then the cache is slightly more power efficient.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: executing small applications from SRAM -- performance implications</title><link>https://devzone.nordicsemi.com/thread/563728?ContentTypeID=1</link><pubDate>Fri, 20 Mar 2026 04:03:55 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:6a877761-c297-4138-b085-43744b51f030</guid><dc:creator>bios-bob</dc:creator><description>&lt;p&gt;i reviewed my power numbers, and confirmed that running a load similar to coremark actually consumes *more* power when executing out of SRAM vs FLASH/CACHE....&amp;nbsp; execution time was roughly the same....&lt;/p&gt;
&lt;p&gt;any explanation as to why???&amp;nbsp; and is it possible to &amp;quot;power-down&amp;quot; the FLASH when active???&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: executing small applications from SRAM -- performance implications</title><link>https://devzone.nordicsemi.com/thread/563348?ContentTypeID=1</link><pubDate>Mon, 16 Mar 2026 14:05:03 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:49fe5130-cb84-40af-abf3-e7797933ff40</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi,l&lt;/p&gt;
&lt;p&gt;You are right, the VPR does not have cache. Regarding wait states you are also right. Note that we recommend that the VPR executes code from RAM and not RRAM (though that is also supported).&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: executing small applications from SRAM -- performance implications</title><link>https://devzone.nordicsemi.com/thread/563345?ContentTypeID=1</link><pubDate>Mon, 16 Mar 2026 13:51:36 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:7b6f64e9-98d8-4ae4-ab7e-301863f0ca52</guid><dc:creator>bios-bob</dc:creator><description>&lt;p&gt;let me relook at my own power numbers -- especially executing from SRAM vs RRAM+CACHE....&lt;/p&gt;
&lt;p&gt;looking at your block diagram, it appears the risc-v does *not* have a cache....&amp;nbsp; even with exclusive access to RRAM, won&amp;#39;t the CPU stall when fetching instructions???&lt;br /&gt;&lt;br /&gt;does the risc-v have a separate INST + DATA bus -- or is it more like an M0???&amp;nbsp; is their benefit to placing risc-v code into a separate SRAM block -- to avoid contention *and* wait-states???&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: executing small applications from SRAM -- performance implications</title><link>https://devzone.nordicsemi.com/thread/563339?ContentTypeID=1</link><pubDate>Mon, 16 Mar 2026 13:32:00 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:a0507bac-9e9b-4580-9207-273e3dc00c71</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;The &lt;a href="https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/cache.html"&gt;cache&lt;/a&gt; is 8 kB. Caching&amp;nbsp;is normally quite efficient, and you will typically not see a benefit using by placing the application in RAM with caching disabled compared ro RRAM with caching enabled when caching is enabled (see &lt;a href="https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/chapters/current_consumption/doc/current_consumption.html#ariaid-title6"&gt;current&amp;nbsp;consumption for&amp;nbsp;CPU running&lt;/a&gt;). To see the effect you can disable instruction cache using&amp;nbsp;&lt;span&gt;&lt;a title="https://docs.nordicsemi.com/bundle/ncs-2.9.0/page/kconfig/index.html#config_icache" href="https://docs.nordicsemi.com/bundle/ncs-2.9.0/page/kconfig/index.html#CONFIG_ICACHE" rel="noopener noreferrer" target="_blank"&gt;CONFIG_ICACHE&lt;/a&gt;=n in prj.conf or similar.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Regarding&amp;nbsp;the&amp;nbsp;VPR RISC-V CPU, there is only a single RRAM bank on the device, so here there will be waits of the ARM and RISC-V core attempts to access at the same time. For RAM, you can avoid it by using separate RAM banks. See &lt;a href="https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/memory-layout-of-applications-using-the-risc-v-coprocessor-of-the-nrf54l-series#Sharing-code-memory-between-the-CPU-and-the-FLPR"&gt;Memory layout of applications using the RISC-V coprocessor of the nRF54L Series&lt;/a&gt;.&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>