For some time now, the features of AMD’s Seattle server processor have been painted in broad brush strokes. We’ve known since last year about Seattle’s eight ARM Cortex-A57 cores, its 28-nm process geometry, and AMD’s plan to deliver it in late 2014. Seattle was the subject of a live demo in May of this year, when AMD disclosed its plan to market the chip as the Opteron A1100.
The specifics of Seattle’s architecture have, however, remained mostly under wraps until today.
This morning, at the Hot Chips symposium, AMD is filling in most of those missing details. We were treated to an advance briefing last week, where AMD provided previously confidential information about Seattle’s cache network, memory controller, I/O features, and coprocessors. We also got our first glimpse at the chip’s physical architecture, both in simplified “floor plan” form and as an abstracted block diagram:
Well then. Let’s work our way down from the cache, shall we?
Seattle’s eight 64-bit Cortex-A57 cores are arranged in four dual-core modules, each of which shares 1MB of L2 cache. That makes for 4MB of L2 cache in all. The four dual-core modules also have access to an 8MB pool of shared L3 cache, which links up all the cores, coprocessors, memory controller, and I/O. The L2 and L3 caches are 16-way associative with ECC protection, and Seattle’s cache network (which also includes L1 instruction and data caches) is fully coherent, meaning there should be no discrepancies between instances of the same data stored at different levels of the cache.
Moving down to the memory controller, Seattle has dual memory channels that support either DDR3 or DDR4 RAM with ECC protection. Each of these 72-bit channels can accommodate a maximum of two modules (of the RDIMM, SO-DIMM, and UDIMM variety, depending on what hardware makers choose) with a peak transfer rate of 1866 MT/s. In all, each Seattle CPU can address up to 128GB of RAM spread across four 32GB modules.
On the I/O front, Seattle can drive eight Serial ATA 6Gbps ports, two 10Gbps Ethernet ports, and eight lanes of PCI Express Gen3 connectivity. The PCIe connectivity can be laid out in three configurations: with a single x8 controller, with two controllers in an x4/x4 arrangement, and with three controllers in an x4/x2/x2 arrangement. Each controller can operate at Gen1, Gen2, or Gen3 speeds without affecting the speed of the other controllers. The same goes for the SATA ports, which can also support legacy drives capped at 3Gbps or 1.5Gbps speeds.
Seattle features two built-in coprocessors: the System Control Processor (SCP) and Cryptographic Coprocessor (CCP).
The SCP is “effectively a small system-on-a-chip” inside Seattle, to use AMD’s words. It comprises an ARM Cortex-A5 core with its own ROM, RAM, and I/O, including a dedicated 1Gbps “system management port.” The SCP is used to “control power, configure the system, initiate booting, and act as a service processor for system management functions.” Thanks to ARM’s TrustZone technology, the SCP can establish a secure environment that operates independently of the main Cortex-A57 cores. In that respect, the SCP is similar to the Platform Security Processor inside AMD’s Mullins and Beema APUs.
As for Seattle’s Cryptographic Coprocessor, that component is simply an offload engine for encryption, decryption, compression, and decompression workloads. It can accelerate AES, ECC, RSA, SHA, Zlib, and supports “true” random number generation in hardware. It’s also accessible both to the SCP for secure processing and to the main Cortex-A57 cores for non-secure activities.
AMD’s advance presentation also includes some dirt on the Seattle reference server. This system features a 1P motherboard tucked inside of a 2U chassis with room for up to eight mechanical hard drives. The board has four DDR3 DIMM slots, two PCI Express slots (with support for either 1×8 or 2×4 lane configs), eight SATA ports, two 10Gbps Ethernet ports, four I²C ports, and two UART ports.
According to AMD, this reference design is “intended to meet the needs of partners,” including both software and hardware vendors. Perhaps some of the first Seattle servers will be based on this design. We’ll find out for sure in the fourth quarter, which is when AMD expects Seattle to become available.