Zeah Engineering Factory

1. NVLink의 동기 (NVLink Motivations)

NVLink는 대역폭(Bandwidth)과 GPU 간 효율적인 동작(GPU-Synergistic Operation)을 목표로 설계되었습니다.

(1) GPU 동작 특성이 NVLink 사양과 적합 (GPU Operational Characteristics Match NVLink Spec)

• 스레드 블록(Thread Block) 실행 구조가 병렬화된 NVLink 아키텍처에 효율적으로 데이터를 전달
• NVLink 포트 인터페이스(NVLink-Port Interfaces)는 L2 캐시와의 데이터 교환 방식과 최대한 일치하도록 설계됨

(2) PCIe보다 빠름 (Faster than PCIe)

• NVLink4 기준 100Gbps/레인 vs PCIe Gen5 기준 32Gbps/레인으로 훨씬 높은 대역폭 제공
• 여러 개의 NVLink를 "ganging" (연결 묶기)하여 총 레인 수를 증가시켜 더 높은 집계 대역폭 실현 가능

(3) 기존 네트워크보다 낮은 오버헤드 (Lower Overheads than Traditional Networks)

• 256개 Hopper GPU를 연결하는 대규모 시스템에서 엔드 투 엔드 재시도(end-to-end retry), 적응형 라우팅(adaptive routing), 패킷 재정렬(packet reordering) 등의 기능을 포트 개수와 트레이드오프 가능
• 애플리케이션, 프레젠테이션, 세션 계층(Application/Presentation/Session-layer)을 단순화하여 CUDA 프로그램 및 드라이버에 직접 포함 가능

2. 오른쪽 블록 다이어그램 설명

이 다이어그램은 NVLink를 통한 GPU 내부 및 외부 데이터 흐름을 보여줍니다.

1. SM (Streaming Multiprocessor, 녹색 박스)
   • GPU의 기본 연산 단위로서 스레드 블록(Thread Block)이 실행되는 곳
   • 여러 개의 SM이 병렬로 동작하며, 서로 데이터를 주고받음
2. SM 간 통신 (SM to SM, 파란색 박스)
   • GPU 내부에서 SM 간 통신을 처리하는 역할
   • SM들 간의 직접적인 데이터 교환을 통해 메모리 접근 오버헤드 감소
3. L2 캐시 (L2, 회색 박스)
   • 모든 SM이 공유하는 L2 캐시
   • NVLink 포트 인터페이스와 연결되어 외부와 데이터를 주고받음
4. NVLink 포트 인터페이스 (NVLink-Port Interfaces, 녹색 박스)
   • GPU 외부의 다른 GPU 또는 CPU와 NVLink를 통해 직접 데이터 교환
   • PCIe를 사용하는 것보다 더 높은 대역폭과 낮은 지연시간 제공

3. 핵심 요약

• NVLink는 GPU 병렬 구조와 잘 맞으며 PCIe보다 훨씬 빠른 대역폭 제공
• 기존 네트워크보다 오버헤드가 낮아 대규모 GPU 시스템에서 효율적인 데이터 교환 가능
• NVLink 포트 인터페이스를 통해 L2 캐시를 활용하여 외부와 직접 연결
• SM 간 통신(SM to SM)과 L2 캐시를 통한 데이터 교환을 최적화하여 GPU 간 연산 성능 향상

이 NVLink 개념은 HPC(고성능 컴퓨팅), AI 모델 학습 및 추론, 데이터 센터 GPU 클러스터링에서 중요한 역할을 합니다.

GPU 내부 신호 흐름 및 NVLink와의 연결 구조 정리

1. SM (Streaming Multiprocessor) 내부 연산 및 통신

• SM은 Thread Block 단위로 연산을 수행하며, CUDA 코어를 통해 병렬 연산을 처리함.
• 같은 SM 내의 CUDA 코어들은 Shared Memory, L1 Cache를 통해 데이터 공유.
• SM 간 통신은 "SM-to-SM" 네트워크를 통해 이루어짐.

2. SM 간 통신 (SM-to-SM 네트워크)

• 여러 SM이 존재하는 GPU에서는 SM 간 데이터 교환이 필요함.
• 이를 위해 "SM-to-SM 네트워크"가 존재하며, 같은 GPC 내 SM들이 데이터를 교환할 수 있음.
• SM 간 데이터를 공유하는 방식:
  1. SM-to-SM 네트워크 직접 이용 (빠른 데이터 공유)
  2. L2 캐시를 거쳐 데이터 공유 (데이터 일관성 유지)

3. L2 캐시를 통한 메모리 계층 구조

• GPU 내부에는 L2 캐시가 존재하며, 모든 SM들이 공유함.
• 주요 역할:
  • SM 간 데이터 공유
  • NVLink 또는 PCIe를 통한 외부 데이터 전송 시 캐싱 역할 수행
  • Global Memory (DRAM/HBM) 접근 시 속도 향상

4. NVLink 및 외부 인터페이스와의 연결

• L2 캐시에서 나온 데이터는 NVLink-Port Interfaces 또는 PCIe를 통해 외부로 전송됨.
• NVLink를 통해 다른 GPU 또는 NVSwitch에 직접 연결 가능.
• NVLink 연결 구조:
  • GPU ↔ GPU (멀티 GPU 환경)
  • GPU ↔ NVSwitch (대규모 GPU 클러스터)
  • 일부 IBM POWER9/10 CPU ↔ GPU (특수한 경우)
  • 일반적인 x86 CPU ↔ GPU 연결은 PCIe를 통해 이루어짐.

정리: GPU 내부 및 외부 신호 흐름

1. SM 내부:
   • Thread Block 실행 → CUDA 코어 연산 → Shared Memory / L1 캐시 활용
