Apple's Cyclone Microarchitecture Detailedby Anand Lal Shimpi on March 31, 2014 2:10 AM EST
The most challenging part of last year's iPhone 5s review was piecing together details about Apple's A7 without any internal Apple assistance. I had less than a week to turn the review around and limited access to tools (much less time to develop them on my own) to figure out what Apple had done to double CPU performance without scaling frequency. The end result was an (incorrect) assumption that Apple had simply evolved its first ARMv7 architecture (codename: Swift). Based on the limited information I had at the time I assumed Apple simply addressed some low hanging fruit (e.g. memory access latency) in building Cyclone, its first 64-bit ARMv8 core. By the time the iPad Air review rolled around, I had more knowledge of what was underneath the hood:
As far as I can tell, peak issue width of Cyclone is 6 instructions. That’s at least 2x the width of Swift and Krait, and at best more than 3x the width depending on instruction mix. Limitations on co-issuing FP and integer math have also been lifted as you can run up to four integer adds and two FP adds in parallel. You can also perform up to two loads or stores per clock.
With Swift, I had the luxury of Apple committing LLVM changes that not only gave me the code name but also confirmed the size of the machine (3-wide OoO core, 2 ALUs, 1 load/store unit). With Cyclone however, Apple held off on any public commits. Figuring out the codename and its architecture required a lot of digging.
Last week, the same reader who pointed me at the Swift details let me know that Apple revealed Cyclone microarchitectural details in LLVM commits made a few days ago (thanks again R!). Although I empirically verified many of Cyclone's features in advance of the iPad Air review last year, today we have some more concrete information on what Apple's first 64-bit ARMv8 architecture looks like.
Note that everything below is based on Apple's LLVM commits (and confirmed by my own testing where possible).
|Apple Custom CPU Core Comparison|
|Apple A6||Apple A7|
|ARM ISA||ARMv7-A (32-bit)||ARMv8-A (32/64-bit)|
|Issue Width||3 micro-ops||6 micro-ops|
|Reorder Buffer Size||45 micro-ops||192 micro-ops|
|Branch Mispredict Penalty||14 cycles||16 cycles (14 - 19)|
|Load Latency||3 cycles||4 cycles|
|Indirect Branch Units||0||1|
|L1 Cache||32KB I$ + 32KB D$||64KB I$ + 64KB D$|
As I mentioned in the iPad Air review, Cyclone is a wide machine. It can decode, issue, execute and retire up to 6 instructions/micro-ops per clock. I verified this during my iPad Air review by executing four integer adds and two FP adds in parallel. The same test on Swift actually yields fewer than 3 concurrent operations, likely because of an inability to issue to all integer and FP pipes in parallel. Similar limits exist with Krait.
I also noted an increase in overall machine size in my initial tinkering with Cyclone. Apple's LLVM commits indicate a massive 192 entry reorder buffer (coincidentally the same size as Haswell's ROB). Mispredict penalty goes up slightly compared to Swift, but Apple does present a range of values (14 - 19 cycles). This also happens to be the same range as Sandy Bridge and later Intel Core architectures (including Haswell). Given how much larger Cyclone is, a doubling of L1 cache sizes makes a lot of sense.
On the execution side Cyclone doubles the number of integer ALUs, load/store units and branch units. Cyclone also adds a unit for indirect branches and at least one more FP pipe. Cyclone can sustain three FP operations in parallel (including 3 FP/NEON adds). The third FP/NEON pipe is used for div and sqrt operations, the machine can only execute two FP/NEON muls in parallel.
I also found references to buffer sizes for each unit, which I'm assuming are the number of micro-ops that feed each unit. I don't believe Cyclone has a unified scheduler ahead of all of its execution units and instead has statically partitioned buffers in front of each port. I've put all of this information into the crude diagram below:
Unfortunately I don't have enough data on Swift to really produce a decent comparison image. With six decoders and nine ports to execution units, Cyclone is big. As I mentioned before, it's bigger than anything else that goes in a phone. Apple didn't build a Krait/Silvermont competitor, it built something much closer to Intel's big cores. At the launch of the iPhone 5s, Apple referred to the A7 as being "desktop class" - it turns out that wasn't an exaggeration.
Cyclone is a bold move by Apple, but not one that is without its challenges. I still find that there are almost no applications on iOS that really take advantage of the CPU power underneath the hood. More than anything Apple needs first party software that really demonstrates what's possible. The challenge is that at full tilt a pair of Cyclone cores can consume quite a bit of power. So for now, Cyclone's performance is really used to exploit race to sleep and get the device into a low power state as quickly as possible. The other problem I see is that although Cyclone is incredibly forward looking, it launched in devices with only 1GB of RAM. It's very likely that you'll run into memory limits before you hit CPU performance limits if you plan on keeping your device for a long time.
It wasn't until I wrote this piece that Apple's codenames started to make sense. Swift was quick, but Cyclone really does stir everything up. The earlier than expected introduction of a consumer 64-bit ARMv8 SoC caught pretty much everyone off guard (e.g. Qualcomm's shift to vanilla ARM cores for more of its product stack).
The real question is where does Apple go from here? By now we know to expect an "A8" branded Apple SoC in the iPhone 6 and iPad Air successors later this year. There's little benefit in going substantially wider than Cyclone, but there's still a ton of room to improve performance. One obvious example would be through frequency scaling. Cyclone is clocked very conservatively (1.3GHz in the 5s/iPad mini with Retina Display and 1.4GHz in the iPad Air), assuming Apple moves to a 20nm process later this year it should be possible to get some performance by increasing clock speed scaling without a power penalty. I suspect Apple has more tricks up its sleeve than that however. Swift and Cyclone were two tocks in a row by Intel's definition, a third in 3 years would be unusual but not impossible (Intel sort of committed to doing the same with Saltwell/Silvermont/Airmont in 2012 - 2014).
Looking at Cyclone makes one thing very clear: the rest of the players in the ultra mobile CPU space didn't aim high enough. I wonder what happens next round.
Post Your CommentPlease log in or sign up to comment.
View All Comments
toyotabedzrock - Tuesday, April 1, 2014 - linkThey should but their sales are too high to care. And remember they tend to use Qualcomm in the US.
Apple's next move might be their own modem ip. They seem to be able to put out better designs than Arm does for the actual chip design.
blanarahul - Monday, March 31, 2014 - linkIf I were Intel, I would be very scared. By 2016-2017 Apple will easily catch up to Haswell. And by 2020 Apple and hopefully ARM will match Intel's architecture. The only advantage Intel's left with are their fabs.
madmilk - Monday, March 31, 2014 - linkARM's advantages over x86 decrease as core sizes increase. Simpler decoders don't help much when each core is over 200 million transistors. Meanwhile Intel's fab advantage is growing, so if all other things are equal, Intel will have a sizable lead in performance and power. Plus, who will port all of the Wintel software to ARM?
Intel will not die before the desktop and laptop PCs die, and I don't see that happening in the next decade.
blanarahul - Monday, March 31, 2014 - linkIntel's can advantage is growing every year. This means that others like Apple will have to compensate in architecture. I am pretty sure ARM/Apple will find a way around the problem you are pointing out. (I am very bad at understanding architectures)
blanarahul - Monday, March 31, 2014 - linkIntel's fab advantage. F**king auto correct.
Mondozai - Monday, March 31, 2014 - linkThis once again proves that we need an edit function at minimum.
iwod - Monday, March 31, 2014 - linkIntel's Fab Advantage is in fact *Shrinking* every year. If we talk about Mobile SoC Intel will have its 14nm SoC early 2015. While TSMC will have its 16nm in 2nd half of 2015. SoC Design and Tools matters a lot in Power Usage.
Desktop and Laptop Wont die. It will continue to ship, but at a much slower pace because people are not upgrading as much. Gaming has now moved into console and mobile space. Most part of the PC upgrade cycle are now in 3 - 5 years. So basically Intel has to figure out its Fab utilization.
And No, there is no need to Port to ARM, because at this rate we will likely have more Software on ARM then they are on x86.
ssj3gohan - Monday, March 31, 2014 - linkIn fact, the 'fab advantage' is woefully underdescribed by just transistor packing density. Not in the least because TSMC and Intel both use different metrics for their nanometer-numbers. Depending on who you ask and what you are doing the differences are larger or smaller. If anything, the intel fab advantage has nothing to do with the chip scale and more with the fact that intel has a toolchain that is perfectly matched to their process.
And designing for low power, high performance or some mix between the two is also a function of synergy between toolchains and processes. They use exactly the same silicon ingots, ASML machines and metallization for HPm and LP processes, it's just a different set of design rules and some (surprisingly small) process tweaks. But with dramatically different outcomes in attainable performance and (leakage) power.
name99 - Monday, March 31, 2014 - linkIntel has an awesome process, yes. But you make some unwarranted assumptions.
Basically: is Intel a fab company that designs CPUs? Or CPU company that owns fabs?
Because Intel's current business model is in trouble.
Designing an x86 is VASTLY more expensive and slower than designing a kick-ass ARM CPU (AMD'd CEO has given us numbers that confirm this intuitively obvious fact). To compete, Intel has to innovate at the pace of ARM, while charging ARM prices. It can do one or the other, but not both simultaneously. Right now they can charge enough for high end Xeons and mid-range Haswells to keep the system going, but every year they have to extract money by squeezing the high end a little harder --- there is no give at the low end. We all know where this game ends (MIPS, SPARC, SGI, Apollo, Alpha, ...).
Which means that at some point Intel has to ask what is their REAL core competence? If they're better at fab than at designing processes matched to the modern world, then they're be better off selling the fab expertise than the CPU design expertise.
Which is all a way of saying that, just because Apple (or almost anyone else) can't buy time in Intel's top of the line fab today, doesn't mean that will still be the case in five years.
WaltFrench - Monday, March 31, 2014 - linkThis is the second savvy and market-aware comment of yours that I've noted. Nice if you could come out from behind the AC screenname and/or point us to a blog that you “follow closely.”