버스는 폰노이만이 1945년 EDVAC 보고서에서 정의한 컴퓨터의 데이터가 다니는 도로이다. 컴퓨터에는 CPU, Memory 등 다양한 블록들이 있는데, 이들이 서로 신호를 주고 받을 수 있도록, 연결해주는 것. 그것이 버스입니다.

도시를 어떻게 설계하느냐에 따라, 교통체증 / 인구 증가 / 부동산 가격을 결정한다. 버스도 도시계획과 비슷합니다.

BUS 구조에서 가장 유명한 것은 "Von Neumann (폰 노이만) 구조"입니다.

제1장: 폰노이만과 버스의 탄생 (1945)

1945년 6월 30일. 존 폰노이만, "First Draft of a Report on the EDVAC" 제출. 101페이지. 현대 컴퓨터 논리 설계의 최초 정의입니다.

폰노이만 아키텍처의 5대 구성 요소:

• CA(연산)
• CC(제어)
• M(메모리)
• I(입력)
• O(출력)

이 다섯개가이 버스로 연결됩니다. 폰노이만은 이것을 "organ"이라 불렀습니다.

웃긴건, "폰 노이만 구조"를 폰노이만이 정의한 것이 아닙니다. 다만, 1945년도에 발표에 2026년 현대에 쓰이는 컴퓨터구조가 이미 설계되어있습니다. 그리고 폰 노이만은 아래 보고서의 완성을 못하고 있는 상태였는데, 동료였던 허먼 골드스타인이 이를 복사해서 배포했습니다. (폰 노이만 단독 저자로.)

당대 최고의 컴퓨터였던 ENIAC은 매 계산마다 사람이 수많은 스위치와 케이블을 직접 재연결해야하는 어려움이 있었고, 펜실베니아 대학교 무어 전기공학과의 연구진들은 EDVAC이라는 새로운 컴퓨터 개발을 구상하게 되었습니다.

1943년 Eckert와 Mauchly는 이 프로젝트의 수석 설계자들으로, 컴퓨터는 "프로그램 내장 방식"으로 동작해야한다는 핵심 아이디어를 구상했고, Arthur Burks는 방법론 구현에 깊이 고민했고, John von Neumann은 1944년에 이 프로젝트에 합류하여 이 아이디어들을 집대성하였습니다.

그러나 이 논문에는 "폰 노이만" 단독 저자 논문으로 올라와서 큰 논란이 생겼습니다. 나머지 연구자의 기여가 인정되지 않은거죠.

논문 목차 2장에서 시스템은 "중앙처리장치, 메모리, IO"로 명확히 구분되어있습니다.

이는 현대의 컴퓨터 구조와 거의 동일합니다!

심지어 동기화 방법인 Clock 구조도 현대 시스템과 동일합니다.

제가 하고싶은 말은 "폰 노이만 구조"를 시작으로, 컴퓨터는 "프로그램 내장 방식"으로 동작하고, 주요 요소는 "Processor Unit, Memory, Input/Output"으로 나뉩니다. 그리고 각 요소를 연결해줄 BUS가 필요해집니다.

자.. 이제 기능 구현 자체는 되었습니다. 이 다음은 속도입니다.

Input에서 Output까지 얼마나 시간이 걸리는지도 중요하지만, 엔지니어들이 가장 중요하게 보는 것은 "단위시간 당 얼마나 많은 양의 데이터를 보내는가" 즉, "대역폭"입니다.

반도체가 발전하면서, HW Flops (트랜지스터 개선) 속도는 무어의법칙에 맞춰 2년에 2배 집적도를 유지했습니다. 예를들어최근 10년간 반도체는 28nm -> 22nm -> 14nm > 10nm -> 8nm -> 5nm -> 4nm -> 3nm 이런식으로 매년 √2 단위로 선폭이 줄어들었습니다.

그리고 배선은 알루미늄, 구리 등 여러가지 전자재료 측면에서 변화가 있었습니다. 하지만 반도체 공정이 미세해질수록 Transistor는 빨라지지만 Interconnect (배선)은 느려지는 문제가 있습니다.

즉, BUS 구조를 어떻게 잡느냐에 따라서 SoC (System on Chip), HBM, AI 반도체의 성능이 결정됩니다.

버스의 근본적 문제는 물리학입니다. 그리고 반도체 재료공학적으로 해결이 어려운 이 문제를 설계 수준에서 해결하기 위해 공유 버스, 크로스바, 링, 메쉬, NoC, 칩렛, 3D-IC이 차례로 발명했습니다. 각 해결책이 새로운 도메인을 끌어들였습니다.

SoC에서 가장 중요한 설계를 꼽으라면, 대부분 CPU, 가속기, 메모리 컨트롤러, PCIe를 말한다.

"이는 틀렸습니다. 다 중요하지만, 제일 먼저 아키텍처를 정해야한다. 그 다음이 각 모듈이다."

• 소비자들은 SoC 내 CPU block의 Clock frequency에는 큰 관심이 없습니다.
  • 시간당 얼마나 많은 연산을 할 수 있는가? 이 게임을 돌릴 수 있는가? 몇 프레임으로? 이런게 궁금한겁니다.
  • 그리고 이 성능의 하한을 버스가 결정합니다.

버스 계층 구조:

실제 컴퓨터에서 "버스"는 용도에 따라 여러 계층으로 나뉜다:

