Sleep mode and power consumption

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
Post Reply
majbthrd
New User
Posts: 3
Joined: Mon Feb 22, 2010 2:40 am

Sleep mode and power consumption

Post by majbthrd »

I was hoping that the forum readers might have some insight into sleep mode and power consumption beyond what is in the XMOS documentation.

The "L series" (e.g. XS1-L1 and eventual XS1-L2) have a "PCU" (Power Control Unit?) that can interrupt the power to the core (via an external PFET) when prompted by the CPU.

The core power is resumed either in response to an external wakeup signal or a counter elapsing. (Presumably, the counter is in the PCU and clocked by SS_CLK.)

My first question would be: are the SRAM contents preserved during Sleep Mode?

Some low-power processors provide such an option, as it allows the processor to resume its state much more quickly (and thus get back to sleep mode more quickly), saving power. This would be particularly true with the XS if the entire program wouldn't fit in the OTP ROM. It does little use in being able to come out of sleep quickly if one then has to wait eons to load the software out of an SPI PROM.

Of course, powering the SRAM takes some power as well, so there is a tradeoff. The best situation is where the processor can be configured to choose whether or not to keep the SRAM powered. (That way, the software can pick the mode that best suits the anticipated Sleep Mode duration.)

I suspect that VDD powers both the CPU and SRAM, meaning that SRAM is lost during Sleep mode, but I was wishfully hoping otherwise.

On the topic of power consumption, it is a bit puzzling that:

The XS1-G2 has a budgetary power consumption of 200 uW/MHz typ. (500 uW/MHz max. for industrial, 650 uW/MHz max. for commercial).

The XS1-G4 has a budgetary power consumption of 200 uW/MHz typ. (300 uW/MHz max. for industrial, 400 uW/MHz max. for commercial).

However, the XS1-L1 has a budgetary power consumption of 450 uW/MHz typ. (It does have the footnote that it was based on pre-production targets, rather than any actual testing. Still, the part seems to be in production now.)

Based purely on the numbers from the datasheets, it seems like the G series might be a better choice for power consumption than the "low power" L series.

It begs my second question: are those numbers right? (Or, when will comparable numbers be available for the L series?)

If the G series does offer better uW/MHz and SRAM retention isn't possible in the L series, then it becomes tempting to use a G series instead of an L series and implement "PCU" equivalent external circuitry to interrupt power outright. That way, one has as good as or better sleep mode power consumption when off, and better power consumption when on.

The only loss with such an approach would be that the G series doesn't have a full equivalent to the Standby Mode in the L series. (Also, it assumes that the application would benefit from the extra processing power from a 2 or 4 core G series.)

So, my third and final question would be: is there a flaw in my logic on considering using the G series instead?

Thanks.


User avatar
dan
Experienced Member
Posts: 102
Joined: Mon Feb 22, 2010 2:30 pm
Contact:

Post by dan »

Hi there,

As you suspected, the SRAM contents will not be preserved during sleep mode because the core power supply is entirely removed via the external FET. Any state you wanted to save would need to be saved externally (e.g. in external flash).

My question is - what is your application and what 'sleep mode' power consumption are you after? The XS1-L devices also have an 'AEC' mode in which they can consume effectively zero dynamic power. (apart from the PLL). However there will still be the leakage power of approximately 14mA typical even in AEC mode. Wake up from AEC mode will be much much faster than sleep mode, since the latter involves rebooting.

I'll get to the rest of your questions about power shortly.

Cheers,

Dan
User avatar
dan
Experienced Member
Posts: 102
Joined: Mon Feb 22, 2010 2:30 pm
Contact:

Post by dan »

On the topic of power consumption, it is a bit puzzling that:

The XS1-G2 has a budgetary power consumption of 200 uW/MHz typ. (500 uW/MHz max. for industrial, 650 uW/MHz max. for commercial).

