Intel in Talks to Fab ARM Cores! (Rumor)

[MisterMac]

IDC:

Given a scenario where Intel would be forced\willing to design an ARM SoC(for it self).

How do you think it would fare?


Would the design talent completely destroy every single other competitor in the ARM Space?

would the foundry advantage?

Or would it be slighty worse/better due to one or both of the above?

 

[Haserath]

Unless I am mistaken, there are no phones shipping with an A15 atm.

RAZR i is shipping now

The iPhone 5 has a derivative of the A15 with its "swift"core.

The Nexus 4 also has an A15.

And Apple's swift blows them away...

 

[Idontcare]

IDC:

Given a scenario where Intel would be forced\willing to design an ARM SoC(for it self).

How do you think it would fare?


Would the design talent completely destroy every single other competitor in the ARM Space?

would the foundry advantage?

Or would it be slighty worse/better due to one or both of the above?

I'm not convinced it would pan out like that. Intel didn't dominate HPC with Itanium despite access to that design talent and leading-edge process nodes. Nor did it deftly bring said resources to bear on the discrete GPU market with its larrabee efforts.

In theory it should work out like, in theory they should have no excuse for not dominating any given segment with a superior IC (both superior in design and superior in process-node characteristics)...so far they only seem to fire on all cylinders when it involves x86 mainstream designs (both Larrabee and Atom were/are x86 and they haven't exactly dominated to date).

Another datum point is the fact that Intel use to design/produce their own ARM chips (StrongArm and, later, XScale) and yet they did not dominate their competitors in the same space.

Intel, for all its highly visible successes, is like that baseball slugger who steps up to the mound and swings wildly at every pitch with reckless abandon giving no consideration for whether or not the ball is high, low, outside, etc all while looking up at the grandstands because it expects that ball to be a homer, it ain't swinging to make singles or doubles, RBI's are not the strategy, it wants a homerun and nothing less, each and every time...only more often than not it strikes out and gets to go take a seat in the dugout.

 

[MisterMac]

I'm not convinced it would pan out like that. Intel didn't dominate HPC with Itanium despite access to that design talent and leading-edge process nodes. Nor did it deftly bring said resources to bear on the discrete GPU market with its larrabee efforts.

In theory it should work out like, in theory they should have no excuse for not dominating any given segment with a superior IC (both superior in design and superior in process-node characteristics)...so far they only seem to fire on all cylinders when it involves x86 mainstream designs (both Larrabee and Atom were/are x86 and they haven't exactly dominated to date).

Another datum point is the fact that Intel use to design/produce their own ARM chips (StrongArm and, later, XScale) and yet they did not dominate their competitors in the same space.

Intel, for all its highly visible successes, is like that baseball slugger who steps up to the mound and swings wildly at every pitch with reckless abandon giving no consideration for whether or not the ball is high, low, outside, etc all while looking up at the grandstands because it expects that ball to be a homer, it ain't swinging to make singles or doubles, RBI's are not the strategy, it wants a homerun and nothing less, each and every time...only more often than not it strikes out and gets to go take a seat in the dugout.

Interesting viewpoint - Itanium was made out of necessity however.
A solution to a problem fast becoming - a huge block for everyone.

I think if AMD had done their own set - while intel delivered a x86 backwards compatible ISA - most people would have just taken it.
They chose the easy road - wether or not itanium is a good ISA.


Too early to tell with MIC\Knights imho - but i geuss well see.



I kinda agree - and i find it weird that they're strategy is pretty much ALL IN or bust.
It's either number 1 or nothing - Intel does not want 2nd.


I would imagine if they did a custom ARM SoC - with the x86 R&D something crazy should pop out.

 

[Haserath]

Intel doesn't want second place, because what happens to second place in the technology industry?

 

[podspi]

The iPhone 5 has a derivative of the A15 with its "swift"core.

The Nexus 4 also has an A15.

And Apple's swift blows them away...

Nexus 4 is QC-Krait, not A15. Swift also is not an A15, it is custom-designed. How custom designed I won't pretend to know, though.

I think people's opinions of Atom will be forced to change when the 22nm refresh comes along. A combination of improvement in the Atom, and high-energy use (reportedly) in the swill change people's perceptions.

Krait and Swift make a lot of sense as products because they allow decent power efficiency without a Big.little configuration that A15 apparently requires.

 

[Nemesis 1]

CPU instruction set is no longer relevant today and it is easy to port. They do use x86 for OSX so they know how to do it anyways. The point is, for the same amount of die space, x86 is not scaling well for power and heat vs ARM on the same node size (i.e. 22nm). There is a reason why everyone use ARM right now, and x86 is losing out not because of monopoly but of power and heat.

Integrating SSD controller on the same die is very risky, by the time you are done with one design it needs to be changed for different generation of NAND chips. A lot of the hardware accelerating part of the SSD controller is designed to overcome NAND's weakness of the generation, primarily increasing block size and erase time, as well as parallelism of the number of chips to use. You either overpay for the NAND controller by putting it into the x86 CPU or you underdesign and have problem. Also a major part of SSD controller is to represent a LBA interface to the x86 OS like OSX, Linux, and Windows. A phone OS do not need to know all that as they can do wear leveling at higher level inside the OS. All they need is a small amount of code and interface to do what is needed, and can lay out files more efficiently without worrying about fragmentation or alignment to block boundary.

NAND and DDR are usually used at the same time because a lot of the processing are done before writing to NAND, and the amount of ram needed is in DDR, so it make sense to have both dedicated instead of MUXed. You need that for performance anyways and even the baseband chips from Qualcomm have them dedicated, so why should an AP like A6 or CPU like x86 have to share them?

Nothing could be further from the truth. Intels Medfield is the First Intel design that actually is exceptable in phone format. Its intels baby step into the market . Intel went from zero Phones to having 2 that I know of . Thats a hugh increase from the year earily results which was Zero phones. Arm was in the market from the beginning . What your saying is the same as me saying Arm hasn't got the performance of Intel X86 processors which at THIS time would be a true statement . Intel will take 1000x more Arm space than arm gets in the big core race to performance . Intel already is producing a 62 core chip . SArm is building from the low end to the top end . Intel is going from top down to bottom . The First Atom chips cost intel $6 dollars to produce . Its cheaper than that now . So I see a $20 Atom chip as being just inside 60% margins. When intel goes to 22nm and 14 nm those margins will rise. Right now Intel leads in this race . Unless you can point out an Atm server chip that is hurting intel at this time . Medfield is real as much as you guys want to discount it . Its real and opened the door wide for intel .


Even tho olds was the first assembly line car made in the world (425 curved dash) and lead sales in 1901-1904. 12 years later Henry ford reinvented the assembly line and thats were the real story begins

 

[ShintaiDK]

Intel went from zero Phones to having 2 that I know of .

Lava XOLO X900
Lenovo K800,
Motorola RAZOR I
Motorola MT788
ZTE Grand X IN
Megafon Mint
Orange San Diego

Thats those I know of atm.

 

[NTMBK]

Lava XOLO X900
Lenovo K800,
Motorola RAZOR I
Motorola MT788
ZTE Grand X IN
Megafon Mint
Orange San Diego

Thats those I know of atm.

To be fair a few of those are just rebrands of Intel's reference platform (Lenovo K800, Orange San Diego, Megafon Mint [?] ). But yeah, it's a definite improvement on the position they were in.

 

[TerryMathews]

Does anyone besides me remember when Intel made the fastest ARM chips?

Yeah, I bet someone regrets spinning that off.

 

[CA19100]

Also remember that Apple did switch from others architectures and didn't give a damn about backward compatibility.

Absolutely incorrect. Apple went to great lengths to ensure backward compatibility.

When Apple switched from PowerPC to x86 in early 2006, the OS included software called Rosetta that dynamically -- and invisibly -- interpreted older PowerPC code to run on the new processor. It required no extra steps for the user, nor a second installed operating system. Users simply launched their old software and it would work as it always had. It worked very, very well.

 

[ShintaiDK]

Does anyone besides me remember when Intel made the fastest ARM chips?

Yeah, I bet someone regrets spinning that off.

ARM itself doesnt make much money.

What makes alot of money is, that you can take a sub 200$ BOM phone and sell it for 599$ And on top of that make people buy a new one every year. With little to no software support for the old one.

 

[Idontcare]

Absolutely incorrect. Apple went to great lengths to ensure backward compatibility.

When Apple switched from PowerPC to x86 in early 2006, the OS included software called Rosetta that dynamically -- and invisibly -- interpreted older PowerPC code to run on the new processor. It required no extra steps for the user, nor a second installed operating system. Users simply launched their old software and it would work as it always had. It worked very, very well.

No question, Apple managed that transition with aplomb.

 

[mrmt]

When Apple switched from PowerPC to x86 in early 2006, the OS included software called Rosetta that dynamically -- and invisibly -- interpreted older PowerPC code to run on the new processor. It required no extra steps for the user, nor a second installed operating system. Users simply launched their old software and it would work as it always had. It worked very, very well.

Rosetta had a fair share of limitations:

http://en.wikipedia.org/wiki/Rosetta_(software)
Rosetta does not support the following:

The Classic environment, and thus any non-Carbon application built for Mac OS 9 or earlier

Code that inserts preferences into the System Preferences pane

Applications that require a G5 processor

Applications that require precise exception handling

Screen savers

Kernel extensions and applications that depend on them

Bundled Java applications or Java applications with JNI libraries that can’t be translated

Java applets in Rosetta-translated applications, meaning that a native Intel web browser application, rather than a legacy PowerPC version, must be used to load Java applets

So while it wasn't a doomsday scenario where nothing you had would work, there were things that wouldn't and still apple switched architecture. If needed, why wouldn't apple do the same again?

 

[CA19100]

Rosetta had a fair share of limitations:

Of course, although some of them really didn't affect the vast majority.

The Classic Environment was probably the one that affected the most people, and even then, it was only used for applications that hadn't been updated for OS X, which had been out for five years prior to that.

I never had a single application that required G5-specific processor code. Some super-high-end software may have required a G5, but I never ran across it.

I ran a pretty wide variety of software, and by the time I had moved to an Intel-powered Mac, I don't think I had anything left in my library that hadn't been updated enough to at least run under Rosetta. Most of my stuff at that point had been updated to Universal applications, with code for both CPUs in it.


In any case, my point was that they went to great lengths for the sake of backwards-compatibility, and I have no reason to think they wouldn't do it again if the iOS devices ever switched platforms. They want to make sure the cash cow (app store) keeps mooing.

 

[2is]

Why are you implying fragmentation? Medfield runs most of the android apps fine. If they port iOS for x86 they could get a similar effect. Also remember that Apple did switch from others architectures and didn't give a damn about backward compatibility. If there is one company who can do that, it is Apple.

Personally I see here a win-win situation. Apple gets the best fab available, Intel gets a lot of insights on SoC design.

Yeah apple switched architecture because PPC was falling well behind x86. ARM is advancing at a very rapid rate and ensures everything works the same on all there mobile devices. No emulation, no taking the chance of running "most" apps. That's fragmentation. And when Apple switched to x86, the moved their entire product line to it so no fragmentation. It's not gonna happen, I'll put money on it, will you?

 

[pablo87]

Does anyone besides me remember when Intel made the fastest ARM chips?

Yeah, I bet someone regrets spinning that off.

I don't think they regret it. The purpose to acquire StrongARM and hold onto it for a while was probably to kill it off softly with Intel's bureaucracy.

Same thing happened with Atom - its all about protecting x86 AND ASP.