• 폰노이만 병목: CPU와 메모리 사이 단 하나의 통로. 아무리 CPU가 빨라도 모든 명령어, 모든 데이터는 이 단일 채널을 통과해야 한다. 1945년 정의, 2025년 현재도 해결 안 된 근본 제약. 우리가 80년 동안 해온 모든 것은 이 병목을 우회하거나 완화하는 것이다.
• 하버드 아키텍처 (1947): 명령어 버스와 데이터 버스 물리적 분리. 명령어 fetch와 데이터 access 동시 가능. DSP, 마이크로컨트롤러에서 사용.
  • 폰노이만 병목의 첫 번째 우회.
  • 명령어/데이터 메모리를 따로 두어야 하므로 프로그램과 데이터가 같은 공간을 공유할 수 없다는 단점.

제2장: 버스의 해부

모든 버스는 세 가지 신호군으로 구성된다.

2.1 Address Bus

"어디"를 지정. n비트 → 2ⁿ개 위치 주소 지정.

2.2 Data Bus

실제 데이터 이동. 이 대역폭이 한 번에 전송할 비트 수 결정.

2.3 Control Bus

Transaction 종류(read/write), 타이밍, 인터럽트, 버스 소유권 제어.

• Memory Read/Write
• I/O Read/Write
• IRQ, Interrupt Acknowledge
• Bus Request/Grant(DMA)
• Clock
• Reset

2.4 버스 트랜잭션의 5단계

1. Arbitration: 여러 마스터 중 누가 버스를 쓸지.
2. Address Phase: 마스터가 목적지 주소를 주소 버스에.
3. Command Phase: Read/Write 제어 버스에.
4. Data Phase: 실제 데이터 이동.
5. Termination: 완료. 버스 반환.

1975년 S-100도, 2025년 PCIe Gen6도 같은 5단계다. 속도와 양, 세부 기술이 바뀌었을 뿐, 트랜잭션의 5단계 자체는 동일하다.

제3장: Interconnect delay: 왜 버스는 느려지는가

3.1 RC Delay

모든 금속 배선은 저항(R)과 커패시턴스(C)를 갖는다. (물론 L, Inductance도 있지만, 주로 RC만 다룬다.) 이 RC가 low-pass filter로 작용, 신호의 상승/하강 시간을 늘린다.

1. 공정 미세화 → W↓, H↓, d↓. C는 대략 일정(W↓이지만 d도 ↓이므로). R은 단면적 감소로 급증. 미세화될수록 배선 느려짐.
2. 트랜지스터는 2년에 2배씩 개선되는데, RC Delay 공정 개선은 그렇게 빠르지 않음.
3. 긴 배선은 Max transition violation, Max capacitance violation을 발생시킨다. 결국, 다량의 repeater cell 균등 삽입해야한다.
   1. repeater 자체가 지연, 전력, 면적 소비. 65nm에서 10mm 배선 구동에는 엄청나게 많은 repeater 필요. 버스가 더 이상 "그냥 선 긋기"가 아니게 된 이유다.

제4장: 버스 프로토콜의 핵심 개념들

4.1 Pipe line

CPU가 메모리에 데이터를 요청하면, 메모리는 즉시 답하지 못한다. 내부에서 데이터를 찾고 준비하는 데 수십~수백 사이클이 걸린다. 이 대기 시간 동안 버스는 어떻게 될까?

가장 단순한 방식은 하나의 트랜잭션이 완전히 끝날 때까지 다음 요청을 기다리는 것이다. 주소 전달 → 데이터 수신 → 완료. 그 다음에야 새 요청이 시작된다. 버스는 중간중간 아무 일도 안 하며 놀게 된다.

파이프라이닝은 이 낭비를 없앤다. 현재 트랜잭션이 데이터를 주고받는 동안, 다음 트랜잭션의 주소 전달을 미리 시작한다. 공장 조립 라인처럼, 앞 단계가 끝나기를 기다리지 않고 각 단계를 겹쳐서 진행하는 것이다.

가장 단순한 방식은 하나의 트랜잭션이 완전히 끝날 때까지 다음 요청을 기다리는 것이다. 주소 전달 → 데이터 수신 → 완료. 그 다음에야 새 요청이 시작된다. 버스는 중간중간 아무 일도 안 하며 놀게 된다.

파이프라이닝은 이 낭비를 없앤다. 현재 트랜잭션이 데이터를 주고받는 동안, 다음 트랜잭션의 주소 전달을 미리 시작한다. 공장 조립 라인처럼, 앞 단계가 끝나기를 기다리지 않고 각 단계를 겹쳐서 진행하는 것이다.

4.2 Split Transaction

버스에는 두 역할이 있다.

• 요청하는 쪽(요청자, Initiator, Master)
• 요청 받는 쪽(응답자, Target, Slave)
  • CPU가 메모리에 데이터를 달라고 할 때, CPU가 요청자이고 메모리가 응답자다. 전통적으로는 마스터(Master)/슬레이브(Slave)라고 불렀으나, 최근 업계에서는 Initiator/Target으로 표현을 바꾸는 추세다.

기본적인 Transaction의 문제는 Read 트랜잭션에서 발생한다.

1. CPU가 메모리에게 데이터를 보낸다.
2. 메모리는 명령을 받고, 메모리 데이터를 읽고, CPU에게 응답을 보내는 데 시간이 걸린다.
3. 이 대기 시간 동안 CPU가 버스를 붙잡고 기다리면, 다른 장치는 버스를 전혀 쓸 수 없다. 버스 전체가 한 요청의 대기 시간에 묶이는 셈이다.

