Become a MacRumors Supporter for $25/year with no ads, private forums, and more!

What to expect from the iPhone 6, Apple's A8, and beyond


macrumors 603
Original poster
Oct 29, 2007
The History of Apple SoCs
To know where we're going, we need to know where we came from. Prior to the A4, Apple sourced Samsung SoCs for the iPhone, iPhone 3G and iPhone 3GS. Let's take a look at Apple's custom SoCs.

  • Manufacturer - Samsung on 45nm process (as featured in iPhone 4)
  • Die Size - 53 mm2 [5]
  • Designer - Apple (Intrinsity[3], also featured in Samsung's 'Hummingbird' SoC[4])
  • CPU Type - 800MHz Cortex-A8 Core with Intrinsity customizations
  • Core Count - 1
  • Instruction Set - ARMv7
  • Chip Designator - S5L8930X
  • L1 Cache - 32/32KB (Instruction/Data)
  • L2 Cache - 512KB
  • RAM - 512MB LPDDR @ 400 MHz (as seen in iPhone 4, 64 bit interface, PoP)
  • Max Theoretical Memory Bandwidth - 3.2 GB/s [1]
  • GPU Type - Dual Core PowerVR SGX 535 @ 200 MHz
  • GPU Performance - 1.6 GFlops, 14 MTriangles/s [2]

  • Manufacturer - Samsung on 45nm process (as featured in iPhone 4S)
  • Die Size - 122.2 mm2
  • Designer - Apple
  • CPU Type - 800MHz Cortex-A9 Core with customizations
  • Core Count - 2
  • Chip Designator - S5L8940X
  • L1 Cache - 32/32KB (Instruction/Data)
  • L2 Cache - 1MB
  • RAM - 512MB LPDDR2 @ 800 MHz (64 bit interface, PoP)
  • Max Theoretical Memory Bandwidth - 6.4 GB/s [1]
  • GPU Type - Dual Core PowerVR SGX 543 @ 200 MHz
  • GPU Performance - 14.4 GFlops, 70 MTriangles/s [2]

  • Manufacturer - Samsung on 45nm process (as featured in 3rd generation iPad)
  • Die Size - 165 mm2
  • Designer - Apple
  • CPU Type - 1GHz Cortex-A9 Core with customizations
  • Core Count - 2
  • Instruction Set - ARMv7
  • Chip Designator - S5L8945X
  • L1 Cache - 32/32KB (Instruction/Data)
  • L2 Cache - 1MB
  • RAM - 512GB LPDDR2 @ 800 MHz (128 bit interface, off package)
  • Max Theoretical Memory Bandwidth - 12.8 GB/s [1]
  • GPU Type - Quad Core PowerVR SGX 543 @ 250 MHz
  • GPU Performance - 36 GFlops, 175 MTriangles/s [2]

  • Manufacturer - Samsung on HKMG 32nm process
  • Die Size - 96.71 mm2
  • Designer - Apple
  • CPU Type - 1.3GHz "Swift" Core
  • Core Count - 2
  • Instruction Set - ARMv7s
  • Chip Designator - S5L8950X
  • L1 Cache - 32/32KB (Instruction/Data)
  • L2 Cache - 1MB
  • RAM - 1GB LPDDR2 @ 1066 MHz (64 bit interface, PoP)
  • Max Theoretical Memory Bandwidth - 8.5 GB/s [1]
  • GPU Type - Triple Core PowerVR SGX 543 @ 333 MHz
  • GPU Performance - 36 GFlops, 175 MTriangles/s [2]

  • Manufacturer - Samsung on HKMG 32nm process
  • Die Size - 123 mm2
  • Designer - Apple
  • CPU Type - 1.4GHz "Swift" Core
  • Core Count - 2
  • Instruction Set - ARMv7s
  • Chip Designator - S5L8955X
  • L1 Cache - 32/32KB (Instruction/Data)
  • L2 Cache - 1MB
  • RAM - 1GB LPDDR2 @ 1066 MHz (128 bit interface, off package)
  • Max Theoretical Memory Bandwidth - 17 GB/s [1]
  • GPU Type - Quad Core PowerVR SGX 554 @ 280 MHz
  • GPU Performance - 71.7 GFlops, 210 MTriangles/s [2]

  • Manufacturer - Samsung on HKMG 28nm process
  • Die Size - 102 mm2
  • Transistors - Approximately 1 billion
  • Designer - Apple
  • CPU Type - 1.3GHz "Cyclone" 64-bit Core (1.4GHz for iPad products)
  • Core Count - 2
  • Instruction Set - ARMv8-A (with custom Apple extensions)
  • Chip Designator - S5L8960X
  • L1 Cache - 64/64KB (Instruction/Data)
  • L2 Cache - 1MB
  • L3 Cache - 4MB
  • RAM - 1GB LPDDR3 @ 1600 MHz (64 bit interface, PoP for iPhone)[13][14]
  • Max Theoretical Memory Bandwidth - 12.8 GB/s
  • GPU Type - "Quad Cluster" PowerVR 6430 @ 450 MHz[15]
  • GPU Performance - 115.2/172.8 GFlops (FP32/FP16)
Apple A-series family tree:

Functional block size allocation on die:

A8 Prediction
  • Manufacturer - TSMC on HKMG 20nm process
  • Die Size - 100-120 mm2
  • Designer - Apple
  • CPU Type - 1.5GHz Third Generation Custom Apple Core
  • Core Count - 2
  • Instruction Set - ARMv8-A (with custom Apple extensions)
  • Chip Designator - S5L8970X
  • L1 Cache - 64/64KB
  • L2 Cache - 1MB
  • L3 Cache - 4MB
  • RAM - 2GB LPDDR3 @ 1600 MHz (64 bit interface, PoP for iPhone)
  • Max Theoretical Memory Bandwidth - 12.8 GB/s
  • GPU Type - "Hex Cluster" PowerVR GX6650 @ 450 MHz
  • GPU Performance - 172.8/354.6 GFlops (FP32/FP16)
The purpose of this piece is to preview and predict the features of the iPhone 6 (and related iPads). If you have not read MacRumors rumor roundup, please go do so before reading this.

A Look Back to Last Year
First of all, I should state this is not my first time doing this. I did an A7 prediction thread last year, which you can find linked in the more reading section. The prediction proved to be almost exactly on for the GPU, just narrowly missing on operating frequency but getting the configuration correct. It also correctly predicted the foundry and process, though that was not hard with the strength of the rumors suggesting Samsung's 28nm process. It also predicted the RAM type (LPDDR3) and size (1GB), but missed on frequency (1333 vs. 1600 MHz).

The post also accurately predicted the cellular radio and transceiver, though that prediction was largely piggy-backed on the work of Brian Klug from Anandtech. The WiFi chip was predicted to not change, and it did not. This came down to predicting whether Apple would adopt the AC standard with the new iPhone, which I predicted it would not due to their history of not adopting the latest in WiFi standards in their iOS devices.

The display was correctly predicted to not change based on the fact that Apple has never changed the display in successive phone generations (this is also true of form factor). I downplayed the idea of a phone with 128GB NAND storage, despite its technical possibility, because of what I perceived to be a combination of challenges involving number of SKUs, product ceiling, and market demand/tolerance of certain storage sizes. I also predicted a battery chemistry change prior to the release of the iPhone 5, which carried over to the 5S.

Where the prediction was wildly off the mark was the CPU. I had followed suit with Anandtech and Ars Technica in assuming that the CPU would be some modified version of Apple's custom core in the A6 SoC, codenamed "Swift." There were quite a few factors in that prediction. First, Swift was a fully custom core, which is very expensive, time-consuming, and rare in today's IC world. Many companies rely on automatic "place and route" tools that synthesize their logic into a layout automatically. By feeding the tools the constraints that will help them meet their target operating frequency, they can have the elements automatically placed much faster than a designer could hand-place them. This is at the expense of optimizing die area, speed, and power usage. Many other mobile SoC designers are able to rely on ARM's reference designs for their CPU cores as well, using the design as-is and tailoring other components around it. The only other prominent names for the consumer space that do custom designs is a short list: Intel, AMD, Qualcomm. Nvidia joins that list with their project Denver, which is a curious case that will be discussed later.

Swift being a custom design meant that the time to design it was lengthened, likely a process that took over the one year cadence that the iPhone design release cycle demanded. This made it likely that they would iterate on this design in small but meaningful ways given what I expected to be their limited manpower. For Swift's successor to be custom as well would likely mean that both designs were in active work simultaneously, necessitating a sizable work force. Finally, it had not been that long since ARM had announced the ARMv8-A ISA and A57 reference design. ARM made the first disclosure of its 64 bit architecture in October of 2011. It was a full year later before they announced their high-end 64 bit reference design, the A57. That meant that Apple had less than a year after the reference design was announced to get their own custom solution to market. Previously, the quickest time to market had been the previous generation, where Cortex A15 designs took about 2 years from the September 2010 licensing availability date to get their own designs out, and that was a comparatively simple iteration on an established ARMv7 ISA. It seems extremely likely that Apple began the design of the Cyclone clone shortly following ARM's disclosure of the ARMv8-A ISA, and they likely had an architecture concept even before then.

It is easy to see the factors working against a custom 64 bit CPU core designed by Apple, despite the rumors, but that is exactly what they did. At the time of this post, there is still no competing mobile device available on the market with a ARMv8-A compatible CPU core. This looks to likely be the case into 2015. Qualcomm, who is rushing their own design, is basing the Snapdragon 808 and 810 on the A57 reference design rather than doing a custom solution, as they have done with the rest of the Snapdragon series. The technically-inclined blogosphere was stunned by this announcement, and an unnamed Qualcomm employee called it a punch to the gut.

This is all in addition to the design providing yet another 2x benchmark improvement, boasting a very wide execution core, and having an impressive transistor density that was approximately double its Swift predecessor. It is truly an impressive undertaking and the chief reason I will never underestimate Apple again when it comes to aggressive time-to-market strategies.

The next biggest miss was the prediction of two distinct SoCs - one for the iPhone, iPad mini and iPod touch line of devices and one for the full-sized iPad line. This was based on the existence of the A5X and A6X SoCs which featured GPUs approximately double in performance to that of their non-"X" designated siblings. They also featured memory interfaces that were double in size, necessary to feed the larger GPUs, and large display resolution of the full-sized iPads. Instead, Apple went with the single A7 SoC offering and a GPU that actually performed below its predecessors in some benchmarks. They did manage to compensate for the memory bus width decrease by moving to much faster 1600 MHz LPDDR3 RAM, however. It seems apparent that Apple is now satisfied with memory bandwidth and GPU performance of the standard iPhone-level SoCs for iPad use and will go with a single SoC strategy moving forward where it only differentiates on the clock speeds and packaging. Packaging may need to be unified such that the RAM is no longer off package as seen in the full-sized iPads in the future, however, as is discussed a bit later.

What I feel the takeaway should be from this is that despite Apple's secretive nature regarding product roadmap, it is possible to predict the components used in their future devices simply based on analyzing their product history. By noting their revision cycle, tendencies on adopting new protocols, current or near-term technology advancement and availability, and their reactiveness to the market (or lack thereof), we can get a somewhat accurate glimpse of where their products may be headed.

These predictions are based on a mixture of supply chain rumors, historical cadence in Apple's SoC offerings and inference based on what parts are available on the market that would make sense for Apple's likely goals.

Comments on Cyclone
Before we begin this year's CPU core prediction, let's try to understand what type of evolution that Cyclone was to Swift. Last year, I predicted an evolution of Swift for the CPU core, with things like L2 pre-fetch and better branch prediction evolving the Swift core. I compared Swift to Qualcomm's Krait architecture because of their similarities in clock speeds and pipeline depths. In that context, I suggested that improvements that been made to the Krait architecture would find their way into the Apple design as well. Krait's pre-fetchers are quite a bit better than the standard ARM ones, making that one area I suggested Apple could perhaps be making improvements.

Cyclone turned out to be a major change from Swift. Shown below is a table from Anandtech's detailing of the Cyclone architecture and comparing it with Swift. Since Apple does not publicly disclose architecture details, the information has to be gleaned from LLVM commits. That microarchitecture piece contains more than is discussed here, and is highly recommended reading.


Other than the ISA change, the first thing that jumps out about the change is that Apple doubled the issue width. This means that the Cyclone core can dispatch twice as many instructions as Swift at a time. With their identical clock frequencies, it's easy to see where their claimed 2x speedup came from. It also highlights the reason that they didn't go quad-core. Going with a wider core gives you more execution power without the overhead of adding circuitry for an independent core capable of running separate threads. However, the issue with dispatching so many instructions at once is data dependencies. If one instruction depends on the outcome of another, that instruction will stall until its required data is ready, slowing the processor down. That leads us to the re-order buffer. It is over four times as large as Swift, which means it can shift instruction execution order around such that these data dependencies never manifest in the actual execution order.

We can see that the branch mispredict penalty is slightly increased. This is likely a byproduct of a more complex core with more concurrent execution possibilities and potentially a deeper pipeline. What this means is that when you reach a conditional instruction that depends on a variable that is determined at runtime, you have to assume some outcome of that conditional instruction so that you can execute instructions that come after it without waiting for its result. In the event that your architecture guesses wrong, you must flush the pipeline and discard all instruction results that depended on that being the correct prediction. The techniques to mitigate misprediction are beyond the scope of this piece, but it suffices to say it's an important part of the architecture that has a significant contribution to overall performance. Furthermore, in addition to doubling the branch units, we can see they've also added an indirect branch unit. This is a type of branch where the destination address is not immediately known, such as being stored in another memory address. Given that this address may not necessarily be loaded into cache, it may take a while to retrieve this data, so having a unit to address this possibility can also cut down on wasted CPU cycles.

The load/store units and ALUs have also essentially been doubled, which makes sense with double the issue width. General purpose and floating point registers doubled as well, as is called for by the ARMv8 ISA. L1 Instruction and data cache have also been doubled. The reason for this relates to memory hierarchy. Modern CPUs often have 2 to 3 levels of cache. With each successive level, the size increases, as does the associativity and access latency. Thus, a processor with double the issue width simply can't rely on a large L2 to feed it data quickly when the latency is much longer than the L1. Associativity and eviction type are reasons why the L1 cache is separated into instruction and data caches.

Finally, Apple decided to add an L3 cache of 4MB. We know from the Anandtech review of the Retina iPad mini that this cache services the CPU, GPU, and the Image Signal Processor (ISP). In addition to extra cache space for the CPU which cuts down on average total memory access latency. It is also significant that the GPU and ISP can access it, given Apple's new camera software enhancements call for a lot of real-time image processing. It could also improve GPU performance, though that would depend on how programmable it is for the end-user developer. If the cache did have some programmability, it could act as a mitigating factor for main memory bandwidth drop from the A6X to A7 for the full-sized iPad, similar to the eDRAM in the Xbox 360 and the eSRAM in the Xbox One consoles. However, I've not seen anything to indicate that this it the case. The result of doubling all of these execution units and adding a large L3 cache was that the transistor count roughly doubled to over 1 billion, as reported directly by apple in the keynote. This is significant because the die area actually decreased from A6 to A7. That is in large part owing to the fact that the L3 cache is 4MB, which is approximately 196 million transistors alone.

For reference, TSMC also claims a 1.9x transistor density increase going from their 28nm to 20nm process, all other things constant. However, in this case, the design changed completely, negating one of those factors. Also, the transition from 28nm to 20nm is actually what is known a full-node transition. The change from 32nm to 28nm, as we saw in A6 to A7, is a half-node transition. Half-node transitions tend to be simple optical shrinks of the prior generation with mostly the same tooling and processes, whereas full-node transitions require all-new tooling and constitute much larger financial investments by fab houses. All of this taken into account, it is very impressive that Apple achieved this transistor density increase on a half-node transition, despite the large, dense L3 cache helping them reach that mark. It is truly a testament to the expertise of their custom design personnel, who improved significantly on an already custom A6 design.

The A8 CPU prediction
When talking about Apple's CPU efforts, it's important to remember how they got the capability level they are at now. Acquiring Intrinsity, PA Semi, among others, and hiring top CPU architects from AMD shows how serious Apple is about top performing, custom CPU solutions. Apple also turned heads with their Macroscalar trademark two years ago, but it is unclear whether any technology related to this has come to market or why Apple felt the need to trademark what would likely be considered a trade secret design process. Moreover, all speculation about the trademark seems to come back to established methods of branch prediction and speculative execution. It will be interesting to see if this topic comes up again at all.

Cyclone and Swift were each sweeping achievements over their successors, and the circumstances make it very tough for Apple to repeat the leap forward once again. Accordingly, the CPU prediction is rather mild this time around. The move to 20nm from 28nm will certainly help in terms of transistor density and speed for the same amount of power, but Apple's history of extremely modest clock speeds suggests we'll see little movement on this front again. For the iPhone, Cyclone stayed at the same 1.3 GHz that Swift was rated at, despite top end Android handsets boasting quad-core architectures with max CPU speeds above 2 GHz. The reason for restraint on clock speed is to save power, but it helps to know exactly how this saves power.

The power of a transistor operating in a digital function is expressed with the equation P = fCV^2, where f is the frequency of operation, C is the capacitive load of the element that the transistor is driving, and V is the voltage applied to the drain of the transistor that it switches back and forth to from ground. It becomes clear that the dominant factor is likely going to be voltage, as power goes up with its square. What's not clear is that the frequency at which you can operate is directly tied to the voltage you operate at because it directly determines how fast you can move electrons to switch states. Thus, by picking a modest frequency to operate at, you can likely pick a voltage that is lower than your competitors who choose to clock their CPUs at or above 2 GHz. To get a similar amount of performance, you simply compensate by adding bigger or more cores. Apple's reluctance to add more cores means they have opted for wider cores. They now sit alone atop of the heap of mobile CPU designers in core width. In fact, as Anand points out in his Cyclone overview, it's as wide as desktop designs such as Sandy Bridge. That definitely warrants the term "desktop class" Apple proudly boasted in the last keynote.

Apple's crown of core width is set to expire next year, however, as Nvidia will introduce their own 64-bit ARMv8-A compatible core with an issue width of 7. That core is a fair bit more complex, however, as it is not a native ARMv8-A core and will rely on binary translation to interpret ARMv8-A machine code. I definitely suggest the preview if this concept interests you more. However, this, along with Qualcomm's own plans to adopt dual-core A57s, should show that large, complex cores in a dual-core configuration is the most optimized solution for mobile at the moment. The "core-war" started by Nvidia's quad-core Tegra 2 seems to finally be subsiding. I have no doubt that mobile environments will benefit from four cores, whether logical or physical, sometime in the future, but it does seem to be later rather than sooner at this point.

Apple has also been in a perfect storm of ISA advancements, reference core designs, and shorter times-to-market for designs. Apple first moved to the Cortex A8 architecture and associated ARMv7 ISA with the iPhone 3GS, two years after the reference design had been disclosed. The Cortex A8 had significantly higher IPC than its ARM 11 predecessor that implemented the ARMv6 ISA. The following year, they used another Cortex A8 design, this time customized by Intrinsity and clocked 50% faster. That was Apple's first custom SoC, dubbed the A4. The Cortex A9 followed, boasting an out-of-order design for another hefty IPC boost. Apple placed two of these cores in their A5 SoC while holding clock speeds steady. Cortex A15 followed with some ISA extensions that put us up to ARMv7s, codenamed "Eagle", which Apple departed from in their first truly custom design codenamed "Swift" in the A6. Another clock boost around 50% allowed them to achieve another 2x benchmark improvement over the A5 design. Most recently, Apple took advantage of another ISA announcement, ARMv8-A, to create their "Cyclone" core in the A7. This design was able to achieve its 2x improvement via a big IPC improvement and more powerful instructions at their disposal while holding the CPU frequency constant. Given this cadence, it seems reasonable to expect some CPU frequency increase this time around.

Now, Apple finally sits at a juncture where there is no new ISA to implement, no new reference core to modify, and no clear low-hanging fruit in terms of design improvements to significantly upgrade over their predecessor. Issue width seems unlikely to increase, given the design is already as wide as many desktop designs. Further attempts to widen the core would likely result in underutilized functional units with little boost to overall actual IPC. Considering all of these factors, it will be quite tough for Apple to achieve a third consecutive 2x benchmark improvement claim unless they significantly increase clock speeds. I feel that it is much more likely that Apple will make small but meaningful improvements to the existing Cyclone design, potentially addressing what they feel are its biggest shortcomings. Examples of what this might include are a better branch predictor, more custom extensions to the ARMv8-A ISA to speed-up frequently used operations, memory latency time reductions, or reductions of cycles needed for complex ALU operations.

In last year's piece, I also spent some time explaining the drawbacks of a quad-core design or implementing ARM's big.LITTLE heterogeneous core topology scheme, and those points are still relevant moving forward. More of this design trade is explained below in the section on TDP, die size, and other design considerations.

All versions of the iPhone have featured a GPU from Imagination Technologies. In fact, Apple owns around a 10% stake in them as well (an interesting side note- ImgTec acquired Caustic Graphics, a company focused on creating dedicated ray tracing hardware that was comprised of former Apple engineers). It seems all but certain that Apple's A8 will feature ImgTec graphics core as well, with Imagination Technologies announcing a multi-year, multi-use extension to their licensing agreement with Apple. Last year, ImgTec's Series 6 "Rogue" architecture was brand new with many performance improvement claims, so it was a big area of interest as a potential upgrade. This year, however, we only have a modest update to that series to eye as a potential upgrade.

One positive thing about the GPU landscape is that ImgTec has been very good about publishing data on their architectures over the course of the past year. This includes a very good comprehensive overview of the Series 6 family of GPUs and a good article on the specific improvements that the 6XT line of GPUs offers over the initial Series 6 GPUs. You can read the articles to get a detailed explanation of the improvements, but they boil down to better DVFS, better compression techniques, higher FP16 performance and improved scheduling. FP16 performance has historically been the determining factor in mobile graphics environments, rather than the FP32 commonplace in the desktop graphics market. They claim performance boosts can be had up to 50%, though it is likely those are highly situation specific and real world improvements which be much more modest.

As to whether Apple intends to adopt the new 6XT series, it is largely a question of time to market. ImgTec has only recently introduced this line of GPUs at CES in January. Given this would represent a time table that is very aggressive and much faster than any other GPU (or CPU) architecture adoption, it seems rather unlikely. ImgTec originally made Series 6 cores available for licensing in January of 2010. It followed that 6 months later with the G6x30 series, that were focused on performance rather than area and featured additional compression technology in addition to more FP16 ALUs. That meant the G6430 in the 5S had a 14 month time to market from being announced. The timetable would only be 9 months if Apple chose to use the G6450 or G6650 GPUs.

However, Apple has many things working in their favor when it comes to adoption of a potential G6x50 GPU solution. Given that they are a 10% stakeholder and the most significant party when it comes to licensing revenue, it is likely they would have early access if they sought it. The GPU architecture's similarity to its predecessor likely means it is also easier to iterate than it would have been to go from the series 5 to series 6 GPUs. The architecture also has many improvements to refine its power consumption, and some of the DVFS improvements in particular were added in response to customer feedback. It seems likely that Apple would have been one of the parties providing such feedback.

Last year, I also addressed Apple's GPU engineer team in Orlando, FL. I suggested it could indicate that they intended to create their own customized versions of ImgTec GPUs, fully custom GPUs, or API/driver improvements to speed things up from the software side. Apple confirmed my last suggestion when they announced the "Metal" (a reference to "coding to the metal", or low level programming that directly addresses the features of the hardware) shader programming language designed to eliminate driver overhead when writing graphics code. Driver overhead can be significant, as well. It is the reason that AMD introduced their own custom graphics API, Mantle. It's also the reason that video game consoles are able to succeed in the face of much more powerful PCs. It is quite possible that my other ideas on this team's function may come to fruition, but this advancement could potentially allow for graphics tasks to run faster than before even if Apple does nothing to update the GPU. In this sense, they could get a free GPU update and may not feel it is necessary to touch the GPU architecture for A8.

In light of these facts, I still think it is highly likely Apple decides to increase the size of the GPU by going to a 6 cluster configuration in addition to or instead of adopting the new G6x50 architecture improvements. They will likely benefit from a full node transition by going to 20nm and the CPU cores seem unlikely to grow significantly, affording plenty of die space to increase the performance of the GPU. This will be especially important if this year's product cycles introduces any more demanding resolutions among their iDevice offerings. From a prediction standpoint, it is exciting to think about the possibility of a G6x50 GPU offering because it represents an aggressive time to market benchmark new for even Apple.

It is worth noting that ImgTec has also introduced a variant of the 6 Series GPU that features dedicated ray tracing hardware. Ray tracing is a physically based lighting method that is more accurate than traditional rasterization methods but much more computationally expensive and memory intensive. CPUs and even GPUs do not do it well. There have been previous attempts to do it with custom silicon that have also failed. However, ImgTec recently acquired Caustic Graphics who have dedicated hardware solutions, which according to famous graphics programmer John Carmack, are actually quite good. ImgTec decided to integrate it into their Series 6 GPUs, making them the first consumer GPUs with dedicated ray tracing hardware.

The problem with ray tracing hardware is that developers would have to implement support for it to actually be useful. While some applications that render 3D graphics may be able to make use of it, the primary use would likely be games. It is often a tough sell to get developers to put major features into games that only a small subset of users will utilize. This is above and beyond the technical challenges it poses. Indeed, before being disclosed on the Caustic hardware, Carmack stated with 90% certainty that any eventual ray tracing hardware would likely be small modifications to existing GPUs. He also downplayed the need for it all together in modern games. Thus, it is likely to be relegated to a curiosity for at least the next few years. The future does have promise though, as ImgTec has already acknowledged the existence of the 7 Series family of GPUs, along with indications that they plan to iterate designs at a faster pace in the future. It seems very likely that we will be talking about the 7 Series much more in the near future, possibly as a GPU candidate for the next wave of GPUs utilized in custom Apple SoCs.

It seems as though this one may have already been determined, based on the populated PCB leaks recently. Using the Hynix mobile memory code reference sheet, it has been determined that the A8 likely has 1GB of 1600 MHz LPDDR3 RAM, the same as its predecessor, with what is assumed to be a 64-bit data bus. The fact that it suggests A8 only has 1GB of RAM is particularly surprising, because as you can see from the list of previous iPhones, Apple has never kept the same amount of RAM in the iPhone for more than 2 generations. Many aspects of their devices have a 2 year cadence including but not limited to form factor, product naming, screen size and technology, and many other features. This also comes into contrast with a rumor earlier this year that suggested Apple may look to include the new LPDDR4 RAM in their iDevices this year. Part of the rumor was based on a 250 million dollar mystery payment made to Micron (who now own Elpida, memory supplier on previous iPhones). While Apple has been known to make large payments to suppliers in the past in order to secure volume and favorable pricing, it seems that this supposition was perhaps unfounded in this case. A large part of the reason it likely cannot be adopted is because suppliers cannot provide volume or acceptable pricing for Apple's needs. Indeed, the standard for LPDDR4 was just ratified by JEDEC in the past week. That being said, LPDDR4 is a significant improvement over LPDDR3, much more so than LPDDR3 was over LPDDR2. It has a lower voltage and completely new interface that will offer significantly more speed and power savings. Apple will likely look to adopt it as soon as possible given their volume and pricing constraints.

In an effort to be critical of what we assume is known about the RAM in the A8 processor, I will offer possible thoughts to suggest our assumed knowledge may not be correct. First, there are several unknown letters in the memory sequence, as is discussed in the linked thread, that suggest a few unknowns may exist. Since the code does not clearly indicate bus-width like Elpida part numbers have in the past, it is possible we may be looking at a data bus wider than 64 bits. Apple has used 128-bit data buses in their A5X and A6X processors in the past. The bus width was needed to drive the large number of pixels in the iPad retina displays, and the memory chips were located off package for thermal reasons, in addition to the difficulty of having a wide memory bus such as that in a PoP memory configuration.

Interestingly, Chipworks' analysis of the A7 revealed that the memory package had decreased their pad pitch and increased the number of pads from 272 in the A6 to 456 in the A7. This further explains the memory code not being listed and gives us a clue as to what may be changing between the A7 and A8. Given that the LPDDR3 standard doesn't call for extra pins over the LPDDR2, they correctly questioned what the large pad increase was if the bus width remained at 64-bit. While this question was never answered, it does point to the possibility that Apple has the capability to properly package memory with the processor and achieve a bus width of 128 bits. It also may indicate that in the misunderstanding of the part number, such that there are two such dies of 1GB each, that add to a total of 2GB.

It is also possible that with the introduction of a 5.5" iPhone model, Apple may seek to differentiate them further by offering them with differing RAM amounts, among other features. Apple has not given their iDevice line different RAM amounts for the same processor since the iPhone 4 had 512 MB compared to the original iPad's 256 MB, however. It is also interesting that Apple continues to put the RAM off package in the full size iPad while clocking it only modestly higher when the iPhone and iPad mini with Retina clearly show that the A7's heat output can be handled in small form factors without aggressive thermal management techniques. I expect Apple to eventually stop doing this for the RAM in the iPad Air, especially since future 3D IC technologies will demand it.

Looking into the future, it is likely that we will eventually see 3D IC memory solutions from Apple for their SoCs. Rather than having individual solder bumps from the memory chip to the interconnects, 3D IC solutions allow the memory to directly interconnect to the SoC through a silicon substrate by what are called through silicon vias (TSV). This will allow for greatly expanded memory interfaces that are 512 or even 1024 bits wide in comparison to the 64 and 128 bit interfaces currently seen in the iPhone and iPad. Sony uses a predecessor to this technique called System in Package (SiP) that uses fine wires as opposed to solder bumps, allowing them to achieve more interconnects in a given space. This allows the Vita's GPU to have a 512 bit interface to its VRAM. Whatever solution they use, it will allow Apple to greatly improve memory bandwidth, which can bottleneck GPU performance.
Last edited:


macrumors 603
Original poster
Oct 29, 2007
Fixed function blocks
Last year, Apple introduced their "M7" motion coprocessor, which turned out to be a part manufactured by NXP, who can also tout design wins for the display interface and this year's NFC chip. The pad pinout for this processor is conspicuously absent from the logic board of the iPhone 6. Moreover, an inspection of NXP's product offerings doesn't offer a clear successor to this part either. It seems highly unlikely that Apple would do away with this functionality, so the easiest conclusion to make is that the part has changed pinouts or been combined with other functionality into a new part and new pinout. Another option is that Apple licensed the IP such that they could include the processor on the die or in the package of the A8. With Apple's push into health related functions in iOS 8, it seems reasonable that they would step up their efforts in this area, including potentially moving this functionality to a location where it could have a secure enclave of data storage similar to how they store fingerprint data.
Including additional circuitry such as this is not free, however, as it can get complicated to create additional clock and power domains on what is already a complicated application processor. This does seem a fair conclusion when the A8's reduced pinout, shown in the PCB analysis section, is taken into account. With fewer pins to interface to the PCB, some of the immediate conclusions would be a reduction in complexity or functionality, a consolidation of functions and hubs onto the chip, or a simplification of interfaces to other chips. Given that the A8 should be a processor with improved capabilities, the first possibility does not seem likely.
There have been some interesting articles in the past years on this topic, so I've left the rest of this section for the content I presented last year, unedited.

The EETimes article ([12],[13]) goes into great detail about comparing the size of the CPU cores in the A6 to the A5 for those interested. It also helps to illustrate that the CPU has taken increasingly larger amounts of the overall die area in Apple's A-series SoCs (also true of the GPU).

The die allocation image above shows that the number of digital blocks on the A-series SoCs has been increasing. Indeed, with acquisitions like Anobit and Authentec, Apple is poised to put more and more custom circuitry on the SoC itself, freeing up space on their board and allowing them to tailor the solutions exactly to their performance and power needs. I expect this number to go up over time.

Apple also surprised many last year when it was found out that Audience's EarSmart noise cancellation technology would not be in the iPhone 5. The fact that they developed and completed the IP to Apple's requirements suggests that Apple potentially competed them against their own internal team. If this was the case, Apple may been able to meet its own requirements with an in-house solution, eliminating the need to license the IP from Audience. This is just another example of Apple's aggressive pursuit of solutions that are integrated, custom and internally created.

There was also an interesting analysis that arose after the AppleTV received a new version of the A5 SoC that trimmed the CPU to a single core and significantly reduced the size of the die. This seems to be thanks to some custom analog circuitry redesign, which suggests Apple is also increasing its design expertise there. Similar reductions in future SoCs would allow Apple to make all of their dies smaller, saving money, or use that area for something else, increasing performance without increasing size comparatively. The AppleTV was a good product to make this change on because it allowed them to test out their new circuitry in a relatively low volume part.

Comments on design fabrication process, TDP, and die size
It is no secret that Apple has been rumored to be moving to TSMC for production of its A-series SoCs for years. This has also often been accompanied by talk of how Apple seeks to break its dependence on Samsung for key components in its iDevices. This year, it looks as if the stars have finally aligned with TSMC demonstrating a process lead on 20nm technology and apparently having sufficient volume to fulfill the demand in the tens of millions for Apple's devices. Reportedly, Samsung dropped out of A8 production over issues with yield. Indeed, there were reports in March that TSMC had begun production of Apple's A8 processor, followed by rumors that deliveries began in July. As mentioned earlier, should Apple move to the 20nm process with TSMC, it will be a full node shrink from the 28nm node they are currently on with the A7 processor. This is in contrast to the transition from A5 to A6, which was only a half-node transition. With a full node transition, you can usually expect the logic density to go up such that the same functionality takes 50 to 70 percent of the original area. This fact is one of the reasons the apparent shrink of the package and pinout size shouldn't be immediately alarming to those concerned about performance. In fact, Apple has previously been very aggressive with their design sizes. For example, A5X was 165 mm^2, whereas Nvidia's Tegra 4 was only 80 mm^2. That high point has come down in recent years, with the designs over the past few years ranging from around 100 to 120 mm^2. This means that you can get fewer chips per wafer and that if there are any defect rates that associated with area as a factor, yield will suffer as a result. Apple's willingness to bear these risks should show that a potential size reduction on the A8 is not one rooted in conservatism.

Moving forward, TSMC looks as though it may have sufficient production capacity on its 16nm FinFET process this time next year. Samsung, along with Global Foundries through their licensing partnership, may also have 14nm FinFET volume capacity next year. There have been conflicting reports of which supplier is slated to supply processors next year, with Global Foundries' facility in New York being named specifically at one time. There have even been rumors that TSMC and Samsung would share production. Ideally, Apple would only choose one of these processes as they have to design and validate to each process, something that would be cost and time prohibitive given that they are now doing full custom designs. Utilizing both processes would also force a lowest common denominator of performance characteristics, unless they segregated processes by device line. The performance delta between the processes is likely to be less than the delta between 20nm and either process, making it a justifiable step forward to go with either supplier.

There has also been talk about Intel as a fab partner for their A-series chips. Intel has opened their fabs up to outsiders slowly in recent years, with it perhaps culminating in the revelation that they would produce ARM 64 bit designs. There is still a healthy amount of skepticism surrounding Intel's willingness to produce designs that directly compete with their own markets, or more importantly, markets they desire higher marketshare for, such as mobile products. Intel has generally kept a one process lead over the rest of the market, with their use of FinFETs at 22nm being the best recent example. The fact that use of their technology could create another leap forward in performance means it is a situation worth keeping an eye on.

Looking further down the road, the situation becomes even more challenging. Most process roadmaps end around the 3nm to 5nm range. Additionally, after over forty years of improving cost per transistor in electronic devices, that curve is trending back upward. Small feature sizes have forced double patterning on chip designers, significantly raising mask costs. Quantum tunneling has forced foundries to use high-k gate materials. While EUV and 450mm have promises of bring costs back under control, they continue to be pushed back with no definite timeline. FinFETs are only the start of topology changes to make the smaller nodes viable and effectively fight quantum effects and device leakage. From III-V materials, to silicon nanowires, quantum FETs, carbon nanotubes, FD-SOI, FinFET SOI, optical transistors and many more, there are a plethora of technologies that promise to increase performance, overcome limitations and push us into single digit nanometer device feature sizes. While difficulties lie ahead, it is an extremely interesting time to follow the electronics industry.

Thermal Design Power (TDP) is the thermal budget designers work in to manage the heat their processors create. Over the years, mobile chip TDPs have been increasing all the way up to 8W. Anandtech talks about this in their excellent x86 vs ARM showdown piece. They get away with this by executing tasks quicker and shutting down or throttling unneeded resources. TDP is one of the reasons that Apple does not put the RAM on the package in its iPad. iPads feature higher CPU frequencies and larger GPUs, generating more heat, which can necessitate moving the RAM off package to allow for a better thermal sink on the package. TDP is important because since we are starting to reach practical limits, there are no more easy gains to be had in speeding up CPUs and GPUs. Last year, I suggested the days of 2x improvement are over because of TDP limits, only to have Apple prove that wrong by making a much wider design that is 64 bit. But it did come at a cost. The A7 draws over twice the current that A6 does during fixed-point operations, and still nearly double during floating-point operations.

Cellular radio
Last year, we had rumors of the iPhone 5S possibly including Qualcomm's 9625 modem capable of carrier aggregation. Anandtech's Brian Klug managed to squash that rumor by confirming the pinout for the WTR1605L on the leaked logic board. The most legitimate argument against that rumor was that no carriers had yet deployed carrier aggregation to take advantage of those advanced features. That is changing now, with each of the four major cellular carriers in the process of deploying CA across the nation. Verizon calls it XLTE, T-Mobile calls it wideband LTE, Sprint calls it Spark, and AT&T doesn't have a name for it, but promises peg all four having deployed it by this year's end.

Last year, Brian Klug from Anandtech did an excellent summary of the state of Qualcomm's modems and transceivers at the time, detailing the capabilities of the 9625 modem and 1605L transceiver. When Qualcomm announced their fourth generation category 6 LTE modem, the 9x35, he detailed the fact that the 1625L transceiver required the WFR1620 to fully support carrier aggregation with the 9625 modem. Unfortunately, there is no good comparison of the feature set of 1605L vs. 1625L beyond carrier aggregation, but Qualcomm has stated that the 1625L can support every band combination on the market. This means that if the iPhone were to feature it, the number of SKUs forced by differing standards around the world would simply depend on the complexity of Apple's amplifier and switch architecture. With the iPhone 5S, five different implementations were necessary to support all of the carriers for which Apple the iPhone available. Chipworks even did a comparison of the RF front-ends between the Asia/Pacific model and the North America one.

The 9625 rumor surfaced again last week after leaked logic boards and schematics emerged. I have since confirmed the presence of the WTR1625L transceiver, which necessitates the modem being the 9625 and the presence of the WFR1620 companion chip. More details of that are in the PCB analysis section. So, buyers of the new iPhone can expect higher peak LTE speeds if their carrier supports CA. It will be interesting going forward to see how many models of the iPhone 6 are required to support all of the carriers Apple deploys the iPhone to, particularly with the logic board growing thanks to the new potential 4.7" and 5.5" screen sizes. It seems unlikely that they will be able to deploy a catch-all model and will still require at least two or three versions. A China Telecom ad seemed to suggest that there would be a comprehensive model for all Chinese carrier options. The leaked PCB suggests that there are again at least six different power amplifiers, but at least one of those appears to be a new multi-mode, multi-band module from Skyworks that supports numerous bands itself.

The next generation 9635 modem, which is implemented on a 20nm process rather than the 28nm found in the 9625, was mentioned in at least one rumor regarding the iPhone 6. While that has been confirmed false at this point, it does seem a likely option moving forward, though Apple would likely wait to deploy until at least a few North American carriers deployed advanced LTE features that would take advantage of it, if recent trends are any indication. Other recent advancements by Qualcomm include the WTR3925 transceiver, which combines the functionality of the WTR1625L and WFR1620 into a single chip and moves from a 65nm RF process to a 28nm one. Given that likely constitutes a significant savings in board space and power consumption, it seems likely that some combination of volume availability, price and time to design prevented Apple from implementing it this time around. The WTR3925 is just one piece of what Qualcomm calls their "RF360" set of RF front-end solutions. Also in that series are QFE11xx envelope trackers, QFE15xx dynamic antenna matching tuner (that is intended to address impedance changers from user handling, for example), QFE23xx power amplifier and antenna switch modules, and the QFE27xx which integrates the QFE23xx with filters and duplexers on the same module.

Apple's competitors HTC and Samsung have implemented part of these solutions, with Samsung using a QFE11xx variant in their Galaxy S5 and HTC using that and a QFE15xx in their HTC One M8. ZTE intends to use the QFE23xx power amplifier line. Samsung's forthcoming Galaxy Alpha/S5 Prime is rumored to include the 9635 modem, which implies it would also use the WTR3925L transceiver. Of all the RF360 options, I believe Apple is using a QFE11xx envelope tracker variant, which allows them to dynamically adjust the supply voltage to power amplifiers based on the amplitude of the waveform being processed, saving power in the process. This supposition is explained in the PCB analysis section. The lack of other components is not necessarily troubling, given Apple tends to use power amplifiers, filters, switches, duplexers, and antenna switches from capable vendors like Skyworks, Avago, Murata, TriQuint, and RF Micro Devices.

Going forward, further use of Qualcomm's latest solutions should not be taken for granted. Apple has recently taken to hiring engineers from baseband developer Broadcom, indicating they could intend to develop their own custom baseband solution. A more mild interpretation could be that they simply wish to develop more expertise in the field or expand their patent portfolio to give them ammunition in patent disputes covering wireless communications. Given the number of reports that Apple is always looking to diversify their suppliers to avoid risk, it makes sense that they may not want to depend on Qualcomm forever.

Last year, I discussed the possibility of Apple improving over the iPhone 5's support of the IEEE 802.11N WiFi standard by including support for the AC standard, such as offered by the Broadcom BCM4335 solution. It is not surprising that they did not include support for it, given they have tended to be somewhat slow in adoption WiFi standards in the iPhone. For example, the 4S only supported 2.4GHz N and the iPhone 5 introduced 5GHz N. In fact, it wasn't until late May of last year that Broadcom announced a solution suitable for a mobile device such as the iPhone that includes all of the front end components. Apple has traditionally gone to Murata for their repackaged Broadcom solutions, and Murata does have an existing implementation of the BCM4339 solution.

While that, with the expanded footprint on the PCB for the WiFi, may be enough evidence to believe AC support is coming, there had been the possibility that Apple could use a solution that combined WiFi, bluetooth and NFC into one module. NFC had been strongly rumored for several years, so that avenue is worth considering as well, given Broadcom does have such a product line. Fortunately, the populated PCB leak confirmed the presence of NFC in a dedicated chip by NXP, eliminating that possibility. With no new Bluetooth standard to adopt, the AC WiFi standard seems to be the only possible explanation for the module growth seen on the iPhone 6 PCB.

After years and dozens of rumors, it appears the iPhone is finally getting NFC. The chip, which has 49 pins according to the bare logic board, also confirmed by the leaked schematic, appears to be similar to the NFC chip featured in the Samsung Galaxy S5 phone. What becomes interesting now is not the chip itself, but how Apple will include the antenna, or more accurately, inductor, in the design of the iPhone 6.

In May of this year, an Apple patent was revealed that suggested the body of the device itself could be used for the NFC antenna, just as the body is part of the antenna structure for cellular, WiFi and bluetooth signals currently. This seems the most likely route, as Samsung's method of placing it on the battery is infeasible with an all-metal body that would block the transmission of signals through the device's shell. More recently, HTC put a NFC antenna in the opening for the camera while maintaining the all metal body. Given that assembled body pieces of the iPhone 6 has also proved this infeasible, we are left with the device using the traditional antenna structures or using the front chin or top of the device where the antenna could be embedded out of view but also not behind a metal structure that would block signals. Given that the patent seems to suggest the former, that is the best assumption moving forward.

Flash storage
Last year, the excellent iPhone 5S rumor roundup from MacRumors shed light on the rumor of a 128GB iPhone, with leading analysts predicting its coming. The first and most important consideration when talking about this is whether it's even technically possible. The iPhone only uses a single NAND module to save space, whereas the iPad and iPod touch enjoy two (making the 128GB iPad easily possible). Fortunately, such modules are technically possible. Over two years ago, Sandisk announced they are making 128 gigabit NAND memory chips. With the typically 8 chip NAND module arrangement, this would allow for a 128GB NAND module. It also seems likely enough time has elapsed for these chips to be available in the volume Apple needs.

The other concern with such an iPhone is what Apple thinks the market will support. Demand for the 128GB iPad and many users' iTunes library sizes no doubt suggest there would be demand for such an iPhone. Previously, apple had also done a maximum storage bump on every "S" model (3GS introduced 32GB, 4S introduced 64GB), making this one seem perhaps overdue. The difficulty would be in price and SKU management. Do they add a 4th storage option like the iPad and increase the price ceiling by another hundred dollars, creating a $499 subsidized iPhone? Or, would it better to drop the low-end of 16GB and maintain the current price points? It's also possible that they could drop the 64GB option and replace it with 128GB, thus making the bottom two iPhones no more expensive to produce. In any event, a 128GB iPhone seems likely, but I am very skeptical about any raise on the price ceiling of the iPhone models.

Fortunately, this year we've been gifted with some leaked schematics covering multiple topics, including NAND storage. The first one was suspect, however, when it showed what appeared to be a 1GB NAND module. This was briefly interpreted as DRAM for a brief period because of the small size. Obviously, there will be no 1GB NAND storage option, so what does it mean? First, I should say that I started being highly skeptical of these schematic leaks. Technically, a designer like Apple can give a manufacturer layout design files and a netlist, and that will be sufficient to build the design. Design schematics often indicate functionality intent to the extent that they could inform competitors how to design things, so it seems unlikely that Apple would even share these outside of their own internal structure.

However, subsequent leaks show a barometric pressure sensor, whose potential location on the board may have been identified, as seen in the PCB section. There was also a leak showing the correct number of pins for the NFC chip, again adding legitimacy to this source of leaks. Thus, if we are to seriously consider this leak, there seem to be three possibilities. The first possibility is that there is an extra NAND chip on the PCB. The bare and populated PCBs do not seem to support that claim. Another possibility is that it is included in the NAND module itself, as a separate memory module. The final option is that it is included in the AP package itself. If either of these is the case, we must realize then we are looking at schematics of those packages themselves, rather than the PCB. This gives me another level of skepticism, since it means those schematics are being shared as well. This assumes that the designers for these parts even produce schematics for them.

So, if this NAND module does exist, what is its potential purpose? The second leak, that gives realistic storage values, also gives the context. If you look at the top right of both schematics, you see they have pins labeled "CE0" and "CEN0". These are chip enable pins. If you are going to have memory devices share a bus, you would route signals to them such that they could be enabled independently and either control the bus themselves free from contention from the other memory device, or to ignore the incoming write data not intended for them. In this case, the format of the net names is similar, with one net name containing "ANC0" and the other containing "ANC1". The net names on the IO of both are also identical, suggesting they do indeed share a data bus. The first NAND schematic also contains the word "POP" in the name, which could refer to the term Package-On-Package, which is how the DRAM is put into the AP package, for example.

Given the details seem logically consistent, what could be the purpose of this memory? My guess is that it is a separate, small pool of memory that is likely encrypted and intended to store health and fingerprint data for the processor. Apple told us that the A7 had a "secure enclave" for fingerprint data, but if they also intend to gather health data as iOS 8 suggests, privacy concerns would also accompany that. Thus, if this leak is legitimate, that seems the most likely answer to me, regardless of whether this additional NAND is in the AP package or the main NAND storage package. In this context, it is also worth mentioning that no package pinout matching that of the M7 from the iPhone 5S logic board appears to be on the iPhone 6 PCB. As is explained elsewhere in the fixed function blocks, it is possible it moved onto the processor package, changed package style, or got integrated with some other function or package.

Getting back to the second leak to wrap up, we see the table shows 16GB, 64GB and 128GB options. It seemingly answers both the question of whether a 128GB model will exist, and what the pricing tier will look like. It also becomes more interesting if the storage options differ across the two screen sizes, as has been suggested.

Perhaps the most anticipated aspect of this year's iPhone update, multiple leaks seem to have confirmed that 4.7 and 5.5 inch screen versions are coming this year, along with several guesses as to how Apple may achieve this with the impacts of pixel density with existing developer assets in mind. This seems likely a response to market pressure, as demand is very high for larger screen size iPhones. Rumors also suggest Apple is acutely aware of this, placing unprecedented order amounts for the new iPhones. Thus, the offerings of these new screen sizes seem all but confirmed. Apple seemingly maintaining pixel density, at least for the 4.7 inch version, also makes sense in that Apple clearly defined that they believe 326PPI is the benchmark for pixels the human eye cannot resolve. This would make any increase above that inconsequential to experience, and ultimately damaging to battery life as it is harder to drive more pixels.

What is less obvious about these screens are what, if any, technology changes enhance their performance in metrics such as thickness, color gamut, brightness, or power consumption. One rumor suggests that Apple may use thinner LED backlights, supporting their overall thinness effort. Supposedly, the effort to reduce the backlight film to one layer from two caused production issues, suggesting several thinning efforts have occurred regarding the backlight. There have also been rumors of potential adoption of an alternative to the current in-cell technology termed "touch-on display", but it is unclear if that effort is still in effect.

While there are clear efforts to reduce the thickness of the display and improve usability, there are no clear examples of efforts to improve quality. When the current display debuted in the iPhone 5, it was described by DisplayMate as the best ever. That crown has since been usurped by the screen of the Samsung Galaxy S5. OLED has clearly overcome its early challenges, the worst of which of was color accuracy. This has happened with the iPad too. For example, the iPad mini with Retina display recently made the change to IGZO transistors, whereas their direct competitors the HDX 7 and the New Nexus 7 are using superior backlighting methods, such as Quantum Dots in the HDX, or a LTPS backplane in the Nexus 7, which is the same power efficient backplane used in iPhones. In that comparison, the HDX manages the best overall rating while having an inferior backplane material to all options and having a better power efficiency than the iPad display.

It will be interesting to see Apple's actions going forward as they have often been at the forefront of display quality, starting with the Retina display in the iPhone 4. If they are simply quality focused, we may see them shift to a new technology such as OLED regardless of the fact that the supplier may be Samsung. I believe Apple's past actions support that quality focus and the drive to avoid Samsung may be a bit overblown. It is also possible that could look to more exotic display technologies in the future, such as Quantum Dot displays. The term Quantum Dot actually refers to the backlighting method, and they can be used as replacements for LED backlighting in conventional LCD displays. They can help boost color accuracy, gamut, contrast, efficiency among many other improvements. DisplayMate has a good summary of display technologies that are new to or close to market in 2014. Fortunately, Apple is looking into Quantum Dot displays, but cite concerns over toxicity, cost and optimized performance. Thus, for the time being, it seems like we can expect IPS, LTPS displays with LED backlighting in all iPhone models.

Looking outside the display itself, one potential power-saving move would be to use a strategy similar to LG's G2 smartphone, which has a local "GRAM" for the display buffer. If the screen has no change in the image it needs to display, it simply refreshes from the local RAM rather than forcing the display controller to generate the same image again for the display to use. They claim up to a 26% savings in power, although this would certainly depend on usage scenario. When you look at the power usage by component in the typical smartphone, the display is almost always leading the pack over the rest of the components, making it is easy to see why this idea has merit.

Apple has also made other moves in terms of acquisitions and partnerships, acquiring LuxVue Technologies, a company that specializes in low-power displays. LuxVue has also developed a technology called "microLED", which promise brighter and more efficient screens, making that another alternative for improved overall display performance. They've also partnered with a company called Pixelworks, whose technology can supposedly enhance color, sharpness, contrast, and de-blur. They also claim their technology can extend battery life, all of which would be a strong interest of Apple's. Finally, Apple also tried to acquire the Renesas SP Driver division, in hopes of bringing display driver technology in house. That division was acquired by Synaptics instead, perhaps suggesting that the purchase wasn't essential to Apple's vision moving forward. Therefore, it does seem clear that Apple has a distinct vision on how to improve their display products, albeit possibly arriving later rather than sooner.

Finally, we come to Apple's heavily rumored use of sapphire in their display panels. While sapphire is more scratch resistant and stronger than gorilla glass, it is also more brittle, making it susceptible to drops. Analysts cannot seem to agree when and if it is coming to iPhone displays. It has also been labeled as more expensive. Given the nature of the product is imperceptible to the user until an accident happens, it seems more of a curiosity to the average user than a truly compelling upgrade that improves the average user experience.

Stories have circulated that Apple could be looking into adding high quality 24-bit audio files to its iTunes library. They already suggest that artists submit 24 bit masters as part of their "Mastered for iTunes" program. Demand for high quality audio may be growing too, with the rise of premium headphone brands recently, including Apple's acquisition of perhaps the most notable brand, Beats. Last year, LG suggest a larger internal speaker for the next iPhone. While perhaps not the preferred method of entertainment audio delivery and more important for voice communication, it does at least indicate that they are not content to stagnate on audio all together.

Apple, through the use of their MFi Made for iPhone program, has allowed 3rd party manufactures to access the digital audio stream of music through the lightning connector. This allows manufacturers to potentially interface higher quality DACs and amplifiers with the iPhone, albeit at 16 bit depth that the iPhone is limited to. Perhaps this is one avenue that Apple can exploit with Beats audio products, including a DAC and amp directly into the headset and having it connect via the lightning connector rather than the standard audio jack.

Two years ago I created a thread that highlighted the battery chemistry change in the iPhone 5. The new chemistry allows for more efficient power delivery and potentially more cycles of the battery for its lifetime. The iPhone 5S battery capacity is 1560 mAh. There have been a total of four leaks for the iPhone 6 battery, the first two of which suggested 1810 mAh for the 4.7" version, while the third suggested 2100 mAh. The only leak for the 5.5" version has suggested 2915 mAh. These are all significant bumps, and are the biggest jumps in battery capacity since the iPhone 4 was introduced at 1420 mAh, improving over the 1219 mAh of the 3GS (battery capacity did drop from 1400 mAh to 1150 mAh going from the iPhone to iPhone 3G).

As you can see in just about any android battery life profiler, the screen is the single biggest user of battery in a smartphone. Thus, with the screen sizes increasing dramatically on the iPhone 6, a large step in battery was necessary to at least keep pace with the increased battery life demand from the screen. If the larger 2100 mAh battery size is true for the 4.7" version, Apple appears to at least have done that.

One can see in the rumor roundup that the pill shaped "True Tone" flash has changed into a circular shape, like previous iPhone flashes. There have been a few rumors regarding the back camera of the device, with one suggesting Apple would again use a Sony IMX sensor, this time at 13MP. Another application was published in January for an OIS implementation. One rumor suggests that the 5.5" model alone will get OIS, and it will be a differentiating factor between the versions in addition to screen and battery size. The iPhone 5S already features software image stabilization, but hardware based image stabilization would no doubt be a step up. Leaks also suggest that at least the 4.7 inch version will feature a [URL="”]protruding[/URL] camera ring as iPhones become thinner and thinner despite the relationship of optic assembly depth and overall photo quality.

