Github Page

레이블이 IF-CXL인 게시물을 표시합니다. 모든 게시물 표시
레이블이 IF-CXL인 게시물을 표시합니다. 모든 게시물 표시

10/28/2025

PCIe 이해 와 USB 비교

1. PCIe 의 기본 구조 
.
PCIe Layer 전체 구조 와 각 Layer 특성을 간단히 알아본 후, USB 와 같이 비교를 해보자 
일단 1차 버전으로 기본을 이해하고, USB 와 지속적으로 비교하면서 업데이를 하겠다. 

  • PCIe Layer 구조 
Ethernet 가 다르게 Layer 3개이며, USB  Layer 비슷하다고 생각되어진다.
이 부분은 나중에 다시 다루도록 하겠음 




  • PCIe 각 Layer 관련 설명
Wiki만 봐도 대충 이해는 갈 듯 하다. 


1.1  PCIe 와 USB 비교 

PCIe 와 USB 가 서로 비슷하므로, 관련 부분들을 일단 비교를 해보고 차이점을 알아보도록 하자. 

  • PCIe 와 USB 비교  
구분 PCI Express (PCIe) USB (특히 USB 3.x 기준) 차이점
Topology Point-to-Point
(Switch fabric)		 Tiered Star
(Host + Hub + Device)		 PCIe P2P  
USB Master-Slave 
Application Layer SW에서 보낸 Memory/Registeer 접근 요청을 처리
(e.g. Memory Read/Write, I/O, Config)		 Host 에서 Description 기반의 
Class Driver 제공 및 별도 정의해서 구현가능
(e.g. Mass Storage, HID 등)
상위 연결 후 (URB)을 통신 		 PCIe 자동 협상+동기화
USB Host Control 중심
Transaction Layer
(TL)		 Packet 단위로 Request/Completion 처리
주소 기반(Load/Store)		 USB Transfer Types
(Control/Bulk/Interrupt/Isochronous)
Transaction 을 Device 정의		 PCIe는 Memory Access 중심
USB는 EndPoint 중심
Data Link Layer
(DLL)		 Ack/Nak, 시퀀스 번호, CRC, 재전송 Link Command 패킷
(Flow Control, Link Management 등)		 PCIe는 신뢰성(ACK/NACK) 보장
USB는 최소 Overhead
Physical Layer
(PHY)		 8b/10b 또는 128b/130b
CDR, EQ(CTLE/DFE), PIPE		 8b/10b(USB 3.0)
128b/132b(USB 3.1)
LFPS,
PHY PIPE		 둘 다 High Speed SERDES PHY사용
둘 다 Channel 특성/속도 협상방식 다름



  • USB 관련자료 
PCIe 와 USB 간단히 비교를 해보고, 이해하자. 

  • TI USB 3.2 정보 
  1. 6  Physical Layer  --> 전체구조 파악 
  2. Section 6.9 Low-Frequency Periodic Signaling (LFPS)   -> 기능확인 (Sequence)

개인생각 
내 개인 생각이지만, 추후 CXL를 잘 사용하기 위해서는 PCIe Switch/CXL Switch 와 USB Host 연결이 중요할 듯하다.
이유는 둘 다 고속 Serial Interface 이면서, 잘 이용한다면, CXL 의 확장으로 쉽게 USB 와 연결하여 
사용할 것 같다. 
USB의 경우 역사가 깊어 Protocol 안전성 과 관련 Host Stack 이미 구현되어져 있는 게 많다. 
더불어 USB의 장점이 Device에서 Transfer Type을 설정하고, 기술하여 마음대로 전송도 가능하므로, 확장도 쉽다. 




1.2 PCIe Version 따른 개별 Layer 변화  

각 용어가 몰라도 좋으니, 그러려니 하고 넘어가도록 하며 각 변화 사항만 파악하도록 하자.

  • PCIe Version 별 각 Layer 변화 
