AMD Announces ARM-Based Server CPU and Development Platform

[Cristian_25H]

AMD today added a major new milestone to its list of seminal developments in server technology. The company displayed a comprehensive development platform for its first 64-bit ARM-based server CPU, fabricated using 28 nanometer process technology, the first from an established server vendor. AMD also announced the imminent sampling of the ARM-based processor, named the AMD Opteron A1100 Series, and a development platform, which includes an evaluation board and a comprehensive software suite. In addition, AMD announced that it would be contributing to the Open Compute Project a new micro-server design using the AMD Opteron A-Series, as part of the common slot architecture specification for motherboards dubbed "Group Hug."

The AMD Opteron A-Series processor, codenamed "Seattle," will sample this quarter along with a development platform that will make software design on the industry's premier ARM-based server CPU quick and easy. AMD is collaborating with industry leaders to enable a robust 64-bit software ecosystem for ARM-based designs from compilers and simulators to hypervisors, operating systems and application software, in order to address key workloads in Web-tier and storage data center environments. The AMD Opteron A-Series development platform will be supported by a broad set of tools and software including a standard UEFI boot and Linux environment based on the Fedora Project, a Red Hat-sponsored, community-driven Linux distribution.



"The needs of the data center are changing. A one-size-fits-all approach typically limits efficiency and results in higher-cost solutions," said Suresh Gopalakrishnan, corporate vice president and general manager of the AMD server business unit. "The new ARM-based AMD Opteron A-Series processor brings the experience and technology portfolio of an established server processor vendor to the ARM ecosystem and provides the ideal complement to our established AMD Opteron x86 server processors."

The AMD Opteron A1100 Series processors support:

• 4 or 8 core ARM Cortex-A57 processors
• Up to 4 MB of shared L2 and 8 MB of shared L3 cache
• Configurable dual DDR3 or DDR4 memory channels with ECC at up to 1866 MT/second
• Up to 4 SODIMM, UDIMM or RDIMMs
• 8 lanes of PCI-Express Gen 3 I/O
• 8 Serial ATA 3 ports
• 2 10 Gigabit Ethernet ports
• ARM TrustZone technology for enhanced security
• Crypto and data compression co-processors

The AMD Opteron A-Series development kit is packaged in a Micro-ATX form factor and includes:

• An AMD Opteron A1100 Series processor
• 4 Registered DIMM slots for up to 128 GB of DDR3 DRAM
• PCI Express connectors configurable as a single x8 or dual x4 ports
• 8 Serial-ATA connectors
• Compatibility with standard power supplies
• Ability to be used stand-alone or mounted in standard rack-mount chassis
• Standard UEFI boot environment
• Linux environment based on Fedora, which provides developers with a rich set of tools and applications
  Standard Linux GNU tool chain, including cross-development version
  Platform device drivers
  Apache web server, MySQL database engine, and PHP scripting language for developing robust web serving applications
  Java 7 and Java 8 versions to provide developers to work in a 64-bit ARM environment

"Since 2012, AMD has been working with members of the Linaro Enterprise Group (LEG) on accelerating the ARM server ecosystem," said Andrea Gallo, LEG director. "Linaro's work on boot architecture including UEFI and ACPI, as well as key core server software such as an optimized LAMP stack and a best-in-class enterprise quality OpenJDK 8 Java implementation developed in collaboration with Red Hat, will enable AMD to deliver differentiated and innovative hardware solutions providing industry-leading performance and low-power products for the next generation of data center server platforms."

AMD continues to drive the evolution of the open-source data center from vision to reality and bring choice among processor architectures. It is contributing the new AMD Open CS 1.0 Common Slot design based on the AMD Opteron A-Series processor compliant with the new Common Slot specification, also announced today, to the Open Compute Project.

"Predefined, 'one size fits all' server platforms are giving way to customized solutions that deliver high performance at the lowest power consumption," said Frank Frankovsky, chairman and president of the Open Compute Project. "AMD's contribution to the Open Compute Project expands a growing portfolio of OCP designs that enable utilization and efficiency gains in data center operations."

For more information please visit AMD's booth at the Open Compute Summit today and tomorrow where the AMD Opteron-A development kit, AMD Open CS 1.0 server platform and partner technologies will be on display.

View at TechPowerUp Main Site

 

[xvi]

Well, this will be interesting. I bet we'll see this offered in HP's Moonshot.

 

[W1zzard]

If AMD plays this right it could bring in serious revenue from datacenters.

Most server workloads can be parallelized just fine, so if I can cram multiple of these CPUs in the same space that I can put 1 Xeon in, for less money, and they use less power, then win. Otherwise fail

 

[Jorge]

AMD has recognized their ability to build custom designed products that leverage their IP and this is a perfect example of what can be done just as the Xbox, Wii and PS are. Unfortunately AMD doesn't have the resources they need to develop a lot of the engineering potential within the company so it will continue to be a day-to-day saga on how well AMD is doing this week for quite awhile.