Chipworks, an advanced teardown and analysis research firm, has their own [URL="”]thoughts[/URL], suggesting the total MP count increase will be modest if at all existent. They also suggest that the new camera may see the addition of on-chip phase detection pixels which enable faster autofocus. They also address the front image sensor, which other rumors have not touched on, suggesting it could increase to 2MP and see a supplier switch from Omnivision to Sony. The article is brief and also has good charts showing the evolution of iPhone front and rear-facing cameras and is a recommended read.

One thing that is certain is that Apple has always stressed the quality of images over touting impressive spec numbers when it comes to camera performance, so I would not anticipate a large MP boost or a decrease in pixel size.


macrumors 603
Original poster
Oct 29, 2007
Other rumored features
There have been several rumors of new functionality in the upcoming iPhones, including haptic feedback, something which android handset manufacturers have included for years. This seems to remain possible, as the post featuring the new speaker also showed a new vibration motor.

There have also been rumors of Apple adding new sensors such as temperature, pressure and humidity. The pressure sensor rumor has gained traction, showing up as "Phosphorous" (perhaps in homage to pure phosphorous's reactivity to oxygen) a leaked schematic, featuring a pinout that matches existing products from Bosch that are featured in competitors' products. This is further supported by a supporting pinout on the leaked logic boards and a potential matching component on the leaked populated board. As has been pointed out in the forums, this sensor's uses could extend beyond weather to perhaps health functions or even navigation inside closed structures. Phosphorous was briefly confused as a M7 successor, which has yet to be identified on the leaked logic boards.

Moving forward, Apple could look to add pressure sensitivity to their screens, as suggested in one patent. This would add a new dimension of user input and potentially enhance a variety of functions, including games.

PCB analysis
In the course of the rumor cycle this year, there have been several logic board leaks of both 4.7 and 5.5 inch iPhone models. We've seen both unpopulated and populated boards leak out, although with many of the components blurred on the latter of those leaks. These boards have also been compared with their predecessor, the iPhone 5S logic board. Given these pictures and previous teardowns as resources, I've annotated both sets of photos. Please keep in mind that the unpopulated boards contain somewhat old information, as the populated board clarified some questions and provided more accurate info. I will comment on both.

Unpopulated board

In this image, we can see the side of the board that houses the application processor. We can see footprints suggesting the presence of multiple power amplifiers in the RF chain, a pinout matching the gyroscope pinout from the 5S board, and a pinout matching the Qualcomm QFE11xx envelope tracker family of parts. One of the pad patterns matches that of new parts from Avago, which has a new line of mutli-band, multi-mode power amplifiers that could help Apple support its carriers worldwide with fewer than the five models that the 5S took. The later populated board shows this to actually be a Skyworks part, and we are left to assume we are actually looking at a logic board from the same region as the unpopulated one. The Skyworks part is also new and fits the exact same function, so the gist of the assumption was sound. Skyworks does not appear to have package information publicly accessible, so this possibility was not considered initially.

The Qualcomm MDM9625M modem is actually confirmed by the presence of the matching WTR1625L pinout on the other side of the unpopulated board, since they are all required for each other to function. Thus, we also confirm the presence of the WFR1620 module that allows the modem and transceiver to support carrier aggregation, part of what is referred to as LTE-Advanced.

Conspicuously absent is the NXP part referred to as "M7" on the previous 5S logic board. There is no matching part on the other side, either, leaving us to believe that the part package changed or that it was absorbed into some other part, potentially the AP. It seems unlikely that the function was removed all together.

Here we have the side of the unpopulated board containing the flash storage. As mentioned before, the WTR1625L matching pinout helped confirm the baseband present in this device. We also see an expanded pinout in the WiFi area, suggesting a new WiFi module that likely supports the AC standard. We know that it does not contain NFC functionality, since that chip's location has been confirmed below it.

We also have numerous pinouts matching those of the previous iPhone board, including touch panel controllers, an apple labeled power management IC, the audo codec, audio amplifier, display interface, TI power management IC. Though some of their locations have moved, it seems likely that these are indeed the same type of parts, if not identical ones. In the case of the apple custom packages such as seen on the PMIC with Dialog IP in it or the audio codec, it's possible that functionality was upgraded while retaining the same package. One curiosity is the distance of the audio amplifier from the audio codec, but the similarity of board metallization in that area for interconnects to audio components suggests that this is correct.

It is also worth pointing out that Apple continues to use two different types of touch panel controllers in their iPhone, something they started with their iPad models.

Newcomers to the board include what appears to be another Qualcomm PMIC from location and pinout style, a pinout matching the potential "Phosphorous" leaked barometric pressure sensor, and various other unknown padouts, such as the pads below the NFC chip. The offset row style suggests it is a Qualcomm chip given that they are the only chip provider in previous iPhones that uses that style of pads. There also appears to be another power amplifier in this side (this is one spot where the populated board differs, suggesting we could be seeing different revisions and/or boards intended for different regions).

Pinout comparison of A8 (top, right) vs. predecessor A7. The reduced pinout suggests some functionality has been consolidated onto the chip, removing it from the board. M7 would be one candidate, but complications of adding functionality like clock and power requirements could make this difficult.

Populated board

Closeup of the RF front-end section on the A8 side of the board. We can see design wins from Skyworks, Avago, and RF Micro Devices, all of who also had design wins in the 5S. Unfortunately, what could be a QFE11xx envelope tracker from Qualcomm has its part number obscured by the shadow of the larger Skyworks part. This is also the location of where I incorrectly placed the NFC chip, based on assuming it was using a different package style. After searching for a package view of the NFC chip on the Galaxy S5 and reading some JEDEC packaging standards, I was able to correct myself and pass that info to MacRumors before this image came out.

While a great view of the flash storage side, it unfortunately does not confirm much that the unpopulated board did not suggest due to obscured part numbers. The similarity of appearance of several packages such as the Apple PMIC and audio codec suggests those assumptions were correct, though.

This entire board view of the A8 side confirms the MDM9625M modem since the part number is partially unobscured. It also shows what could be an antenna switch on the extreme left based on previous iPhone boards. It also confirms the Skyworks amplifiers because of the logo, despite the part numbers being obscured. There is a part matching the pinout of the gyroscope from the 5S (as of yet unidentified on the 6), but the package looks different, making it inconclusive.

This image is interesting because it shows that the silkscreen (package markings) on the A8 are rotated 180 degrees from previous iPhones. This is not readily apparent because the boards have been rotated 180 degrees to compensate for that fact. This may suggest what is considered pin 1 on the device has moved. I do not believe that it indicates the image is not legitimate. The markings on the package also suggest the processor carries 1GB of Hynix LPDDR3 RAM, making it the first time that Apple has gone more than one generation before increasing RAM again. Perhaps this will be a differentiating factor between the 4.7" and 5.5" models, something we'd need to see a populated 5.5" board to confirm. The lack of the M7 coprocessor in its previous location can also be seen here.

[5]Apple A4 Teardown

More reading:
TSMC will offer only one process at 20nm
TSMC 20nm product brief
Last year's A7 prediction thread
ARM announces 64 bit architecture
A7 a "punch to the gut" for Qualcomm
David Kanter's ARMv8-A deep-dive
iPhone battery chemistry change
Rogue GPU family feature chart
Explanation of PowerGear
Memory latency of custom vs. vanilla ARM cores
Anandtech: Cyclone Microarchitecture Detailed
LLVM Wikipedia entry
Anandtech review of the Retina iPad Mini
Anandtech Nvidia Tegra K1 preview
Chipworks analysis of the 20nm MDM9635M modem from Qualcomm
Anandtech's article: State of the SoC Manufacturers
MDM9635M details
Qualcomm's "RF360" RF front-end detailed
Chipworks Apple iPhone 5S and Samsung Galaxy S5 teardowns
Chipworks iPhone 6 camera predictions

ALU - Arithmetic Logic Unit. Functional block that processes mathematical operations such as add, multiply, divide.
AP - Application Processor. Refers to processor with functions in addition to the CPU, such as GPU, memory controller and other things.
CA - Carrier Aggregation. Using two non-contiguous pieces of bandwidth for faster cellular data transmission.
CPU - Central Processing Unit.
DVFS - Dynamic Frequency and Voltage Scaling. A method of saving power and heat under different, non-peak operating conditions.
FP16 - Floating-point operation, 16 bit precision.
FP32 - Floating-point operation, 32 bit precision.
GPU - Graphics Processing Unit.
GRAM - Graphics RAM. A memory local to the display that allows it to refresh static images locally rather than having the graphics chain send repeat images, wasting power.
IC - Integrated Circuit.
IGZO - Indium Gallium Zinc Oxide. A transistor type used in displays known for its relatively high carrier mobility, which saves power.
IPC - Instructions per Clock. The number of instructions a processor can retire in a given clock cycle.
ISA - Instruction Set Architecture. Defines the set of operations that processors are designed to implement.
ISP - Image Signal Processor. Functional block that processes data from the camera.
LTPS - Low-temperature polycrystalline silicon. A transistor type used in displays known for its very high carrier mobility, though often relegated to small displays due to cost.
mAh - milliamp hour. The number of milliamps a particular battery can theoretically sustain for one hour. Apple batteries are often listed in Watt hours recently.
MP - Megapixel. Refers to the total number of pixels in a camera's image sensor. Also part of the abbreviation in ImgTec's Series 5 GPUs referring to multiple cores.
NFC - Near Field Communication. Wireless protocol intended for very short range communication.
OIS - Optical Image Stabilization. A mechanical method for compensation of device motion during image capture.
PCB - Printed Circuit Board.
PMIC - Power Management Integrated Circuit.
SoC - System on a Chip. Refers to a IC that has a collection of interrelated functional blocks all contained on the same die or package.
TDP - Thermal Design Power. The max power dissipation a part is designed to reach.

I'd like to thank Anandtech, Anandtech writers Anand Shimpi and Brian Klug, David Kanter, Jon Stokes, Ars Technica, EETimes, TechInsights, Chipworks and MacRumors forum members such as cmaier, kdarling, mulan03, (including editor Eric Slivka) and many others for providing much of the information this prediction sources in the form or articles, pictures and intelligent discussion.

My background is in electrical engineering, but I am not in the consumer electronics field or any directly connected industry. I have no insider information or contacts. All of this content comes from sourcing existing rumors and available product information with a basic working knowledge of modern electronics. It is done purely for my own enjoyment.


macrumors 6502a
Nov 20, 2012
That was a long, but very informative, read. The MR community thanks you for your excellent summary and analysis!


macrumors regular
Apr 24, 2014
Wow one of the mind blowing thread i have ever seen, it is really very good information and it is really very helpful to me. thank you sir. :)

macrumors 65816
Nov 10, 2006
Great right-up. I have to admit I haven't fully read and digested it all yet, but I wanted to bring up a thought on the issue of why Apple seemingly wants to keep the RAM capacity unchanged at 1 GB, RAM speed unchanged at LPDDR3-1600, and base flash storage capacity unchanged at 16 GB when they all seem due for upgrades.

Last year Apple bought AlgoTrim which specializes in various compression technologies including data and code compression. They claim their algorithms can achieve up to 50% reduction in code size with random access, fast decompression. In OS X, Apple has been doing compressed data storage since Snow Leopard and memory compression since Mavericks. iOS apps are currently delivered compressed before decompressing on device. Apple adopting a comprehensive data and code compression strategy in iOS/A8 based around AlgoTrim's techniques could explain the lack of RAM and flash upgrades.

Specifically, everything stored in flash memory and RAM could be stored compressed. The data and code could be decompressed transparently when transferred into CPU cache or maybe Apple could even modify the CPU such that everything can remain compressed deeper into the CPU pipeline perhaps decompressing at instruction decode. AlgoTrim claims up to 50% size reduction, but average reduction is no doubt lower. If AlgoTrim can achieve an average 33% size reduction as memory compression in Mavericks and iOS .ipa files seem to get, then the 1 GB RAM in the A8 presents the equivalent of 1.5 GB of uncompressed system memory, the LPDDR3-1600 can offer the equivalent bandwidth of uncompressed LPDDR3-2400, and 16 GB of flash memory has the equivalent of 24 GB of uncompressed storage. AlgoTrim's algorithms were software-based, but Apple could implement a hardware compressor/decompressor to save CPU cycles and power. Just speculation on my part, but it would be an interesting use of the AlgoTrim purchase.


macrumors 603
Original poster
Oct 29, 2007
Great right-up. I have to admit I haven't fully read and digested it all yet, but I wanted to bring up a thought on the issue of why Apple seemingly wants to keep the RAM capacity unchanged at 1 GB, RAM speed unchanged at LPDDR3-1600, and base flash storage capacity unchanged at 16 GB when they all seem due for upgrades.

Last year Apple bought AlgoTrim which specializes in various compression technologies including data and code compression. They claim their algorithms can achieve up to 50% reduction in code size with random access, fast decompression. In OS X, Apple has been doing compressed data storage since Snow Leopard and memory compression since Mavericks. iOS apps are currently delivered compressed before decompressing on device. Apple adopting a comprehensive data and code compression strategy in iOS/A8 based around AlgoTrim's techniques could explain the lack of RAM and flash upgrades.

Specifically, everything stored in flash memory and RAM could be stored compressed. The data and code could be decompressed transparently when transferred into CPU cache or maybe Apple could even modify the CPU such that everything can remain compressed deeper into the CPU pipeline perhaps decompressing at instruction decode. AlgoTrim claims up to 50% size reduction, but average reduction is no doubt lower. If AlgoTrim can achieve an average 33% size reduction as memory compression in Mavericks and iOS .ipa files seem to get, then the 1 GB RAM in the A8 presents the equivalent of 1.5 GB of uncompressed system memory, the LPDDR3-1600 can offer the equivalent bandwidth of uncompressed LPDDR3-2400, and 16 GB of flash memory has the equivalent of 24 GB of uncompressed storage. AlgoTrim's algorithms were software-based, but Apple could implement a hardware compressor/decompressor to save CPU cycles and power. Just speculation on my part, but it would be an interesting use of the AlgoTrim purchase.

A good point. I always miss something :)