PCIe Version Transaction Layer Data Link Layer Physical Layer (PCS / PMA / PIPE)
1.0 / 1.1 • Basic TLP (Memory, I/O, Config)
• No Atomic Ops / FLIT concept		 • Basic ACK/NAK mechanism
• 8-bit Sequence Number		 • 8b/10b Encoding (2.5 GT/s)
• No standardized PIPE (Vendor-specific)
• PMA = Basic SerDes
2.0 • Adds Virtual Channels (QoS)
• Transaction Layer split enhancement		 • LCRC reliability improved
• Replay buffer efficiency improved		 • PIPE introduced (v3.0) ✓
• 5 GT/s signaling
• Same 8b/10b encoding
• PHY–MAC separation begins
3.0 • Atomic Ops added
• TLP Compression (Header Reduction)		 • 16-bit Sequence Numbers
• DLLP optimization for higher throughput		 • 128b/130b Encoding (8 GT/s)
• PIPE 4.x
• Equalization / Training introduced
• Advanced LTSSM states
4.0 • Enhanced Ordering Rules
• Improved Completion Handling		 • Retry buffer + Replay Timer improvement • PIPE 5.1
• 16 GT/s, improved EQ tuning
• Enhanced Link Training sequences
• Jitter tolerance improved
5.0 • No major logical change
• Mainly supports higher bandwidth TLP		 • Optimized flow control timing • PIPE 6.1
• 32 GT/s, retimer interoperability
• Power Management enhancements (L1.1/L1.2)
6.0 • FLIT-based TLP (Fixed-Length Packet) ✓
• Forward Error Correction (FEC) added		 • Replay protocol removed (replaced by FEC)
• Simplified ACK logic		 • PAM-4 signaling (64 GT/s) ✓
• PIPE 6.2+
• FEC engine in PHY
• LTSSM updated for FLIT and PAM-4 link training
7.0 (draft) • Continuation of FLIT architecture • TBD minor optimization • PIPE 7.0 (planned)
• PAM-4 extended, improved EQ/FEC interaction
• Anticipated 128 GT/s signaling


  • 주요특징정리
Transaction Layer: 3.0부터 Atomic Ops, 6.0에서 FLIT 구조로 근본적 변화
Data Link Layer: 6.0에서 FEC 도입으로 ACK/NAK 메커니즘 단순화
Physical Layer:
2.0 → PIPE 등장
3.0 → 128b/130b 전환
6.0 → PAM-4 + FEC로 신호방식 자체 변화


2. PCIe Layer 

상위 Layer 기반으로 각 기능들을 간단히 설명하도록 하겠으며, 아래와 같이 1개의 Serial 통신이 생성이 되어진다. 


2.1 Transaction Layer 


A.역할  

CPU, DMA, 또는 다른 SoC 내부 논리에서 발생한 메모리 접근, 
I/O Access, Message Transaction을  Packet(TLP, Transaction Layer Packet)으로 생성하는계층.

B.기능정리
  1. Memory Read / Write, I/O Read / Write, Configuration Read / Write 등의 Trasaction 정의
  2. 각 요청(Request)과 응답(Completion) 관리
  3. Address Translation, BAR (Base Address Register) Mapping
  4. MSI/MSI-X Interrupt 관리
  5. Flow Control 관리 
    1. Credits 방식
B.세부사항  
  1. 실제 PCIe Core (Controller) 의 대부분의 로직이 여기에 있음
  2. 펌웨어/드라이버는 주로 Transaction Layer 레벨에서 동작 (메모리 접근, DMA 제어 등)
  3. SW ↔ HW 인터페이스는 Configuration Space (PCI Config) 를 통해 이루어짐

2.2 Data Link Layer


A. 역할

Transaction Layer에서 내려온 TLP에 대해 신뢰성을 보장하고, ACK/NACK 기반의 재전송 메커니즘을 수행한다.
Network 치면, TCP와 유사할 것 같다. 
즉, “Reliable Delivery”를 담당

B. 기능정리
  1. Sequence Number 관리 (순서 보장)
  2. LCRC (Link CRC) 계산 및 검증
  3. ACK / NACK 프로토콜 (Data Link Layer Packet, DLLP 사용)
  4. Flow Control Credit 업데이트 (DLLP 통해 전송)

C. 주요패킷 종류
  1. TLP (Transaction Layer Packet): 실제 데이터
  2. DLLP (Data Link Layer Packet): 제어 정보 (ACK/NACK, Flow Control 등)

B. 세부 사항  
  1. TLP이 손상되거나 순서가 어긋나면 재전송 요청
  2. PHY 신호 오류는 Data Link Layer에서 검출하여 자동으로 복구
  3. 한 Link마다 독립적으로 동작 
    1. (ex. Root ↔ Endpoint, Switch ↔ Device)

2.3. Physical Layer


A. 역할

Data Link Layer에서 전달 받은 데이터 패킷을 직렬화(Serialize) 하여 실제 신호로 전송하고, 수신 데이터를 복원(Deserialize) 한다.
전송 매체는 AC-Coupled Differential Pair (Tx/Rx Lane) 로 구성된다.
중간에 Bypass Capacitor 사용하여 ,즉 AC로 전송을 하는 구조이다.  

