Today, Qualcomm is announcing the new Zeroth Platform, which is enabled by the Snapdragon 820 SoC.

While Qualcomm is avoiding any real disclosure of the SoC at this point, we do know that the Snapdragon 820 will be built on a FinFET process, which could be either TSMC’s 16nm or Samsung’s 14nm process. In addition to all of the improvements that the move to a new process brings, Qualcomm is finally introducing their custom ARMv8 CPU core, named Kryo. Unfortunately, there are no real details here either, but given that there’s only one architecture named it’s likely that Qualcomm is moving away from big.LITTLE with the Snapdragon 820.

The final detail regarding Snapdragon 820 is that it will begin sampling in the second half of 2015, which should mean that we can expect it to be in devices some time either at the end of 2015 or the beginning of 2016. Ultimately, the fact that Qualcomm has come up with a custom ARMv8 CPU architecture in such a short time continues to show just how quickly Qualcomm can respond to changing market conditions, something that we first saw with the Snapdragon 810.

Comments Locked

36 Comments

View All Comments

  • MikhailT - Monday, March 2, 2015 - link

    > Ultimately, the fact that Qualcomm has come up with a custom ARMv8 CPU architecture in such a short time continues to show just how quickly Qualcomm can respond to changing market conditions, something that we first saw with the Snapdragon 810.

    Short time in relative to what? Definitely not to 810, didn't they release 810 because they needed more time with Kryo?
  • JoshHo - Monday, March 2, 2015 - link

    To our knowledge, Qualcomm did not have an ARMv8 CPU core planned when Cyclone was first announced with the iPhone 5s.
  • MikhailT - Monday, March 2, 2015 - link

    1. ARMv8-A was announced around October 2011.
    2. Cyclone back in 2013 with A7 by Apple
    3. Samsung just announced 14nm ARMv8 CPU shipping in S6 next month.
    4. Qualcomm releases Kyro in late 2015/early 2016.

    What exactly is so impressive about Qualcomm's turnaround if they're 1-3 years behind everyone else and Samsung managed to get ahead of them?
  • Klug4Pres - Monday, March 2, 2015 - link

    Well, to be fair, Samsung are just using ARM's off-the-shelf core designs, which Qualcomm has also done with SD810. Qualcomm doesn't fab its own SoCs, so it can't guarantee to match Samsung's process technology.

    But I am not impressed by Qualcomm - it was blind-sided by the move to ARMv8, which is very embarrassing.
  • R3MF - Monday, March 2, 2015 - link

    that matters only if zeroth on arrival performs significantly faster than exynos7, and only then if samsung haven't already transitioned to a product sporting Arm A72 based cores...
  • TheJian - Monday, March 2, 2015 - link

    Denver isn't off the shelf and K1 has been with us for a while, and we'll be seeing it again this xmas in whatever follows X1. So qcom is what probably a year and a half behind Nexus 9 with 64bit CUSTOM denver cores right? And yes, I believe it was always on the map, the just didn't know others would beat them to the punch. So I don't think anything turned around quickly. Socs rev yearly and are on maps way before this (even if hidden internally). The Denver in the xmas chip may even be enhanced from the first rev (they had another year to upgrade some details).

    I'm not impressed by qcom and even less impressed by anandtech for talking up a total failure to recognize where the market was going and this is at least the 2nd time they've acted like qcom is a nimble company here. Denver will be in (nexus 9) and out (X1) and back in devices (xmas 14nm from samsung will have Denver or denver2 or whatever they call it) before we see an 820 device...LOL.

    Levizx, you etc are all correct. NV just did a stopgap themselves for time to market with X1 going off the shelf for 20nm. They didn't push anything up, this is qcom's schedule for years. Are they going to add a comment saying nvidia is super nimple and quick to react too? LOL.

    When Jen stepped out to announce T3, he said they were simultaneously working on T4/5/6. I'd be shocked if a company with 10x earnings (qcom 6B income 1.5x NV's total revenue...LOL) doesn't do the same thing or even more at once.
  • Ryan Smith - Monday, March 2, 2015 - link

    Note that Denver has been in development since 2011 (and possibly even earlier). Whereas indications are that Kyro wasn't a full project until after the iPhone 5s was introduced in September of 2013.

    Which would be as much credit to QC on getting something ready in such a short period of time as it is the realization that they were behind the curve on CPU development in 2013 and were unprepared for Cyclone. Just because you can pull off a crash course program doesn't mean it's a good thing...
  • sonicmerlin - Monday, March 2, 2015 - link

    I think Apple's move to ARMv8 was a little premature. 64 bit apps use up 30% more RAM, which is still at a premium with iDevices. I would personally prefer my Air 2 was using a 32 bit processor if it could free up more RAM. I doubt I would notice the slight performance drop with the 32 bit CPU.
  • name99 - Monday, March 2, 2015 - link

    The sooner you move to 64-bit, the sooner you can drop 32-bit, which means simpler SW and HW development. It wouldn't surprise me if Apple are shipping a 64-bit ONLY core before the rest of the ARM ecosystem has fully switched over to 64-bit. The advantage of such a core is not that the 32-bit decoder is expensive, but that being forced to support 32-bit code paths constrains how you can design the rest of the CPU (eg you probably have to have a permanent shift stage stuck in the integer pipeline, and you need to play weird games with the registers to support all the v7 interrupt modes); and the 32-bit legacy is a whole lot verification for not much value.

    Likewise in the OS/frameworks.
  • MikhailT - Monday, March 2, 2015 - link

    It really depends on what you need more memory for.

    If you're asking for more memory on Air 2 that has 2GB of memory, it's not the 64-bit CPU that's the fault. You're using an app that is leaking memory badly and iOS 7/8 itself isn't optimized that well. Safari is the worst of them all, it'd eat up a lot of memory, regardless of 32-bit/64-bit.

    Majority of the apps on the app market does not use more than 100-300mb of memory, even as a 64-bit app. Also, the 64-bit app does not eat up 30% more by default, it varies depending on the app itself.

    In addition, 64-bit apps are actually finishing tasks much faster than a 32-bit CPU would, that's a fact because of the other improvements based on the ARMv8 improvements not related to the 64-bit.

Log in

Don't have an account? Sign up now