I would expect applications to have a more economic footprint if they are implemented in Apple's new Swift language as well (not to be confused with A6 CPU codename).


macrumors 603
Original poster
Oct 29, 2007
Regarding the rumored 1GB of RAM, is it really worth jumping through the hoops of using AlgoTrim's memory compression algorithms just to save $5 on an additional GB of memory?
Seems crazy to me.

It's not only an issue of cost. For example, more memory would have a higher static power dissipation associated with refresh cycles.

I'm sure Apple uses memory profiling tools and does an evaluation of the impact on the end user.

macrumors 65816
Nov 10, 2006
Regarding the rumored 1GB of RAM, is it really worth jumping through the hoops of using AlgoTrim's memory compression algorithms just to save $5 on an additional GB of memory?
Seems crazy to me.
Besides capacity, there's also the bandwidth issue. LPDDR4 doesn't seem ready and the best LPDDR3 can do is 1866 MHz which is a negligible increase from the current 1600 MHz on a 64-bit memory bus. So even if they go 2 GB they'll still have to address memory bandwidth by either really increasing L3 cache if they stay at 64-bit or go to a 128-bit memory bus, both of which add cost, power, and heat. Implementing a data/code compression/decompression co-processor does have some cost and power consumption associated with it, but perhaps the ability to simultaneously address RAM capacity, RAM bandwidth, and flash capacity would make it worthwhile.

