ARM told us to expect some of the first 64-bit ARMv8 based SoCs to ship in 2014, and it looks like we're seeing just that. Today Qualcomm is officially announcing its first 64-bit SoC: the Snapdragon 410 (MSM8916). 

Given that there's no 64-bit Android available at this point, most of the pressure to go to 64-bit in the Android space is actually being driven by the OEMs who view 64-bit support as a necessary checkbox feature at this point thanks to Apple's move with the A7. Combine that with the fact that the most ready 64-bit IP from ARM is the Cortex A53 (successor to the Cortex A5/A7 line), and all of the sudden it makes sense why Qualcomm's first 64-bit mobile SoC is aimed at the mainstream market (Snapdragon 400 instead of 600/800).

I'll get to explaining ARM's Cortex A53 in a moment, but first let's look at the specs of the SoC:

Qualcomm Snapdragon 410
Internal Model Number MSM8916
Manufacturing Process 28nm LP
CPU 4 x ARM Cortex A53 1.2GHz+
GPU Qualcomm Adreno 306
Memory Interface 1 x 64-bit LPDDR2/3
Integrated Modem 9x25 core, LTE Category 4, DC-HSPA+

At a high level we're talking about four ARM Cortex A53 cores, likely running around 1.2 - 1.4GHz. Having four cores still seems like a requirement for OEMs in many emerging markets unfortunately, although I'd personally much rather see two higher clocked A53s. Qualcomm said the following about 64-bit in its 410 press-release:

"The Snapdragon 410 chipset will also be the first of many 64-bit capable processors as Qualcomm Technologies helps lead the transition of the mobile ecosystem to 64-bit processing.”

Keep in mind that Qualcomm presently uses a mix of ARM and custom developed cores in its lineup. The Snapdragon 400 line already includes ARM (Cortex A7) and Krait based designs, so the move to Cortex A53 in the Snapdragon 410 isn't unprecedented. It will be very interesting to see what happens in the higher-end SKUs. I don't assume that Qualcomm will want to have a split between 32 and 64-bit designs, which means we'll either see a 64-bit Krait successor this year or we'll see more designs that leverage ARM IP in the interim. 

As you'll see from my notes below however, ARM's Cortex A53 looks like a really good choice for Qualcomm. It's an extremely power efficient design that should be significantly faster than the Cortex A5/A7s we've seen Qualcomm use in this class of SoC in the past.

The Cortex A53 CPU cores are paired with an Adreno 306 GPU, a variant of the Adreno 305 used in Snapdragon 400 based SoCs (MSM8x28/8x26).

The Snapdragon 410 also features an updated ISP compared to previous 400 offerings, adding support for up to a 13MP primary camera (no word on max throughput however).

Snapdragon 410 also integrates a Qualcomm 9x25 based LTE modem block (also included in the Snapdragon 800/MSM8974), featuring support for LTE Category 4, DC-HSPA+ and the usual legacy 3G air interfaces.

All of these IP blocks sit behind a single-channel 64-bit LPDDR2/3 memory interface.

The SoC is built on a 28nm LP process and will be sampling in the first half of 2014, with devices shipping in the second half of 2014. Given its relatively aggressive schedule, the Snapdragon 410 may be one of the first (if not the first) Cortex A53 based SoCs in the market. 

A Brief Look at ARM's Cortex A53

ARM's Cortex A53 is a dual-issue in-order design, similar to the Cortex A7. Although the machine width is unchanged, the A53 is far more flexible in how instructions can be co-issued compared to the Cortex A7 (e.g. branch, data processing, load-store, & FP/NEON all dual-issue from both decode paths). 

The A53 is fully ISA compatible with the upcoming Cortex A57, making A53 the first ARMv8 LITTLE processor (for use in big.LITTLE) configurations with an A57

The overall pipeline depth hasn't changed compared to the Cortex A7. We're still dealing with an 8-stage pipeline (3-stage fetch pipeline + 5 stage decode/execute for integer or 7 for NEON/FP). The vast majority of instructions will execute in one cycle, leaving branch prediction as a big lever for increasing performance. ARM significantly increased branch prediction accuracy with the Cortex A53, so much that it was actually leveraged in the dual-issue, out-of-order Cortex A12. ARM also improved the back end a bit, improving datapath throughput. 

The result of all of this is a dual-issue design that's pushed pretty much as far as you can without going out-of-order. Below are some core-level performance numbers, all taken in AArch32 mode, comparing the Cortex A53 to its A5/A7 competitors:

Core Level Performance Comparison
All cores running at 1.2GHz DMIPS CoreMark SPECint2000
ARM Cortex A5 1920 - 350
ARM Cortex A7 2280 3840 420
ARM Cortex A9 r4p1 - - 468
ARM Cortex A53 2760 4440 600

Even ignoring any uplift from new instructions or 64-bit, the Cortex A53 is going to be substantially faster than its predecessors. I threw in hypothetical SPECint2000 numbers for a 1.2GHz Cortex A9 to put A53's performance in even better perspective. You should expect to see better performance than a Cortex A9r4 at the same frequencies, but the A9r4 is expected to hit much higher frequencies (e.g. 2.3GHz for Cortex A9 r4p1 in NVIDIA's Tegra 4i). 

