🧩 CPU

AMD CCD와 Central IOD

개요

AMD EPYC의 칩렛 구조는 CPU 코어를 담은 여러 CCD(Core Complex Die)와 메모리·I/O 기능을 모은 Central IOD(Central I/O Die)를 분리한다. CCD는 Zen 코어, private L2와 공유 L3를 가까이 배치해 compute locality를 제공하고, Central IOD는 메모리 컨트롤러, PCIe와 외부 인터페이스, die 간 fabric의 집계 지점을 제공한다. 이 분리는 코어용 공정과 I/O용 공정을 독립적으로 발전시키면서 작은 compute die를 반복 조합할 수 있게 한다.

Central은 여러 CCD가 공통으로 접근하는 I/O die라는 패키지 수준의 역할을 가리키며, 모든 트랜잭션이 하나의 단일 crossbar를 지난다는 뜻은 아니다. 제품 세대와 SKU에 따라 CCD 수, core/cache grouping, IOD 공정, memory channel, I/O link와 NUMA 노출 방식이 달라진다. 따라서 아래의 CCD → Infinity Fabric → Central IOD → memory/I/O 경로는 EPYC 칩렛을 이해하기 위한 대표 모델이고, 제품별 exact route·queue·coherence directory는 공개 자료와 측정 범위를 벗어날 수 있다.

핵심 개념

1. CCD와 Central IOD의 역할

CCD와 IOD는 모두 CPU 패키지 안에 있지만 맡는 locality와 병목이 다르다.

블록	주된 구성	처리하는 트래픽	성능 관점
CCD	Zen core, L1/L2, 공유 L3, local cache fabric	instruction 실행, cache lookup, core-to-core coherence 요청	같은 CCD 안의 cache locality와 core 경쟁
Infinity Fabric link	die 간 데이터·제어 연결과 flow control	request, response, data, snoop, ownership, I/O traffic	link width, clock, queue, retry와 congestion
Central IOD	memory controller, PCIe/외부 I/O, fabric gateway, 보안·관리 기능	여러 CCD의 memory·I/O 요청 집계와 시스템 경계 처리	fan-in, memory-controller queue, I/O 경쟁
Memory endpoint	DDR channel, rank, bank와 DRAM service	cache miss의 backing-store read/write	channel parallelism, row policy와 DRAM timing
Socket/package endpoint	다른 socket, accelerator 또는 외부 device	remote NUMA, coherent 또는 I/O traffic	package·socket link, NUMA distance와 QoS

CCD는 어디서 코어 계산과 cache lookup이 가까이 끝나는가를 설명하는 단위다. Central IOD는 여러 CCD가 어떤 memory·I/O service를 공유하는가를 설명하는 집계 단위다. 둘 사이를 연결하는 Infinity Fabric은 cache coherence 자체가 아니라, coherence와 memory/I/O transaction을 운반하고 조정하는 interconnect 계층이다.

2. CCD 내부의 core와 cache locality

CCD의 cache 구조는 Zen 세대에 따라 달라진다. Zen 2 EPYC에서는 한 CCD에 두 개의 4-core CCX가 배치되고 각 CCX가 16MB L3를 공유하는 구성이 대표적이다. Zen 3부터는 한 CCD의 최대 8코어가 하나의 unified complex와 32MB L3를 공유하는 모델로 바뀌어 CCD 내부의 과거 CCX 경계를 단순화했다.

세대 사례	CCD 구성의 대표 모델	공개 제품 맥락	해석할 locality
EPYC 7002, Zen 2	4-core CCX 2개, CCD당 최대 8코어	최대 8 CCD, 64코어, 8채널 DDR4, 128 PCIe 4.0 lanes	CCX 내부, 같은 CCD, 다른 CCD의 경계를 구분
EPYC 7003, Zen 3	CCD당 최대 8코어 unified complex, 32MB L3 모델	7002와 같은 세대급 I/O 확장 기반에서 core/cache locality 개선	같은 CCD shared data의 경계가 Zen 2보다 단순
EPYC 9004, Zen 4/Zen 4c	제품 SKU에 따라 standard 또는 dense compute CCD 조합	최대 128코어, 12채널 DDR5 제품군	CCD 수와 core density, IOD service capacity를 함께 확인
EPYC 9005, Zen 5/Zen 5c	Zen 5와 Zen 5c compute chiplet 조합	최대 192코어를 제공하는 5th Gen 제품군	core density와 cache·frequency·전력 목표가 SKU별로 다름