If I'm not mistaken, compression algorithms can often include encryption, and the ability to offer encryption throughout the memory hierarchy (cache, RAM, and flash) including the buses connecting them may be an interesting selling point to go alongside the addition of health and payment functionality and increased focus on corporate and government sales.


macrumors 68040
Jul 16, 2014
It's not only an issue of cost. For example, more memory would have a higher static power dissipation associated with refresh cycles.

I'm sure Apple uses memory profiling tools and does an evaluation of the impact on the end user.

First of all: you did a great job, this is really an interesting thread.

I agree on the fact that more memory means more dissipation and slightly more power consumption, so there is a little price you have to pay for a memory increase.
Memory compression is good on the Mac, but there's the swap to disk there, so they compress the memory to avoid reading/writing on the SSD.
iOS handles memory in a different way, if the OS needs more memory it simply closes an app, forcing it to restart from scratch next time. If they can avoid closing background apps simply by compressing their memory is ok, but what happens if the user continuously switch between apps, requiring the OS to compress/decompress memory?
Obviously they are profiling apps to find out the actual memory usage of an average user, but I really want 2GB of memory this time.
Maybe 1GB is more than enough for the average user, but given the price of iPhone I expect it to be fast for a "PRO" user as well


macrumors G4
Jan 8, 2012
It's not only an issue of cost. For example, more memory would have a higher static power dissipation associated with refresh cycles.

