NoC 필요 이유, 버스가 한계에 부딪힌 SoC 설계의 배경

교실이 네 개뿐인 작은 학교는 복도 하나면 충분합니다. 쉬는 시간에 학생들이 한 줄로 오가도 크게 막히지 않죠. 하지만 교실이 백 개로 늘어나면 복도 하나로는 감당이 안 되고, 층마다 복도를 두고 계단과 교차로, 안내 표지를 갖춘 길 체계가 필요해집니다.

시스템 온 칩(SoC, System on Chip) 안에서도 같은 일이 벌어졌습니다. CPU와 GPU, NPU, 메모리 컨트롤러, 각종 IP가 수십 개로 늘면서 칩 안의 통신을 도로망처럼 짜야 하게 되었고, 이 글은 NoC 필요 이유를 배경부터 차근차근 따라가 봅니다.

학교 복도와 다른 점이 있습니다. 칩 안의 길은 면적과 전력을 쓰는 실제 회로이고, 데이터가 서로의 길을 막고 기다리다 영영 움직이지 못하는 교착 상태까지 설계로 막아야 합니다.

공유 버스가 SoC 안에서 한계에 닿은 이유

버스는 여러 IP가 하나의 공유 배선을 나눠 쓰는 구조입니다. 한 번에 한 쌍만 통신할 수 있어 중재기(Arbiter)가 순서를 정하고, IP가 몇 개 안 될 때는 단순하고 면적도 작아 아주 좋은 선택입니다.

IP가 늘면 먼저 대기 시간이 길어집니다. 하나뿐인 대역폭을 모두가 나눠 쓰니 한 IP가 오래 점유하면 다른 IP는 기다려야 합니다.

배선 길이도 문제입니다. 칩 전체를 가로지르는 긴 배선은 저항과 커패시턴스 때문에 지연이 커서 한 클록 안에 신호를 건너보내기 어려워지고, 모든 IP를 같은 클록에 맞춰야 하는 제약까지 겹칩니다.

크로스바로 풀면 생기는 새 문제

크로스바(Crossbar)는 마스터와 슬레이브 사이에 스위치 격자를 두어, 서로 다른 쌍이 동시에 통신하게 하는 구조입니다. 한 번에 한 쌍이라는 버스의 병목은 풀립니다.

대신 연결점이 마스터 수와 슬레이브 수의 곱으로 늘어납니다. 연결점마다 배선과 중재 로직이 필요하니 규모가 커질수록 면적과 전력, 배선 혼잡이 빠르게 커집니다.

버스는 동시성이 막히고, 크로스바는 연결 수와 배선이 폭발합니다. 이 두 방식의 한계가 겹치는 지점이 NoC 필요 이유의 출발점입니다.

NoC 필요 이유, 통신을 도로망으로 바꾸는 발상

NoC(Network-on-Chip, 온칩 네트워크)는 컴퓨터 네트워크의 발상을 칩 안으로 가져온 구조입니다. 데이터를 패킷으로 묶어 보내고, 길목마다 놓인 라우터가 목적지 방향으로 한 단계씩 전달합니다.

각 IP는 라우터 하나에 연결되고, 라우터끼리는 짧은 링크로 이어집니다. 칩을 가로지르는 긴 배선 하나 대신 짧은 배선 여러 개를 쓰므로 링크마다 높은 클록으로 돌리기 쉽고, 경로가 다르면 여러 통신이 동시에 진행됩니다.

IP 입장에서는 평소처럼 버스 프로토콜로 요청을 내기만 하면 됩니다. 길을 찾고 순서를 정하는 일은 NI와 라우터가 대신하고, 덕분에 IP를 추가하거나 바꿔도 전체 구조를 다시 짜지 않아도 됩니다.

패킷이 NoC를 지나는 과정

한 번의 읽기 요청이 NoC를 지나가는 흐름을 따라가 보면, 각 부품의 역할이 어떻게 이어지는지 보입니다.

