Patrick "at" MoorInsightsStrategy "dot" com

07 May AMD Infuses Ambidextrous into Their Core DNA

Six quarters ago AMD announced its “ambidextrous” strategy for creating processor product lines based on x86 and ARM 64-bit instruction sets. On Monday AMD clarified a lot of their direction for that strategy. AMD gave us an interesting look at forward-looking SoC and systems architecture and also at frugal use of design resources via core co-development, design element reuse, and common hardware and software interfaces. While these will reduce AMD’s R&D costs, they will also have a beneficial impact on AMD’s ability to rapidly customize products for specific markets and to leverage SoC peripheral software driver development between their x86 and ARM products.

Before I focus on AMD, I’ll point to Table 1, a short and very much simplified review on ARM intellectual property (IP) licensing options for processor cores and core complexes (clusters of cores with associated IP included). My point in this table isn’t to compare licensing options for different cores or generations of instruction set, but instead to compare options once a customer has decided to license a specific ARM product, say the 64-bit ARMv8 instruction set in a big core format, like the ARM Coretex-A57.

Table 1: ARM Licensing Options for Processor Core IP

  Licensed Core IP Design Investment Time-to-Market Back-End Royalties Why Do It?
1. Crawl “Hard macro” from foundry plus validation – drop a black box into your design Low 9-18 Months High Low volumes, rapidly changing products
2. Walk RTL plus verification and validation tools from ARM – quick start for custom layout Medium 2-ish Years Medium Reduce production costs, opportunities for light customization
3. Run Specification document plus verification and validation tools from ARM – a DIY (do it yourself) project, the fabled “architecture” license High 3-4+ Years Low Optimize production costs, maximize market differentiation

Monday AMD demonstrated its 64-bit ARM-based AMD Opteron A-Series processor, code named “Seattle,” running the Fedora OS. AMD looks to be on track for Seattle production release in Q4.

Seattle will contain four (4) to eight (8) ARM Coretex-A57 cores. GlobalFoundries is an ARM IP partner as well as a close foundry partner to AMD – neither has disclosed which party is responsible for layout, verification and validation of Seattle’s 28nm cores, but I suspect that AMD skipped the crawl step and licensed the RTL. That makes sense in that I believe AMD will use Seattle to pave the way for the K12 architecture, also announced at the same time, in terms of market readiness. Seattle will enable AMD to familiarize itself with ARM’s IP ecosystem and allow AMD to fine tune their plans for K12, such as the features they might integrate on future K12 SoCs and their relative performance investments, as well as hardware and software development tool plans.

That brings me to AMD’s really big announcements: K12 and SkyBridge.

First K12 and AMD’s much awaited confession that, yes, they have an ARMv8 instruction set architecture license. This is important from the perspective that AMD is trying to focus its design resources and not overreach for its R&D footprint. It is also important from a design goal perspective – it looks like AMD is not trying to create the highest performance core platform with K12, nor are they trying to create the lowest power core platform.

From a market perspective, it looks like K12 will not address markets for smaller mobile devices – perhaps smartphones as a whole – nor will they address server markets for big, hot sockets – converged and virtualized F500 core enterprise IT building blocks.

AMD appears to be aiming for the middle, a fairly wide range of features and performance points optimized for the power consumption expected by each market.

Jim Keller, K12’s architect, described the K12 architecture as a modular processor core architecture, where large portions of the 64-bit design could be leveraged for both x86 and ARM instruction sets. The front-end instruction decoder would obviously be different for each of the instruction sets. Behind the decoder there are opportunities to optimize some of the blocks for either x86 or ARM (and for performance vs. power consumption), but in general he indicated there would be a lot of common functional blocks and design element reuse.

AMD has a long history of analyzing x86 server workload performance, and has assembled a competitively differentiating collection of test vectors over the last dozen years. There is not a similar body of server test vectors for ARM anywhere in the industry, which puts AMD is in a unique position in the ARM server competitive arena – it will take years for their competitors to generate similar insight into server workload performance and then translate that insight into an optimized processor core architecture and overall SoC design.

This level of core architecture innovation is not possible without an ARM architecture license.

At a system level, AMD’s “Project SkyBridge” appears to be an even more aggressive design leverage strategy. AMD says it a design framework that can be customized for specific markets and products. I don’t believe there is anything in what we used to call “northbridge” and “southbridge” functionality that should remain intrinsically x86 or ARM based. The PC and x86 server markets have moved to UEFI and ACPI to describe low-level chipset and SoC feature sets. I think AMD sees things similarly and is taking the opportunity while implementing their ambidextrous strategy to drop some of the ancient, legacy x86 system design complexity (i.e. “cruft”) and streamline their platform design to share it with upcoming ARM-based SoCs.

SkyBridge has two major benefits for AMD:

  1. All of AMD’s K12 core x86 and ARM SoCs will share the same menu of system design components and peripherals. AMD will be able to leverage I/O, network, graphics, and compute offload driver development across both instruction sets. The implication is that a Linux or Microsoft based OS on either an x86 or an ARM flavor of an AMD SoC will see (nearly?) identical drivers. That is a really big deal for both SoC deployment and for support. This will be a clear benefit to AMD in winning the attention of OS, hypervisor, software stack (such as LAMP and OpenStack) and applications software developers.
  2. Pin compatible x86 and ARM SoCs will enable the hyperscale server supply chain to leverage a small set of AMD reference board designs across many products. Typically an OEM or a major service provider (such as Google) might ask an ODM for a slightly customized version of a board design already in the ODM’s library. Intel and AMD have a long history of supplying the basic reference designs the ODMs use as starting points. Separate x86 and ARM reference designs would mean more design cost for AMD and less design reuse for an ODM or contract manufacturer. By enabling x86 and ARM to fit into a common server socket, AMD can reduce friction in their supply chain and decrease customer time-to-market.

Looking back at Seattle, Jim said that SkyBridge would not appear in AMD’s server products until 2016, coincidentally with their K12 core architecture. That’s probably a major reason why AMD cannot match their x86-based server APUs with an ARM-based APU until K12 and SkyBridge.

So, Seattle will be interesting this year, but it will be a relatively small step for AMD. 2016 should see AMD take a much larger leap forward.


Comments are closed.