Arm promises a diverse array of products from partners based on their market needs. To that end, partners can use Arm’s own IPs such as the CMN fabric and various accelerators or they can roll their own custom designs. The key takeaway is that there are plenty of options.
The Ares platform is Arm’s first infrastructure-optimized core. This is not a Cortex-derivative. It’s a new core with different power and performance targets specifically for the server market. It targets leading-edge 7 nm process. Arm says we can expect silicon from partners next year. Ares, like the current Cosmos platform, relies on the current coherent mesh network (CMN-600) to scale up the core count as well as interface with the newly added CCIX support. Among other things, some slides by Arm suggested the core might be supplemented by an improved interrupt controller (GIC) and MMU. Ares intends on scaling from a single DDR4 channel up to eight channels.
In fact, in Supercomputing 2018, we’ve already caught sight of what we believe is the first Ares system in the wild (worth noting that while originally we were told this chip uses an Ares core, we have since received other conflicting information). For a while, WikiChip was told Huawei was preparing a large leap in performance with the HiSilicon Hi1620. Compared to the Hi1616 which incorporated 32 Cortex-A72 cores per chip, the Hi1620 doubles that to 64 and more than doubled the TDP. The new chip, which will be Huawei flagship Arm chip also features eight DDR4 channels, 2 and 4-way SMP, 40 PCIe Gen 4 lanes, and CCIX support.
The Zeus platform is Ares successor. This core is intended to take the added benefits of the 7+ nm process. Zeus targets DDR5 memory as well as more advanced memory technologies such as HBM. Zeus will be accompanied by Arm’s next-generation coherent mesh network.
The final platform revealed by Arm was Poseidon. It is expected to succeed Zeus in 2021 and targets the 5-nanometer process node. Poseidon is designed to scale up further with an improved CMN and higher memory support. Not much more than this has been revealed. My own notes from TechCon says it will possibly feature simultaneous multithreading (SMT) but I don’t recall where I heard this so take it with a grain of salt.
One of the other key pieces of the Neoverse that unfortunately received much less attention is ServerReady. We consider ServerReady the most important announcement, more so than even the Neoverse itself. The goal of the Arm ServerReady program to be able to drive compliance through the entire industry, making it easier for everyone to build platforms and server solutions around Arm. In other words, the goal ServerReady is to ensure “everything just works,” much like a typical x86-based system.
Arm understands that the server market is a very different beast to some of their current markets like embedded. In the server market, you have standard operating systems that must run common software – both of which more than likely to predated the silicon itself. On top of this, the installation process needs to simply work; unlike in the embedded world, modifying the OS to suit the hardware is not a viable option. This is where ServerReady comes in. ServerReady ensures that everything adheres to a minimum set of common rules for hardware and firmware.
There are four components to Arm’s standards approach – collaboration, standards, participation in industry standards, and open source projects – the biggest of which is the collaboration. Arm established the ARM Server Advisory Committee or ArmServerAC in 2011 which currently consists of 46 members from across the industry (cloud vendors, OS vendors, OEMs bios vendors, etc..). The committee was initially established to define what an Arm server looks like and what were the requirements to make it work.
There is a whole list of Arm server standards, but the two major ones are SBSA and SBBR. There are other specifications such as PSCI for power management and SMCCC for calling trusted firmware. We’ll touch on the two major ones here.
The Server Base System Architecture (SBSA) covers the hardware requirements for servers. That is, if you were to design a server, what are the requirements/properties that the operating system and hypervisor expect from your hardware. This includes core architectural requirements and various other things such as PCIe writing/interfacing, SMMU, and GIC properties. The intent of the standard is to ensure that all SBSA-compliant systems implement the minimum functionality that is critical to the system software and application software that run on most servers.
The second major specification is the Server Base Boot Requirements (SBBR) which is the firmware set of requirements. This specification looks at various firmware standards such as UEFI, ACPI, SMBIOS and defines the minimum requirements that the firmware expects are implemented.
One thing that’s worth noting is just how far back this has been in the planning – 7 years now. The first release of the standards was in 2014. By last year, the enterprise test suites were also published. Today, the current SBSA specification is 5.0 and SBBR is 1.1.
In order to ensure Arm and Neoverse partners are compliant with the specifications mentioned above, Arm developed the Architectural Compliance Suites (ACS). The compliance suites are open source and may be found on GitHub. The goal here is to design a set of tools in order for companies to self-check their designs as well as or OS vendors to ensure that things work on their side as desired. The ACS primarily tests the SBBR and SBSA specifications. This is mainly done through UEFI-based testing and operating system-based testing. Many of the tests were written by Arm but it also incorporates some other tests such as the Firmware Test Suite (FWTS) by Canonical which performs sanity checks on the firmware (BIOS/UEFI/ACPI) in an attempt to identify errors.
All of this comes back to the Arm ServerReady compliance process. Arm partners run the tests and with the help from Arm, they debug the various issues that they might have. The tests include the architecture compliance suites for SBSA and SBBR but it also includes things such as booting of standard Linux distros and smoke testing. Partners that pass the process are provided with a certificate along with the right to use the ServerReady logo indicating compliance.
Arm has since announced that Huawei, Ampere, Cavium, and Qualcomm have obtained the Arm ServerReady version 1.0 certificate.
A Plan Set In Motion
Arm’s server plan has been in the works for the better part of the decade. What we see today is not the start of anything but rather the convergence of multiple components that needed to come together to make this possible. Arm servers are already here – from multiple vendors, deployed by multiple companies. But it’s not enough – at least on Arm’s side, current offerings are rather weak. Addressing this are the three new platforms that were announced – Ares, Zeus, and Poseidon; all three targets very high “server-class” performance. Arm’s new roadmap is part of their aggressive plan in an attempt to make a dent in the server market. So far, Arm has been doing a lot of things correctly – establishing standards, forming the foundation, and planning more powerful cores. Doing everything right doesn’t necessarily translates to success. Arm will need to generate demand. They will need to do this through additional value not currently present in existing Intel and AMD solutions. Ultimately, it remains to be seen how successful Arm will be.