Revision as of 15:31, 16 December 2019

Zen 2 is AMD's successor to Zen+, a 7 nm process microarchitecture for mainstream mobile, desktops, workstations, and servers. Zen 2 will eventually be replaced by Zen 3.

For performance desktop and mobile computing, Zen is branded as Athlon, Ryzen 3, Ryzen 5, Ryzen 7, Ryzen 9, and Ryzen Threadripper processors. For servers, Zen is branded as EPYC.

History

Zen 2

Zen 2 succeeded Zen in 2019. In February of 2017 Lisa Su, AMD's CEO announced their future roadmap to include Zen 2 and later Zen 3. On Investor's Day May 2017 Jim Anderson, AMD Senior Vice President, confirmed that Zen 2 was set to utilize 7 nm process. Initial details of Zen 2 and Rome were unveiled during AMD's Next Horizon event on November 6, 2018.

Codenames

Zen 2 on the roadmap

Brands

Ryzen brand logo

AMD Zen-based processor brands
Logo	Family	General Description	Differentiating Features
			Cores	Unlocked	AVX2	SMT	IGP	ECC	MP
Mainstream
	Ryzen 3	Entry level Performance	?
	Ryzen 5	Mid-range Performance	Hexa	✔	✔	✔	✘	✔	✘
	Ryzen 7	High-end Performance	Octa	✔	✔	✔	✘	✔	✘
	Ryzen 9	High-end Performance	12-16	✔	✔	✔	✘	✔	✘
Enthusiasts / Workstations
	Ryzen Threadripper	Enthusiasts	12-64	?
Servers
	EPYC	High-performance Server Processor	8-64	✘	✔	✔	✘	✔	✔
Embedded / Edge
	EPYC Embedded	Embedded / Edge Server Processor	?
	Ryzen Embedded	Embedded APUs	?

Process technology

Zen 2 comprises multiple different components:

• The Core Chiplet Die (CCD) is fabricated on TSMC 7 nm HPC process
• The client I/O Die (cIOD) is fabricated on GlobalFoundries 12 nm process
• The server I/O Die (sIOD) is fabricated on GlobalFoundries 14 nm process

Compiler support

• Note: Initial support in GCC 9 and LLVM 9.

Architecture

Zen 2 inherits most of the design from Zen+ but improves the instruction stream bandwidth and floating-point throughput performance.

This article is a work in progress!

Key changes from Zen+

• 7 nm process (from 12 nm)
  • I/O die utilizes 12 nm