식당에 비유하면 이렇다.

기본 Transaction 구조:

1. 주문을 받은 서빙 직원이 음식이 나올 때까지 옆에 서서 기다린다.
2. 그 사이에 새 주문은 받지 않는다.
3. 서빙 직원(버스)이 한 손님(요청)에게 독점된다.

Split transaction 구조

1. 요청자가 명령을 전달한다.
   1. 명령 전달이 완료되면, 직원(버스)을 즉시 반납한다.
2. 주방(응답자)이 음식(데이터)를 준비하는 동안, 다른 요청자가 버스를 자유롭게 사용한다.
3. 데이터 준비가 완료되면, 응답자가 버스를 다시 요청해 데이터를 전달한다.

버스 점유 시간이 크게 줄고, 여러 요청이 동시에 진행 중인 상태(outstanding transaction)가 가능해진다.

다만 응답이 요청 순서와 다르게 돌아올 수 있기 때문에, 각 트랜잭션에 고유한 ID를 부여해 매칭하는 메커니즘이 필요하다.

AXI 프로토콜의 AWID/RID가 대표적인 예시다.

4.3 Burst Transfer

데이터를 한 번에 하나씩 요청한다고 생각해보자. 주소를 보내고, 데이터를 받고, 또 주소를 보내고, 데이터를 받고. 데이터 하나를 받을 때마다 주소 전달 과정을 반복해야 한다.

• 그런데 대부분의 경우, 우리가 원하는 데이터는 연속된 주소에 몰려 있다.
• Array, List, 이미지, 동영상 프레임 모두 메모리에 순서대로 저장된다.
  • 이걸 하나씩 요청하는 건 마치 마트에서 계산할 물건을 한 번에 올리지 않고 하나씩 계산원에게 건네는 것과 같다.
  • 양 손으로 가득 집어서 계산대에 올릴 방법이 필요하다.

Start address 하나와 burst length만 보내면, 그 이후 데이터는 주소 없이 연속으로 전송된다. 주소 전달의 오버헤드가 한 번으로 줄어든다.

단순 전송:  [Addr:100]-[Data] [Addr:101]-[Data] [Addr:102]-[Data]
버스트:     [Addr:100, Length=3]-[Data]-[Data]-[Data]

메모리 입장에서도 유리하다. DRAM은 한 번 행(row)을 열면 그 행 안의 데이터를 연속으로 읽는 게 훨씬 빠르다.

버스트 전송은 이 특성을 그대로 활용한다. AXI4 프로토콜에서는 INCR 타입 버스트로 최대 256개 데이터를 한 번의 주소 전달로 처리할 수 있다.

4.4 QoS, Quality of Service

SoC 안에는 CPU만 버스를 쓰는 게 아니다. System이 버스를 공유한다.

GPU, 카메라, 디스플레이, 오디오, 통신 모듈까지 수십 개의 장치가 같은 버스를 공유한다. 이 장치들이 동시에 데이터를 요청하면 누구를 먼저 처리해야 할까?

아무 기준 없이 순서대로 처리하면 문제가 생긴다. 디스플레이는 화면을 60Hz로 갱신하기 위해 정해진 시간 안에 반드시 데이터를 받아야 한다.

이 요청이 중요도가 낮은 요청들에 밀리면 화면이 끊기거나 깨진다. 반면 파일을 백그라운드에서 저장하는 작업은 몇 밀리초 늦어도 사용자가 체감하지 못한다.

QoS가 이 우선순위를 관리하는 주요 방식 정리:

1. Priority-based: 높은 우선순위 요청이 항상 먼저 처리된다. 단순하지만 낮은 우선순위 요청이 영원히 밀릴 수 있다. (starvation).
2. Weighted Round-Robin: 모든 요청자에게 순서대로 기회를 주되, 가중치가 높은 쪽에 더 많은 처리 슬롯을 배분한다. 완전한 독점은 막으면서 우선순위를 반영한다.
3. Credit-based: 각 장치에 일정량의 크레딧을 주고, 요청할 때마다 소진한다. 대역폭 상한과 하한을 모두 보장할 수 있어 실시간성이 중요한 장치에 적합하다.
4. Age-based: 오래 기다린 요청일수록 우선순위가 올라간다. 기아 현상을 방지하는 보완책으로 다른 방식과 함께 쓰인다.

ARM의 AXI4 프로토콜은 AxQoS 신호로 4비트(16레벨) QoS를 제공하고, CHI 프로토콜은 QoS를 프로토콜 안에 더 깊이 통합해 복잡한 멀티코어 환경에서도 지연 시간을 보장할 수 있도록 설계되어 있다.

제5장: Cache coherency

반도체 산업은 무어의 법칙, 데나드 스케일링 두가지로 성장해왔다고 말해도 과언이 아니다.

데나드 스케일링이란, 반도체 내부의 트랜지스터 크기를 줄일 때, 전력 밀도는 일정하게 유지되면서 성능은 향상된다는 반도체 물리학의 스케일링 법칙

문제는, 미세공정에 들어오면서 스케일링의 법칙이 포화되기 시작했다. 그러나 반도체 회사는 새 반도체를 팔아야한다. 그렇게 "Single core에서 Dual core"로 진화하기 시작했다. 시작은 IBM의 Power4 이다.

