AMD's first 64-bit ARM cores star in ... Heatless in Seattle*
* Relatively speaking – this SoC tries to be low-power, data-center-grade
Hot Chips 26 AMD today sheds more light on its "Seattle" 64-bit ARM architecture processor at the Hot Chips conference in Cupertino, California.
Take one glance at this new Opteron A1100-series system-on-chip, and you'll realize it's aimed squarely at servers rather than the traditional ARM scene of handheld gadgets and embedded computing – although that was to be expected: AMD CEO Rory Read said as much in April.
As expected, Seattle has eight Cortex-A57 cores – ARM's top-end design running 64-bit ARMv8-A code – and will be fabricated using a 28nm process. The cores will run at 2GHz or more.
The octo-core Seattle SoC will have 4MB of level-two cache and 8MB of level-three cache; two 64-bit DDR3/4 channels with ECC and two DIMMs per channel running up to 1866MHz, supporting up to 128GB of RAM per chip; and controllers for eight 6Gbps SATA3 ports, two 10Gbit Ethernet ports and eight lanes of generation-three PCIe.
Seattle also uses ARM's System Memory Management Unit (SMMU) to link the aforementioned interfaces to the A57 cores. The S in SMMU should really stand for Super or Steroids, because the SMMU does more than the usual address translation and access protection: it allows hypervisors to define per-guest OS translation tables, keeping guests in separate pools of physical RAM. The SMMU design has been kicking around for a few years now [PDF] but its use in virtualization is especially relevant to this server-grade SoC.
And if you like your SoCs, AMD has put a SoC within a SoC: a system control processor (SCP) packing a little Cortex-A5 core with 64KB of ROM; 512KB of SRAM; timers and a watchdog; the usual SPI, UART and I2C interfaces; TrustZone execution space; and a 1Gbps Ethernet remote management port (RGMII).
The idea of the SCP is to boot up, configure and monitor the main processor while maintaining its own (in theory) secure space to execute code. If the system running on the main processor falls over, or otherwise needs to be restarted from scratch, the SCP is needed to be on hand (and non-compromised) to power cycle the machine or similar. The TrustZone component of the SCP is supposed to guarantee this by ensuring the system boots from a known good, secure state each time.
Seattle is not unique in having one of these sidekick CPUs to keep it on the straight and narrow – far from it – but it's worth noting its presence.
The computer within the computer ... Your Seattle chip actually includes two systems, one sorta hidden
The SCP follows UEFI 2.4, in that it starts first when the machine is powered up, initializes the main SoC, starts its own real-time operating system, and then releases the A57 boot core from reset to start the UEFI ARM firmware.
This sidekick processor also includes a coprocessor for accelerating cryptographic algorithms, which is attached to the SCP or via an interconnect to the SMMU. This coprocessor includes a random number generator, and can perform zlib compression and decompression in hardware along with AES, Elliptic Curve Cryptography, RSA, and SHA algorithms.
Sponsored: DevOps and continuous delivery