So this story came out of nowhere. Whether the rumors are true or false, I am stuck on how everyone seems to be talking about it with a casual deadpan. I spent a couple hours Googling whether I missed some big announcement that made Intel potentially fabricating ARM chips a mundane non-story. Pretty much all that I found was Intel allowing Altera to make FPGAs with embedded ARM processors in a supporting role, which is old news.
Image Credit: Internet Memes…
The rumor is that Intel and TSMC were both vying to produce LG's Nuclon 2 SoC. This part is said to house two quad-core ARM modules in a typical big.LITTLE formation. Samples were allegedly produced, with Intel's part (2.4 GHx) being able to clock around 300 MHz faster than TSMC's offering (2.1 GHz). Clock rate is highly dependent upon the “silicon lottery,” so this is an area that production maturity can help with. Intel's sample would also be manufactured at 14nm (versus 16nm from TSMC although these numbers mean less than they used to). LG was also, again allegedly, interesting in Intel's LTE modem. According to the rumors, LG went with TSMC because they felt Intel couldn't keep up with demand.
Now that the rumor has been reported… let's step back a bit.
I talked with Josh a couple of days ago about this post. He's quite skeptical (as I am) about the whole situation. First and foremost, it takes quite a bit of effort to port a design to a different manufacturing process. LG could do it, but it is questionable, especially for a second chip ever sort of thing. Moreover, I still believe that Intel doesn't want to manufacture chips that directly compete with them. x86 in phones is still not a viable business, but Intel hasn't given up and you would think that's a prerequisite.
So this whole thing doesn't seem right.
Intel could have designed its
Intel could have designed its own RISC micro-architecture and developed the software ecosystem to go along with it for the same amount of money it wasted on contra revenue alone. Intel wasted billions with very little mobile phone market share to show for the billions spent on contra revenue. Intel is all about the high margin CPU/SOC business and is very likely to avoid the low margin ARM ISA based market where profit margins are razor thin. The only reason that Intel would even consider fabricating an ARM based SOC is to keep its expensive to maintain fab capacity from costing Intel too much to maintain. Fab capacity is expensive enough to maintain, and excess fab capacity is an even more expensive cost if the chip fab is not operating at as close to full capacity as possible.
The only ARM based micro-architectures currently that are any threat to Intel’s x86 is the custom micro-architectures that are engineered to run the ARMv8A ISA. ARM holdings’ reference design(A53, A57, and A72) designs are all narrower order superscalar designs that can only execute 3 IPC, while Apple’s A7 for example is a custom wider order superscalar design that can execute 6 IPC, so Intel would not have that much competition from ARM Holdings’ reference design cores! AMD’s K12 custom micro-architecture, if it has SMT and shares the same basic design tenets as Zen in execution resources, will be Intel’s biggest threat for a custom ARMv8A ISA running micro-architecture. AMD will be able to have an ARM based tablet SKU that can very likely beat Apple’s custom ARM designs, and add to that AMD’s GPU IP on an custom ARM based APU, and AMD could have a definite advantage over the other custom ARM micro-architecture players.
the first picture clear
the first picture clear applies to myself. i wasnt aware that LG had opted to jump into the Arm soc war. makes sense tho i guess…all the other guys are doing it no? and what a difference a few years and a shot at the “nexus” line make huh?? this LG… watch out sammie! rofl 😉
i like the speculation in regards to intel even considering anything other than x86 also. especially how amd comes into play, and how their potential portfolio would ultimately affect intel’s decision in this space. sounds plausible enough.
and this may be a silly question, but given my ignorance in lg’s recent doings, it should come as no surprise. is attempting to chase after the holy unicorn of high performance computing in extremely low power envelopes with Cisc, an exercise in futility?? and although the answer may ultimately lie in the current state of battery technologies more than anywhere else, is not that the whole point in the first place? to someone with very limited knowledge in this field, it would seem very silly to truly expect x86 to compete with Arm unless something drastic happens in battery tech that allows us to cram 10x mAh into the same form factor. and even then, is still not ‘energy efficiency’ the name of the game? granted, a 300k mAh capable device would make the energy inefficiencies of x86 almost moot (as is the case in laptops), and allow the performance of the architecture to stand unencumbered. but imagine what a arm soc could do with that kind of power reservoir. or how ‘long’ it could do it for rather… until battery technology matures to the point where one could realistically, and safely, assume that a full charge on their device would see them through an entire business week of usage, w/o needing a recharge, ‘energy sipping’ Arm Socs seem like the way to go. i dunno, thats they way it seems to me. going throughout one’s day, with all the various locations of potential power sources ruminating in the back of your mind is not ideal…let alone truly mobile. it is a type of behavior with which many can empathize and would soon see go away.
RISC and CISC do not really
RISC and CISC do not really apply to modern processors. The original RISC processors had a much smaller and much simpler instruction set compared to modern processors. Modern processors are not clearly RISC or CISC. Instructions which accomplish more work are actually favored since they essentially compress the instruction stream. L1 instruction cache is very limited. The thing that hurts performance and power consumption is complex encodings and/or variable length encodings. Modern compilers will tend to not use such instructions though. It would be interesting to look up how much of the x86 instruction set is still actually used in AMD64 compilers. It contained a lot of addressing modes and other stuff which would not be suitable to a modern processor. Many of those instructions are essentially deprecated; the hardware will still handle them, but the compilers will not issue them. The processor would probably just invoke some microcode to handle them. The x87 FP code should mostly not be used anymore.
It has been said that the decode overhead for power consumption is very small. I don’t know if that is actually the case, but it seems believable. Most of the instructions that compilers normally generate will be highly optimized for performance and power. The barrier for pushing AMD64 into the mobile market is quite high for other reasons. Most companies will not want to use an AMD64 processor even if it had similar power consumption because it would limit their suppliers. Many companies offer ARM processors, and many companies are making their own. For buying AMD64 processors, they would be limited to Intel or AMD; I believe Via still has a license also. They can’t make their own AMD64 processors either.
The other issue is the software. I don’t know how this even works currently for the few AMD64 based devices on the market. With almost the entire market being ARM based (on iOS or Android), there doesn’t seem like there will be much support for AMD64 devices.
It takes more transistors to
It takes more transistors to implement a CISC micro-architecture compared to a RISC micro-architecture in the core hardware on a microprocessor, so CISC ISAs like the x86 will consume more power. So by the laws of physics a CISC based microprocessor’s more transistors turning on and off will consume more power and leak more current/produce more heat relative to a RISC ISA based microprocessor with less transistors to tun on and off, leak current, and generate heat.
Sure Intel can power gate its processor’s cores more aggressively, but when the CPU cores are running full powered on, the CISC based micro-architecture will consume/waste more power. CISC micro-architectures also have to be engineered to run some of their execution units in multiples of the processor’s clock to get those complex instructions more able to execute a complex instruction in a single clock cycle if possible, so some transistors on CISC microprocessors can and do run at multiples of the processor’s clock. The same can be said for RISC processors, but RISC processors have less complex ISAs that need less of this type of multiple transistor clocking to get their simpler instructions executing in single clock cycles if possible.
So CISC x86 ISA base microprocessors are always going to be at a disadvantage compared to RISC based microprocessors for the power usage metric! So Intel’s x86 based processors at 14nm are still having troubles relative to the ARM based processors that are fabricated at 28nm in the power usage metrics! Now the custom ARM ISA based processors are being fabricated at 14nm/16nm and that lower transistor count power usage metric is even more pronunced.
I believe your cisc vs risc
I believe your cisc vs risc concepts are a bit out-dated. Current risc arch have evolved and now include cisc ideas like simd, hardware fp, ooo, etc. Likewise cisc arch have evolved towards risc philosophies. My point is, you can no longer say one is good and the other is bad, the story is more complex and depends on the cpu at hand.
Read this: http://archive.arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html
Sry, tried to comment to:
Sry, tried to comment to: December 2, 2015 | 04:05 AM – Posted by Anonymous (not verified)
Sure the RISC ISA based ARM
Sure the RISC ISA based ARM Processors have their Neon/SIMD instructions/other instructions, but RISC designs still use less transistors than CISC ISA processors! The ARM based SOC/APU processors also have GPUs with more Execution resources relative to Intel’s GPU execution resources. So for the ARM based SOC/APU designs the PowerVR, Mali, AMD, or Nvidia based GPUs that are used in SOCs/APUs can have their GPUs running at lower clocks relative to Intel’s GPU cores which are clocked higher to make up for the deficiencies in EU/CU/other GPU execution units counts. Lower clocks save on power usage/heat generated.
The PowerVR GPU cores on Apple’s A9X can be clocked lower and still achieve more effective work, dew to having more execution resources able to be operated in parallel at lower clock speeds. The amount of HSA style compute offloaded to the GPU cores on mobile SOCs/APUs is even more utilized in the mobile market, and wait until the Vulkan graphics/HSA compute API begins to be utilized, then even more GPGPU work will be done on the GPUs FPU/other units.
So the GPU designs with more AMD like HSA aware Hardware with asynchronous compute designed into the GPU’s hardware will have even more advantages. GPUs with more execution resources in parallel will be able to be clocked lower while still maintaining more effective work done relative to GPUs with less execution resources in parallel that have to be clocked higher to get the same amount of work done, and high clocks mean more power wasted.
AMD’s GPU IP even on its x86 based SKUs will still offer advantages over Intel’s GPUs for mobile devices. AMD will also have its K12 custom ARMv8A ISA running micro-architecture to go lower power into the mobile market devices, with AMD’s HSA aware GPU graphics IP to complement its Custom ARM cores in the mobile market that has embraced fully the design tenets of the HSA foundation, just look at the HSA foundation’s membership list. When the APUs on an interposer begin to become available the power savings, as well as space savings will become even more advantageous for those using the interposer technology.
AMD even has a method to get more processor circuity on a given process node for CPU cores in using its high density design libraries to design a CPU core for mobile usage and get 30% more space savings without having to do a die shrink. Those high density design libraries will allow AMD to put more CPU cores per unit area at 14nm/16nm than anyone using low density design libraries for CPU core layout. With AMD’s future APUs able to have more CPU cores relative to Intel’s CPU cores on the same fabrication process node AMD could use more CPU cores and clock the cores lower and let the Vulkan API/other OS resources manage its CPU cores better while also offloading more compute to AMD’s ACE units on its GPU cores that have more execution resources than Intel’s GPU cores have.
So more parallel resources operating at lower clock speeds may be the way to go for mobile CPUs as well as the parallel usage that GPUs take advantage of to get more work done at lower clock speeds, it all depends on the usage model for the devices that the SOCs are going to be used in.
The Vulkan API will be used extensively in the mobile market so those without the hardware resources to fully utilize the Vulkan API will be at more of a disadvantage.
Apple will probably bake a lot of the Vulkan/Mantle IP into its Metal API, and AMD definitely allows for that as Apple is a big user of AMD’s GPU hardware.