big.LITTLE: Heterogeneous ARM MP

The Cortex A15 is going to be a significant step forward in performance for ARM architectures. ARM hopes it will be enough to actually begin to threaten the low end of the x86 space, which gives you an idea of just how powerful these cores are going to be. The A15 will also find its way into smartphones and tablets, ultimately replacing the Cortex A9s used by high-end devices today. 

For heavy workloads, the Cortex A15 is expected to be more power efficient than the A9. The core may draw more instantaneous power, but it will do so for a shorter period of time thus allowing the CPU(s) to get to sleep quicker and reducing average power.

As ARM has often argued (particularly against Intel) however, these big out-of-order microprocessor architectures are inefficient at dealing with lightweight mobile workloads. In particular, things like background tasks running on your phone while it’s locked in your pocket simply don’t demand the performance of a Cortex A15. ARM further argues that the power consumed by an A15 running these tasks, even though only for a short period of time, is greater than it would be on a much simpler in-order architecture. This is where the A7 comes into play.

Although the Cortex A7 is fully capable of being used on its own (and it most definitely will be), ARM’s partners are free to integrate Cortex A7 cores alongside Cortex A15 cores in a big.LITTLE (or little.BIG?) configuration. 

Since the A7 and A15 are equally capable of executing the same ARM instruction set, any applications running on one core can just as easily be migrated to run on the other. In the example above there are a pair of A15s and a pair of A7s on a single SoC. In this particular configuration, the OS only believes there are two cores in the machine. ARM’s own power management firmware determines which core cluster to activate depending on performance states requested by the OS. If the OS wants a high performance state, ARM returns the A15 cores at a high p-state. If it wants a low performance state, the chip will put the A15s to sleep and schedule everything on the A7s. Cache coherency is guaranteed via the CCI-400 interconnect, so any data invalidated by one core cluster will be reflected in the other cluster’s cache. ARM claims it can switch between core clusters in this configuration in as quick as 20 microseconds.

If everything works the way ARM has described it, a big.LITTLE configuration should be perfectly transparent to the OS (similar to what NVIDIA is promising with Kal-el). ARM did add that SoC vendors are free to expose all cores to the OS if they would like, although doing so would obviously require OS awareness of the different core types.

Core Configurations, Process Technology & Final Words

ARM’s Cortex A7 will be available in 1 - 4 core configurations, both as the primary CPU in an SoC as well as in a big.LITTLE configuration alongside some A15s. ARM expects that we will see some 40nm A7 designs as early as the end of next year for use in low end smartphones (~$100). Most smartphone configurations, even at these price points will likely use dual-core A7 implementations. It’s only in emerging markets that ARM is expecting to see single core Cortex A7 smartphone devices. This is pretty big news as it means that even value smartphones will be dual-core by 2013.

Costs will keep the A7 on 40nm for a while although the cores will be offered at 28nm for integration into A15 designs as well as for even higher performance/lower power implementations.

I have to say that I’m pretty excited about the Cortex A7 announcement across the board. It looks like this core will not only enable much better performance at the value end of the device spectrum but it should bring battery life improvements at the high end as well. Chip architects have argued for years that we were going to see heterogeneous computing as the next phase in the evolution of microprocessors, it’s fascinating to see that we may get the first consumer application of it in ultra mobile devices.

Architecture
POST A COMMENT

76 Comments

View All Comments

  • leonzio666 - Friday, October 21, 2011 - link

    "No one can boost performance without sucking more power."
    I beg your pardon ? I hope what you mean is that that`s impossible over one architecture type and/or manufacturing process ? Because if not, you`re talking nonsense - how about Intel SB compared to Nehalem or Ivy Bridge which is said to provide both up to 15-20% boost over SB while still lowering TDP for some cpu`s (e.g. 77 W desktop quadcore) ?
    Reply
  • C300fans - Friday, October 21, 2011 - link

    Better performance requires more power. Pentium M, Core2, SB, they are all labeled 35W TDP on laptop although SB has the latest 32nm technology. Reply
  • french toast - Friday, October 21, 2011 - link

    More performance only requires more power on the same manufacturing process and same bandwith/cache etc.

    Penryn increased performance whilst lowering tdp over previous core 2 quad, with virtually same architechture.- mainly superior 32nm HMGK process.
    Reply
  • french toast - Friday, October 21, 2011 - link

    Didnt nvidia do some type of demo with tegra 3 where it beat a core 2 duo?? seemed a bit suspicious to me but if that is true then a quad cortex-a15 might match up against a low level core 2 quad!

    What are you thoughts on krait??
    Reply
  • blueboy11 - Friday, October 21, 2011 - link

    We really need to find a way to keep a display from draining the battery. If they can use these processors so that you can keep the brightness but have as little of an impact on display draining the battery, we might have something here to jump on. In mean the phones today use about 3/4 of the battery life on just the display alone (and I'm not talking even talking about the LTE band for you people on Verizon), so this would be really nice feature. I hear they're already trying some battery-saving features in Ice Cream Sandwich (4.0). Any takes on this? Reply
  • hyvonen - Saturday, October 22, 2011 - link

    Would you please do a quick comparison of modern x86 vs. ARM solutions in terms of performance and power effiiency. The arguments keep going back/forth, and some reliable numbers would be very useful. Thanx! Reply

Log in

Don't have an account? Sign up now