Next-Gen iPhone & iPhone Nano Speculation

[anexanhume]

The 1.7GHz clock speed may be a holdover from the previous 31% faster rumour since that's a 31% higher clock than the 1.3GHz in the A6.

http://cannyvision.com/2013/09/12/the-most-forward-thinking-apple-yet.html

There's some thought that introducing 64-bit support now is less for smartphones than to prep for a true Apple TV/console which would need >4GB of RAM to be competitive with next-gen consoles and would help to have developers already familiar with 64-bit iOS to hit the ground running.

Seems more for laptop and other aspirations to me. I don't know that Apple necessarily wants in the console market as opposed to set top box.

With a 1.7 GHz clock, you need a 50% IPC improvement to get to your 2X claim if it's purely derived from that. Still seems a tall order. Though I should qualify that there could be one scenario that explicitly takes advantage of this arch that doesn't necessarily need a full 50% IPC improvement to be performing at that level. Their CPU comparisons aren't as "scientific" as their raw GPU GFLOPs comparison.


EDIT:

1.7 GHz clock rate seems "confirmed" by Mountain Sheep COO: http://mashable.com/2013/09/12/iphone-5s-gaming/

edit 2:

That author backed out of the 1.7 GHz claim.

The A7 chip is faster: 1.7GHz compared to the 1.3GHz A6. The A7 will most likely have a better memory bandwidth, and it will most likely be more energy efficient, which means you get more computing power for the same amount of power.

Seems odd he can quote clock rate but not memory bandwidth.

 

[Grall]

Actually that post seems more about criticizing the 64-bit CPU than whether the A7 has Rogue.

That was a strange rant. Complaining about battery life and whatnot is bizarre when iP5S has the same or slightly better battery life as its predecessor. How does the author explain that...?

 

[anexanhume]

Ok, so now Bajarin is claiming that Apple is doing some custom ISA extensions to ARMv8.

https://twitter.com/BenBajarin/status/378585813887356928

edit: This is via Patrick Moorhead. Ben says he's the one that explained it to him.

 

[french toast]

This article is suggesting a big-little like implementation, with custom takes on A57 and A53.
http://www.itproportal.com/2013/09/...7-two-cortex-a53-class-socs-rogue-20000-mips/

Seems like the auther is going off of guess work as I think that seems unlikely imo.

 

[Exophase]

Ben Bajarin claims that A7 is dual-core, not quad. I can't get him to elaborate why he's sure.

http://techpinions.com/the-apple-a7-a-is-for-ambition/22934

edit: He claims he has a source.

https://twitter.com/BenBajarin/status/378567815969525761

Another author outright claims A7 is 1.7 GHz but it being Rogue is just rumored. Super confused on that one.

https://medium.com/tech-talk/fb96c0d7fd4e

The entire crux of this article is that Apple is getting a massive performance boost from ARMv8, which is silly. Apparently this insanity was also found on AllThingsD, according to the comments:

“The fact that the A7 has twice as many processor registers means that more operations can occur without the processor using main memory, which is slower to access,” Carl Howe, VP of research and data sciences at the Yankee Group toldAllThingsD. “This means for that, for some codes, the A7 will be twice as fast (or faster, depending on how many memory accesses the original code had) to run code, because the processor doesn’t have to use main memory as much.”

This Bajarin guy goes on to list more nonsense in the comments too:

Things like more complex image recognition (again using desktop class libraries) of course there are many things in OpenGL that were not possible before in mobile that are now with 64-bit GPU

I guess Principal Analysts and VPs of Research and Data Science can say some pretty ignorant things.

 

[anexanhume]

This article is suggesting a big-little like implementation, with custom takes on A57 and A53.
http://www.itproportal.com/2013/09/...7-two-cortex-a53-class-socs-rogue-20000-mips/

Seems like the auther is going off of guess work as I think that seems unlikely imo.

That guy is out of his mind. 22nm process or finer? Whose process, exactly?

He doesn't substantiate his claim at all for big.LITTLE. As Exophase pointed out, granularity in DVFS is a much more likely approach to optimizing power consumption.

 

[Xmas]

Actually that post seems more about criticizing the 64-bit CPU than whether the A7 has Rogue.