With all three console wins, the Kaveri desktop APU and soon to be laptop APU releases and now a custom ARM based server option, AMD is moving forward from their reorganization. They have a tall mountain to climb and they've just started the journey. If they can keep the profits coming they will be able to increase their resources and capitalize on a lot of other products.

 

[Hilux SSRG]

AMD has recognized their ability to build custom designed products that leverage their IP and this is a perfect example of what can be done just as the Xbox, Wii and PS are. Unfortunately AMD doesn't have the resources they need to develop a lot of the engineering potential within the company so it will continue to be a day-to-day saga on how well AMD is doing this week for quite awhile.

With all three console wins, the Kaveri desktop APU and soon to be laptop APU releases and now a custom ARM based server option, AMD is moving forward from their reorganization. They have a tall mountain to climb and they've just started the journey. If they can keep the profits coming they will be able to increase their resources and capitalize on a lot of other products.

If AMD can eek out profits on sales of these chips for the purpose of reducing debt and boosting R&D then that's great. But a tall mountain to climb indeed.

 

[Kärlekstrollet]

AMD has recognized their ability to build custom designed products that leverage their IP and this is a perfect example of what can be done just as the Xbox, Wii and PS are. Unfortunately AMD doesn't have the resources they need to develop a lot of the engineering potential within the company so it will continue to be a day-to-day saga on how well AMD is doing this week for quite awhile.

With all three console wins, the Kaveri desktop APU and soon to be laptop APU releases and now a custom ARM based server option, AMD is moving forward from their reorganization. They have a tall mountain to climb and they've just started the journey. If they can keep the profits coming they will be able to increase their resources and capitalize on a lot of other products.

Agreed, do what IBM does. Creating custom designed products for other companies looks very profitable, the consoles are already reeling them in for AMD.

 

[mliska1]

So NVIDIA has project Denver and now AMD has Seattle. Did these two companies somehow predict this years' Superbowl matchup years in advance? Do NVIDIA fanboys have to root for the Bronocos and AMD for the Seahawks?

 

[MxPhenom 216]

If AMD plays this right it could bring in serious revenue from datacenters.

Most server workloads can be parallelized just fine, so if I can cram multiple of these CPUs in the same space that I can put 1 Xeon in, for less money, and they use less power, then win. Otherwise fail

Not to mention, overall power consumptions for datacenters should drop considerably as well.

 

[Aquinus]

Not to mention, overall power consumptions for datacenters should drop considerably as well.

Only if it doesn't take much more compute power to do the same operations. There are a lot of instructions that x86 has that will run in only a handful of cycles that very well might take considerably more on a RISC CPU. I share your sentiment though, I would love to see ARM take a bigger hold of the market and AMD take advantage of it. I would like to see where this goes.

 

[Steevo]

If AMD plays this right it could bring in serious revenue from datacenters.

Most server workloads can be parallelized just fine, so if I can cram multiple of these CPUs in the same space that I can put 1 Xeon in, for less money, and they use less power, then win. Otherwise fail

What about the virtualization market for performance hindered phone apps, if we can stream games why not more compute intensive apps with lower latency requirements? Native code with this much processing power might push the mobile market further faster.

 

[xenocide]

Not to mention, overall power consumptions for datacenters should drop considerably as well.

Yes and no. It's not that ARM solutions are inherently more energy conservative, they are just a lot more focused and refined to consider energy usage in every field they exist in (i.e. Phones and Tablets). But, you can also get x86-based CPU solutions to run within similar power envelopes. That first round of Intel phone CPU's (Medfield I think it was) was on par and in some situations better than comperable ARM-based CPU's. Assuming that was what you were getting at, not entirely sure.

I personally think if AMD is going to focus on ARM they really need to get Phone and Tablet APU's to the market. If they could get a decent energy efficient CPU paired with a mobile GCN-esque GPU they could clean up in the mobile market--which is pretty damn profitable these days.

 

[W1zzard]

What about the virtualization market for performance hindered phone apps, if we can stream games why not more compute intensive apps with lower latency requirements? Native code with this much processing power might push the mobile market further faster.

I think what you are saying is that you want an ARM server to be able to run ARM apps from mobile phone? These servers don't run Android or iOS, so no point. Also those OS aren't optimized for server hardware anyway.

The correct way to do it (and is done already) is to add functionality to the app (on phone), to talk over internet to your server, and your server runs a specialized server program that can handle the queries (from multiple clients, and reply quickly)

 

[cyneater]

If they are cheap enough myself and a boat load of other people would use them over Intel Celeron / Atom for home servers. Normally Arm SOC are low power draw and great performance.

 

[Yorgos]

I think what you are saying is that you want an ARM server to be able to run ARM apps from mobile phone? These servers don't run Android or iOS, so no point. Also those OS aren't optimized for server hardware anyway.

The correct way to do it (and is done already) is to add functionality to the app (on phone), to talk over internet to your server, and your server runs a specialized server program that can handle the queries (from multiple clients, and reply quickly)

there is no point to do all that hard work since you can have perfect virtualization in x86 with those v-pro and amd-v features.

