Between program execution from RAM vs flash, what is the point of indifference in terms of power consumption?

Jason,

There is overhead to set up functions to run out of RAM, but this is a difficult question to find the "tipping point" on power savings because it will vary so much depending on the application. Unfortunately we don't have any literature on this that I am aware of.

To put this in perspective, I will make the following example with the assumption that flash execution = 2X the power of RAM execution.

Flash Execution Power = Flash Execution Energy * t1, let's assume t1 = 1s for some function

RAM Execution Power = Ram Execution Energy *t1 + Flash Execution Energy * t2 where t2 is the time is takes to move code into RAM

if RAM Execution Power < Flash execution power then

Ram Execution Energy *t1 + Flash Execution Energy * t2 < Flash Execution Energy * t1

Ram execution energy = flash execution energy/2

Flash Execution Energy/2 *t1 + Flash Execution Energy * t2< Flash Execution Energy * t1

So t1/2 + t2 < t1

or t2 < t1/2

This is some pretty simple math, but in principle it means that the function needs to run in RAM for twice the period as it takes to move it to RAM for any power savings (with our assumptions). In general this will be true of simple loops that will be very repetitive.

For instance when drawing an image to an LCD display, this simple function is all that is required, and will write a total of 400 * 240 /8, or 12KB to a RAM display buffer.

static void
Sharp400x240_DrawMultiple(void *pvDisplayData, int lX, int lY, int lX0, int lCount, int lBPP, const unsigned char *pucData, const unsigned int *pucPalette)
{
unsigned char *pData = &DisplayBuffer[lY][lX>>3];
unsigned int xj = 0;

//Write bytes of data to the display buffer
for(xj=0;xj<lCount>>3;xj++)
*pData++ = *pucData++;

//Write last data byte to the display buffer
*pData = (*pData & (0xFF >> (lCount & 0x7))) | *pucData;

}

So this simple function will easily save a large amount of power because t2 (time to copy function to RAM) will be very short compared to t1 (time to execute function).

I hope this helps some, this is mostly stuff you already knew, but my advice would be to only perform this RAM execution on functions where the power savings will obviously be there. Time of development and debug complexity will certainly be added when doing this so it is probably wise to stick to the big power saving functions.

In general I have never really seen this done as a real power saving method, it is typically done out of necessity. I think the significant effort this would require may be better placed elsewhere to reduce power, such as verifying good use of LPMs, etc. As mentioned in the other post you linked to- "the savings is somewhere around the difference between picking XCAP14PF vs XCAP0PF for my crystal." 

customer said:

That doesn’t directly address the point on which I’m trying to get clarification.

 

If the method described is valid then it implies that the power consumption is driven cycle-by-cycle depending on whether the instruction source is Flash or RAM.

 

If I was to attempt this approach for power consumption savings I’d simply load the function block into RAM once, at startup, and therefore the overhead required to move code to RAM is basically zero.

 

But what I want to know is, if there is code being executed alternately out of RAM and out of Flash, is there a minimum time during which we incur higher power consumption (at the Flash execution current) due to the Flash block being active?

 

OK, understood. Let me get back to you about this

customer said:

That’s exactly what I was looking for. I can try this out here and see what difference it makes.

Just to add to Mike's point, there is quite a bit of potential power saving in scenarios where the application mainly resides in LPMs and periodically performs short burst of activities most likely responding to interrupts. Relocating critical and most frequently used functions and ISRs into RAM could significantly reduce the number of flash accesses (virtually LPM + RAM-only access) during the majority of the application's lifetime. 

Regards,

Dung

Let me add some more thoughts abotu this:

If your applicaiton makes heavy use of tables, this may also be considered.

All initialized variables are stored in flash and linked to ram. At startup, the values are copied from flash to ram. However, if you have many tables, it usually makes sense to declare them const. This way, they are still stored if flash (where else?)  but not copied to ram but rather linked against their flash location.

Now it could be a good idea, to still copy a table you need to heavily use, from flash to ram for usage. The noted increased power consumption for code execution from flash also applies to data access from flash.
So i tmight pay to copy any data you'll be using much soon, from flash to ram before using it.
Of course you may decide to not declare it const (and it will be in ram after startup then), but if you have multiple tables that exceed available ram, and only need one at a time...