ARM has been doing a good job figuring out its PR strategy as of late. In the span of a couple of years we went from very little outward communication to semi-deep-dives on architecture and a regular cadence of IP disclosures. ARM continues its new trend today with the announcement of its 2015 mid-range CPU IP: the Cortex A17.

As its name implies, the Cortex A17 is a 32-bit ARMv7-A CPU design (64-bit ARMv8 cores belong to the Cortex A50 series - e.g. A53/A57). The best way to think about Cortex A17 is as an evolution of the recently announced Cortex A12, rather than anything to do with the Cortex A15. ARM's Cortex A17 takes the basic 2-wide out-of-order architecture of the Cortex A12 and improves it. Specific details are still light at this point, but I'm told that the front end and execution engine are similar to Cortex A12, with most of the performance/efficiency gains coming from improvements to the memory subsystem. 

The result is a design that is roughly 60% faster than a Cortex A9r4 at a given frequency/process/memory interface (Cortex A12 is 40% faster than A9r4 under the same conditions). Using ARM's own DMIPS/MHz ratings I threw together a little table of relative/estimated performance ratings to help put all of this in perspective:

ARM 2014/2015 CPU IP lineup
CPU IP Target Estimated DMIPS/MHz big.LITTLE Shipping in Devices/Systems
Cortex A57 High-end mobile/servers 5* Yes (w/ A53) 2015
Cortex A53 Low-end mobile 2.3 Yes, LITTLE, w/ A57 2H 2014
Cortex A17 Mid-range mobile 4.0* Yes, big, w/ A7 Early 2015
Cortex A15 High-end mobile 4.0* Yes, big, w/ A7 Now
Cortex A12 Mid-range mobile 3.5 No 2H 2014
Cortex A9 High-end mobile 2.5 No Now
Cortex A7 Low-end mobile 1.9 Yes, LITTLE, w/ A15/A17 Now

*Estimate based on ARM's claims

On a given process node, the Cortex A17 can occupy around 20% more area than a Cortex A9 or a marginal increase over a Cortex A12 design. Running the same workload, ARM expects the Cortex A17 to be 20% more energy efficient than the Cortex A9 (race to sleep), but I'd expect higher peak power consumption from the A17. The Cortex A17 name was deliberately chosen as ARM expects to be able to deliver similar performance to the Cortex A15 (in mobile apps/benchmarks, likely not in absolute performance), but in a much smaller area and at a lower power. I can't help but wonder if this is what the Cortex A15 should have been from the very beginning, at least for mobile applications.

ARM expects many early Cortex A17 designs to be built on a 28nm process, with an eventual shift over to 20nm once the cost of that process drops. ARM supplied an interesting slide showcasing the number of transistors $1 will buy you as a function of process node:

If you're a fabless semiconductor, it looks like 28nm will be the sweet spot for manufacturing for a little while.

Keep in mind that the target market for the Cortex A17, like the Cortex A12, is somewhere in between a device like the Moto G and the latest flagship Galaxy S device from Samsung. 

big.LITTLE Support

If you remember back to our analysis of the Cortex A12, the first version of the core didn't support ARM's big.LITTLE (lacking the requisite coherent interface) but a future version was promised with big.LITTLE support. The Cortex A17 is that future version. In a big.LITTLE configuration, the Cortex A17 will function as the "big" core(s) while the Cortex A7 will serve as the "LITTLE" core(s).

Rather than giving the Cortex A12 a new major revision number, ARM improved the design, added big.LITTLE support and called the finished product the Cortex A17. It's an interesting approach to dealing with the fact that ARM can rev/improve a single IP offering many times over the course of its life. In case it isn't already obvious, there won't be a big.LITTLE version of the Cortex A12.

ARM expects some overlap between Cortex A17 and Cortex A12. If a customer is looking to ship in 2014, Cortex A12 will be the only option for them in the mid-range from ARM. If a customer wants big.LITTLE or they are starting a design now, Cortex A17 is the obvious fit. I expect Cortex A17 will contribute to a relatively short lifespan for Cortex A12 in the grand scheme of things.

ARM sees some of the biggest opportunities in addressing the entry level and performance mainstream smartphone markets going forward. With the Cortex A17 aiming at the latter, ARM sees a potential market of around 450 million devices in 2015. The lack of 64-bit support makes ARM's mid-range lineup a little odd, especially considering the Cortex A53 and Cortex A57 will ensure both entry level and high-end smartphones will be 64-bit enabled. While I don't have an issue with a good mid-range device shipping without 64-bit support, I'm not sure how handset and tablet OEMs will feel. With Apple, Intel (and likely Qualcomm), embracing 64-bit-only strategies in mobile, I do wonder just how much success these A12/A17 architectures will have over the long run.

ARM tells me we should see the first devices using Cortex A17 CPU cores shipping in early 2015. Cortex A17 IP will be available to ARM customers for implementation by the end of this quarter.

Comments Locked

41 Comments

View All Comments

  • OreoCookie - Monday, February 17, 2014 - link

    I'm surprised how everybody is up in arms about the A17 not being 64 bit. First of all, ARM works with its licensees to see what they want ARM to build, and until Apple released the A7, nobody in the mobile ecosystem was seriously thinking of 64 bit as being a pressing need. On the other hand, they saw the A15 as an unpopular part compared to its competition, so they acted on it and designed a better, more energy efficient alternative. The A12 and A17 are significantly more powerful than the A53 -- performance is not determined by the 64 vs. 32 bit but IPC and clocks. Also, the A12 (and thus, also the A17 I presume) has PAE which means it can address more than 4 GB of RAM.

    Right now, iOS is the only mobile OS which runs 64 bit natively and Google has yet to make an announcement when they will be able to make the transition. And even if they make the transition, since Android apps run on top of a VM, it's not clear to me whether and how big the obstacles are here.

Log in

Don't have an account? Sign up now