ARM included a number of power efficiency improvements and is targeting 130mW single-core power consumption at 28nm HPM (running SPECint 2000). I'd expect slightly higher power consumption at 28nm LP but we're still talking about an extremely low power design.

I'm really excited to see what ARM's Cortex A53 can do. It's a potent little architecture, one that I wish we'd see taken to higher clock speeds and maybe even used in higher end devices at the same time. The most obvious fit for these cores however is something like the Moto G, which presently uses the 32-bit Cortex A7. Given Qualcomm's schedule, I wouldn't be surprised to see something like a Moto G update late next year with a Snapdragon 410 inside. Adding LTE and four Cortex A53s would really make that the value smartphone to beat.

Comments Locked

95 Comments

View All Comments

  • psychobriggsy - Tuesday, December 10, 2013 - link

    In terms of the iPhone 5S, the 64-bit ARM cores actually are a step up in performance, due to operating system optimisations for the hardware, as well as instruction set changes that improve performance, and larger/more registers (the obvious 64-bit benefit). I believe there was an article on Ars explaining the operating system enhancements that allow iOS7 to take advantage of the 64-bit architecture more than a straight 64-bit port of an OS normally would.
  • Ronald Maas - Wednesday, December 18, 2013 - link

    A couple of months ago there was an interesting discussion on realworldtech.com about the benefits of 64-bit. Linus Torvalds (if I remember correctly) mentioned that 64-bit was already beneficial when physical memory exceeds 896 MB. Reason was that above 896 MB, it is not possible to address all physical memory from 32-bit kernel virtual memory space (which is limited to 1 GB). At that point managing memory becomes significantly less efficient because of the need to frequently remap virtual memory space to different chunks of physical memory.
    Unfortunately was not able to locate the thread anymore.
  • MadMan007 - Monday, December 9, 2013 - link

    Anand, if you would truly "personally much rather see two higher clocked A53s", and if that applies to quad core versus dual core in general, you should start using your influence through this site and with direct industry connections to put that out there. I don't recall reading anything significant talking down quad cores versus dual cores in your articles when it may have been applicable (not Apple because they don't have a quad core anyway), and if it was even mentioned it was so minor that it was easy to overlook.
  • Anand Lal Shimpi - Monday, December 9, 2013 - link

    I've been doing this for the past year (in fact I literally just did this last week). I am going to start campaigning for this more aggressively though. It'll take a while before we see any impact given how long it takes to see these things come to fruition though.

    Take care,
    Anand
  • extide - Monday, December 9, 2013 - link

    Why not campaign for better dynamic clock control/turbo/etc. To me, that seems like the best solution going forward. For example, back in the day of the Core 2 Duo vs Core 2 Quad, you had to make the compromise, max clock (Dual) or Max Multi Thread Perf (Quad). Nowadays with turbo mode and whatnot you can essentially have the best of both worlds. A quadcore chip that shuts down 2 cores and can run as a fast dualcore if needed.

    For a lot of reasons I think it will be very difficult convincing people, oems, etc that moving from 4 cores to 2 cores is a good thing, and in some ways it really IS moving backwards. (You are still making that same compromise)
  • Anand Lal Shimpi - Monday, December 9, 2013 - link

    Also another part of what I (and a few others) have been campaigning for over the past year as well. Power management and opportunistic turbo is still largely a mess in mobile. Thankfully there are improvements coming along this vector.
  • FwFred - Monday, December 9, 2013 - link

    Extending the A53 pipeline length to go higher frequencies would seem to go against the big.LITTLE scheme. ARM probably gets non-trivial benefits by keeping the pipeline on the short side.

    I'd like to know if A57 is going to allow sustained usage in <=5" phones without having to kick over to the A53. Perhaps only for 1-2 thread usages?
  • Wilco1 - Monday, December 9, 2013 - link

    Agreed, a longer pipeline will reduce power efficiency considerably, making it less suitable for big.LITTLE. However further frequency gains are likely, the ARM website says 2GHz is expected (no mention of process, so I guess on 16nm in 2015).

    We already have 1.8GHz quad-core A15 phones today. ARM claims that A57 is actually more power efficient, so I don't see why there would be an issue with using A57 in a phone besides the fact that 64-bit seems a bit unnecessary. The 20nm process will be used next year as well, improving power and performance further.
  • Wilco1 - Monday, December 9, 2013 - link

    Dual vs quad is a lost cause already, especially since we're moving towards 8 cores (4+4 in big.LITTLE). The die-size cost is low enough that the performance gain in the cases where you can use all CPUs is worth it.
  • psychobriggsy - Tuesday, December 10, 2013 - link

    Very true, I don't know the die size of a 28nm A53 core (and the L2 cache it will need), but on a modern ~60mm^2 "economy SoC" there's probably not much difference between two and four cores (<5 mm^2).

Log in

Don't have an account? Sign up now