FTA, it's intended to be used as a standalone in sub-$100 phones, or as a low-powered processor that could be paired with a more powerful chip and take care of tasks that aren't performance-intensive. So it's not out of the realm of possibility that it will see duty in top-of-the-line phones.
The biggest killer for his iPhone 5 question is the fact it's not slated for release until 2013, which puts it well past the iPhone 5's introduction.
This is binary compatible with the upcoming A15 processor, but lower speed and more power efficient. The intent is that a chip will have some A15 cores and some A7 cores and use them as appropriate to balance speed and energy consumption.
It could also be used as a standalone processor where its performance is sufficient and energy efficiency is a win.
The "Cortex A∗" numbering scheme should not be confused with the "Apple A∗" numbering scheme. They are unrelated. There is in fact an A5 in each scheme at the moment.
I wanted to bring up, the numbering scheme has always been awkward to me, and I'm wondering what will happen when Apple releases the A7, if they'll just let the confusion continue...
Was this an intentional move on Apple's part or just not something they paid attention to?
That—and I always figured it was a bit of a joke. The iPad was the first device to ship with the A4 chip. The iPad is a sort of digital ...pad of paper. And what's the smallest standard size of paper that fully covers an iPad? (Basically, the kind of envelope you'd buy to put an iPad into?) A4.
In overall power consumption how high is the CPU on the list of components? I'd imagine the display, WiFi, cell radios, Bluetooth are the real battery zappers. If a device was to be built using this big dog-little dog strategy, realistically how much battery life could expected to be gained?
If you have an Android phone it does have a breakdown. The couple times I've looked at mine it was screen and radios (wifi, cell) active/standby. But I think that is not important. As programmers, we look at the overall and can pick and choose parts to consider for optimization. Hardware isn't quite so general -- ARM needs to be ready in case a breakthrough in screen or radio battery usage leaves the CPU being the power hog.
It really depends how much of each of those things you're using. If you have an LCD display that you set to be bright, its going to dominate your power usage when its on, but not if you're really maxing out the CPU. When you're not using the phone the cell radio is going to dominate power usage, but if you're on WiFi range it won't be that bad. Most of the time in that case the processor is going to be sleeping, but occasionally it will wake up and check for updates, etc, before going back to sleep. Its in a case like that where having it be a little A7 instead of the big A15 that wakes up will be a big advantage.
Careful though, that's apples to oranges. Clearly you're right: waking up a small core for a tiny task is going to require less power than doing the same on a big core. But the choice here is between a A15-only design (you need the big core always) and an A15+A7 design. The one with an A7 is a larger chip. That silicon area has built-in costs in both money and power consumption and has to be accounted for.
It certainly has an area cost, but its not going to contribute to power consumption when its not turned on. Power gating is a pretty well developed technique these days, and on the high Vt processes that everyone but NVidia uses you could probably make due with just clock gating for something as tiny as an A7.
It means you can have the CPU and OS running 24x7. So much simpler to program (and more like a desktop system) than most embedded where you have to wake up every N seconds, check for tasks and go back to sleep.
I've noticed that when I play a game, I can drain the battery in a matter of 2-3 hours. My guess is that most of that power drain is due to the CPU and GPU. Certainly the screen is a big factor.
What would be amazing is if the OS on devices with these smaller cores would provide a mechanism for apps to request the kind of CPU they want. For example, services or background tasks could always run on the smaller core, even if they are fully utilizing the core, without getting pushed to the bigger core. This could help Android, for example, make sure that background tasks don't eat up battery life while the phone appears to be sleeping or doing other things.
It's really tough to say. The short answer (I'm assuming you haven't done much embedded/mobile development) is that doing _anything_ uses power. Power is the Big Problem in mobile development. Use the CPU, it will burn up tons of power. If you are easy on it, but you are constantly streaming network data, the radios will burn up tons and tons of power. Even the GPS module uses a ton of power. Even the accelerometer measurably drains the battery when apps are accessing it. They say the reason the iPhone and some other smartphones still ship with such limited ram is that continually striping additional DRAM to keep the values fresh has too big of an impact on power consumption.
It's crazy, if you aren't used to thinking about it, how much your software's behavior can affect power usage. Have a sloppy inner loop where you spin on a lock, destroy the battery. Leave open HTTP connections that aren't really doing anything but are waiting on data, destroy the battery. Set the accelerometer update frequency hire than you absolutely need to, there goes the battery. Fire up a GL view that turns on the GPU, god forbid you try to run synchronously and spin on framebuffer renders, goodbye battery.
I have a theory, and it's...essentially totally baseless, hand-waving speculation, but I'll share it anyway, that that's really the difference you see with a lot of these new phones that come out that have terrible battery life. It's not necessarily that running the slightly larger screen automatically decimates the battery, say, its that the carriers don't have the discipline to be brutal with regard to the software's power consumption.
With iOS, this has historically been mitigated to some degree by the fact that 3rd party apps weren't allowed to run in the background, and that Apple was fairly psychotic about managing power use in its first party software. That is changing, but I suspect a lot of what has driven the API design there is sensitivity to power consumption.
It's actually wild, if you have an iPhone, say, to turn off the Wifi, 3G, and BT radios, and location services. Use it like a dumb phone. The battery will easily last for a week, probably a lot longer if its a new battery, and all you do is send texts and make the occasional call. The OS and phone radio can idle for a long time on a single charge, with occasional powerings of the screen. We think of phones as just being intrinsic power hogs due to the screen and phone functionality, but the power efficiency of those has risen dramatically over the last several years. It's all the other shit now, which is the shit that makes the phone interesting, that consumes all the power.
So yes, a dramatically more power-efficient CPU would make a huge difference. However, I am personally skeptical that having a separate, off-die CPU that's lower power consumption will lead to dramatically better power performance, but we'll see.
How much battery life is saved using an asymmetric multicore design as compared to dynamically downclocking of a "big dog" core? The article does not address this, but it does say that smaller die size of the "little dog" core uses 1/3 less power.
It's a huge "it depends", and on things that aren't ever going to be publicly visible. "Shutting down" a core is itself really complicated. You can drop all the power rails and push the quiescent current all the way to zero, but that loses the cache; so on resume those cache lines have to be refilled, which is work you don't have to do if you maintain power to the cache. Which to choose has to do with how long the CPU will be active for, which depends in sensitive ways on the architecture of the whole system (how much work can be offloaded to the hardware vs. requires interrupt handling in the CPU, etc...). But then of course those other hardware devices have their own power needs. And there's further complexity due to multiple layers of cache, etc...
Balancing the whole thing is a big guessing game, and the guesses have to be made by the SoC vendors years before the actual product appears in the market.
My intuition, FWIW, is that the asymmetric idea is a non-starter. It sort of exists right now: c.f. the "baseband CPU" (or all the DSP cores you find scattered around these things) in many Android designs, and the extra CPU is really just a huge resource waste. The hardware people will never get this right. Putting all the transistors into a single set of SMP cores gives up on the ability to tune things perfectly, but it puts the OS in control of things. OS vendors are much closer to the problem and better positioned to make good guesses.
There should be decent public visibility in time, if an A7 ever shows up on a Nexus phone or on a successor to Beagleboard/Pandaboard. Actually, I don't have the link just now, but IIRC someone was trying to write software to do the same thing on the Pandaboard's OMAP4, transferring a running Linux kernel from the A9 core to one of the OMAP4's built-in M3s. (I don't know what they were planning to do for memory protection.)
I believe the idea here is that the coherency logic allows the A7 to be presented to the OS as simply another core that happens to run slower and consume less power. This means that the OS is in control - the transition to low-power mode is handled by the OS scheduling processes on the little dogs while putting the big dogs into power saving states.
In the extreme case of mostly low-activity, switching to a smaller, slower, low-power core is going to save you power. If discrete, the low-power core can be made with completely different parameters and process technology and consume virtually 0 power compared to the "big-dog" in low-power-mode, and you can properly cut power to the leaky "big-dog".
However, if you find yourself switching back and forth frequently, you are probably wasting time, power and materials.
I doubt this will change process model or application lifecycle already present in the major smartphone OS. In the "always" on services, long-running background tasks arena the precious commodity is not cpu usually, it's memory. There is no "swap space".
Interesting to see QNX\RIM listed as an early partner.
Reminds me of the old BBC coprocessors, which is interesting as ARM's predecessor was Acorn Computers. Funny to see an idea from the 80's getting a second run out!
NVidia's Kal-El SoC implements this approach, although it uses Cortex A9 for both the Big Dog and Little Dog cores. The Little Dog is produced using low-leakage transistors, which is where their obtain their power savings (at the cost of clock speed). In the Kal-El design, the Little Dog communicates with the Big Dogs through a shared L2 cache.
26 comments
[ 5.5 ms ] story [ 107 ms ] threadEdit: But it could appear in future iPhones as a secondary processor.
The biggest killer for his iPhone 5 question is the fact it's not slated for release until 2013, which puts it well past the iPhone 5's introduction.
It could also be used as a standalone processor where its performance is sufficient and energy efficiency is a win.
The "Cortex A∗" numbering scheme should not be confused with the "Apple A∗" numbering scheme. They are unrelated. There is in fact an A5 in each scheme at the moment.
Was this an intentional move on Apple's part or just not something they paid attention to?
What would be amazing is if the OS on devices with these smaller cores would provide a mechanism for apps to request the kind of CPU they want. For example, services or background tasks could always run on the smaller core, even if they are fully utilizing the core, without getting pushed to the bigger core. This could help Android, for example, make sure that background tasks don't eat up battery life while the phone appears to be sleeping or doing other things.
It's crazy, if you aren't used to thinking about it, how much your software's behavior can affect power usage. Have a sloppy inner loop where you spin on a lock, destroy the battery. Leave open HTTP connections that aren't really doing anything but are waiting on data, destroy the battery. Set the accelerometer update frequency hire than you absolutely need to, there goes the battery. Fire up a GL view that turns on the GPU, god forbid you try to run synchronously and spin on framebuffer renders, goodbye battery.
I have a theory, and it's...essentially totally baseless, hand-waving speculation, but I'll share it anyway, that that's really the difference you see with a lot of these new phones that come out that have terrible battery life. It's not necessarily that running the slightly larger screen automatically decimates the battery, say, its that the carriers don't have the discipline to be brutal with regard to the software's power consumption.
With iOS, this has historically been mitigated to some degree by the fact that 3rd party apps weren't allowed to run in the background, and that Apple was fairly psychotic about managing power use in its first party software. That is changing, but I suspect a lot of what has driven the API design there is sensitivity to power consumption.
It's actually wild, if you have an iPhone, say, to turn off the Wifi, 3G, and BT radios, and location services. Use it like a dumb phone. The battery will easily last for a week, probably a lot longer if its a new battery, and all you do is send texts and make the occasional call. The OS and phone radio can idle for a long time on a single charge, with occasional powerings of the screen. We think of phones as just being intrinsic power hogs due to the screen and phone functionality, but the power efficiency of those has risen dramatically over the last several years. It's all the other shit now, which is the shit that makes the phone interesting, that consumes all the power.
So yes, a dramatically more power-efficient CPU would make a huge difference. However, I am personally skeptical that having a separate, off-die CPU that's lower power consumption will lead to dramatically better power performance, but we'll see.
Balancing the whole thing is a big guessing game, and the guesses have to be made by the SoC vendors years before the actual product appears in the market.
My intuition, FWIW, is that the asymmetric idea is a non-starter. It sort of exists right now: c.f. the "baseband CPU" (or all the DSP cores you find scattered around these things) in many Android designs, and the extra CPU is really just a huge resource waste. The hardware people will never get this right. Putting all the transistors into a single set of SMP cores gives up on the ability to tune things perfectly, but it puts the OS in control of things. OS vendors are much closer to the problem and better positioned to make good guesses.
However, if you find yourself switching back and forth frequently, you are probably wasting time, power and materials.
What is "frequently"? I cannot say.
http://en.wikipedia.org/wiki/BBC_Micro_expansion_units