B. 하부구조

A. PCS (Physical Coding Sublayer)
  1.  Encoding/Decoding
    1. 128b/130b (Gen3 이상)
    2. 8b/10b (Gen1/2)
  2. Scrambling/Descrambling (DC Balance 유지)
  3. Lane Alignment, Symbol Lock
  4. SKP Ordered Set 삽입 (Clock 보정용)
  5. PIPE 인터페이스
B. PMA (Physical Medium Attachment)
  1. Serializer / Deserializer (SerDes)
  2. Equalizer (CTLE, DFE 등)
  3. Clock Data Recovery (CDR)
  4. Transmit Driver / Receiver Front-End
  5. Eye Diagram, Pre-emphasis 등 실제 아날로그 신호 특성 조정

  • PHY 의 PCS vs PMA 비교 
구분 PCS (Physical Coding Sublayer) PMA (Physical Medium Attachment)
성격 Digtal Logic Analog/ Mixed-signal
주요 기능 • Encoding/Decoding (8b/10b, 128b/130b)
• Scrambling
• Alignment
• LTSSM
• SerDes
• Equalization
• CDR
• Voltage swing
주요 위치 Controller Side Channel(Lane) Side
주요 변화 PIPE 3.0~6.0 사이 인코딩 변화 PCIe 3.0부터 EQ·CDR 고도화


  • Serializer / Deserializer (SerDes)
  1. Controller에서 오는 병렬 데이터를 직렬 신호로 변환 (TX)
  2. 수신 시 반대로 직렬 데이터를 병렬로 복원 (RX)
  3. PCIe x1, x4, x8, x12, x16, x32 Lane  동작

  • Equalization (Channel 보정)
  1. 신호 감쇠, 반사, ISI(inter-symbol interference)를 보정
  2. 송신단 (Tx Pre-emphasis / De-emphasis)
  3. 수신단 (Rx CTLE, DFE) 조합으로 수행
  4. PCIe 3.0 이후에서 매우 중요해짐

  • CDR (Clock and Data Recovery)
  1. 수신 신호에서 클록을 복원하여 비트 타이밍 동기화 수행
    1. Inverse Filter를 사용하여 복원 
  2. Eye Diagram을 기반으로 샘플링 포인트 결정

  • Electrical Interface
  1. 전압 스윙, 신호 스펙트럼, 임피던스 매칭, EMI 최소화
  2. 실제 Package Pin / PCB Trace/ Connecter / Cable과 직접 연결

3. TI 와 AMD  PCIe Controller 분석 


TI PCIe Controller

AMD PCIe Controller 


3.1 USB-DRD(Dual Role Data) 정리  

USB의 경우, Host 와 Device 즉 Master / Slave 구조라서 각 Role 의 역할이 정해져 있으며, 협상을 통해 이를 정하는 기능이 존재했다. 
그것이 기존의 OTG이고, USB Type-C  기존 OTG에서 확장된 개념으로 생각하면 될 듯하다. 

  • i.MX6 OTG/DRD(Dural Role Data) 이해 
USB OTG(On The Go) 이해해야, DRD(Dural Role Data)  이해가 가능 

  • USB 3.0 이후 OTG 와 DRD 차이점 
USB OTG 차이를 생각하면, 단지 Host / Device Role 구분 뿐만 아니라,
USB-PD(Power Delivery)가 Source/ Sink 구분되어 
기존의 USB Host에서 만 전원을 제공하던 개념이 깨진 것이 핵심일 것 같다. 

  • USB-DRD(Dual Role Data)
AMD USB 3.2 DRD(Dual Role Data) Controller 

댓글 없음 :
Tags: , ,

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가 맞을 듯 하다 

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

  • PCIe
PCI에서 발전된 Bus로 PCI/HPI는 직접 Driver를 개발했지만, PCIe 직접 개발해보지 못해 이 부분은 나중에 별도로 정리하도록 한다. 
요즘은 솔직히 Kernel Platform화가 잘 되어있어, 개발보다는 주로 설정하고 변경하는 것이라 이 부분은 별도로 기회가 있으면 다시 정리하도록 하겠다. 

  • 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 기반으로 연결 확장 가능하며, 이를 다양하게 더 확장이 가능 설명  

  • CXL 의 Spec 과 이해 