표의 수치는 제품군의 대표 공개 값이다. 예를 들어 EPYC 9004의 최대 128코어는 모든 SKU가 같은 CCD 수와 cache 구성을 갖는다는 뜻이 아니며, EPYC 9005의 최대 192코어도 Zen 5와 Zen 5c의 내부 grouping을 하나의 고정 모델로 만들 근거가 아니다.

3. Central IOD의 기능 경계

Central IOD는 여러 CCD와 외부 자원을 잇는 시스템 경계다.

Memory service: CCD에서 온 cache miss를 주소 mapping에 따라 memory controller와 DDR channel로 전달한다.
I/O service: PCIe와 기타 외부 I/O endpoint의 요청·응답을 수용하고 CPU fabric과 외부 link 사이의 경계를 처리한다.
Fabric gateway: CCD-to-IOD traffic을 수신하고 방향·traffic class·flow-control 상태에 따라 service domain으로 보낸다.
Coherence participation: cache line의 home, owner 또는 memory service를 선택하는 transaction에 참여한다. 구체적인 directory와 probe-filter 구현은 세대·제품별로 확인해야 한다.
Management and security: 부팅, 전원, RAS와 보안 기능은 compute die만의 기능이 아니며, 제품의 SoC 구성과 IOD 경계를 함께 고려해야 한다.

Central IOD를 단순한 메모리 컨트롤러 모음으로 보면 안 된다. 반대로 IOD가 모든 coherence 판단을 단일 중앙 directory에서 수행한다고 단정해서도 안 된다. 공개 block diagram이 보이는 기능 경계와 내부 route·directory의 미공개 영역을 분리해야 한다.

4. Infinity Fabric과 물리 경계

동일한 Infinity Fabric이라는 이름 아래에도 서로 다른 범위의 연결이 존재할 수 있다.

경계	대표 경로	추가되는 비용
CCD 내부	core → L2/L3 → local cache fabric	cache lookup, local arbitration, coherence state
CCD ↔ Central IOD	CCD → IF link → IOD gateway	die-to-die hop, link queue, clock/power domain
IOD ↔ memory	IOD → memory controller → DDR	controller queue, channel scheduling, DRAM timing
IOD ↔ I/O	IOD → PCIe/root complex → device	protocol ordering, DMA competition, I/O completion
socket ↔ socket	local IOD → socket link → remote IOD	NUMA distance, remote home, link retry와 queue

같은 패키지 안에 있다는 사실만으로 CCD와 IOD의 latency가 같아지는 것은 아니다. die-to-die link는 on-die wire보다 별도의 PHY, clock, power, training, retry와 error-containment 문제를 가진다. 반대로 모든 CCD 간 access가 독립적인 direct link를 사용한다고도 할 수 없다. 특히 여러 세대의 EPYC를 설명할 때는 중앙 IOD를 경유하는 대표 모델과 제품별 예외 가능성을 함께 표시해야 한다.

5. Memory와 I/O의 fan-in

각 CCD는 여러 코어의 요청을 만들지만, 같은 IOD의 memory controller나 I/O gateway를 공유한다. 그러므로 CCD 수를 늘리는 것과 end-to-end bandwidth를 늘리는 것은 같은 일이 아니다.

many cores in CCDs
    -> CCD injection queues
    -> Infinity Fabric links
    -> Central IOD gateway and service queues
    -> memory controller / PCIe endpoint

IOD가 제공하는 aggregate service capacity보다 CCD에서 유입되는 offered load가 크면 IOD queue와 upstream credit이 먼저 포화된다. 이때 CCD 내부 cache와 IF link가 유휴 상태로 보이더라도 memory miss의 p95/p99 latency가 커질 수 있다. streaming workload와 PCIe DMA가 동시에 실행될 때는 data payload뿐 아니라 control, ordering과 retry traffic도 IOD 자원을 사용한다.

6. NUMA와 locality

