Jeonghun (James) Lee

10/17/2025

CXL 의 이해 와 구조

1. CXL(Compute Express Link) 의 이해

CXL (Compute Express Link) 에 대해 급하게 알아야 할 듯하여,관련 자료들을 수집하고 학습.

CXL(Compute Express Link) 란?

PCIe 기반으로 사용되어지는, 고속 DMA Controller 비슷할 것 같다.

즉 CPU 입장에서 생각하면, 각 Cache 에 연결된 AMBA(AHB,APB,AXI) 와 DMA를 이용하여 각 Memory 고속으로 전송하는 Bus Switch Interface가 맞을 듯 하다

https://en.wikipedia.org/wiki/Compute_Express_Link

UCIe

CXL 기반으로 출발한 것 같으며, 현재 Chiplet이라는 ,즉 실리콘 즉 반도체에서 이를 다 연결하려고 하는 Interface가 맞을 것 같다.

https://en.wikipedia.org/wiki/UCIe

PCIe

PCI에서 발전된 Bus로 PCI/HPI는 직접 Driver를 개발했지만, PCIe 직접 개발해보지 못해 이 부분은 나중에 별도로 정리하도록 한다.

요즘은 솔직히 Kernel Platform화가 잘 되어있어, 개발보다는 주로 설정하고 변경하는 것이라 이 부분은 별도로 기회가 있으면 다시 정리하도록 하겠다.

https://en.wikipedia.org/wiki/PCI_Express

CXL 의 개인적 생각 과 결론

종합적으로 보면, CXL는 PCIe Interface 이용하지만, CPU 의 내부에서 비교하자면, AMBA(PCIe) 역할과 DMA Contorller 와 Memory Controller 가능 일 것이다.

그러니, CPU 밖에서, 다양한 CPU들 과 연결하는 것도 쉽게 가능 하리라고 본다.

더 나아가 왜 UCIe가 실리콘, 즉 반도체 위에서 한다는 이유도 대충 이해가 가는 듯하다.

1.1 CXL 구조 와 CXL Type

CXL 구조 와 Type 의 이해

CXL에 대해 쉽게 설명이 되어 있어 , CXL 기본 구조 와 Type 1/2/3 쉽게 이해

CXL 2.0 이 후 Type1/2/3 기반으로 연결 확장 가능하며, 이를 다양하게 더 확장이 가능 설명

https://www.eugenefn.com/common/files/amail/20250321_B45_sophie.yim_67.pdf

CXL 의 Spec 과 이해

1.6 Flex Bus Layering Overview : Flex Bus 의 이해

2.0 Compute Express Link System Architecture : CXL의 Type1/2/3 의 이해

PDF의 좌측 Index 기반으로 각 살펴보면, 쉽게 감이 잡히는 듯하다

관련 그림들은 혹시 문제가 될 듯해서 가져오지 않음

https://computeexpresslink.org/wp-content/uploads/2024/02/CXL-1.0-Specification.pdf

Compute Express Link Consortium

CXL 최신 Spec 신청가능하며 왠지 무료는 아닐듯?
일단 Spec 1.0으로만 만족

https://computeexpresslink.org/

CXL Device Type 1/2/3 구조 와 역할

CXL Type	포함 프로토콜	주요 역할	예시 디바이스	특징
Type 1	CXL.io + CXL.cache	가속기(Accelerator) – 호스트 메모리를 캐시 형태로 접근	Smart NIC, FPGA Accelerator, AI Inference Engine	자체 메모리는 거의 없고, Host DRAM을 Cache Access 함
Type 2	CXL.io + CXL.cache + CXL.mem	고성능 가속기 – Host 메모리 접근 + 자체 메모리 공유 가능	GPU, FPGA with onboard HBM, AI Chip	호스트와 디바이스가 서로의 메모리에 Coherent Access
Type 3	CXL.io + CXL.mem	메모리 익스팬더(Memory Expander) – Host에 추가 메모리 제공	CXL.DIMM, CXL Memory Card, Persistent Memory	CPU가 Device 메모리를 Load/Store 식으로 사용

CXL Controller 관점의 비교

각 Host 와 CXL Device(CXL Controller) 관점에서 비교를 해보자.

Cache 에 따라 성능이 변경되므로,

Coherency Directory 즉 Cache 의 일관성을 어디까지 해야 하는 지이며, 알고리즘은 어떤 것을 쓰는지 또, 범위는 어디까지 하는 지가 중요하다(이 부분 다시 밑에)

구성 요소	Type 1	Type 2	Type 3
CXL.cache	✔	✔	✘
CXL.mem	✘	✔	✔
CXL.cache	✔	✔	✘
Coherency Directory	(Host side only)	(Host + Device side)	(Host side only)
Local DRAM Access	✘	✔	✘
목적	Compute 가속	Compute + 메모리공유	Pure Memory 확장

CXL Device Type1/2/3 확장 (결합)

CXL 2.0 이상부터는 이 Type 1/2/3 디바이스를 스위치와 Fabric구조에서 논리적 결합(Logical Device) 으로 묶을 수도 있다고 한다.