1.6 Flex Bus Layering Overview : Flex Bus 의 이해 
2.0 Compute Express Link System Architecture : CXL의 Type1/2/3 의 이해 
PDF의 좌측 Index 기반으로 각 살펴보면,  쉽게 감이 잡히는 듯하다 
관련 그림들은 혹시 문제가 될 듯해서 가져오지 않음 

Compute Express Link Consortium
  1. CXL 최신 Spec 신청가능하며 왠지 무료는 아닐듯?
  2. 일단 Spec 1.0으로만 만족 
 

  • 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) 으로 묶을 수도 있다고 한다. 
증권사 자료이지만, 이해 하기가 자료 좋음 

  • 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 확인 

  • CXL Controller IP기능 확인
  1. CXL Controller 3.1 vs CXL 2.0 비교 
  2. CCIX(Cache Coherent Interconnect for Accelerators) Controller  각 기능 
  3. CXL Controller  -> 거의 이게 핵심 
    1. PIPE 부분은 PCIe 와 같이 봐야 할 듯 

  • CXL 2.0 Controller 의 구조 
  1. CXL 2.0 Controller 
    1. CXL Protocol Layer
    2. User Interface Layer
    3. Integrity and Data Encryption (IDE)  -> AES-GCM 방식
    4. Unique Features & Capabilities
  2. CXL 2.0 Controller with AXI Block  
    1. ARM과 AMBA 호환 
  
  • Rambus CXL 2.0 Controller with IDE 
  1. IDE(Encrytion)의 Zero Latency  
    1. AES-256-GCM, GCM 이외 CTR 지원 가능? 
  2. 상위와 CXL 2.0 Controller 와 동일 

  • PCIe 의 구조 
  1. PCIe Contoller 
  2. PCIe Switch 
  3. PCIe Phy
CXL의 이해하려면 PCIe의 Phy를 사용하므로, 이 부분은 어 쩔 수 없이 봐야 할 듯하다 



2.  CXL 의 Cache 이해 

CXL의 Cache 는 아주 중요한 개념이며,  어떻게 보면, CXL 성능 핵심 기능일 듯하다.
즉 Cache 알고리즘에 따라 각 CXL의 성능이 달라질 것이며, 이 부분은 거의 회사마다 민감한 문제가 있을 듯하다. 


2.1  Cache Coherence 의 이해 

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

  • OS 입장의 SMP vs AMP 관점 
OS 입장에서는 다중 코어일 경우,  SMP vs AMP 어떻게 Scheduling 할 것인지, 즉 방법 
Linux 의 경우, SMP기준으로 많이 사용 

  • 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 오래되어, 이제 필요가 없어지는 문제이다. 

  • Cache Coherence 의 개인 생각 정리 
결과적으로, Cache Coherence 범위, Cache 사이즈 및 갯 수 정확하게 제대로 예측 못하면, Cache의 Hit 율이 계속 떨어지고 효율은 낮다. 
어떻게 보면, Cache 예측과 Coherence 범위가 가장 중요할 듯 하다 

좀 더 세부적으로 Cache Coherence 생각해보면, 아직 아래 Protocol도 이해를 못했지만, 
Cache Coherence 운영을 하는 입장에서 생각을 해보면, 다음과 같은 생각도 얼마든지 해볼 수 있다.  
  1. Cache Coherence를 3가지로 A.전체/B.부분(범위)/C.제외 이런 식으로 될 것 같기도 하다. 
  2. 가중치(weight,bias)기반으로 매번 Cache Coherence 변경되어지거나 다양하게 생각 할 수 있을 것 같다.
  3. CNN으로 TinyML 사용해서, 가중치 대신해서 사용 가능 할 것 같다. (다양하게 생각이 듦)
이 부분은 Spec 과 나중에 Cache Corency Protocol 이해 후 다시 생각해 보고, 이해해보도록 하자 


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



2.2 Cache Corency Protocol 

우선적으로 Cache Corency Protocol 이해 하기 위해서 각 Cache 상태들 부터  이해 해보도록 하자  
머리가 나쁘면, 고생이다. 

