🔌 NoC(Network-on-Chip) 완전 정복 — SoC 설계의 핵심 인터커넥트 기술
반도체 SoC 내부 통신의 패러다임 전환, Crossbar에서 NoC로 | 데이터 흐름·라우팅·실무 설계 관점까지
💡 한 줄 요약: SoC 내부 IP가 10개를 넘어서는 순간, 전통적인 Crossbar 배선은 물리적 한계에 부딪힙니다. NoC(Network-on-Chip)는 패킷 기반 네트워크로 이 문제를 해결하며, 2026년 현재 모바일 AP·AI 가속기·자동차 SoC의 사실상 표준 인터커넥트로 자리잡았습니다.
📌 Crossbar vs NoC — 패러다임이 바뀐 이유
기존 Crossbar(Multi-layer Interconnect) 방식은 모든 마스터와 슬레이브를 직접 물리적 전선으로 연결합니다. 출발지와 목적지마다 전용 도로를 깔아주는 셈이죠. IP 수가 적을 때는 단순하고 빠르지만, 규모가 커지면 두 가지 치명적 문제에 직면합니다.
⚠️ 배선 혼잡 (Wiring Congestion)
IP 수가 N개이면 배선 복잡도는 O(N²)로 증가합니다. 수만 가닥의 구리선을 칩 내부에 배치하면 면적이 폭증하고, 제조 비용 역시 급등합니다.
⚡ 타이밍 & 전력 문제
전선이 길어지면 RC Delay가 증가합니다. 고클럭 유지를 위해 리피터를 대량 삽입해야 하고, 이는 막대한 동적 전력 소모로 이어집니다.
반면 NoC는 전용 도로 대신 고속도로 + 허브 시스템을 구축합니다. 데이터를 패킷 단위로 쪼개 공유 경로를 통해 전송하고, 중간의 라우터(Router)가 최적 경로를 안내합니다. 물리적 배선은 줄이되 논리적 연결성은 극대화한 것이죠.
🔄 Crossbar vs NoC 구조 비교
Crossbar (Point-to-Point)
CPU
⟷
GPU
⟷ ✕ ⟷
DSP
⟷
DRAM
모든 노드 간 직접 연결 → O(N²) 배선
NoC (Packet-Switched)
CPU
→
R
→
R
→
DRAM
GPU
→
R
→
R
→
DSP
라우터(R) 경유 패킷 전송 → O(N) 배선
🌐 SoC NoC vs 인터넷 — 같은 듯 다른 패킷 교환
SoC NoC와 TCP/IP 기반 인터넷은 모두 '패킷 교환(Packet Switching)'을 사용하지만, 설계 철학은 완전히 다릅니다.
| 항목 |
🖥️ SoC NoC |
🌍 인터넷 (TCP/IP) |
| 전송 단위 |
Flit (Flow Control Unit) |
Packet (1500B MTU) |
| 지연 시간 |
수 ns (나노초) |
수 ms (밀리초) |
| 데이터 유실 |
절대 불허 (Lossless) |
재전송으로 복구 (Best-effort) |
| 버퍼 크기 |
수십 Flit (게이트 최소화) |
수 MB ~ GB |
| 흐름 제어 |
Credit-based / On-Off |
TCP Window / Congestion Control |
핵심 차이는 무손실(Lossless) 보장입니다. 인터넷에서는 패킷이 유실되면 TCP가 재전송하지만, 칩 내부에서 데이터 유실은 곧 시스템 크래시를 의미합니다. 따라서 SoC NoC는 하드웨어 레벨의 Credit-based Flow Control로 패킷 유실을 원천 차단합니다.
🧩 Flit 구조 상세
NoC에서 하나의 패킷은 여러 개의 Flit(Flow Control Unit)으로 구성됩니다. 각 Flit은 고유한 역할을 담당합니다.
🏷️ Head Flit
목적지 주소, 패킷 ID, QoS 정보, 트랜잭션 타입
→
📦 Body Flit(s)
실제 데이터 페이로드 (읽기/쓰기 데이터)
→
🔚 Tail Flit
패킷 종료 표시, 라우터 자원 해제 트리거
🚀 데이터의 여행 — Master에서 Slave까지 5단계
CPU가 DRAM에 데이터를 읽으려 할 때, 패킷이 어떤 과정을 거치는지 단계별로 따라가 봅시다.
1
NIU 패킷화 (Packetization)
CPU가 AXI/CHI 프로토콜로 Read Request를 발행하면, 소스 측 NIU(Network Interface Unit)가 이를 NoC용 패킷(Flit 시퀀스)으로 변환합니다.
2
라우팅 (Routing Decision)
Head Flit이 첫 번째 라우터에 도착하면, 라우터는 목적지 주소를 참조하여 출력 포트를 결정합니다. XY 라우팅이라면 X축 → Y축 순서로 방향이 정해집니다.
3
중재 및 스위칭 (Arbitration & Switching)
여러 패킷이 동시에 같은 출력 포트를 요청하면, 중재기(Arbiter)가 우선순위를 판단합니다. 가상 채널(Virtual Channel)을 통해 논리적으로 경로를 분리하여 Deadlock을 방지합니다.
4
멀티 홉 전송 (Multi-hop Traversal)
패킷은 여러 라우터를 홉(Hop) 단위로 경유하며 목적지까지 이동합니다. 각 홉에서 동일한 라우팅·중재 과정이 반복됩니다.
5
역패킷화 (Depacketization)
타겟 측 NIU가 수신된 Flit을 다시 AXI/CHI 프로토콜로 복원하여 슬레이브 IP(DRAM 컨트롤러 등)에 전달합니다.
🗺️ 라우팅 알고리즘 — 경로는 어떻게 결정되는가?
NoC에서 가장 널리 사용되는 라우팅 방식은 Deterministic Routing(결정적 라우팅), 그 중에서도 XY 라우팅입니다.
🔹 XY 라우팅이란?
2D Mesh 토폴로지에서 패킷을 먼저 X축(가로)으로 이동시킨 뒤, Y축(세로)으로 이동시키는 단순 명쾌한 방식입니다.
📐 XY 라우팅 예시 (4×4 Mesh)
S → → → ● — — — ●
● — — — ↓ — — — ●
● — — — D — — — ●
S(Source) → X축 이동 → Y축 이동 → D(Destination)
🔹 왜 단순한 방식을 고집하는가?
▶ Deadlock 방지: XY 라우팅은 순환 의존성(Circular Dependency)이 구조적으로 발생하지 않아 별도의 Deadlock 복구 로직이 필요 없습니다.
▶ 순서 보장: 동일한 소스-목적지 쌍의 패킷은 항상 같은 경로를 따르므로, 도착 순서가 뒤바뀌지 않습니다.
▶ 하드웨어 경량화: 라우팅 테이블이나 복잡한 경로 계산 로직 없이 단순 비교 연산만으로 동작합니다.
💡 Adaptive Routing은? 트래픽이 특정 경로에 집중될 때 우회하는 적응형 라우팅도 연구가 활발합니다. 하지만 실제 양산 SoC에서는 Deadlock 위험과 순서 보장 문제 때문에 제한적으로만 사용됩니다. 대신 가상 채널(Virtual Channel)로 논리적 경로를 분리하거나, 설계 단계에서 대역폭을 넉넉히 할당하는 전략을 선호합니다.
🏗️ 2026년 NoC 토폴로지 트렌드
NoC의 물리적 배치 구조(토폴로지)는 SoC의 특성에 따라 다양하게 선택됩니다. 2026년 현재 주요 양산 칩에서 채택하는 토폴로지를 정리합니다.
| 토폴로지 |
특징 |
적용 사례 |
| 2D Mesh |
확장성 우수, 균일한 대역폭 |
AI 가속기, 매니코어 프로세서 |
| Ring |
구현 간단, 소규모에 적합 |
Intel Core 시리즈 (Ring Bus) |
| Hierarchical |
클러스터별 로컬 NoC + 글로벌 NoC |
모바일 AP (Arm DynamIQ) |
| Tree / Fat Tree |
낮은 홉 수, 루트 병목 가능 |
데이터센터 칩, 네트워크 프로세서 |
| Chiplet Mesh |
다이 간 UCIe/BoW 브릿지 연동 |
AMD EPYC, Intel Ponte Vecchio |
특히 2026년 현재 칩렛(Chiplet) 아키텍처의 확산으로, 하나의 패키지 안에서 여러 다이(Die)를 NoC로 연결하는 기술이 급부상하고 있습니다. UCIe(Universal Chiplet Interconnect Express) 표준이 업계 전반에 채택되면서, 다이 간 NoC 브릿지 설계가 핵심 경쟁력으로 떠오르고 있죠.
⚙️ 현대 SoC에서 NoC가 필수인 이유
🧱 디자인 재사용
IP 배치가 바뀌어도 라우터와 링크만 재배치하면 됩니다. 레고 블록처럼 유연한 조합이 가능해 설계 기간이 대폭 단축됩니다.
🔄 GALS 지원
각 IP가 서로 다른 클럭 주파수로 동작해도 NIU가 비동기 동기화를 처리합니다. 전력 효율 극대화에 핵심입니다.
📈 확장성
마스터 IP가 10~16개를 넘으면 Crossbar는 한계에 도달합니다. 수십~수백 코어 시대에 NoC는 유일한 대안입니다.
🎯 언제 Crossbar를 쓰고, 언제 NoC를 쓸까?
▶ Crossbar 적합: IP 10개 미만의 단순 MCU, 면적·비용 최소화가 목표일 때
▶ NoC 필수: IP 16개 이상, 이기종 코어 혼합, 칩렛 구조, 고대역폭 요구 시
🔑 실무에서 흔히 겪는 NoC 설계 실수와 팁
NoC 설계는 이론만으로는 완성되지 않습니다. 실제 양산 프로젝트에서 자주 만나는 함정과 해결책을 공유합니다.
❌ 대역폭 과소 산정: 피크 트래픽이 아닌 평균 트래픽 기준으로 설계하면, 실제 워크로드에서 병목이 발생합니다. 반드시 버스트 트래픽 시나리오를 포함한 시뮬레이션을 수행하세요.
❌ QoS 미설정: CPU와 디스플레이 컨트롤러가 같은 경로를 공유할 때, QoS 없이는 화면 티어링이 발생할 수 있습니다. Latency-critical IP에는 반드시 높은 QoS 레벨을 할당하세요.
✅ 트래픽 프로파일링 먼저: NoC 토폴로지를 결정하기 전에, 실제 애플리케이션의 트래픽 패턴(읽기/쓰기 비율, 버스트 길이, 접근 패턴)을 반드시 분석하세요.
✅ Power Gating 연동: 사용하지 않는 NoC 영역의 라우터를 Power Gating하면 대기 전력을 크게 줄일 수 있습니다. 이를 위해 NoC 토폴로지를 Power Domain과 정렬하여 설계하는 것이 중요합니다.
📚 주요 NoC IP 벤더 비교 (2026년 기준)
| 벤더 |
제품 |
특장점 |
| Arm |
CMN (Coherent Mesh Network) |
CHI 프로토콜 네이티브 지원, 서버/모바일 AP 주력 |
| Arteris |
FlexNoC, Ncore |
자동화된 NoC 생성 도구, 자동차/IoT SoC에 강점 |
| Synopsys |
DesignWare NoC |
EDA 통합 워크플로, 고성능 컴퓨팅 최적화 |
| Cadence |
Interconnect IP |
Tensilica DSP 통합, AI/ML 워크로드 특화 |
🔮 마무리하며
30년 전 단순했던 공유 버스가 이제는 도시의 교통망처럼 정교하게 진화했습니다. SoC의 복잡도가 일정 수준을 넘어서는 순간, NoC는 선택이 아닌 생존을 위한 필수 기술이 됩니다. 칩렛과 UCIe의 시대가 열리면서, 다이 경계를 넘나드는 차세대 인터커넥트가 또 어떤 혁신을 가져올지 — 반도체 설계의 가장 흥미로운 시대가 바로 지금입니다.
📎 References
→ Arm AMBA Specification — developer.arm.com/architectures/system-architectures/amba
→ Arteris NoC Technology — arteris.com/noc-technology
→ Synopsys DesignWare NoC — synopsys.com/designware-ip/interconnect-ip.html
본 콘텐츠는 반도체 설계 전문가의 경험과 최신 기술 자료를 바탕으로 작성되었으며, 투자 조언이 아닌 기술 정보 공유를 목적으로 합니다.
📄 Raw Data
안녕하세요, Arm에서 30년 넘게 버스 아키텍처의 탄생과 성장을 지켜본 마스터 엔지니어입니다. 제가 처음 업계에 발을 들였을 때는 단순한 공유 버스(Shared Bus) 형태인 초기 AMBA 규격을 다루던 시절이었습니다. 하지만 현대의 SoC(System-on-Chip)는 수십, 수백 개의 IP가 복잡하게 얽혀 있어 과거의 방식으로는 도저히 감당할 수 없는 수준에 이르렀죠. 오늘은 그 해결책으로 등장한 **NoC(Network-on-Chip)**에 대해 깊이 있게 이야기해보려 합니다.
### 1. Crossbar Interconnect vs NoC: 왜 패러다임이 변했는가?
기존의 **Crossbar(또는 Multi-layer Interconnect)** 방식은 마스터(Master)와 슬레이브(Slave) 사이를 직접적인 물리적 전선으로 연결하는 구조입니다. 마치 모든 출발지와 목적지 사이에 전용 도로를 깔아주는 것과 같죠. 하지만 이 방식은 두 가지 치명적인 문제에 직면했습니다.
* **배선 혼잡(Wiring Congestion):** IP 개수가 늘어날수록 전선의 수는 기하급수적으로 증가합니다. 칩 내부의 한정된 공간에 수만 가닥의 구리선을 배치하는 것은 물리적 한계에 부딪혔고, 이는 곧 칩 면적 증가와 비용 상승으로 이어졌습니다.
* **타이밍과 전력 문제:** 전선이 길어지면 신호 지연(RC Delay)이 발생합니다. 높은 클럭 주파수를 유지하기 위해 중간중간 리피터를 박아야 하고, 이는 엄청난 전력 소모를 야기합니다.
반면 **NoC**는 도로망이 아닌 **'고속도로와 허브'** 시스템입니다. 데이터를 패킷 단위로 쪼개어 공유된 통로를 통해 전송하며, 중간중간 **라우터(Router)**가 이 패킷의 길을 안내합니다. 물리적 전선은 줄이되, 논리적인 연결성은 극대화한 것이죠.
### 2. NoC의 트랜잭션과 '인터넷 NoC'와의 차이점
SoC에서의 NoC와 우리가 흔히 아는 인터넷(TCP/IP) 기반 네트워크는 '패킷 교환'이라는 개념은 공유하지만, 그 설계 철학은 완전히 다릅니다.
* **트랜잭션 형태:** SoC NoC에서 데이터는 **Flit(Flow Control Unit)**이라는 단위로 전송됩니다. 하나의 패킷은 Head Flit(주소 및 제어 정보), Body Flit(실제 데이터), Tail Flit(끝 알림)으로 구성됩니다.
* **제약사항의 차이:**
* **지연 시간(Latency):** 인터넷은 수 밀리초(ms)의 지연을 허용하지만, SoC는 수 나노초(ns) 단위에서 승부가 납니다. 따라서 프로토콜 오버헤드를 극단적으로 줄여야 합니다.
* **무손실 전송(Lossless):** 인터넷은 패킷 유실 시 재전송을 하면 되지만, 칩 내부에서 데이터 유실은 곧 시스템 다운입니다. SoC NoC는 하드웨어적으로 완벽한 흐름 제어(Flow Control)를 통해 패킷 유실을 원천 차단합니다.
* **면적 및 전력:** 라우터 하나를 만들 때도 게이트(Gate) 수를 최소화해야 합니다. 인터넷 라우터처럼 거대한 메모리 버퍼를 가질 수 없습니다.
### 3. Master에서 Slave까지: 데이터의 여행(Data Flow)
데이터가 마스터 IP에서 출발해 슬레이브까지 가는 과정을 따라가 봅시다.
1. **NIU(Network Interface Unit) - 패킷화:** 마스터(예: CPU)가 AXI나 CHI 같은 표준 프로토콜로 읽기/쓰기 요청을 보냅니다. 입구에 있는 NIU는 이 신호를 NoC용 패킷으로 변환(Packetization)합니다.
2. **라우팅(Routing):** 패킷은 첫 번째 라우터에 도착합니다. 라우터는 패킷 헤더의 목적지 정보를 보고 어느 방향으로 보낼지 결정합니다.
3. **스위칭(Switching) 및 중재(Arbitration):** 여러 패킷이 동시에 한 경로로 몰리면 라우터 내부의 중재기가 우선순위에 따라 순서를 정합니다. 이때 가상 채널(Virtual Channel)을 사용해 정체(Deadlock)를 방지합니다.
4. **전송(Traversal):** 패킷은 여러 홉(Hop)을 거쳐 목적지 근처 라우터까지 이동합니다.
5. **Target NIU - 역패킷화:** 슬레이브 쪽 NIU에 도착한 패킷은 다시 원래의 프로토콜(AXI 등)로 복원되어 슬레이브 IP(예: DRAM 컨트롤러)에 전달됩니다.
### 4. 경로는 어떻게 결정되는가? (Routing Algorithm)
NoC에서 패킷의 경로는 보통 **Deterministic Routing(결정적 라우팅)**을 주로 사용합니다. 가장 대표적인 것이 **XY 라우팅**입니다. 가로(X축)로 먼저 이동한 뒤 세로(Y축)로 이동하는 단순한 방식입니다.
* **왜 단순한 방식을 쓰는가?** 경로를 매번 계산하면 라우터가 복잡해지고 지연 시간이 늘어납니다. 또한 패킷의 순서(Ordering)가 뒤바뀌면 이를 다시 맞추는 데 엄청난 비용이 들기 때문입니다.
* **우회 경로(Adaptive Routing)는 없는가?** 특정 경로에 부하가 심할 때 우회하는 '적응형 라우팅' 연구도 활발하지만, 실제 양산 SoC에서는 **데드락(Deadlock)** 위험과 **순서 보장 문제** 때문에 제한적으로만 사용됩니다. 대신, 특정 경로가 막히지 않도록 **가상 채널(Virtual Channel)**을 통해 논리적으로 경로를 분리하거나, 설계 단계에서 대역폭을 넉넉히 할당하는 방식을 선호합니다.
### 5. 현대 SoC에서 NoC가 필수인 이유
결론적으로 왜 NoC일까요? 그것은 **'확장성(Scalability)'**과 **'모듈화'** 때문입니다.
* **디자인 재사용:** 과거에는 IP 배치가 바뀌면 버스 구조 전체를 다시 설계해야 했습니다. NoC는 라우터와 링크만 연결하면 되므로 레고 블록처럼 IP를 배치하기 쉽습니다.
* **GALS 아키텍처 지원:** 각 IP가 서로 다른 클럭 주파수로 동작하더라도 NoC 인터페이스가 이를 동기화해주므로 설계가 매우 유연해집니다.
* **적정 규모:** 보통 마스터 IP가 **10~16개 이상**이 되면 Crossbar 방식은 한계에 도달합니다. 최근의 모바일 AP나 AI 가속기처럼 수십 개의 코어가 들어가는 칩에서는 NoC 외에는 대안이 없습니다.
반면, 아주 작은 규모의 단순한 MCU라면 여전히 Crossbar가 유리할 수 있습니다. NoC는 라우터와 NIU라는 추가적인 로직 면적이 필요하기 때문입니다. 하지만 **성능, 전력, 면적(PPA)**의 균형을 생각할 때, 복잡도가 일정 수준을 넘어서는 순간 NoC는 선택이 아닌 생존을 위한 필수 기술이 됩니다.
30년 전 단순했던 버스 구조가 이제는 거대한 도시의 교통망처럼 진화한 것을 보며, 저는 다음 세대의 Interconnect가 또 어떤 혁신을 가져올지 기대가 됩니다.
---
## References
- [Arm AMBA Specification](https://developer.arm.com/architectures/system-architectures/amba)
- [Arteris NoC Technology](https://www.arteris.com/noc-technology)
- [Synopsys DesignWare NoC](https://www.synopsys.com/designware-ip/interconnect-ip.html)
댓글
댓글 쓰기