The XS1-G4 has a budgetary power consumption of 200 uW/MHz typ. (300 uW/MHz max. for industrial, 400 uW/MHz max. for commercial).
However, the XS1-L1 has a budgetary power consumption of 450 uW/MHz typ. (It does have the footnote that it was based on pre-production targets, rather than any actual testing. Still, the part seems to be in production now.)
Which version of the datasheet are you looking at? V2.0 is just been posted on xmos.com. V2.0 states that the power consumption is 450uW/MIPS, 1 MIPS=1mhz. I make that 225mA @1V.

The G4 datasheet has the G4 leakage at 120mA, so you need to add this to the G4 dynamic power, which I can confirm is definitely at the MAX end of the commercial qualification scale. The G4 datasheet power figures are somewhat optimistic in my view - we'll update them accordingly. Also don't forget the G4 dynamic power consumption is per core (whereas the leakage is per device).

While the G4 datasheet is a bit optimistic, the L1 datasheet is fully up to date. The quoted 450uW/MIPS also assumes those mips are fully utilised (e.g no waiting on events, ins, outs etc) and that the system switch is being used and clocked at core frequency, and that AEC mode is not being used. Your application may well use considerably lower dynamic power than this full utilisation case. In fact I have just finished a few days ago writing a full XS1-L power app note (honest!) which should be published in one or two days. I'll post the link here when its available, but for now I can assure you the XS1-L is by far the better choice for dynamic and static power consumption, with or without the PCU.

Hope that helps,

Dan
majbthrd
New User
Posts: 3
Joined: Mon Feb 22, 2010 2:40 am

Post by majbthrd »

Which version of the datasheet are you looking at? V2.0 is just been posted on xmos.com.
2009/11/05 V1.5 for the XS1-L1
2009/11/05 V3.3 for the XS1-G4
2009/11/05 V2.3 for the XS1-G2

I just checked xmos.com, and it still downloads these datasheets.
In fact I have just finished a few days ago writing a full XS1-L power app note (honest!) which should be published in one or two days.
I look forward to reading it when it is available.

Thanks.
User avatar
dan
Experienced Member
Posts: 102
Joined: Mon Feb 22, 2010 2:30 pm
Contact:

Post by dan »

Here is the XS1-L power app note:

http://www.xmos.com/system/files/xs1-l-power.pdf

Note that it does not deal with PCU operation. Please have a look over this app note and let us know whether you need further info on the PCU.

Dan
User avatar
shawn
XCore Addict
Posts: 238
Joined: Thu Dec 17, 2009 5:15 am

Post by shawn »

I knew we would get into the power questions and well hear we are.
As we all know the issue of power are often over looked and taken
for granted. When power is the very issue that dictates what one
may do or note in a given reference. It would be wise to put power
managment in a kernel. The Xmos chips have excellent power to
comp's ratio's it should be able to compete comfortably with
the ARM and its 9 layer abstraction.
User avatar
BrianMiller
Active Member
Posts: 33
Joined: Wed Jan 13, 2010 7:50 am
Location: USA, NC, Raleigh
Contact:

Post by BrianMiller »

dan wrote:Here is the XS1-L power app note:

http://www.xmos.com/system/files/xs1-l-power.pdf

Note that it does not deal with PCU operation. Please have a look over this app note and let us know whether you need further info on the PCU.

Dan
That's some quick reply
User avatar
dan
Experienced Member
Posts: 102
Joined: Mon Feb 22, 2010 2:30 pm
Contact:

Post by dan »

That's some quick reply
I was fortunate that the document had in fact just been finished and was awaiting publication prior to this thread getting started!

We've spent quite a lot of time characterising the power of the XS1-L chips on the tester and in our lab so we're pretty confident in the numbers presented in the app note. The XS1-L devices do not get hot like the G4 devices do.

I'm also looking forwards to seeing what use people can make of the Active Energy Conservation (AEC) feature. To assist with this we'll do an app note on this quite soon.

Long story short, AEC simply provides two clock dividers from which two core clock frequencies are derived, one fast and one slow (and both programmable). Then when all active threads are paused, the core frequency switches over automatically to the slower divider. You can then wait on a port or timer or channel operations etc at the slow frequency, and when the operation completes the core frequency is switched back to the fast divider. There are some things you need to be careful of when doing this but these will be covered in the app note.
Post Reply