CAPI(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 태그만 존재 ✘ ✘ ✘ 주소만 남겨 빠른 재활성 가능


Cache Corency Protocol 의 종류 와 알고리즘 
각 알고리즘의 흐름이 변경되어지는 것을 대충 알 수 있으며, 이 부분은 나중에 좀 더 확인하자.


MESI 의 이해 (대표적)
아직 완벽히 이해가 되지 않은 상태 

MESIF 의 이해 (요즘?)
아직 완벽히 이해가 되지 않은 상태 



3. CXL 의 Linux Manual  

현재 Linux를 잠시 보면, CXL는  Device Type 3으로 메모리 확장용 으로만 사용하는 듯하다. 

  • Linux Device Driver (CXL)
  1. CXL Linux Device Driver 와 Manual 
  2. CXL Device Type 3으로만 사용? 
CXL Device Type 3(Memory 확장용)로만 사용한 것 같으며, Manaul도 거기 까지 인듯하다. 

  • Linux UserSpace
  1. CXL Linux User Manual 
  2. CXL ioctl 이용 


3.1 CXL 의 Linux Kernel 소스 

Linux Kernel 소스 찾아 각 부분 확인 

  • PCI의 ACPI 의 정보 
다만 PCIe가 아닌 PCI 인듯하며, PM 제어는 오래전부터 존재 했던거 같다. 
상위 CXL 1.0 Spec을 보면 PM제어는 부분이 많이 나온다. 

  • BIOS 와 ACPI 관련이해 
BIOS 에서 사용하는 UEFI의  ACPI(Advanced Configuration and Power Interface)  


  • CXL 의 Core 소스 (Linux Kernel)
  1. 상위 Device Type 3 의 Memory 확장형 소스 인것 같음 
  2. Memory 를 보면 주로 모듈형 RAM을 제어 DIMM

  • CXL 의  이외 소스 (Linux Kernel)
  1. 상위 Core 기반으로 Memory 확장형에  ACPI 기술이 첨부
    1. UEFI 의 ACPI(Advanced Configuration and Power Interface)  
  2. PCIe를 그냥 PCI로 기술을 하는 듯함 



상위 Device Driver 와 각 Spec 1.0을 보면서 느낀 점을 정리하자면 아래와 같다. 

  • CXL Switch 의 개인생각 
CXL 관련 Linux Kernel 소스 부분 확인 및 구조 확인 했지만, Device Type 3만 확인되는 듯하며,
CXL Switch Driver(각 CXL Type1/2/3 복합적 연결)는 아직 발견을 못했으며, 
분명, USB Host 처럼 Bus 형태의 Driver 일 것 같은데, 현재 각 제조사마다 다 다를 테니 이것은 초창기 USB Host Controller와 비슷하게 갈 듯하다 

또한, 분명히 CXL Switch가 구조화가 복잡하게 되므로, USB Host처럼 각 Device 의 구조를 설명하는 Description 형태로 각 설정을 변경하는 구조로 갈 듯하다. 왠지?
상위 부분은 Spec을 보고 나중에 다시 생각해보자  


  • CXL 기반의 AI 업체 개인생각 
H/W 입장에서 보면, CXL기반의 AI 업체들의  핵심 개발은 왠지  CPU 와 GPU 와 NPU 의 CXL.cache 가 가장 중요할 듯 하다. 
이유는 SRAM을 가장 효율적으로 빨리 동작 시켜서 DRAM기반으로 VRAM으로 성능 최적화를 하려고 할 것 같다. 

S/W 입장에서 보면, NVIDIA처럼 이제 AI H/W 도 중요하지만, 오히려 S/W Platform의 다각화가 더 중요할 듯하다. 
(NVIDIA 사이트만 가봐도 이해가 되며, Training 대충 경험이 있다면 이해가 더 빠르다)


3.2 Linux 의 Yocto 

Yocto 기반의 Linux에서 CXL 관련부분 을 검색하고 자료 수집 하려 했으나, 아직 제대로 찾지를 못함 
나중에 찾으면, 아래에 링크를 추가하겠음 

  • Yocto 의 기본이해 
Yocto 의 기본이해 



  • Yocto 의 openembedded Layer 확인 
각 최신 버전 과 Layer 확인 했지만, 아직 발견 못함 
CXL Switch 일 경우, 각 Bus Driver가 있어야 할 듯한데, 흐음? 



3.3 Linux 의 QEMU 

Linux Kernel에서 QEMU의 기반의 CXL 부분 확인 

  • QEMU 의 Linux Device Driver (CXL) 
  1. CXL 전체 구조를 보면 역시 Device Type 3 메모리 확장형만 사용 
    1. CXL 2.0  Type.1/2/3 지원 (문제는 Type 3만 사용)
    2. KERNEL CONFIG 확인 
    3. QEMU 으로 동작되는 것을 확인 
      1. 아래 링크 확인

댓글 없음 :
Tags: , , , , ,
피드 구독하기: 덧글 ( Atom )