OS Driven Power Management

When Intel introduced Nehalem and the Core i7, we saw a new generation of power engineering in microprocessors. In the past, the OS would request a particular performance state from the CPU and the chip would respond by changing its clock speed. Nehalem’s Power Control Unit (PCU) instead dedicated enough transistors to build a 486 to monitoring the power and performance demands on the chip. Based on those demands and what the OS was doing, the PCU would power up or down individual cores, as well as move clock speeds up or down. The PCU would guess at what the OS was trying to do and respond accordingly.

Nehalem and its successors were massive chips, eating up to 130W of power under load and idling down in the 6 - 10W range. Lincroft has to be sub-1W under load and 6mW at idle. With even more stringent power demands and a much smaller die, Intel couldn’t blow a sizeable percentage of the Lincroft transistor budget on power management.

Instead of guessing at what the OS wants, the Moorestown platform uses OS Driven Power Management (OSPM) to tell Lincroft and Langwell what to do. OSPM is supported in Moblin and presumably the Wind River build of Android.

The OSPM process tells the hardware what apps it’s running and to shut down what it doesn’t need. There are well defined operating modes - standby, internet browsing, MP3 playback, video playback, voice call, video capture, etc... Based on the profile, the hardware doesn’t have to guess at what it should turn off/on, it just does it right away.

The OSPM driver communicates directly with the two power management units in Moorestown - one in Lincroft and one in Langwell. It instructs those PMUs to shut off various blocks, and in turn they tell Briertown to gate and cut voltage to the parts of chip that aren’t needed.

I wondered if this couldn’t be done in hardware, but it seems that given current die constraints and the sort of accuracy of information it needs Intel must implement at least some of the power management control in software. Toolkits will be available for developers to control the OSPM.

Power Gating Putting Power in Perspective: Estimated Battery Life of a Moorestown Phone
Comments Locked

67 Comments

View All Comments

  • CSMR - Wednesday, May 5, 2010 - link

    Agreed. Intel needs a process advantage to beat ARM with x86. (Notwithstanding the software pain of transitioning to x86). But it actually doesn't have it. They are roughly on par in this segment, Intel leading by maybe a few months.
    http://channel.hexus.net/content/item.php?item=225...
  • hyvonen - Wednesday, May 5, 2010 - link

    Sorry, but Intel is ahead way more than two months. Intel's 32nm process is better from performance/power point of view than 28nm bulk processes from others. Relying on numbers such as 32nm and 28nm to figure out which one is better is like using only CPU clock frequency numbers to determine which CPU is fastest.

    Oh, and since Intel's 32nm products started shipping in the beginning of this year, Intel is roughly a year ahead... maybe more.
  • metafor - Wednesday, May 5, 2010 - link

    Yes and no. The 32nm shipping is the high-performance (high leakage) one used in desktop/laptop processors and also the current Atom. For a smartphone, that simply won't do.

    The 45nm low-leakage process they used for Moorestown is new territory for Intel and in that respect, they are behind TSMC. While the current bulk silicon 45nm isn't faster than Intel's metal gate 45nm, it's a lot less leaky in terms of power. I would guess it'll take Intel 2 iterations or so before they have leakage down to the point of being competitive. But they have performance going for them.
  • hyvonen - Wednesday, May 5, 2010 - link

    Yeah; first iteration: 45nm low-power process. Second iteration: 32nm low-power process.

    TSMC is stuck, and won't be able to come up with a low-power process beyond the current one for a couple of years. 40nm is in trouble, 32nm is toast. Good luck with making anything below 32nm "low power" in any sense of the word.
  • LuxZg - Wednesday, May 5, 2010 - link

    Ok, so this should be x86 CPU. So will the "tablet version" support normal Windows 7 OS or something similar? That's my only question.. I don't expect Win 7 on smartphone, but unless we have 100% software compatibility "x86 everywhere" won't mean much to people (except to Intel).
  • iwodo - Wednesday, May 5, 2010 - link

    It looks great, If Intel could give Apple some VERY good deal i guess Apple might take it.

    I cant wait for the 32nm Medfield.

    But Apple using it would means no more surprise in terms of Hardware.....
  • iwodo - Wednesday, May 5, 2010 - link

    After reading, I still do not understand the idea why Apple needs to buy other Chip Maker. If Morrestown is this good, and Medfield is much better. ( Apple should know it well before hand ) why spend money.

    Intel is making chips at volume much cheaper then Apple designing and making their own. Hardware CPU dont differentiate the product. Outlook and Software does.
  • WaltFrench - Sunday, May 9, 2010 - link

    “…I still do not understand the idea why Apple needs to buy other Chip Maker. If Morrestown is this good, and Medfield is much better.”

    I think you answered your own question. Apple, who probably had some inkling of Intel's plans, has been plowing ahead with proprietary silicon. They must think that for the next couple of years, anyway, they're better off with ARM-based designs, tweaked in-house and sent to whatever foundry gives them the capability they need.

    Can anybody estimate the number of Atom-class chips Intel sells? The general estimates are that ARM designs go into a billion devices per year, and Apple is probably thinking that they'll move 50 or 100 million per year. Intel would appear to have a serious resource/investment challenge, in addition to the business challenge of talking people into abandoning ARM.
  • Visual - Wednesday, May 5, 2010 - link

    Let me see if I get this straight... this is a x86 system. And it will NOT run standard x86 OSes or binaries?
    If so, the developers of this are complete idiots.

    It must definitely have the ability to run normal desktop windows apps at launch - either by running a full windows OS, maybe modded to make better use of small screen and no kbd, or at least by some wine-like layer. It must run dosbox with the dynamic core.

    Else it being x86 is completely useless.
  • safcman84 - Wednesday, May 5, 2010 - link

    Windows 7 for Phones is hardly an established Smartphone OS. As this chip is targeted for Smartphones, then not having support for Windows is not an issue.

    Besides, why would Intel support a OS that is not optimised for their CPU when it is touted as the most powerful smartphone solution ? A non-optimised OS will make the chip look bad. If Intel supports andriod devices (plus MeeGo and Moblin) suddenly get 2x the performance, with excellent battery life then Intel's decision not to support Windows based phones could force MS to optimise their OS for use on Moorestown, otherwise Windows based devices dont have a chance.
    Intel have not said they will NEVER support windows devices, just that they dont at the moment cos the current iteration of Windows 7 for phones is unoptimised.

    In addition, as someone who used Smartphone for use with work, I would happily deal with the inconvenience of having a slightly longer phone if I got 2x the performance for the same battery life.

    If the theoretical performance proves true in practice then:

    Andriod + Moorestown = Yes please

Log in

Don't have an account? Sign up now