핵심은 4단계의 흐름 제어입니다. 다음 버퍼에 자리가 없는데 플릿을 밀어 넣으면 데이터가 사라지거나 길이 막히므로, 많은 NoC가 자리가 있다는 신호(크레딧)를 주고받으며 한 칸씩 보냅니다.

토폴로지와 라우팅, 데드락을 피하는 방법

라우터를 어떤 모양으로 이을지가 토폴로지(Topology)입니다. 링은 구조가 단순하고, 메시(Mesh)는 격자 모양이라 칩의 평면 배치와 잘 맞으며, 트리는 계층적인 통신에 알맞습니다. 어느 쪽이 좋은지는 IP 배치와 통신 패턴에 달려 있습니다.

경로를 정하는 규칙이 라우팅(Routing)입니다. 가장 단순한 XY 라우팅은 먼저 가로 방향으로 끝까지 간 뒤 세로로 꺾는 식으로 방향의 순서를 고정하며, 하드웨어가 간단하고 경로가 하나로 정해집니다.

설계에서 가장 조심하는 위험은 데드락(Deadlock)입니다. 패킷 A가 B가 쥔 버퍼를 기다리고, B는 C를, C는 다시 A를 기다리는 원형 대기가 생기면 아무도 움직일 수 없습니다. 라우팅 규칙으로 순환이 생기지 않게 하거나, 버퍼를 논리적으로 나눈 가상 채널(Virtual channel)로 경로를 분리해 피합니다.

NoC가 가져온 장점과 치른 대가

SoC가 커질수록 NoC 필요 이유가 선명해지는 것은 확장성 때문입니다. 짧은 링크로 이루어져 타이밍을 맞추기 쉽고, 서로 다른 클록과 전압으로 동작하는 IP도 NI에서 경계를 처리해 연결할 수 있으며, 라우터와 링크를 더해 규모를 키울 수 있습니다.

대가도 있습니다. 라우터와 버퍼가 면적과 전력을 쓰고, 홉 수만큼 지연이 늘어나며, 라우팅과 흐름 제어와 데드락을 검증하는 설계 부담도 커집니다.

그래서 NoC가 버스보다 항상 빠르다는 생각은 흔한 오해입니다. 가까운 두 IP 사이에서는 버스가 오히려 지연이 짧고 회로도 작으며, NoC의 이득은 여러 통신을 동시에 처리하는 총 대역폭과 규모를 키울 수 있는 확장성에서 나옵니다.

버스와 크로스바와 NoC 비교 표

구분	공유 버스	크로스바	NoC
연결 방식	하나의 공유 배선	마스터와 슬레이브를 잇는 스위치 격자	라우터와 짧은 링크로 이룬 망
동시 통신	한 번에 한 쌍	서로 다른 쌍은 동시에 가능	경로가 다르면 동시에 가능
IP가 늘어날 때	대기 시간과 배선 길이 증가	연결점이 곱으로 증가	라우터와 링크를 더해 확장
지연	IP가 적을 때 짧음	짧음	홉 수에 비례해 늘어남
면적과 전력	작음	규모가 커지면 급증	라우터와 버퍼 비용
알맞은 규모	소규모 SoC	중간 규모	IP가 많은 대규모 SoC
놓치기 쉬운 점	IP가 늘면 대역폭을 나눠 써야 함	연결점 폭증은 선형이 아님	작은 SoC에서는 오히려 과함

핵심 정리

버스는 동시에 한 쌍만 통신하고 배선이 길어지는 한계가 있고, 크로스바는 연결점이 곱으로 늘어나는 한계가 있습니다. NoC 필요 이유는 IP가 많아진 SoC에서 통신을 짧은 링크와 라우터의 망으로 바꿔 동시성과 확장성을 함께 얻기 위해서입니다.

교실이 백 개로 늘어난 학교가 복도 하나를 층과 교차로가 있는 길로 바꿨듯이, 칩도 통신 구조를 바꿨습니다. 다만 칩의 길은 면적과 전력, 지연을 치르므로, IP의 수와 통신 패턴을 보고 버스와 NoC 중 알맞은 쪽을 고르는 판단이 설계의 몫입니다.

면접 대비 질문