단일 소켓 EPYC에서도 CCD와 memory controller의 거리가 access cost에 영향을 줄 수 있다. 서버 firmware와 Linux가 이를 NPS(NUMA Per Socket) 설정, NUMA node와 distance로 노출하는 방식은 제품과 설정에 따라 달라진다. 두 소켓 시스템에서는 local socket의 IOD와 remote socket의 IOD를 구분해야 하며, remote memory를 피하는 것만으로 충분하지 않고 thread affinity와 page placement도 함께 고정해야 한다.

access 범위	개념 경로	주요 비용
같은 CCD의 L3 hit	core → local L3 → core	cache tag/data lookup과 local contention
같은 socket의 다른 CCD cache	source CCD → IF/IOD 또는 package fabric → target CCD	die-to-die traversal, remote cache/coherence service
같은 socket의 memory miss	source CCD → IF → Central IOD → local MC → DRAM	IOD queue, controller scheduling, DRAM service
다른 socket의 memory miss	local CCD/IOD → socket link → remote IOD → DRAM	socket link, remote NUMA home와 remote memory service

local은 항상 가장 빠른 access라는 보장이 아니라 측정 범위를 지정하는 이름이다. local L3가 높은 경쟁 상태에 있으면 remote cache나 memory path보다 loaded latency가 커질 수 있으며, address mapping이 특정 memory controller에 집중되면 평균 거리와 무관하게 hotspot이 생긴다.

비교/분석

1. Monolithic CPU와 CCD + Central IOD

항목	모놀리식 CPU die	CCD + Central IOD 칩렛	해석할 질문
compute 확장	하나의 큰 die에 core와 I/O를 함께 배치	작은 compute die를 여러 개 조합	core 수를 늘릴 때 die size와 package 경계는 어떻게 변하는가?
공정 선택	전체 기능이 같은 공정에 묶임	compute와 I/O die의 공정을 분리	logic density와 I/O analog·PHY 요구를 독립 최적화할 수 있는가?
cache locality	die 내부 topology 중심	CCD 내부와 CCD 간 경계를 추가	shared data가 어느 CCD에서 소비되는가?
memory access	on-die fabric과 MC 경로	IF link + IOD + MC 경로	link와 IOD queue가 memory service를 지배하는가?
확장 방식	die 면적·배선·reticle 증가	CCD 조합과 IOD service capacity 증가	package link와 중앙 fan-in이 충분한가?
제조·제품화	큰 die 수율과 공정 혼합에 불리할 수 있음	die 재사용, 수율과 SKU 조합에 유리	packaging·검증·열 비용이 이득을 상쇄하는가?
실패·검증 범위	die 내부 timing·coherence closure	die-to-die link, reset, retry, coherence 조합	경계 오류를 독립적으로 격리·복구할 수 있는가?

칩렛의 장점은 작은 die를 반복 사용하는 데서 나오지만, 모든 workload의 latency가 낮아지는 것은 아니다. 같은 CCD 안에서 끝나는 cache-heavy workload는 boundary traffic을 거의 사용하지 않는 반면, all-to-all sharing과 streaming memory는 IF link와 Central IOD의 fan-in을 직접 압박한다.

2. 세대별 CCD/IOD 분석 단위

분석 축	Zen 2 / EPYC 7002	Zen 3 / EPYC 7003	Zen 4·4c / EPYC 9004	Zen 5·5c / EPYC 9005
compute unit	CCD 안의 4-core CCX 2개	CCD 안의 unified 8-core complex 모델	standard/dense CCD SKU 조합	Zen 5와 Zen 5c 조합
대표 제품 최대 코어	64	64	128	192
대표 memory I/O	8채널 DDR4, 128 PCIe 4.0 lanes	제품군별 DDR4/PCIe 4 세대 플랫폼	12채널 DDR5, PCIe Gen5 세대	SKU·플랫폼 datasheet 확인 필요
핵심 locality	CCX → CCD → IOD	unified CCD → IOD	CCD density → IOD service	heterogeneous compute → IOD service
비교 주의점	CCX 간 L3 locality를 별도 측정	unified L3가 remote CCD 비용을 제거하지 않음	128코어가 모든 SKU 구조를 의미하지 않음	192코어를 고정 CCD 수로 역산하지 않음