I'm sure Apple uses memory profiling tools and does an evaluation of the impact on the end user.

How do you feel this static power dissipation compares to apps being pushed from a suspended state and then immediately reloaded by the user? Example, using tapatalk, going to safari to reference information then returning back to tapatalk and it needs to reload the app and the user needs to dive back to the level they previously were. This is using CPU, GPU, screen and data (cellular or wifi).

Good post btw.


macrumors member
Jul 2, 2010
Can you take a look at the below datasheet from Hynix, and see if there's anything interesting that can be gleaned?


  • Mobile Product Decoder_20140901.pdf
    115.1 KB · Views: 1,442


macrumors 603
Original poster
Oct 29, 2007
Can you take a look at the below datasheet from Hynix, and see if there's anything interesting that can be gleaned?

Unfortunately it looks as though a smaller package and pinout smaller by 30 are the only differences. It's still curious why they need so many pins for a 2 channel interface though. I doubt Hynix will share that pinout though :)

How do you feel this static power dissipation compares to apps being pushed from a suspended state and then immediately reloaded by the user? Example, using tapatalk, going to safari to reference information then returning back to tapatalk and it needs to reload the app and the user needs to dive back to the level they previously were. This is using CPU, GPU, screen and data (cellular or wifi).

Good post btw.

That dynamic load would vary somewhat based on the user, but you're always refreshing all that RAM regardless of what you're doing. Not saying that I think it's the best reason, just that it's not only about cost.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.