CPU가 메모리에서 데이터를 읽으면 Cache에 복사본을 만든다. 기존에는 CPU가 한개니까 이런 단순함이 통했다. 문제는 멀티코어에서 발생한다.

Core 2개라고 치자.

메모리에 변수는 x = 0 이라고 정의되어있다.

문제: Core 0이 x = 1로 바꿨다. Core 1의 캐시에는 아직 x = 0이 있다. 이 상황에서 Core 1이 x를 읽으면 틀린 값을 읽는다.

Cache coherency는 "모든 Core가 같은 값을 보도록 강제하는 규칙"이다.

5.1 MESI 프로토콜

캐시는 각 캐시 라인마다 상태 태그를 붙인다. 4가지 상태만 있다.

상태 한 줄 요약

직관적으로 보면

• 처음: Core0, Core 1 모두 X를 읽음
  • 둘 다 Shared
  • 코어0이 X에 쓰기 시도:
    • → Core 0: Shared → Modified
    • → Core 1: Shared → Invalid
• 코어1이 X를 다시 읽으려 하면:
  • Invalid → Cache miss → 다른 코어한테 최신값 가져옴
    • → Core 0: Modified → Shared
    • → Core 1: Invalid → Shared

핵심 규칙: Modified 상태인 라인이 있으면, 다른 코어의 같은 주소는 반드시 Invalid여야 한다.

MOESI / MESIF는 MESI의 성능 최적화 변형이다.

• MOESI (AMD): Modified 데이터를 메모리에 쓰지 않고 다른 캐시에 직접 전달 가능 (Owned 상태) → 메모리 트래픽 감소
• MESIF (Intel): Shared 상태 중 하나가 "대표"가 되어 miss 요청에 응답 (Forward 상태) → 중복 응답 방지
• MERSI (IBM): Intel 구조랑 거의 비슷한데 R에서만 차이가 있음.

5.2 Snooping

모든 코어가 shared bus에 연결되어 있다. 어떤 코어가 bus에 무언가를 쓰면 모든 코어가 그걸 본다.

코어0이 주소 X에 write:
  → bus에 "X 씀" broadcast
  → 코어1, 코어2, 코어3의 cache controller가 이걸 "snoop"
  → 자기 캐시에 X 있으면 → Invalid로 표시

구현이 단순하다. Bus 하나만 보면 되니까 초기 멀티코어 설계에서 사용했다.

단, 코어가 16개, 64개가 되면 broadcast 트래픽이 bus를 포화시킨다. Bus 자체가 병목이 되다보니, 10개 미만 멀티코어 설계들에서 쓰인다.

참고로, SoC내 멀티코어는 산업용이 가장 많고, PC, 모바일 순서로 줄어든다.

PC와 모바일도 계속 코어가 많아지는 추세이므로, 서버에서 사용한 설계 구조를 PC와 모바일이 상속 받는 경향이 있다.

5.3 Directory-Based Coherency

Snooping의 근본 문제

Broadcast는 "아무도 관심 없는 코어"에게도 메시지를 보낸다. 코어가 많을수록 낭비가 심해진다.

Directory의 해법

Memory controller (home node라고도 함)가 "누가 이 캐시 라인을 갖고 있나" 목록을 관리한다.

• X의 directory: [코어1, 코어3이 Shared 상태로 보유 중]
• 코어0이 X에 write 요청:
  → home node가 코어1, 코어3에게만 invalidation 메시지 전송
  → broadcast 없음 (unicast만 사용)

ARM CHI

ARM의 고성능 interconnect 프로토콜. Directory-based coherency를 표준으로 채택했다. Snoop request와 response가 명시적 packet으로 정의되어 있어, 설계자가 timing과 트래픽을 예측할 수 있다.

정리

Cache coherency는 "누가 최신 데이터를 갖고 있는지"를 추적해서 모든 코어가 stale value를 읽지 않도록 강제하는 메커니즘이다. 코어가 적으면 snooping, 많으면 directory.

제6장: Off Chip Bus의 진화

6.1 초기 — S-100, ISA

• S-100 (1975): MITS Altair 8800. 100-pin. 8-bit data, 16-bit address. Asynchronous.
• ISA (1981, IBM PC): 8-bit (4.77MHz, ~4MB/s) → 16-bit (8.33MHz, ~16MB/s).

6.2 PCI (1992)

Intel 주도. 33MHz, 32-bit = 133MB/s. 66MHz, 64-bit = 533MB/s. Synchronous bus. Bus mastering. Plug and Play.

PCI transaction:

• FRAME# signal이 address phase 시작
• IRDY# (Initiator Ready)와 TRDY# (Target Ready)가 data phase handshake
  • 두 신호가 모두 assert되어야 한 data phase 완료
  • Wait state 삽입 가능

6.3 PCI-X (1998)

PCI의 고속화. 133MHz, 64-bit = 1.06GB/s. Split transaction 도입. 서버 시장.

6.4 PCI Express — Serialization 혁명 (2004~현재)

Parallel bus의 근본 문제: 모든 data line이 한 clock cycle 안에 도착해야 한다. Clock frequency가 올라갈수록 skew가 허용 범위를 초과한다.

해결책 = Serialization.

Gen5에서 Nyquist는 16GHz. PCB trace의 insertion loss, return loss, crosstalk를 16GHz까지 관리해야 한다. Bus design이 RF engineering이 된 순간.

6.5 CXL (Compute Express Link, 2019~)