이 표의 maximum 값은 AMD 제품군 페이지의 공개 범위이고, latency·bandwidth 수치가 아니다. 7002의 8채널 DDR4나 9004의 12채널 DDR5는 플랫폼의 memory interface 규모를 보여줄 뿐이며, 애플리케이션 sustained bandwidth는 IOD queue, memory scheduling, access pattern과 NUMA placement를 통과한 결과다.

3. Request 유형별 병목

request	대표 경로	1차 병목	관측할 지표
CCD local L3 hit	core → local L3	L3 capacity와 core 경쟁	L2/L3 miss, loaded cache latency
remote CCD cache hit	source CCD → IF/IOD/package fabric → target CCD	link hop, remote cache/coherence service	remote access ratio, IF utilization, p99
read memory miss	CCD → IOD → MC → DRAM	IOD·MC queue와 DRAM timing	MC occupancy, queue time, read bandwidth
write-sharing	CCD → home/coherence service → sharer/owner	invalidate, ownership, acknowledgement	coherence message, line migration, ack wait
PCIe/DMA traffic	CCD or device → IOD → PCIe/MC	I/O gateway, ordering, DMA interference	I/O utilization, fabric class, tail latency
two-socket remote access	local IOD → socket link → remote IOD	remote home과 NUMA link	remote ratio, socket-link utilization, p95/p99

4. 지연과 대역폭 모델

제품 내부 cycle 수를 알 수 없을 때는 다음처럼 측정 경계를 분리한다.

L_memory = L_core_miss
         + L_CCD_lookup
         + L_IF_forward
         + L_IOD_queue
         + L_MC_schedule
         + L_DRAM_service
         + L_response
         + L_retry

공유 cache 또는 coherence transaction에서는 L_MC_schedule과 L_DRAM_service가 없을 수 있고, 대신 remote owner·invalidate·acknowledgement 항이 추가된다. L_IF_forward만 낮춰도 IOD queue와 DRAM service가 그대로라면 end-to-end latency는 줄지 않는다.

B_sustained <= min(sum of CCD injection capacity,
                   IF link capacity,
                   IOD gateway capacity,
                   memory/I/O service capacity)

이 식은 독립적인 capacity가 완전히 합산된다는 뜻이 아니다. 여러 CCD가 같은 IOD gateway, memory controller 또는 response path를 공유하면 공통 cut의 capacity가 상한이 된다. peak link rate와 sustained payload bandwidth를 비교할 때는 protocol overhead, coherence traffic, backpressure, retry와 workload read/write 비율을 함께 기록해야 한다.

5. Workload와 배치 선택

workload	유리한 배치 방향	피해야 할 해석
private-cache 계산	thread와 working set을 같은 CCD에 유지	CCD 수가 많으면 단일 thread가 자동으로 빨라진다고 생각하지 않음
read-mostly shared data	공유 데이터를 소비하는 core를 같은 CCD 또는 가까운 locality에 배치	unified L3가 remote CCD와 같은 latency를 보장한다고 보지 않음
lock·write-sharing	owner와 sharer 수를 제한하고 affinity 고정	data payload가 작으므로 fabric 비용도 작다고 보지 않음
streaming memory	channel과 MC에 주소를 분산하고 NUMA placement 고정	12채널 또는 8채널 peak를 sustained application rate로 사용하지 않음
CPU + DMA/I/O	IOD와 I/O endpoint 경쟁을 함께 측정	CPU bandwidth와 PCIe bandwidth를 독립 capacity로 단순 합산하지 않음
multi-socket service	local memory와 local thread placement 우선	socket 수 증가를 memory bandwidth 선형 증가로 해석하지 않음

동작 원리

1단계: Core가 CCD에 요청을 주입한다

코어가 L1과 L2에서 cache miss를 감지하면 cache controller는 physical address, read/write 종류, ordering과 coherence attribute를 가진 transaction을 만든다. 요청은 CCD의 local queue와 cache fabric에 들어간다. 이 단계에서 miss 감지, queue 삽입, IF link 전송 시작을 나누어야 core stall과 die-to-die 지연을 혼동하지 않는다.