증권사 자료이지만, 이해 하기가 자료 좋음

https://www.eugenefn.com/common/files/amail/20250321_B45_sophie.yim_67.pdf

CXL Fabric 간단 정리

지능형 연결망이라고 하는데, 각 기능들을 Thread 즉 실로 보고, 이를 엮어서 각 기능들의 총체적인 기능을 말한다고 한다.

즉 CXL Fabric 구조는 여러 외부 CPU들 과 다양한 Peripherial 들 연결 확장까지도 생각을 해볼 수 있는 것이다.

1.2 CXL Swtich 구조

다양한 PCIe Channel 들을 처리하기 때문에 Arbiter/Mux 는 역할이 중요할 것 같으며,

즉, DMA Controller 역할이 비슷할 거라고 생각되어진다.

상위 Spec1.0 보면 다양한 기능들이 들어가면서, 다양한 기능들을 처리하려면, 단순한 DMA Controller가 아닌 복합적인 DMA Controller 동작할 거 같다.

CXL Switch 역시 여러 CXL Device Type 1/2/3 조합으로 각 CXL switch 마다 각 기능이 다 다를 것이다.

여러 CXL Device Type 1/2/3 조합이 가능하므로, 아래로 한정적으로 생각하지 말자.

CXL Switch Diagram

CXL 2.0 부터 추가되어진 기능

기능	역할
Address Mapping / Routing	어떤 요청이 어느 Type으로 가야 하는지 결정
Coherency Management	여러 Type 2/3 장치가 같은 주소 접근 시 캐시 일관성 유지
QoS / Credit Flow	트래픽 제어 및 우선순위 관리
Memory Pooling / Partitioning	여러 메모리 모듈을 하나의 논리 풀로 묶음
Security (IDE)	각 링크별 암호화 및 키 관리

1.3 Rambus 의 CXL Controller IP 확인

실제 CXL Controller IP 팔고 있는 곳이 있기에 관련 부분을 보도록 하자

Data Encrytion 의 이해

AES의 대칭키 이해와 KEY 운영 GCM 확인

https://ahyuo79.blogspot.com/2020/03/cipher-suite.html

CXL Controller IP기능 확인

CXL Controller 3.1 vs CXL 2.0 비교
CCIX(Cache Coherent Interconnect for Accelerators) Controller 각 기능
CXL Controller -> 거의 이게 핵심

PIPE 부분은 PCIe 와 같이 봐야 할 듯

https://www.rambus.com/interface-ip/cxl/#controller

CXL 2.0 Controller 의 구조

CXL 2.0 Controller

CXL Protocol Layer
User Interface Layer
Integrity and Data Encryption (IDE) -> AES-GCM 방식
Unique Features & Capabilities

CXL 2.0 Controller with AXI Block

ARM과 AMBA 호환

https://www.rambus.com/interface-ip/cxl/cxl2-controller/

Rambus CXL 2.0 Controller with IDE

IDE(Encrytion)의 Zero Latency

AES-256-GCM, GCM 이외 CTR 지원 가능?

상위와 CXL 2.0 Controller 와 동일

https://www.rambus.com/rambus-delivers-cxl-2-0-controller-with-industry-leading-zero-latency-ide/

PCIe 의 구조

PCIe Contoller
PCIe Switch
PCIe Phy

CXL의 이해하려면 PCIe의 Phy를 사용하므로, 이 부분은 어 쩔 수 없이 봐야 할 듯하다

https://www.rambus.com/interface-ip/pci-express/

2. CXL 의 Cache 이해

CXL의 Cache 는 아주 중요한 개념이며, 어떻게 보면, CXL 성능 핵심 기능일 듯하다.

즉 Cache 알고리즘에 따라 각 CXL의 성능이 달라질 것이며, 이 부분은 거의 회사마다 민감한 문제가 있을 듯하다.

2.1 Cache Coherence 의 이해

CPU 입장 의 SMP 관점

다중 코어의 cache-coherency protocols 이용하여 1개의 Core처럼 사용을 하려 한다면, 어떻게 해야 하지

https://en.wikipedia.org/wiki/List_of_cache_coherency_protocols#SMP_%E2%80%93_symmetric_multiprocessor_systems

OS 입장의 SMP vs AMP 관점

OS 입장에서는 다중 코어일 경우, SMP vs AMP 어떻게 Scheduling 할 것인지, 즉 방법

Linux 의 경우, SMP기준으로 많이 사용

https://ahyuo79.blogspot.com/2021/10/esp32-freertos.html

CPU Cache Coherence 의 기본이해

각 독립적인 Cache를 Sync를 맞춰주는 작업이며, 아래 그림을 보면 쉽게 이해 간다.

그럼 Why 사용할까 , ARM 같은 다중 코어 일 때, SMP로 Task Scheduling 하려면, Cache Coherence의 역할은 중요하다

이유는 아래같이 여러 Core 같이 동시에 나누어서 작업을 해야 하기 때문이다.

https://en.wikipedia.org/wiki/Cache_coherence#Overview

Cache Coherence 의 문제