• Core
  • Higher IPC (AMD self-reported up to 15% IPC)
  • Front-end
    • Improved branch prediction unit
      • Improved prefetcher
    • Improved µOP cache tags
    • Improved µOP cache
      • Larger µOP cache (4096 entries, up from 2048)
    • Increased dispatch bandwidth
  • Back-end
    • Increased retire bandwidth (??-wide, up from 8-wide)
    • FPU
      • 2x wider datapath (256-bit, up from 128-bit)
      • 2x wider EUs (256-bit FMAs, up from 128-bit FMAs)
      • 2x wider LSU (2x256-bit L/S, up from 128-bit)
      • Improved DP vector mult. latency (3 cycles, down from 4)
    • Integer
      • Increased number of registers (180, up from 168)
      • Additional AGU (3, up from 2)
      • Larger scheduler (4x16 ALU + 1x28 AGU, up from 4x14 ALU + 2x14 AGU
      • Larger Reorder Buffer (224, up from 192)
  • Memory subsystem
    • 0.5x L1 instruction cache (32 KiB, down from 64 KiB)
    • 8-way associativity (from 4-way)
    • 1.33 larger L2 DTLB (2048-entry, up from 1536)
    • 48 entry store queue (was 44)
• CCX
  • 2x L3 cache slice (16 MiB, up from 8 MiB)
  • Increased L3 latency (~40 cycles, up from ~35 cycles)
• Security
  • In-silicon Spectre enhancements
  • Increase number of keys/VMs supported
• I/O
  • PCIe 4.0 (from 3.0)
  • Infinity Fabric 2
    • 2.3x transfer rate per link (25 GT/s, up from ~10.6 GT/s)
  • Decoupling of MemClk from FClk, allowing 2:1 ratio in addition to 1:1
  • DDR4-3200 support, up from DDR4-2933

This list is incomplete; you can help by expanding it.

New instructions

Zen 2 introduced a number of new x86 instructions:

• CLWB - Write back modified cache line and may retain line in cache hierarchy
• WBNOINVD - Write back and do not flush internal caches, initiate same of external caches
• MCOMMIT - Commit stores to memory
• RDPID - Read Processor ID
• RDPRU - Read Processor Register

Block Diagram

Individual Core

Memory Hierarchy

• Cache
  • L0 Op Cache:
    • 4,096 Ops, 8-way set associative
      • 64 sets, 8 Op line size
    • Parity protected
  • L1I Cache:
    • 32 KiB, 8-way set associative
      • 64 sets, 64 B line size
      • Shared by the two threads, per core
    • Parity protected
  • L1D Cache:
    • 32 KiB, 8-way set associative
      • 64 sets, 64 B line size
    • Write-back policy
    • 4-5 cycles latency for Int
    • 7-8 cycles latency for FP
    • ECC
  • L2 Cache:
    • 512 KiB, 8-way set associative
      • 1,024 sets, 64 B line size
    • Write-back policy
    • Inclusive of L1
    • ≥ 12 cycles latency
    • ECC
  • L3 Cache:
    • Matisse, Castle Peak, Rome: 16 MiB/CCX, shared across all cores
    • TBD: 4 MiB/CCX, shared across all cores
    • 16-way set associative
      • 16,384 sets, 64 B line size
    • Write-back policy, Victim cache
    • 39 cycles average latency
    • ECC
    • QoS Monitoring and Enforcement
• System DRAM
  • Rome:
    • 8 channels per socket, up to 16 DIMMs, max. 4 TiB
    • Up to PC4-25600L (DDR4-3200 RDIMM/LRDIMM), ECC supported
  • Castle Peak, sTRX4:
    • 4 channels, up to 8 DIMMs, max. 256 GiB
    • Up to PC4-25600U (DDR4-3200 UDIMM), ECC supported
  • Matisse:
    • 2 channels, up to 4 DIMMs, max. 128 GiB
    • Up to PC4-25600U (DDR4-3200 UDIMM), ECC supported

Translation Lookaside Buffers

• ITLB
  • 64 entry L1 TLB, fully associative, all page sizes
  • 512 entry L2 TLB, 8-way set associative
    • 4-Kbyte and 2-Mbyte pages
  • Parity protected
• DTLB
  • 64 entry L1 TLB, fully associative, all page sizes
  • 2,048 entry L2 TLB, 16-way set associative
    • 4-Kbyte and 2-Mbyte pages, PDEs to speed up table walks
  • Parity protected

Core

Zen 2 largely builds on Zen. Most of the fine details have not been revealed by AMD yet.

This article is a work in progress!

Front End

In order to feed the backend, which has been widened to support 256-bit operation, the front-end throughput was improved. AMD reported that the branch prediction unit has been reworked. This includes improvements to the prefetcher and various undisclosed optimizations to the instruction cache. The µOP cache was also tweaked including changes to the µOP cache tags and the µOP cache itself which has been enlarged to improve the instruction stream throughput.

Execution Engine

AMD stated that both the dispatch bandwidth and the retire bandwidth has been increased.

Floating Point Unit

Like the Zen/Zen+ microarchitecture, the Zen 2 floating point unit utilizes a coprocessor architectural model comprising a dedicated rename unit, a single 4-issue, out-of-order scheduler, a 160-entry physical register file (PRF), and four execution pipelines. The in-order retire queue is shared with the integer unit. The FPU handles x87, MMX, SSE, and AVX instructions. FP loads and stores co-opt the EX unit for address calculations and the LS unit for memory accesses.

In the Zen/Zen+ microarchitecture the floating point physical registers, execution units, and data paths are 128 bits wide. For efficiency AVX-256 instructions which perform the same operation on the 128-bit upper and lower half of a YMM register are decoded into two macro-ops which pass through the FPU individually as execution resources become available and retire together. Accordingly the peak throughput is four SSE/AVX-128 instructions or two AVX-256 instructions per cycle.

Zen 2 doubles the width of the physical registers, execution units, and data paths to 256 bits. The L1 data cache bandwidth was doubled to match. The number of micro-ops issued by the FP scheduler remains four, implying most AVX-256 instructions decode to a single macro-op which conserves queue entries and reduces pressure on RCU and scheduling resources. AMD did not disclose how the FPU was restructured. Die shots suggest two execution blocks splitting the PRF and FP ALUs, one operating on the lower 128 bits of a YMM register, executing x87, MMX, SSE, and AVX instructions, the other on the upper 128 bits for AVX-256 instructions. This improvement doubles the peak throughput of AVX-256 instructions to four per cycle, or in other words, up to 32 FLOPs/cycle in single precision or up to 16 FLOPs/cycle in double precision. Another improvement reduces the latency of double-precision vector multiplications from 4 to 3 cycles, equal to the latency of single-precision multiplications. The latency of fused multiply-add (FMA) instructions remains 5 cycles.

The rename unit receives up to four macro-ops per cycle from dispatch. It maps x87, MMX, SSE, and AVX architectural registers and temporary registers used by microcoded instructions to physical registers. MMX and x87 registers occupy the lowest 64 or 80 bits of a PR. The Zen/Zen+ rename unit allocates two 128-bit PRs for each YMM register. Only one PR is needed for SSE and AVX-128 instructions, the upper half of the destination YMM register in another PR remains unchanged or is zeroed, respectively, which consumes no execution resources. (SSE instructions behave this way for compatibility with legacy software which is unaware of, and does not preserve, the upper half of YMM registers through library calls or interrupts.) Zen 2 allocates a single 256-bit PR and tracks in the register allocation table (RAT) if the upper half of the YMM register was zeroed. This necessitates register merging when SSE and AVX instructions are mixed and the upper half of the YMM register contains non-zero data. To avoid this the AVX ISA exposes an SSE mode where the FPU maintains the upper half of YMM registers separately. Zen 2 handles transitions between the SSE and AVX mode by microcode which takes approximately 100 cycles in either direction. Zeroing the upper half of all YMM registers with the VZEROUPPER or VZEROALL instruction before executing SSE instructions prevents the transition.

Zen 2 inherits the move elimination and XMM register merge optimizations from its predecessors. Register to register moves are performed by renaming the source register and do not occupy any scheduling or execution resources. XMM register merging occurs when SSE instructions such as SQRTSS leave the upper 64 or 96 bits of the destination register unchanged, causing a dependency on previous instructions writing to this register. AMD family 15h and later processors can eliminate this dependency in a sequence of scalar FP instructions by recording in the RAT if those bits were zeroed. By setting a Z-bit in the RAT the rename unit also tracks if an architectural register was completely zeroed. All-zero registers are not mapped, the zero data bits are injected at the bypass network which conserves power and PRF entries, and allows for more instructions in flight. Earlier AMD microarchitectures, apparently including Zen/Zen+, recognize zeroing idioms such as XORPS combining a register with itself and eliminate the dependency on the source register. AMD did not disclose if or how this is implemented in Zen 2. Family 16h processors recognize zeroing idioms in the instruction decode unit and set the Z-bit on the destination register in the floating point rename unit, completing the operation without consuming scheduling or execution resources.

As in the Zen/Zen+ microarchitecture the 64-entry non-scheduling queue decouples dispatch and the FP scheduler. This allows dispatch to send operations to the integer side, in particular to expedite floating point loads and store address calculations, while the FP scheduler, whose capacity cannot be arbitrarily increased for complexity reasons, is busy with higher latency FP operations. The 36-entry out-of-order scheduler issues up to four micro-ops per cycle to the execution pipelines. A 160-entry physical register file holds the speculative and committed contents of architectural and temporary registers. The PRF has 8 read ports and 4 write ports for ALU results, each 256 bits wide in Zen 2, and two additional write ports supporting up to two 256-bit load operations per cycle, up from two 128-bit loads in Zen. The FPU is capable of superforwarding load data to dependent instructions through the bypass network, obviating a write and read of the PRF. The bypass network enables back-to-back execution of dependent instructions by forwarding results from the FP ALUs to the previous pipeline stage.

The floating point pipelines are asymmetric, each supporting a different set of operations, and the ALUs are grouped in domains, to conserve die space and reduce signal path lengths which permits higher clock frequencies. The number of execution resources available reflects the density of different instruction types in x86 code. Each pipe receives two operands from the PRF or bypass network. Pipe 0 and 1 support FMA instructions which take three operands; The third operand is obtained by borrowing a PRF read port from pipe 3, stalling this pipe for one cycle, unless the operand is available on the bypass network. All pipes can perform logical operations. Other operations are supported by one, two, or three pipes. The execution domains distinguish vector integer operations, floating point operations, and store operations. Instructions consuming data produced in another domain incur a one cycle penalty. Only pipe 2 executes floating point store-data micro-ops, sending data to the store queue at a rate of up to one 256-bit store per cycle, up from one 128-bit store in Zen. It also takes care of transfers between integer and FP registers on dedicated data busses.

Same as Zen/Zen+ the Zen 2 FPU handles denormal floating-point values natively, this can still incur a small penalty in some instances (MUL/DIV/SQRT).

Rome

Rome is codename for AMD's server chip based on the Zen 2 core. Like prior generation (Naples), Rome utilizes a chiplet multi-chip package design. Each chip comprises of nine dies - one centralized I/O die and eight compute dies. The compute dies are fabricated on TSMC's 7 nm process in order to take advantage of the lower power and higher density. On the other hand, the I/O makes use of GlobalFoundries mature 14 nm process.

The centralized I/O die incorporates eight Infinity Fabric links, 128 PCIe Gen 4 lanes, and eight DDR4 memory channels. The full capabilities of the I/O have not been disclosed yet. Attached to the I/O die are eight compute dies - each with eight Zen 2 core - for a total of 64 cores and 128 threads per chip.

All Zen 2 Chips

Bibliography

• AMD 'Tech Day', February 22, 2017
• AMD 2017 Financial Analyst Day, May 16, 2017
• AMD GCC 9 znver2 enablement patch
• AMD 'Next Horizon', November 6, 2018
• AMD. Lisa Su Keynote. May 26, 2019
• AMD 'Next Horizon Gaming' event at E3, June 10, 2019

See Also

• Intel Ice Lake