edit: those servers are a completely new platform and need a tone of modifications and patches to make android work. as I said before you can achieve nearly 90% of the performance of a system that runs on the metal with the right virtualization s/w and the acceleration from those amd-v and v-pro features

 

[W1zzard]

there is no point to do all that hard work since you can have perfect virtualization in x86 with those v-pro and amd-v features.

edit: those servers are a completely new platform and need a tone of modifications and patches to make android work. as I said before you can achieve nearly 90% of the performance of a system that runs on the metal with the right virtualization s/w and the acceleration from those amd-v and v-pro features

Did you misread my post? I said that you do not want to run anything not Linux on these CPUs

 

[Aquinus]

there is no point to do all that hard work since you can have perfect virtualization in x86 with those v-pro and amd-v features.

edit: those servers are a completely new platform and need a tone of modifications and patches to make android work. as I said before you can achieve nearly 90% of the performance of a system that runs on the metal with the right virtualization s/w and the acceleration from those amd-v and v-pro features

X86 processors are good at virtualizing x86 workloads, they do not virtualize workloads for other CPU architectures. Performance goes down the drain as soon as you need to start emulating a different architecture. Also, you wouldn't use Android on something like a server. You'd be better off using something like the ARM port of Debian.

 

[Steevo]

I think what you are saying is that you want an ARM server to be able to run ARM apps from mobile phone? These servers don't run Android or iOS, so no point. Also those OS aren't optimized for server hardware anyway.

The correct way to do it (and is done already) is to add functionality to the app (on phone), to talk over internet to your server, and your server runs a specialized server program that can handle the queries (from multiple clients, and reply quickly)

I have been led to believe that many are running a Java VM server side to allow the execution of the same code that other more powerful mobile devices can run natively, and with the overhead associated with running a Java VM server side has been huge in cost of performance per dollar, and the hardware has been years in the making to get us to this point as ARM works much better at this (hence why so many things are moving to java on mobile and even desktop). We use about 10 applications in my line of work that have been handled this way, I have only gone along kicking and screaming as the end user experience is so much worse than what a hard coded program made to run on specific performance hardware was, but I understand that development and deployment is easier with one common language that runs on android, iOS, and Windows, and depending on device performance fits into one of three performance groups.

 

[W1zzard]

iOS runs Objective C, Android runs Java. Neither are directly compatible with any other platform.

Running Java on servers is an acceptable choice for many enterprises, because scaling is much easier than with a traditional LAMP stack.

Base memory overhead of Java is kinda bad (but scales well for many connections), and RAM is kinda free nowadays.

Our TPU mobile apps use just a normal REST API to fetch their data. Easy to integrate with the existing web server structure, and easily accessible from any other platform, in case we decide to have apps for other mobile systems.

 

[Aquinus]

iOS runs Objective C, Android runs Java. Neither are directly compatible with any other platform.

Running Java on servers is an acceptable choice for many enterprises, because scaling is much easier than with a traditional LAMP stack.

One the first point, it's important to note that the hardware itself that iOS runs on can run Java. The OS doesn't implement it or support it though.

On the second point, I agree with this a lot. A great example is every time you run a PHP script from a LAMP stack, the entire state of the application needs to be configured, where on a Java server, it very well could be sitting, waiting, and ready to roll. It's also important to make the distinction between Java itself and the JVM. There some languages like Clojure that leverage the JVM and Java classes. It's actually pretty cool having the JVM under you when you're writing functional code. The only downfall (as W1zz said already) is the initial memory footprint and the time it takes to spin up the JVM, which makes it suitable for long running applications but not CLI tools.

 

[Steevo]

iOS runs Objective C, Android runs Java. Neither are directly compatible with any other platform.

Running Java on servers is an acceptable choice for many enterprises, because scaling is much easier than with a traditional LAMP stack.

Base memory overhead of Java is kinda bad (but scales well for many connections), and RAM is kinda free nowadays.

Our TPU mobile apps use just a normal REST API to fetch their data. Easy to integrate with the existing web server structure, and easily accessible from any other platform, in case we decide to have apps for other mobile systems.

Perhaps why they only list a couple apple products as being supported dependent on browser.


Java does make coding tools to code once for all the platforms, at the expense of performance, which is highly evident in their implementations performance.

 

[cyneater]

Are they going to make a dual core with 8 sata3 ports. If so ill have one would make a great nas.
Pit a 16x PCI-E port and it would make a great HT-PC.

 

[TRWOV]

I bet these will do great on I/O limited loads like web hosting and such. I would get one for a media server.

 

[Aquinus]

I bet these will do great on I/O limited loads like web hosting and such. I would get one for a media server.

A web server serving up strictly static content, maybe. I don't seem how ARM would be much faster than X86 with I/O though. What makes you think that this will be the case?

 

[W1zzard]

ARM is at least one order of magnitude slower than x86 for these workloads, BUT, if you can jam 10 ARM machines into the space of 1 or 2 x86 systems for similar price, then it could pay off.

One potential issue could be single thread performance which affects page generation time, nothing can even come close to x86 here.