2. SM 간 통신:
   • SM-to-SM 네트워크를 통한 직접 통신 (빠름)
   • L2 캐시를 거쳐 통신 (데이터 일관성 유지)
3. L2 캐시를 통한 데이터 공유:
   • 여러 SM에서 공통 데이터 저장
   • 외부 메모리(HBM/GDDR) 접근 최적화
4. 외부 인터페이스 연결:
   • NVLink를 통해 GPU ↔ GPU 또는 NVSwitch와 직접 연결 가능
   • x86 CPU와는 NVLink 직접 연결 불가능 → PCIe로 연결 필요

결론적으로, SM → SM-to-SM 네트워크 → L2 → NVLink/PCIe 흐름을 기본적으로 따르며, 특정 환경에서는 SM 간 직접 NVLink 통신도 가능하지만, CPU 연결은 일반적으로 PCIe를 통해 이루어집니다. 

Explanation of the Code:

This Python code demonstrates how to load and preprocess the CIFAR-10 dataset for training, validation, and testing using PyTorch. The CIFAR-10 dataset is commonly used for image classification tasks and consists of 10 classes, with 60,000 images total. The code includes splitting the training dataset into a training and validation set, applying transformations, and loading data using the DataLoader class.

Step-by-Step Breakdown:

1. Image Preprocessing (Transforms):
   • This part of the code defines the preprocessing steps applied to the CIFAR-10 images before they are passed through the neural network.
     • Resize(64): Each image is resized to 64x64 pixels.
     • ToTensor(): The images are converted to PyTorch tensors (required for model input).
     • Normalize(): The image data is normalized using the mean and standard deviation values calculated from the CIFAR-10 dataset.
2. Loading CIFAR-10 Training Data:
   • This code block loads the CIFAR-10 training data from the specified path (c:/Users/zeah/data/cifar-10-batches-py). The train=True flag ensures the training portion of the dataset is loaded. The transform=transform argument applies the previously defined transformations.
3. Splitting Training Data into Training and Validation Sets:
   • The training data is split into two parts: 90% for training and 10% for validation. This ensures that a portion of the data is reserved to evaluate the model's performance during training without overfitting on the training data.
   • random_split() is used to divide the dataset randomly.
4. Loading CIFAR-10 Testing Data:
   • The CIFAR-10 testing data is loaded in this block. Setting train=False loads the test set, which consists of 10,000 images. The transformations defined earlier are also applied here.
5. Creating DataLoaders for Training, Validation, and Testing:
   • DataLoader is used to handle the batches of data that will be fed into the model during training. The batch_size=32 argument specifies that 32 images will be processed in each iteration.
   • shuffle=True is applied to the training data so that the images are fed into the model in a random order during each epoch, which helps improve the generalization of the model.
6. Inspecting Data Batches:
   • These lines grab the first batch of images and their corresponding labels from the training, validation, and test sets. This is useful for inspecting the data shape and verifying that the loaders are working as expected.
7. Printing the Shape of the Data Batches:
   • Finally, the shapes of the data batches are printed to ensure that the data is correctly loaded and prepared. Since the batch size is 32, and each image has three color channels (RGB) with a size of 64x64 pixels, the expected output shape for the training batch is [32, 3, 64, 64].

Here's a detailed guide designed for university students who are new to SoC, explaining how to use a multicore cache behavior simulator. This guide includes the simulation's purpose, detailed technical descriptions of each component, how to run the code, and how to analyze the results.

1. Purpose of the Simulator
This simulator is a tool for understanding cache operations and bus arbitration algorithms in multicore processors. Each core manages its own cache and processes memory access requests through a bus. The simulation allows you to observe firsthand how cache coherence is maintained and how data synchronization issues are handled in a multicore environment.

2. Simulation Component Descriptions
  (1) CacheLine Class
-Purpose: Models an individual cache line within the cache system. A cache line is the basic unit for storing blocks of data in memory.
-Attributes:
  -`state`: Indicates the current state of the cache line.

               Possible states include `Invalid`, `Shared`, `Exclusive`, and `Modified`.
  - `data`: Represents the actual data stored in the cache line.

  (2) Bus Class
-Purpose: Models the role of a bus that mediates data transfers between the CPU and memory. In multicore systems, the bus is a critical component for managing cache coherence and data synchronization.
-Methods:
  -`broadcast(sender, address, action)`: Alerts other CPUs when a particular CPU requests data, facilitating appropriate actions to maintain coherence.

 (3) BusArbitrator Class
- Purpose: Ensures fair bus access across multiple cores in a multicore system.
- Functionality: Uses a round-robin algorithm to sequentially allocate bus access to each CPU.

 (4) CPU Class
- Purpose: Represents each core in a multicore processor. Operates as a separate thread, independently simulating memory access requests.
- Methods:
  - `run()`: Main execution function of the CPU thread, simulating various memory access requests.
  - `access_memory(address, mode)`: Handles cache hits or misses based on the given address.

3. How to Run the Code
1. Install Python: Ensure Python is installed on your system.
2. Create Code File: Save the above code as `cache_simulation.py`.
3. Execute Code: Run the script by typing `python cache_simulation.py` in the terminal.
4. Check Log Files: After execution, review the log file generated. The log file is saved in the same directory as the script with the format `cache_simulation_YYYY-MM-DD_HH-MM-SS.log`.

4. How to Analyze Results
- Log File Analysis: Check each CPU's cache hits, misses, snooping events, and clock cycles in the log file.
-Performance Metrics: Calculate the total clock cycles and average latency for each CPU from the logs to assess the overall system performance.

This guide aims to provide students with a deeper understanding of the complexities of multicore systems and cache management, bridging theoretical knowledge with practical operation to enhance the learning experience.