T0: L1/L2 miss 또는 write-sharing 감지
T1: CCD request queue 삽입
T2: local L3/home lookup
T3: local hit 또는 IOD-facing IF injection

2단계: CCD의 local cache를 조회한다

요청이 CCD의 L3에 있고 필요한 permission을 얻을 수 있으면 data는 CCD 내부에서 반환될 수 있다. Zen 2에서는 요청 core의 CCX와 다른 CCX를 구분해야 하고, Zen 3 이후에는 unified complex의 공유 L3를 하나의 중요한 locality group으로 분석한다. unified L3는 같은 CCD 내부 경계를 단순화하지만, 다른 CCD나 socket의 remote access를 없애지는 않는다.

3단계: Home과 목적지를 선택한다

local lookup이 실패하면 주소 mapping과 coherence metadata가 다음 service domain을 선택한다. 개념적인 목적지는 다음 요소로 표현할 수 있다.

destination = {
    source_ccd,
    home_or_coherence_agent,
    target_ccd_or_iod,
    memory_controller_or_io_endpoint,
    request_class,
    coherence_state
}

실제 home hash, directory, probe filter와 route algorithm은 제품별 공개 범위가 다르다. 따라서 코어 번호만 보고 특정 CCD나 memory controller를 고정적으로 예측하지 않고, firmware topology, NUMA 정보, address sweep과 PMU 측정을 함께 사용한다.

4단계: Infinity Fabric이 CCD와 IOD 사이를 운반한다

remote service 요청은 CCD의 gateway에서 IF link로 주입된다. link는 request header뿐 아니라 data, coherence control, ordering과 response traffic도 운반할 수 있다. 수신 측 buffer가 부족하면 credit 또는 backpressure가 source CCD로 전파되어 새로운 요청의 injection이 늦어진다.

이 단계의 분석 항목은 다음과 같다.

CCD별 outbound link utilization과 방향별 busy time
IOD gateway input/output queue occupancy와 credit stall
request, data, snoop, invalidate, acknowledgement의 traffic 비율
link retry, corrected error와 power-state transition
동일 IOD gateway 또는 memory controller를 공유하는 CCD 집합

여기서 IF의 물리 link 수와 논리적 coherence home 수를 같은 값으로 취급하지 않는다. 일부 경로는 IOD의 fabric service를 거치고, 제품별로 direct 또는 다른 hierarchy가 있을 수 있으므로 block diagram과 측정 결과를 기준으로 경로를 확정해야 한다.

5단계: Central IOD가 memory 또는 I/O service를 수행한다

IOD에 도착한 memory request는 address mapping에 따라 channel·rank·bank·row·column service로 이어진다. memory controller는 요청 순서와 DRAM timing, read/write 전환을 조정하며, 여러 CCD에서 온 요청은 controller queue에서 경쟁한다.

I/O request는 PCIe 또는 해당 제품의 외부 I/O agent로 향한다. DMA가 memory에 접근하는 경우 CPU cache traffic과 IOD의 memory service resource를 공유할 수 있으므로, CPU-only bandwidth와 device-concurrent bandwidth를 따로 측정한다. Central IOD의 central 역할은 이처럼 여러 CCD의 service request가 모이는 경계를 의미하며, 내부 구현이 하나의 blocking crossbar라는 뜻은 아니다.

6단계: Coherence response와 memory response를 수렴한다

cache line이 다른 CCD의 owner 또는 sharer와 연관되면 home/coherence service는 필요한 data forwarding, invalidate와 acknowledgement를 처리한다. line이 cache hierarchy에 없으면 memory controller가 DRAM에서 data를 읽는다. 응답은 request ID와 ordering rule에 맞춰 source CCD로 돌아가며, source cache는 data와 line state를 갱신한다.

cache hit       -> local CCD response
remote owner    -> coherence service -> owner data -> source CCD
memory miss     -> IOD -> MC -> DRAM -> IOD -> source CCD
I/O transaction -> IOD -> PCIe/device -> completion -> source/device

모든 remote CCD transaction이 동일한 순서로 IOD → target CCD를 지나는 것은 아니다. 이 흐름은 EPYC chiplet의 대표 분석 모델이고, exact response path, directory placement와 data forwarding policy는 SKU별 자료 또는 silicon counter로 확인해야 한다.

