It Begins: AMD Announces Its First ARM Based Server SoC, 64-bit/8-core Opteron A1100
by Anand Lal Shimpi on January 28, 2014 6:35 PM EST- Posted in
- CPUs
- IT Computing
- AMD
- Arm
- Opteron
- Enterprise
- Enterprise CPUs
- Opteron A1100
Around 15 months ago, AMD announced that it would be building 64-bit ARM based SoCs for servers in 2014. Less than a month into 2014, AMD made good on its promise and officially announced the Opteron A1100: a 64-bit ARM Cortex A57 based SoC.
The Opteron A1100 features either 4 or 8 AMD Cortex A57 cores. There's only a single die mask so we're talking about harvested die to make up the quad-core configuration. My guess is over time we'll see that go away entirely, but since we're at very early stages of talking about the A1100 there's likely some hedging of bets going on. Each core will run at a frequency somewhere north of 2GHz. The SoC is built on a 28nm process at Global Foundries.
Each pair of cores shares a 1MB L2 cache, for a total of up to 4MB of L2 cache for the chip. All cores share a unified L3 cache of up to 8MB in size. AMD designed a new memory controller for the Opteron A1100 that's capable of supporting both DDR3 or DDR4. The memory interface is 128-bits wide and supports up to 4 SODIMMs, UDIMMs or RDIMMs. AMD will be shipping a reference platform capable of supporting up to 128GB of Registered DDR3 DIMMs off of a single SoC.
Also on-die is an 8-lane PCIe 3.0 controller (1 x8 or 2 x4 slot configurations supported) and an 8-port 6Gbps SATA controller. AMD assured me that the on-chip fabric is capable of sustaining full bandwidth to all 8 SATA ports. The SoC features support for 2 x 10GbE ports and ARM's TrustZone technology.
AMD will be making a reference board available to interested parties starting in March, with server and OEM announcements to come in Q4 of this year.
It's still too early to talk about performance or TDPs, but AMD did indicate better overall performance than its Opteron X2150 (4-core 1.9GHz Jaguar) at a comparable TDP:
| AMD Opteron A1100 vs. X2150 | |||||||||
| CPU Core Configuration | CPU Frequency | SPECint_rate Estimate | SPECint per Core | Estimated TDP | |||||
| AMD Opteron A1100 | 8 x ARM Cortex A57 | >= 2GHz | 80 | 10 | 25W | ||||
| AMD Opteron X2150 | 4 x AMD Jaguar | 1.9GHz | 28.1 | 7 | 22W | ||||
AMD alluded to substantial cost savings over competing Intel solutions with support for similar memory capacities. AMD tells me we should expect a total "solution" price somewhere around 1/10th that of a competing high-end Xeon box, but it isn't offering specifics beyond that just yet. Given the Opteron X2150 performance/TDP comparison, I'm guessing we're looking at a similar ~$100 price point for the SoC. There's also no word on whether or not the SoC will leverage any of AMD's graphics IP.
The Opteron A1100 is aimed squarely at those applications that either need a lot of low power compute or tons of memory/storage. AMD sees huge demand in the memcached space, cold storage servers and Apache web front ends. The offer is pretty simple: take cost savings on the CPU front and pour it into more DRAM.
Early attempts at ARM based server designs were problematic given the lack of a 64-bit ARM ISA. With ARMv8 and the Cortex A53/A57 CPUs, that's all changed. I don't suspect solutions like the Opteron A1100 to be a knockout success immediately, but this is definitely the beginning of something very new. Of all of the players in the ARM enterprise space, AMD looks like one of the most credible threats. It's also a great way for AMD to rebuild its enterprise marketshare with a targeted strike in new/growing segments.
AMD's Andrew Feldman included one of his trademark reality check slides in his Opteron A1100 presentation today:
Lower cost, high volume CPUs have always won. That's how Intel took the server market to begin with. The implication here is that ARM will do the same to Intel. Predicting 25% of the server market by 2019 may be feasible, but I'm not fond of making predictions for what the world will look like 5 years from now.
The real question is what architecture(s) AMD plans to use to get to a leadership position among ARM CPUs and a substantial share of the x86 CPU market. We get the first hint with the third bullet above: "smaller more efficient x86 CPUs will be dominant in the x86 segment".
Facebook
Twitter
RSS
122 Comments
View All Comments
tuxRoller - Wednesday, January 29, 2014 - link
You wouldn't run cad tools on these.There's no reason to target an isa when writing a VCS.
Java.
Also, there's a reason why fedora is the go to distro on these boards: RH is going to get into this space pretty soon. In the meantime you simply don't use them for mission critical activities.
factual - Wednesday, January 29, 2014 - link
CAD tools' performance is mission-critical so they are not written in Java, they are written in C or even assembly for best performance. VCS which is a Synopsys tool does not currently have an ARM-compatible version available, neither does any other Synopsys, Cadence, Ansys, Mentor, .. tools.tuxRoller - Thursday, January 30, 2014 - link
I've no idea what kind of crap codebase these cads are based upon but I doubt they would be in assembler. If you could provide an example of a cad operation where assembly is necessary I'd be grateful. My point was not that they are written in java (I've no idea what they are written in since I don't see that as something they would advertise) by r that the company can perform a recompile if their toolchain isn't useless.My point, in general, is that as long as you aren't making use of assembler, which I can't see any of these programs doing, the companies can recompile to armv8.
factual - Thursday, January 30, 2014 - link
I remember reading a paper about critical parts of CAD programs being written in assembly for maximum performance (http://www.fourmilab.ch/autofile/www/subsection2_3...That being said, they are mostly written in C/C++ (http://www.linkedin.com/jobs2/view/6473323) and most people who've tried porting complex c code to a different ISA know that it's not as easy as using a different compiler. There are many x86-specific syntax/optimizations that need to be completely re-written (things like endian-ness, atomic read/write/lock, etc.).
tuxRoller - Thursday, January 30, 2014 - link
Neither of those links worked.I'm also not taking about changing compilers only changing the target arch.
BMNify - Thursday, January 30, 2014 - link
for the VERY limited assembly you talk about its only antiquated SSE2 for some small machine interface routines for some implementations, so its not even hard to beat that on the NEON SIMD that's in these 64bit cortex, any competent arm dev writes assembly in his sleep as is the custom for many arm cores for years nowyou can use https://play.google.com/store/apps/details?id=com.... on android :)
nutjob2 - Friday, January 31, 2014 - link
No one writes in assembler anymore because it's next to impossible to write better code than a decent compiler can generate, for instance GCC. The link you provide is very old.C (and C++) is a horrible language which does cause problems with porting, but those issues (platform dependencies) are generally handled in a library, and not really a huge problem.
How difficult it is to port code depends very much on how it was written, just like almost any other thing you want to do with code.
factual - Friday, January 31, 2014 - link
Well, C is the most popular programming language in the world and for good reason!porting a complex c program with thousands of ISA specific optimizations to a different ISA is not a trivial task. x86 is ubiquitous in both the PC and server space , so a lot of apps have tons of x86 specific syntax and optimization, especially in cases were performance is critical.
AMD's decision to design an ARM-based server chip is a marketing move more than anything else. An ARM chip in the server space will be crippled software-wise.
BMNify - Thursday, January 30, 2014 - link
you are aware of the actual linaro membership right ?http://www.linaro.org/members
that the enterprise hardware vendors have their top software teams working inside the Linaro collaborative initiative
http://www.linaro.org/engineering/engineering-grou...
Linaro Networking Group
http://www.linaro.org/engineering/engineering-grou...
Linaro Enterprise Group etc...
not only that Linaro have become one of the largest providers of up-streamed patches to the linux core code base since its initiation
http://www.linaro.org/engineering/status
zero copy and many more of their patches migrating to x64 and ppc etc...
nutjob2 - Friday, January 31, 2014 - link
Funny that you don't mention the price advantage of this part.1. You're mistaken, software is not written for a processor, it's written to be independent of the processor. It's not 1990 anymore. The obvious example is Linux. Most decent software has been ported to many platforms and ARM is just another one, a very good one.
2. That's great but this is a different product to those competitors, and a better product. If it even gets near Intel in power efficiency (which it seems to have done) it will thrash it in cost.
3. You're jumping the gun. Leakage is a big problem and new process nodes are not delivering huge power gains. It may be smaller but it won't be cheaper, which, again is the point. AMD is only one or two process nodes behind.
You're missing the whole point of moving to ARM. The x86 arch is a dog with fleas. It's bloated and a dead end. Intel keeps it alive with its huge process advantage and massive R&D, both very costly. AMD, as smart as they are, can't make a purse from a sow's ear and rightly are moving to other archs. ARM is an open arch which will spur competition which is sorely lacking in the x86 world due to Intel's monopolistic practices, and that competition will deliver lower cost, higher performance and more choice. That's what the computing industry has been built on.