PCIe physical layer 위에 cache coherency protocol을 올린 것. CXL 3.0은 PCIe 6.0 기반.

CXL은 expansion bus(PCIe)와 memory bus의 경계를 허물고 있다. CXL-attached memory는 CPU의 system memory map에 직접 통합된다.

제7장: Memory Bus: DDR SDRAM 인터페이스

7.1 DRAM 접근의 기본

DRAM 셀은 row, column로 구성된 2차원 배열이다. 엄청 큰 책서랍에 좌표값을 넣었다고 보면 됩니다.

DRAM에 데이터를 읽으려면 3단계를 거친다:

① ACTIVATE (행 열기, ~15–30ns)
원하는 row 전체를 "row buffer(sense amplifier)"라는 임시 공간으로 복사한다. 느리다. 책장에서 책 한 칸 전체를 책상 위로 꺼내는 동작이다.

② READ / WRITE (열 선택)
row buffer에서 원하는 column 위치의 데이터를 읽거나 쓴다. 빠르다. 이미 책상 위에 꺼낸 책들 중 하나를 집는 동작이다.

③ PRECHARGE (행 닫기)
row buffer를 비우고 다음 ACTIVATE를 준비한다.

버스 설계에서 핵심:
ACTIVATE가 느리므로, 한 번 row를 열었으면 같은 row의 데이터를 연속으로 최대한 많이 전송하는 게 유리하다. 이것이 버스트 전송이다. DDR 인터페이스가 반드시 버스트를 지원하는 이유다.

7.2 DDR 세대별 진화

DDR의 발전 방향은 단순하다: 큰 대역폭 (저전력도 중요하지만.)

크게 두 가지 방법을 썼다.

• Clock Edge 활용: 클럭의 rising edge뿐 아니라 falling edge에도 전송 (DDR이 Double Data Rate라는 뜻이다.)
• prefetch 증가: 한 번의 READ 명령에 내부적으로 더 많은 비트를 미리 꺼내 전송

8채널 DDR5-6400은 51.2 × 8 = 409.6 GB/s. 4K 영화(약 50GB) 약 8편을 1초에 전송하는 대역폭이다.

7.3 메모리 버스의 물리: DQS가 왜 필요한가

DDR은 소스 동기 인터페이스다.

일반적인 통신은 수신 측이 자기 클럭으로 샘플링한다.

그런데 DDR처럼 수 GHz에서 동작하면, 데이터가 wire를 지나는 동안 발생하는 미세한 지연(skew) 때문에 수신 측의 클럭과 데이터 타이밍이 어긋난다.

해결책: 데이터(DQ)와 함께 Strobe 신호(DQS)를 함께 보낸다. 수신 측은 자기 클럭 대신 DQS를 기준으로 데이터를 샘플링한다. 데이터와 스트로브가 같이 이동하므로, wire 지연이 생겨도 둘의 상대적 타이밍은 유지된다.

• DDR5 버스 구조:
  • 64-bit 데이터 버스 = 8바이트 × 8비트
  • ECC용 8비트 별도
  • DQS는 differential(P/N 쌍), 바이트 레인(8비트)마다 하나씩 독립
  • 각 레인 독립 → 레인 간 skew를 각자 보정 가능

제8장: On Chip Bus 표준 — AMBA, Wishbone, OCP

8.1 AMBA (ARM, 1996~)

칩 내부에서 CPU, 메모리, 주변기기를 연결하는 버스 표준. ARM이 설계했고, 현재 사실상 산업 표준이다.

성능 요구가 커질수록 프로토콜이 복잡해진 과정을 세대별로 보면:

AXI의 핵심 아이디어: 5개의 독립 채널:

AHB까지는 읽기/쓰기가 같은 버스를 공유해서, 한 작업이 끝나야 다음 작업이 시작된다. AXI는 다섯 채널을 완전히 분리했다.

• AW (Write Address): 쓰기 주소 전송
• W (Write Data): 쓰기 데이터 전송
• B (Write Response): 쓰기 완료 응답
• AR (Read Address): 읽기 주소 전송
• R (Read Data): 읽기 데이터 전송

읽기와 쓰기가 동시에 진행되고, 요청 순서와 완료 순서가 달라도 된다(out-of-order). 여러 트랜잭션을 겹쳐서 파이프라인처럼 처리 가능.

CHI — 인터넷 프로토콜 수준의 복잡도:

OSI 7계층과 구조가 같다. 칩 내부 버스가 인터넷과 같은 수준의 계층 설계를 요구하게 된 것은, 수십 개의 코어가 캐시 일관성을 유지하며 통신해야 하기 때문이다.

8.2 Wishbone (Silicore, 1999)

오픈소스 버스 표준. OpenCores 커뮤니티에서 널리 사용한다.

AMBA보다 단순하고, 라이선스 비용이 없다. FPGA 프로젝트나 오픈소스 IP에서 선택하는 이유다. 성능보다 진입 장벽이 낮은 게 장점.

8.3 OCP (Open Core Protocol, 2001~)

OCP-IP 컨소시엄이 개발한 point-to-point 버스 인터페이스. AMBA보다 인터페이스 정의가 유연하다.

• 명령(Command) 채널과 응답(Response) 채널이 완전히 독립
• Thread(tag)를 사용해 out-of-order 트랜잭션 지원
• Texas Instruments, STMicroelectronics 등이 채택