각 CPU Cache의 Coherence를 맞추어 주는 것은 좋으나, Cache Coherence의 범위를 예측을 못하는 문제가 발생하다.

SMP 기준으로 간단히 생각을 해보면,

모든 CPU의 Cache가 Coherence되어, 1/2번째 CPU는 작업을 나누어 완료 후, 3번째 CPU의 Cache 오래되어, 이제 필요가 없어지는 문제이다.

https://en.wikipedia.org/wiki/List_of_cache_coherency_protocols#Cache_coherency_problem

Cache Coherence 의 개인 생각 정리

결과적으로, Cache Coherence 범위, Cache 사이즈 및 갯 수 정확하게 제대로 예측 못하면, Cache의 Hit 율이 계속 떨어지고 효율은 낮다.

어떻게 보면, Cache 예측과 Coherence 범위가 가장 중요할 듯 하다

좀 더 세부적으로 Cache Coherence 생각해보면, 아직 아래 Protocol도 이해를 못했지만,

Cache Coherence 운영을 하는 입장에서 생각을 해보면, 다음과 같은 생각도 얼마든지 해볼 수 있다.

Cache Coherence를 3가지로 A.전체/B.부분(범위)/C.제외 이런 식으로 될 것 같기도 하다.
가중치(weight,bias)기반으로 매번 Cache Coherence 변경되어지거나 다양하게 생각 할 수 있을 것 같다.
CNN으로 TinyML 사용해서, 가중치 대신해서 사용 가능 할 것 같다. (다양하게 생각이 듦)

이 부분은 Spec 과 나중에 Cache Corency Protocol 이해 후 다시 생각해 보고, 이해해보도록 하자

ESP32 Cache 와 Memory 비교

개인적으로 ESP32 CPU 설계를 잘했다고 생각을 하며, ESP-IDF 역시 너무 잘 구현을 해놨다.

https://ahyuo79.blogspot.com/2022/02/esp32-memory-3-external-memory-1.html

https://ahyuo79.blogspot.com/search/label/MCU-ESP32-MEM

2.2 Cache Corency Protocol

우선적으로 Cache Corency Protocol 이해 하기 위해서 각 Cache 상태들 부터 이해 해보도록 하자

머리가 나쁘면, 고생이다.

CAPI(Coherent Accelerator Processor Interface)

https://en.wikipedia.org/wiki/Coherent_Accelerator_Processor_Interface

Cache 의 상태 이해

Cache Coherency Protocol States

상태	약어 의미	설명
M	Modified / D / Dirty / DE / EM	- 한 개의 캐시에만 존재하고 수정된(Dirty) 상태 - 메모리 내용은 오래된 값 (아직 반영 안 됨) - 교체 시 반드시 Write-back 필요
O	Owner / SD / SM / T	- 여러 캐시에 복사본 존재하지만 메모리는 오래된 값 - 한 캐시만 “소유자(Owner)” 역할 - 다른 캐시의 읽기 요청 시 Owner 캐시가 데이터 공급
E	Exclusive / R / VE / EC / Me	- 한 캐시만 데이터 보유하고 메모리와 동일(clean) - 다른 캐시에는 복사본 없음 - 쓰기 시 바로 M(Modified)로 전환
S	Shared / V / SC	- 여러 캐시에 동일 데이터 복사본 존재 - 주로 읽기 전용(Read-only) 상태 - 메모리와 일관됨 (clean) - 단, 일부 프로토콜(예: Dragon)은 Shared Clean이 dirty일 수 있음
I	Invalid	- 유효한 데이터 없음 (태그 불일치 또는 무효화됨) - 접근 시 메모리나 다른 캐시로부터 새로 읽어와야 함

Special / Extended States (MESI 확장형)

상태	이름	설명
F (또는 R)	Forward / Recent	- Shared 상태 중 대표 캐시(Forwarder)가 응답 역할 담당 - 동일 데이터가 여러 캐시에 있을 때 메모리 대신 이 캐시가 응답(intervention) - Intel: MESIF, IBM: R-MESI (MERSI)
H	Hover	- 캐시에 주소 태그만 유지, 데이터는 무효(Invalid) - 버스에서 해당 주소가 탐지되면 빠르게 유효(S) 상태로 복귀 - HR-MESI, HRT-MESI 등에서 사용되어 검색 속도 개선

Cache Status 요약 비교

상태	캐시에 존재	메모리 최신성	공유 가능성	쓰기 가능성	설명
M	✔ 있음	✘ 오래됨	✘	✔	수정됨, 아직 메모리 반영 안 됨
O	✔ 있음	✘ 오래됨	✔	✘	여러 캐시 중 한 곳이 최신 데이터 소유
E	✔ 있음	✔ 최신	✘	✔	유일한 캐시 복사본, clean 상태
S	✔ 있음	✔ 최신	✔	✘	여러 캐시에서 읽기만 가능
I	✘ 없음	✔/✘ 불명	✘	✘	데이터 없음 또는 무효 상태
F	✔ 있음	✔ 최신	✔	✘	공유 중 대표 캐시(Forwarder)
H	태그만 존재	✘	✘	✘	주소만 남겨 빠른 재활성 가능