Unfortunately it's poorly argued criticism. I wish more people would understand that it makes sense for the virtual address space to be larger than the physical address space, so the best time to go beyond 32b is before devices get 4+ GiB RAM. And if it's going to take years for apps to get recompiled and optimised...

 

[Turbotab]

Is the idea of Apple implementing a big.LITTLE config, based around customised Swift cores really that far fetched? 2 x A53 inspired cores wouldn't add much extra die area, and would help explain Apple's 2x perf claim. My question is there anything in iOS software stack that would prevent this, I've only seen HMP support mentioned alongside the Linux Kernel, and who wants big.LITTLE without HMP!

 

[Nebuchadnezzar]

Another author outright claims A7 is 1.7 GHz but it being Rogue is just rumored. Super confused on that one.

https://medium.com/tech-talk/fb96c0d7fd4e

There’s a reason why other companies like Samsung and HTC haven’t launched 64-bit enabled phones yet (Android doesn't support 64-bit so they couldn't but that’s not the only reason).

The guy doesn't know what the hell he's talking about.

 

[Helmore]

Unfortunately it's poorly argued criticism. I wish more people would understand that it makes sense for the virtual address space to be larger than the physical address space, so the best time to go beyond 32b is before devices get 4+ GiB RAM. And if it's going to take years for apps to get recompiled and optimised...

And I think it makes sense for Apple that if they can go with a 64-bit SoC right now, that it's smart to do so just from a future proofing standpoint. They will still be selling devices based on this A7 SoC 2 years from now and they might want to have a 64-bit iOS on all their iOS devices by then, just to provide a single OS on all their devices. It might also help them converge iOS and OS X a little easier if they're both 64-bit, though that seems like a weak argument.

 

[anexanhume]

Is the idea of Apple implementing a big.LITTLE config, based around customised Swift cores really that far fetched? 2 x A53 inspired cores wouldn't add much extra die area, and would help explain Apple's 2x perf claim. My question is there anything in iOS software stack that would prevent this, I've only seen HMP support mentioned alongside the Linux Kernel, and who wants big.LITTLE without HMP!

IMO, yes. big.LITTLE is only something people without full licenses are talking about. Qualcomm even has a whitepaper out on ASP saying big.LITTLE is inferior.


Going back to transistor density, Intel's 22nm has 1.4B transistors in 177mm^2. That's for a chip with 8MB L3 cache (384M). I still can't wrap my head around how Apple is getting the density their numbers suggest.

 

[Helmore]

IMO, yes. big.LITTLE is only something people without full licenses are talking about. Qualcomm even has a whitepaper out on ASP saying big.LITTLE is inferior.

Of course Qualcomm is going to claim that big.LITTLE is inferior. They have to compete against big.LITTLE solutions. That said, I'm not convinced of big.LITTLE's usefulness. I think Qualcomm's, Apple's and Intel's approach works just fine.

Going back to transistor density, Intel's 22nm has 1.4B transistors in 177mm^2. That's for a chip with 8MB L3 cache (384M). I still can't wrap my head around how Apple is getting the density their numbers suggest.

Then try wrapping your head around the kind of densities that NVIDIA and AMD are getting. Just look at Tahiti, GK104 or the X-Box One APU as examples. All have densities that get you quite a bit more than 1 billion transistors per 100 mm². Whether that's a valid comparison? I don't know. That for the experts to answer.

 

[anexanhume]

Xbox has about 2.1 billion transistors spent on SRAM alone, and GPUs are inherently dense and don't have mixed blocks like SoCs do.

 

[Lazy8s]

Not nearly as mixed, anyway. GPUs are starting to house quite a few distinct co-processors, though, with on-core accelerators for tasks like 2D and low-power composition, color space calculations, video functions on some, and a scheduler or multiprocessor delegator like the aforementioned Hydra which is a part of the SGX MP innovation that allowed them to scale vertex, not just fragment, workload across cores.

 

[ltcommander.data]