AMBA처럼 생태계가 크지는 않지만, 특정 용도에서 더 유연한 커스터마이징이 가능하다.

제9장: 공유 버스의 죽음과 구조 진화

버스는 각 모듈간 연결 역할을 한다.

그런데 현대 System on Chip에는 많은 모듈이 멀티 코어로 설계되어있고, 여러개의 외부 메모리와 데이터를 주고 받아야한다. 이럴 때에 어떻게 해야 최적의 PPA로 버스를 설계 할 수 있을까?

9.1 공유 버스의 임계점

공유 버스의 원리는 단순하다. 1개의 1차선 도로를 그리고, 이를 모두가 이용한다.

N개 노드(코어, 캐시, 메모리 컨트롤러 등)가 하나의 버스를 나눠 쓴다.

구현이 단순하지만, 한 노드가 버스를 사용하는 동안은 나머지는 대기해야한다.

각 노드당 유효 대역폭 ≤ 총 대역폭 / N

위 부등식이 공유 버스의 사망 선고다.

Intel의 실제 사례:

코어가 4개로 늘어나자 메모리 대역폭이 코어를 못 따라간다. 공유 버스는 N=4에서 사실상 한계에 도달했다.

9.2 Crossbar switch: 면적이 O(N²)으로 폭발

Cross bar switch는 N개의 입력과 N개의 출력을 모두 직접 연결한다. Crossbar는 당시 혁신적인 설계였다. 당시에 아무도 버스에는 신경을 안 썼으니까.

모든 노드가 동시에 통신 가능하다. 근데 N²개의 버스가 필요하다보니, 사이즈가 매우 커진다.

문제는 면적과 Routing congestion 문제다. crosspoint(교차점)가 N² 개 필요하다.

IBM Power4로 Crossbar 리뷰하기

IBM은 과거에 하드웨어 설계를 선도했다. 이들은 칩 자체를 팔기보다는 서버용 컴퓨터 자체를 팔았는데, 2001년 당시 매출이 2조원 이상. 거기에서 쓰인 Power4 Chip이 Dual core 기술이 사용된 최초의 양산 칩이다.

참고문헌:The circuit and physical design of the POWER4 microprocessor, IBM https://ieeexplore.ieee.org/document/5389045

IBM의 Power4 chip 설계 보면 Processor core와 Cache 사이에 CIU Switch라고 나와있다. 이게 Crossbar다.

Physical layout, Die shot으로 보자.

CPU 다이샷을 처음 보면 대부분 이렇게 생각한다.

이걸 보고 뭘 알 수가 있어?

잘 보면, 동일한 모양이 반복된 것이 보이고, 가장자리 부분에도 특이한 것들이 보인다.

"왜 Core (LSU) 는 위에 있고, L2 Cache는 아래에 있고, L3 디렉토리는 옆에 있지?"

"그냥 가운데에 다 몰아넣으면 안 되나?"

하지만 실제 CPU Floorplan은 기능보다 배선(Interconnect) 이 먼저 결정한다.

IBM Power4의 메모리 및 버스 구조는 CPU -> L2 -> L3 -> DDR Memory 계층 구조를 가진다.

Q1: Chip의 정중앙에 중요한 것이 있을 것 같은데 표현이 안 되어있는데, 뭐임?

A1: 여기에 Crossbar가 설계되어있다. Crossbar 자체는 버스 역할일 뿐이다. Mux Buffer Arbiter Control Logic의 집합이다.

최근 AI 가속기의 Dieshot을 보면, Mainbus, northbus, southbus, eastbus, westbus 등등 다양한 버스가 있는데, 이게 다 프로세서들과 다른 블록 간 중개자 역할을 해주는 블록들이라고 보면 된다.

Q2: L2가 중앙에 있을까?

A2: 정확히 말하면, 코어와 L2가 중앙부에 있다.

POWER4에서 가장 중요한 목표는 코어→L2 접근 지연 최소화였다.

그래서 L2를 중앙에 배치하고 코어를 위에 붙여놓은 것이다.

Q3: 왜 코어는 Cache 위에 있을까?

A3: CPU 코어는 IFU, LSU, ISU, FPU 같은 복잡한 논리회로 덩어리다. L2는 SRAM으로 구성된 매우 규칙적인 Bit cell 배열 덩어리이다.

코어는 복잡한 standard cell 덩어리라 모양 잡기가 어려우니, SRAM 먼저 잡아놓는게 Floorplan 엔지니어 입장에서는 쉽다.

Q4: 왜 L2가 3개 Bank로 나뉘었을까?

A4: 당시 Foundry technology로 1.5MB 사이즈의 SRAM을 하나로 만들면 배선이 너무 길어진다. (느려진다.)

예를 들어 1.5MB SRAM 덩어리라면,

• 한 덩어리라면 왼쪽 코어와 오른쪽 코어가 접근하는 거리 차이가 커진다.
• 그래서 L2 Cache를 3개의 Bank로 나눈다. 이를 Banked Cache라고 한다.

이로써 Routing 거리도 줄이고, 병렬 접근도 가능해진다.

• Core 0 -> Bank0, Bank1
• Core 1 -> Bank2 이런식으로 동시에 접근 가능하다.

Q5: 왜 L3 Directory가 왼쪽 구석에 있을까?

A5: POWER4는 CPU Die -> 외부 L3 SRAM 구조이다.

따라서 Directory는 외부 SRAM과 가까운 곳에 두는 것이 유리했다.

