AMD Announces Project SkyBridge: Pin-Compatible ARM and x86 SoCs in 2015, Android Support
by Anand Lal Shimpi on May 5, 2014 12:45 PM EST
This morning AMD decided to provide an update on its CPU core/SoC roadmap, particularly as it pertains to the ARM side of the business. AMD already committed to releasing a 28nm 8-core Cortex A57 based Opteron SoC this year. That particular SoC is aimed at the enterprise exclusively and doesn't ship with an on-die GPU.
Next year, AMD will release a low-power 20nm Cortex A57 based SoC with integrated Graphics Core Next GPU. The big news? The 20nm ARM based SoC will be pin compatible with AMD's next-generation low power x86 SoC (using Puma+ cores). The ARM SoC will also be AMD's first official Android platform.
I don't expect we'll see standard socketed desktop boards that are compatible with both ARM and x86 SoCs, but a pin compatible design will have some benefits for embedded, BGA solutions. AMD expects to target embedded and client markets with these designs, not servers.
AMD's motivation behind offering both ARM and x86 designs is pretty simple. The TAM (Total Addressable Market) for x86 is decreasing, while it's increasing for ARM. AMD is no longer married to x86 exclusively and by offering OEMs pin compatible x86/ARM solutions it gets to play in both markets, as well as benefit if one increases at the expense of the other.
Note that we're still talking about mobile phone/tablet class CPU cores here (Cortex A57/Puma+). AMD has yet to talk about what it wants to do at the high end, but I suspect there's a strategy there as well.
Facebook
Twitter
RSS
34 Comments
View All Comments
nevertell - Monday, May 5, 2014 - link
https://www.youtube.com/watch?v=oIIdnoNSeSESo they called it first. It's around 5-8 minutes. Well, maybe not precisely, but this could be the next step.
I think that if we go so far as to have x86 and arm cores on the same SoC to do roughly the same thing, we might as well just abstract the microarchitecture even further and just develop a custom ISA and a clock synced interpreter to execute assembly from different architectures on one piece of hardware.
name99 - Monday, May 5, 2014 - link
Spoken like a true (pseudo-) engineer.There's a certain class of people who spend their lives figuring out ways to virtualize and machines, regardless of the need --- seems to have something to do with the plasticity of the digital world and a theory that if something can be done it should be done. It's the same sort of mindset that gives us things like CORBA or OpenDoc or networked VM.
I've no doubt that someone, somewhere, will consider it a valuable use of resources to put a high-end ARM chip in an x86 box and then do a (likely half-assed) job of trying to get Android and Windows to run simultaneously and to share a filesystem, clipboard, network, and peripherals. I've substantially more doubt that this will ever be worthwhile.
Something like this is only worthwhile if you can articulate a convincing use case. Such a use case would be (in principle) something like:
- OK we'll add a small screen to the outside of a laptop then
- we'll have Android running on the ARM and it will
- display on the screen whatever notifications, etc, come in to the laptop
Sounds cool, right? The question is, how is this more useful than what your phone does today? Who is it easier to implement than the more general solution of having your phone send notifications to a wearable on your wrist? Working hard to solve a problem that only exists in one person's mind ("What about people without phones? What about email accounts that I have on my computer but not my phone?") is precisely the kind of pseudo-engineering I mentioned at the start of this comment.
Kevin G - Monday, May 5, 2014 - link
Agreed. A full hybrid ARM + x86 chip brings all the compromises and few of the benefits of each platform.The idea of cramming two architectures into one chip has been done before: IBM's PowerPC 615 project. Its goal was to bridge the x86 and PowerPC markets together roughly 20 years ago. It never made it to market as the software side was too ugly. There was a bit of office politics involved (MS didn't want to support a hybrid then) but numerous bugs in BIOS and drivers. It was far from stable. The market has matured significantly in 20 years but the technical pieces that made the PowerPC 615 a challenge haven't changed.
The only advantage to a hybrid ARM + x86 design would be in servers for virtualization purposes (where the chip's hybrid nature is not exposed) or as a mainframe-like coprocessor. In the coprocessor scenario, both architectures can address memory but the front end of an application will only deal with one particular architecture (presumably x86). Delegating specific functions or the entire backend to ARM with some abstraction isn't a big deal: it is what modern GPU's do today. Like today, the coprocessor arrangement will have some overhead dependency on the host processor. There are a few niche areas like storage and networking where embedded an ARM coprocessor would be advantageous.
fallaha56 - Monday, May 5, 2014 - link
would we not be more likely to see a BIG.little approach with x86 cores? jaguar+steamrolleror is the AMD big core so bad, so Pentium 4 that they should just take jaguar and run with it?
or BIG.little ARM?
Kevin G - Monday, May 5, 2014 - link
The problem for big.LITTLE between just x86 cores is that the dynamic power range of designs has a lot of overlap already. AMD's Jaguar cores can scale to moderate clock speeds given a bit of voltage. It'd only be under absolute load that a Steamroller derived core would awaken to handle the load. The cost-benefit of adding a steamroller module simply wouldn't be worth it for as frequently as it'd be used. The die space would be better off spent as more cache, more GPU functionality and//or more IO on the SoC.This doesn't preclude the idea of big.LITTLE with any of their future x86 designs. I personally just don't see it likely given the extra power budget in laptops, desktops and servers that the x86 platform is dominate in.
tuxRoller - Monday, May 5, 2014 - link
The problem is you didn't provide a convincing use case (since you so easily deconstruct it).Running torrents would be a great use for ARM. Basically any long running tasks that don't need huge amounts of single thread performance.
The_Assimilator - Monday, May 5, 2014 - link
Because exactly what everyone needs is for Android to be even slower.TheSlamma - Tuesday, May 6, 2014 - link
Exactly. Quad core 2.4 Ghz 2GB of RAM just to make it run on par and in many cases slower than iOS and Windows phone OS. Never understood the fascination with that OS, it's an embarrassment to the Linux Kernel.sonicmerlin - Wednesday, May 7, 2014 - link
People vehemently deny seeing any lag or stuttering... Until you specifically point it out to them. Then they say "it doesn't affect me, I don't even notice it." Sigh...Anders CT - Monday, May 5, 2014 - link
A SoC with both arm and x86 cores would be very neat. You could have an android laptop, runining legacy x86 software under WINE or simmilar compatibility layer.