As an aside to the discussion of the A7/iPhone 5S, I'm guessing the A6 in the iPhone 5C is unchanged and Apple didn't shrink it to 28nm? They claim 3G talk time and 4G internet increased from 8 hr to 10 hr and a 25 hr increase in standby time. Other stats like audio/video playback and WiFi internet are unchanged. So the battery life improvements likely coming from changes in the cellular systems and the 5% bigger battery rather than the SoC. I suppose with the iPad Mini expected to go retina and likely to jump directly to a A6X variant and no iPod Touch refresh this year, likely jumping directly to the A7 when it's refreshed next year, it wasn't worthwhile to shrink the A6 to 28nm.

 

[anexanhume]

I'd guess it's a trade of component cost and need for battery life. iPads have gotten shrinks but not iPhones.

 

[Lazy8s]

As mentioned, with the A7's GPU identifying itself only under Apple branding to GfxBench, determining the underlying Rogue configuration will be more challenging. While I had been hoping Apple wouldn't continue optimizing so much for area on their iPhone line of SoCs and therefore use a G64xx, and while a low clocked G6430 seems a tempting configuration to consider, the few performance numbers we have so far are, as of now, leading me to believe it's a G62xx (I'll assume a 623x) at around 340 MHz.

Support for or evidence against that theory should come to light when the pixel fill rate numbers are revealed since the surprising consequence of that GPU configuration would be a lower fill than that of the iPhone 5...

 

[anexanhume]

As mentioned, with the A7's GPU identifying itself only under Apple branding to GfxBench, determining the underlying Rogue configuration will be more challenging. While I had been hoping Apple wouldn't continue optimizing so much for area on their iPhone line of SoCs and therefore use a G64xx, and while a low clocked G6430 seems a tempting configuration to consider, the few performance numbers we have so far are, as of now, leading me to believe it's a G62xx (I'll assume a 623x) at around 340 MHz.

Support for or evidence against that theory should come to light when the pixel fill rate numbers are revealed since the surprising consequence of that GPU configuration would be a lower fill than that of the iPhone 5...

Apple has always quoted the direct FLOPs multiplicative factor for GPUs when claiming x increases. Therefore I'm assuming 69.2 GF until otherwise counter-indicated.

 

[Turbotab]

Read an article on semiwiki, the author Daniel Nenni is positive that the A7 SoC is a Samsung 28nm Quad-core, confirmed by his foundry contacts. He must feel confident to issue such a claim, as there would be a lot of egg on his face, if it turned out to be 2c TSMC chip.

"The only reason why I know my iPhone 5 has a 32nm dual core SoC is because I work with the foundries, which is why I also know that the iPhone5s A7 SoC is a 28nm LP quad core SoC manufactured by Samsung. "

http://www.semiwiki.com/forum/content/2763-intel-bay-trail-fail.html

 

[Exophase]

Read an article on semiwiki, the author Daniel Nenni is positive that the A7 SoC is a Samsung 28nm Quad-core, confirmed by his foundry contacts. He must feel confident to issue such a claim, as there would be a lot of egg on his face, if it turned out to be 2c TSMC chip.

"The only reason why I know my iPhone 5 has a 32nm dual core SoC is because I work with the foundries, which is why I also know that the iPhone5s A7 SoC is a 28nm LP quad core SoC manufactured by Samsung. "

http://www.semiwiki.com/forum/content/2763-intel-bay-trail-fail.html

Well I don't know what this guy's overall credibility is but his stance against Bay Trail is ridiculous. Of course there are no phone wins using it, we've always known that Merrifield will be the phone platform and it's coming early next year. He thinks A7 somehow eclipses Bay Trail because it's 64-bit, never mind that Bay Trail is also supposed to be 64-bit. Then follows up all of his Apple SoC trumpeting with a claim that no one cares about SoC tech anyway.

No, I don't trust him when he says that it isn't made in TSMC when that'd invalidate the claims he made at the start of the year.. I don't care if he says he works with the foundries. You didn't have to "work with the foundries" to know A6 was a dual core on Samsung's 32nm process like he says. Everyone knows this. Given that he's also the guy who thinks that Apple is just taking a break from Samsung and will be looking for more business come 14nm while everyone else is declaring that Apple wants to get as far away from Samsung as possible (the most sane conclusion).. no, I don't trust him at all.