Q6: 왜 Memory Controller가 L2, L3 아래에 있을까?

외부 메모리 인터페이스는 엄청난 수의 IO를 사용한다.

그래서 Memory Controller -> IO Pad 구조가 된다.

9.3 Ring bus: 인텔의 시대 (2008~2014)

위에서 말한 것처럼 Core 증가는 불가피하고, 대규모 코어 설계에서 Crossbar 구조는 Routing 문제가 발생한다. Intel은 코어가 많은 서버용 칩 설계, 즉 Nehalem-EX(2010) 를 설계하면서 Ring Interconnect 구조를 Hot chips에서 발표했다.

그러나 일반적으로 "Intel이 Ring Bus 아키텍처를 본격 도입한 첫 CPU"라고 하면 Sandy Bridge를 의미한다. Intel도 Sandy Bridge를 설명하면서 Ring을 핵심 혁신으로 내세웠다.

위에서 보이는 것처럼, 배선이 O(N)으로 깔린다.

각 노드는 이웃 두 노드와만 연결. 데이터는 링을 따라 한 방향 또는 양방향으로 흐른다.

Haswell의 교훈:

• 링 자체가 과열되면 링 클럭이 따로 떨어진다(2.4 → 1.8GHz). 코어가 멀쩡해도 코어 간 데이터 이동이 느려져 전체 성능이 떨어진다.
• OS는 이 현상을 볼 수 없다. OS는 코어 주파수만 보지, ring bus 클럭은 모른다. 실제로 엔지니어들은 이 반도체 병목이 어디서 발생하는지 조사하는 것에 매우 많은 시간이 걸렸다.

수율 문제:

• Ring에 Physical defect가 발생하면, 그 칩은 끝장 날 수 있고, 이에 대한 DFT도 많이 필요하다.
• 기존에 Crossbar 구조일때 한개 bus에 defect이 발견되면, 해당 모듈을 disable 시키고, 보급형 칩으로 판매 할 수 있었다.
• 결국, Ring bus 구조에서는 redundancy bus 추가로 가는데, 이는 die 면적 증가로 발생한다.

9.4 Mesh bus

Ring Bus의 한계를 넘기 위해 인텔이 도입. 2D grid 구조에서 각 교차점에 라우터가 있다.

이제는 Physical Design의 연구가 많아지기 시작된다.

• 라우터는 4방향 switching이 가능해야 한다.
  • 전력 밀도 급상승
• 라우터가 상위 metal layer를 mesh 배선으로 점유
  • power grid가 아래 metal로 밀려남 → IR drop 악화
    • Small IR drop: timing 흔들림
    • Big IR drop: functional failure

mesh가 등장하면서 RTL 설계자가 모르는 곳에서 PD 엔지니어가 power grid와 싸우기 시작했다.

NoC, Network-on-Chip

NoC(Network-on-Chip)는 칩 내부를 패킷 스위칭 네트워크로 만든다. 메쉬의 확장된 개념이다. 인터넷의 라우터·패킷 개념을 그대로 칩에 옮긴 것이다. 보면, 새로운 시그널들이 있다.

설계 차원이 여섯 개:

실제 제품:

• ARM CMN-600: 128코어, 1TB/s 이상
• ARM CMN-700: 256코어, 4TB/s
• Arteris FlexNoC: Qualcomm, Samsung, Bosch가 채택한 상용 IP

NoC가 끌어들인 도메인

NoC를 만든다는 건 더 이상 회로 설계가 아니다. 인터넷을 설계하는 것이다.

최근 NoC로 제일 유명한 회사는 Cerebras 이다.

Wafer scale의 Chip. 거의 1,000,000개의 core를 NoC로 연결하고 있다. 즉, 일부 코어가 physical defect 나더라도, 그거 disable 시키면 되니까 사실상 수율이 100%인 Chip.

제10장: GPU Fabric

GPU는 단일 칩 안의 통신만으로는 부족하다. 여러 GPU가 하나의 작업(LLM 학습)을 나눠 처리해야 하므로, 칩 외부에 별도의 고대역폭 패브릭이 필요했다. NVIDIA가 만든 게 NVLink.

NVSwitch — GPU 간 Crossbar 전용 ASIC:

DGX H100 구성: 8 GPU + 4 NVSwitch.

각 NVSwitch는 64-port non-blocking 크로스바. TSMC 4N 공정, 약 100mm². 시스템 통신을 위해서만 존재하는 별도 ASIC이다. CPU도 GPU도 아니고 그 사이 트래픽만 담당하는 칩.

Bisection bandwidth(전체 시스템을 절반으로 나눴을 때 두 절반 사이 대역폭): 25.6 TB/s

Pentium III FSB(528 MB/s) 대비 48,485배. 30년 만에 5만 배.

PAM4 신호, Nyquist 32GHz. 이 영역은 RF 엔지니어링 영역이다. 또한, Signal Integrity, Power Integrity 문제가 된다. 결국 RF, SI/PI, PD, DFT 엔지니어들이 엄청나게 많이 필요해짐.

제12장: 칩렛: 버스가 다이 경계를 넘다

단일 die가 reticle 한계(약 858mm²)에 도달했다. 더 큰 칩을 만들려면 여러 die를 한 패키지에서 연결해야 한다.

UCIe (Universal Chiplet Interconnect Express): 업계 표준:

• Standard PHY: 16Gbps × 64 lane = 128 GB/s
• Advanced PHY: 32Gbps × 64 lane = 256 GB/s

UCIe로 서로 다른 회사의 die를 한 패키지에 섞을 수 있게 됐다. AMD die + Intel die + 한국 스타트업 die가 한 칩이 되는 미래가 가능하다.

물리적 난제 네 가지:

1. psec 클럭 정렬 — die 사이를 건너는 클럭이 picosecond 단위로 맞아야 함
2. 32Gbps signal integrity — die 사이 짧은 거리지만 PCB 수준의 SI 문제
3. Cross-die power delivery — 한 die에서 다른 die로 전류 흐름이 어떻게 가는가
4. Thermal gradient 15~20°C — die마다 온도가 다름 → die별로 derating factor가 다름

마지막이 핵심이다. 같은 셀이라도 위치에 따라 다른 timing을 갖는다. STA가 한 die 단위로는 풀리지만 multi-die에서는 die 간 thermal coupling을 모델링해야 한다.

제13장: 3D-IC: 버스의 수직화

수평으로 die를 붙이는 게 칩렛이라면, 수직으로 쌓는 게 3D-IC다.

Hybrid bonding이 게임 체인저:

• 구리 pad + 산화막을 상온에서 접합
• 열처리로 확산 접합 완료
• bump가 사라진다 — 솔더 범프 없이 Cu-Cu 직접 연결
• pitch 1µm 도달 → on-chip 배선 밀도의 die-to-die 연결

제품 사례:

• AMD 3D V-Cache (2022): TSMC SoIC, 9µm pitch, +64MB L3
• Intel Foveros Direct: sub-10µm pitch

4대 난제:

3D-IC는 PD, packaging, thermal, mechanical, DFT, EDA, Foundry 한 자리에서 만나야 풀린다.

제14장: HBM: 메모리와 로직의 경계 소멸

DDR이 수평으로 chip을 펼친다면 HBM(High Bandwidth Memory)은 수직으로 쌓는다.

1024-bit PHY가 만드는 문제:

PHY가 die edge를 통째로 점유한다. 1024개 신호 + 제어 신호가 동시에 들어가야 하니까. die의 한 변 전체가 HBM 인터페이스가 된다.

위치별 derating:

8~12단 DRAM이 쌓이고 → 그 위 열이 TSV를 통해 base die로 전달 → PHY 근처 로직 셀이 다른 위치보다 뜨겁다 → 같은 셀도 PHY 근처면 더 느리다. STA가 위치 좌표를 알아야 풀린다.

6,144 신호의 RDL 배선:

6-stack 구성이면 1024 × 6 = 6,144개 신호가 interposer RDL을 통해 라우팅된다. PCB 수준의 라우팅 복잡도가 칩 안으로 들어왔다.

Repair flow의 통합:

DRAM die는 일부 불량 셀이 있는 게 정상이다. spare cell로 교체해야 한다. 이 repair 정보가 OS/driver까지 통합되어야 시스템이 동작한다. 하드웨어 결함을 소프트웨어가 알아야 한다.

결론

이 글은 버스로 시작했다.

대역폭만 보면 80년 동안 2조 배 이상 늘었다. 그러나 바뀐 건 대역폭만이 아니다. 버스 설계가 요구하는 인간의 구조가 바뀌었다.

• 1970년대: 전기 신호를 아는 사람
• 1990년대: 프로토콜 스택을 아는 사람
• 2000년대: 마이크로아키텍처까지 아는 사람
• 2020년대: 11개의 RTL2GDS 도메인에 어떤 영향을 주는지 아는 사람

AI가 이 11개 도메인을 동시에 처리하지 못하는 이유는 컨텍스트 창이 아직 작아서가 아니다.

• 결정적 데이터를 반도체 회사들이 외부 공유를 안하고, (학습이 안 되었고)
• 관련 데이터 볼륨은 어떤 컨텍스트도 구조적으로 초과하며 (GDS들만 합쳐도 PB 단위일듯.)
• 도메인 간 인과관계는 텍스트 패턴이 아니라 실패의 내면화에서 온다.

엔지니어의 뇌 안에 있는 Tape out 경험, Silicon respin과 post mortem 원인 분석 사례가 지금 존재하는 어떤 AI 컨텍스트 윈도우보다 크다.

조건이 하나 있다.

• 이런 경험이 없다면,
• 그 경험이 하나의 도메인 안에만 갇혀 있다면,
• 당신은 그냥 주어진 스펙을 받아서 Flow 따라 구현하는 것이 전부라면,
  • AI가 그 도메인의 반복 작업을 흡수하는 날 당신의 컨텍스트는 무용해진다.

지금까지 반도체 엔지니어링은 나만의 도메인 지식만 깊으면 되었다.

• 이제는 내 뒷단계와 앞단계에 어떤 설계가 필요할지, 어떤 영향이 발생할지 답을 줄 수 있어야한다.
• 다른 것들과 융합하고 새로운 혁신이 있어야한다.
• 이런 데이터들은 학술 문헌에도 드물고, AI 학습 데이터에도 없는 자리다.
  • 그 자리를 채우는 사람이 폰노이만의 다음 장을 쓴다.

반도체 80년. 하나의 Bus organ에서 11개 공학 도메인의 수렴점으로. 그 수렴점을 읽을 수 있는 사람의 뇌가, 지금 이 산업에서 가장 큰 컨텍스트 윈도우다.