7단계: NUMA 배치와 실험으로 검증한다

성능 원인을 분리하려면 CPU affinity와 memory placement를 고정한 뒤 다음 실험군을 비교한다.

동일 CCD의 private/shared cache access
동일 socket의 다른 CCD cache 또는 owner access
local memory와 remote NUMA memory access
uniform memory stream과 특정 memory controller hotspot
read-mostly와 write-sharing coherence workload
CPU traffic과 PCIe/DMA 동시 부하

각 실험에서 평균뿐 아니라 p50/p95/p99 latency, local/remote 비율, CCD·IF·IOD·MC utilization, queue occupancy, corrected error와 전력 상태를 기록한다. lscpu -e, numactl --hardware, numactl --show, Linux perf와 AMD uProf는 OS·플랫폼 수준의 단서를 제공하지만, 내부 IF queue와 exact route를 모두 노출한다고 기대해서는 안 된다.

장단점

장점	단점 및 주의점
작은 CCD를 반복 조합해 코어 수와 제품 SKU를 확장하기 쉬움	CCD 수가 늘면 IF link, IOD gateway와 coherence traffic이 함께 증가함
compute와 I/O를 서로 다른 공정과 die로 분리할 수 있음	die-to-die PHY, package routing, power와 signal-integrity 검증이 추가됨
Zen 3 unified CCD는 같은 CCD 안의 shared-data locality를 단순화함	unified L3가 remote CCD·remote memory 지연을 제거하지는 않음
여러 CCD와 memory channel을 병렬로 활용할 수 있음	Central IOD와 특정 memory controller가 fan-in hotspot이 될 수 있음
CCD·IOD 조합으로 core density와 I/O 요구를 제품별로 조절할 수 있음	standard/dense CCD, cache, frequency와 thermal budget이 SKU마다 다름
socket과 package 수준의 시스템 확장이 쉬움	NUMA distance, remote service와 socket link가 tail latency를 키울 수 있음
IOD에 memory·I/O·RAS와 관리 경계를 모을 수 있음	중앙 경계의 queue, reset, retry와 failure containment 검증이 복잡함

선택과 검증 기준

공유 데이터와 synchronization이 같은 CCD에 머무는지 먼저 확인하고, unified L3를 remote locality의 대체물로 사용하지 않는다.
CCD 수와 최대 core 수보다 IF link utilization, IOD gateway queue, MC occupancy와 p99를 함께 측정한다.
memory bandwidth 비교에는 채널 수, data rate, request size, read/write 비율, address interleave와 NUMA placement를 명시한다.
CPU-only, CPU+DMA, read-mostly, write-sharing과 streaming workload를 분리한다.
Central IOD를 단일 crossbar나 모든 coherence 판단의 중앙 directory라고 단정하지 않고, 공개 block diagram과 분석 모델을 구분한다.
Zen 2의 CCX 경계, Zen 3의 unified CCD, Zen 4/5의 standard·dense CCD 조합을 동일한 cache locality 모델로 비교하지 않는다.
다른 CCD 간 경로는 제품의 공개 topology와 측정 결과가 없는 한 고정된 direct link 또는 고정 cycle로 쓰지 않는다.
multi-socket 시스템은 thread affinity, page placement, NPS/NUMA 설정과 remote memory 비율을 실험 조건에 기록한다.

핵심 정리

CCD는 Zen core와 cache locality를 담는 compute die이고, Central IOD는 여러 CCD를 memory controller·PCIe·외부 service와 연결하는 시스템 경계다.
CCD → Infinity Fabric → IOD → memory/I/O는 대표적인 분석 경로이며, 모든 제품의 고정 배선·cycle·central crossbar를 뜻하지 않는다.
Zen 2의 CCX 경계, Zen 3의 unified CCD, Zen 4/5의 standard·dense chiplet 조합은 서로 다른 locality 모델을 요구한다.
CCD 수가 늘어도 처리량은 IF link, IOD gateway, memory controller와 공통 response path 중 가장 작은 capacity에 제한될 수 있다.
실제 성능은 cache state, NUMA 배치, IOD·MC queue, coherence traffic, DMA 경쟁과 p95/p99를 분리해 측정해야 한다.