The demise of innovator Calxeda and the excellent performance per watt of the new Intel Avoton server were certainly not good omens for the ARM server market. However, there are still quite a few vendors that are aspiring to break into the micro server market. 

AMD seems to have the best position with by far the most building blocks and experience in the server world. The 64 bit 8-core ARMv8 based Opteron A1100 should see the light in the second half of 2014. Broadcom is also well placed and has announced that it will produce a 3 GHz 16 nm quadcore server ARMv8 server CPU. ARM SoC marketleader Qualcomm has shown some interest too, but without any real product yet. Capable outsiders are Cavium with "Project Thunder" and AppliedMicro with the x-gene family

But unless any of the players mentioned above can grab Intel-like marketshare of the micro server market, the fact remains that supporting all ARM servers is currently a very time consuming undertaking. Different interrupt controllers, different implementation of FP units... at this point in time, the ARM server platform simply does not exist. It is a mix of very different hardware running their own very customized OS kernels. 

So the first hurdle to take is to develop a platform standard. And that is exactly what ARM is announcing today: the platform standard for ARMv8-A based (64-bit) servers, known as the ARM ‘Server Base System Architecture’ (SBSA) specification.

The new specification is supported by a very broad range of companies ranging from software companies such as Canonical, Citrix, Linaro, Microsoft, Red Hat and SUSE, OEMs (Dell and HP) and the most important component vendors active in this field such as AMD, Cavium, Applied Micro and Texas Instruments. In fact, the Opteron A1100 that was just announced adheres to this new spec.

All those partners of course formulated comments, but the best comment came from Frank Frankovsky, president and chairman of the Open Compute Project Foundation. 

"These standardization efforts will help speed adoption of ARM in the datacenter by providing consumers and software developers with the consistency and predictability they require, and by helping increase the pace of innovation in ARM technologies by eliminating gratuitous differentiation in areas like device enumeration and boot process." 

The primary goal is to ensure enough standard system architecture to enable a single OS image to run on all hardware compliant to this specification. That may sound like a fairly simple thing, but in reality it's extremely important to solidifying the ARM ecosystem and making it a viable alternative in the server space.

A few examples of the standard:

  • The base server system shall implement a GICv2 interrupt controller
  • As a result, the maximum number of CPUs in the system is 8
  • all CPUs must have Advanced SIMD extensions and cryptography extensions.
  • the system uses generic timers (Specified by ARM)
  • CPUs must implement the described power state semantics
  • USB 2.0 controllers must conform to EHCI 1.1, 3.0 to XHCI 1.0, SATA controllers to AHCI v1.3
We can only applaud these efforts: it will eliminate a lot of useless time investments, lower costs and help make ARM partners a real option in servers. With the expected launch of many ARM Cortex A57 based server SoCs this year, it looks like 2014 can be a breakthrough year for ARM servers. We looking forward to do another micro server review. 
POST A COMMENT

15 Comments

View All Comments

  • kpb321 - Wednesday, January 29, 2014 - link

    From what I understand this is a bigger deal than it would seem. Unlike x86 where pretty much everyone builds cpus/chipset with a set baseline that is needed to boot windows ARM SOCs aren't as standardized and might have different types of buses available, might handle the boot sequence differently etc which is a difficulty for the OS and part of the reason why most ARM SOCs can't just compile and run the standard linux kernel.

    Interestingly, Microsoft did something similar for their Windows Phone and tablets to make things easier on them.
    Reply
  • FwFred - Wednesday, January 29, 2014 - link

    Much needed move, good to see this is already implemented on the first AMD ARM soc.

    Unfortunately this underscores the challenge facing the ARM server ecosystem. x86 architecture just isn't the ISA.
    Reply
  • Krysto - Thursday, January 30, 2014 - link

    Agreed. I hope this leaks into the mobile market, too, so we can finally have that standardized OS image for smartphones. I hope Android 5.0 allows for that, especially if it comes with kernel 3.8+, which I believe supports device-tree, which should make it easier to do this.

    I realize we probably still won't see Samsung OS images running on Sony hardware, but it would be nice if at the very least a Sony OS image would run on ALL Sony mobile hardware, or a Samsung OS image running on ALL Samsung mobile hardware, and so on. I really hope Google and their partners have been working on this already, and it's ready for Android 5.0. It would be by far the biggest announcement for Android this year (even if it will take a bit to see the results of that with new hardware).
    Reply
  • Hrel - Wednesday, January 29, 2014 - link

    "As a result, the maximum number of CPUs in the system is 8"

    Isn't that gonna become a problem... really quickly?
    Reply
  • bobbozzo - Wednesday, January 29, 2014 - link

    Hrel, That's the BASE system with the base interrupt controller. Reply
  • extide - Wednesday, January 29, 2014 - link

    Not really, many of these high density ARM setups (like moonshot, etc) consist of many small servers, so that limit would apply to each server, not the whole thing. Reply
  • Krysto - Thursday, January 30, 2014 - link

    No. If a CPU is an atom, think of the whole thing as a molecule. Things are built of many molecules, and so are server farms. They could've decided to make it 4-core only, but I guess they thought the whole system makes more sense with 8-cores. They can probably upgrade the spec in 2 years for 16-cores anyway, for 16nm-10nm processes. Reply
  • JohanAnandtech - Thursday, January 30, 2014 - link

    Exactly, this is the first spec. Reply
  • npz - Friday, January 31, 2014 - link

    The problem is that it prevents licensees like AMD in creating a multi-socket system or multi-processor on a die, say, using their own proprietary interconnect. It really limits this first version of the spec to pure micro-server duties, restricting scaling out only in the form of individual, separate but networked systems (small dense blades, etc). Reply
  • btb - Friday, January 31, 2014 - link

    If the primary intended use is lots and lots of small blades, perhaps it makes good sense? Just guessing here, but its probably simpler to nail down a design spec if they dont have to deal with multi-socket issues, interconnects etc. Reply

Log in

Don't have an account? Sign up now