ARM GIC-600 PE 증가에 따른 GICR 2MB 정렬 제약의 원인과 타당성 분석

🔧 ARM GIC-600 GICR Base Address와 2MB 정렬 제약사항 완전 분석

ARM SoC 설계 · GICv3 아키텍처 · 인터럽트 컨트롤러 · 하드웨어 제약

ARM 기반 SoC에서 GIC-600 인터럽트 컨트롤러를 설정할 때, PE(Processor Element) 수가 증가하면 GICR Base Address에 2MB 정렬이 강제되는 현상이 발생합니다. 공식 문서에 명시되지 않은 이 제약의 원인과 실무 대응 방법을 심층 분석합니다.

💡 핵심 요약 — GIC-600의 내부 Redistributor Child Node 그룹핑(16 PE × 128KB = 2MB)과 RTL 주소 디코딩 최적화로 인해, PE가 일정 수를 초과하면 Bit[20]이 주소 판별에 사용되면서 2MB 정렬이 사실상 필수가 됩니다.

📐 1. 기본 제약사항: GICR의 128KB 정렬

GICv3 아키텍처에서 각 PE에 대응하는 Redistributor(GICR)는 다음과 같은 주소 공간을 점유합니다.

구성 요소	크기	설명
RD_base	64KB	Redistributor 기본 레지스터
SGI_base	64KB	Software Generated Interrupt 레지스터
합계 (PE당)	128KB	0x20000 단위 정렬 필요

GICv4 이상에서 가상화 인터럽트(vLPI)를 지원하면 VLPI_base 등이 추가되어 PE당 256KB를 차지하기도 합니다. 하지만 표준 GICv3/GIC-600 사양에서는 PE당 128KB(0x20000)가 기본 단위이며, GICR Base Address는 최소 128KB 단위로 정렬되어야 합니다.

이 128KB 정렬은 널리 알려진 기본 상식이지만, PE 개수가 증가하면 상황이 달라집니다.

⚡ 2. PE 개수 증가와 2MB 경계의 상관관계

"20번째 비트(Bit[20])를 바라보게 되어 2MB 정렬이 강제되는 상황"은 GIC-600의 내부 버스 구조와 주소 디코딩 최적화에서 비롯됩니다.

🔍 A. 주소 디코딩의 효율성 (RTL Optimization)

PE가 많아지면 GIC Distributor(GICD)와 GICR 간의 통신 부하가 커집니다. GIC-600은 이를 해결하기 위해 GICR들을 개별적으로 연결하지 않고, Redistributor Child Node라는 그룹 단위로 관리합니다.

▶ 한 그룹에 16개의 PE가 포함되면:

16 PE × 128KB = 2,048KB = 2MB

→ RTL 설계 시 상위 비트(Bit[21] 이상)를 그룹 선택자로, 하위 비트(Bit[20:0])를 그룹 내 오프셋으로 사용하도록 하드웨어가 고정(Hard-wired)됩니다.

📦 주소 비트 구조 다이어그램

Bit[31:21]

그룹 선택자

GICR 블록 식별

Bit[20:17]

PE 인덱스

그룹 내 PE 선택

Bit[16:0]

레지스터 오프셋

RD_base / SGI_base

→ Bit[20]이 PE 인덱싱에 사용되면서 2MB(0x200000) 정렬이 강제됨

📄 B. 2MB Huge Page 정렬과의 시너지

현대적인 OS(Linux, Zephyr 등)와 하이퍼바이저는 메모리 관리 효율을 위해 2MB 단위의 Section/Huge Page를 사용합니다. GICR 레지스터 공간이 2MB 경계에 걸쳐 있으면 다음과 같은 문제가 발생합니다.

⚠️ MMU 페이지 테이블에서 속성(Device-nGnRnE 등)을 다르게 부여하기 어려움

⚠️ 캐시 설정(Non-cacheable 필수)과 보안 영역(Secure/Non-secure) 분리 시 복잡도 급증

⚠️ TrustZone 환경에서 TZASC/TZPC 설정이 2MB 단위로 동작하는 경우 충돌 발생

따라서 하드웨어 설계 시 아예 2MB 단위로 Base Address를 고정하는 것이 소프트웨어 이식성 측면에서도 합리적인 설계 원칙입니다.

🏗️ 3. GIC-600만의 특수성: 내부 Interconnect

GIC-600은 이전 모델(GIC-400/500)과 달리 AXI4-Stream 인터페이스 기반의 내부 메시지 라우팅 방식을 사용합니다. 이 아키텍처가 2MB 정렬 제약에 직접적인 영향을 미칩니다.

🔀 GIC-600 내부 토폴로지

GICD (Distributor)

인터럽트 라우팅 엔진

↕ AXI4-Stream

Child Node 0

PE 0~15 (2MB)

Child Node 1

PE 16~31 (2MB)

Child Node N

PE N×16~ (2MB)

① GICD와 GICR의 분리: GIC-600은 물리적으로 멀리 떨어진 GICR들로 메시지를 보낼 때, 내부적으로 주소 필터링을 수행합니다. 이 필터링 로직이 2MB 블록 단위로 동작합니다.

② Affinity Routing: 인터럽트 전달 시 MPIDR_EL1의 Affinity 레벨을 사용하는데, 이 데이터가 실제 메모리 맵 주소와 매핑될 때 특정 비트 범위를 예약(Reserved)하거나 고정된 오프셋 계산식을 따르게 됩니다.

③ PE 카운트와 파라미터: RTL 구성 시 GICR_COUNT나 PE_PER_BLOCK 같은 파라미터가 조절되면, 주소 버스에서 유효하게 판단하는 비트의 범위가 달라집니다. 20번째 비트의 참조는 하드웨어가 "최소 2MB 크기의 연속된 블록"을 하나의 노드로 인식하기 시작했음을 시사합니다.

🔬 4. GIC-600AE와 Multi-Chip 환경에서의 추가 고려사항

안전 기능이 강화된 GIC-600AE(Automotive Enhanced) 변형이나 Arm Neoverse 기반의 Multi-Chip 구성에서는 2MB 정렬 제약이 더욱 엄격해집니다.

🔸 Multi-Chip Topology: GIC-600은 최대 4개의 칩에 걸쳐 분산 배치될 수 있으며, 각 칩의 GICR 영역은 독립적인 2MB 블록으로 정렬되어야 합니다. 칩 간 인터럽트 라우팅 시 상위 비트로 칩을 식별하므로 하위 21비트의 정렬이 더욱 중요합니다.

🔸 ASIL-B/D 인증: GIC-600AE에서는 ECC나 Lock-step 검증 로직이 추가되며, 주소 디코딩 경로에 대한 중복 검증이 수행됩니다. 비정렬 주소는 오류 감지 회로에서 잘못된 에러를 트리거할 수 있습니다.

🔸 CMN-700 Interconnect와의 연동: Arm의 CMN-700(Coherent Mesh Network)과 결합할 경우, SAM(System Address Map) 설정에서 GICR 영역을 Device 타입으로 매핑하는데 이 역시 2MB 단위의 Region 설정을 기본으로 합니다.

✅ 5. 타당성 검토 결과

PE 증가에 따른 2MB 정렬 제약의 발견은 매우 타당한 기술적 통찰입니다. 문서에 명시되지 않았더라도 다음과 같은 이유로 2MB 정렬은 필수적인 제약이 됩니다.

🛡️ 하드웨어 버그 방지

GIC-600의 특정 리비전이나 Multi-chip 설정에서 주소 디코더가 하위 21비트(Bit[20:0])를 마스킹(Masking)하는 설계가 포함될 수 있습니다. 2MB 정렬을 지키지 않으면 주소 에일리어싱(Aliasing)이 발생하여 잘못된 PE로 인터럽트가 전달될 위험이 있습니다.

🔄 SMMU와의 호환성

외부 디바이스가 GICR에 접근하거나 SMMUv3를 거치는 환경에서, 2MB 경계가 정렬되지 않으면 Stage-2 주소 변환 오류가 발생할 확률이 매우 높습니다. 특히 Arm CCA(Confidential Compute Architecture) 환경에서는 Realm 경계 설정과도 충돌합니다.

📈 확장성(Scalability)

향후 PE가 더 추가될 것을 대비하여 하드웨어 파라미터가 2MB 블록 단위로 주소 공간을 예약하도록 설계된 결과입니다. 64코어 이상의 서버급 SoC에서는 이 정렬이 거의 표준처럼 적용됩니다.

📋 6. 실무 지침 및 권장사항

GIC-600을 사용하는 대규모 멀티코어 시스템을 설계할 때 반드시 따라야 할 지침을 정리합니다.

① GICR Base의 2MB 정렬 필수

GICR의 시작 주소는 0x200000(2MB) 단위로 정렬하십시오. RTL 상의 제약을 회피할 뿐만 아니라 Linux 커널의 Device Tree 설정, U-Boot의 GIC 초기화 코드, 하이퍼바이저의 패스스루 매핑 등 소프트웨어 이식성 측면에서도 가장 안전합니다.

예시: 0x30200000, 0x30400000, 0x30600000 ✅

금지: 0x30180000, 0x302A0000 ❌

② GICD와의 거리 확보

GICD와 GICR 사이의 주소 공간을 충분히 띄워, 향후 PE 증가 시 주소 맵이 겹치지 않도록 설계해야 합니다. 최소 16MB 이상의 간격을 권장하며, 이는 최대 128코어까지 확장 가능한 여유를 제공합니다.

③ RTL 파라미터 재확인

IP 구매 시 제공되는 Configuration Results 또는 Implementation Guide 문서에서 주소 버스 폭(Address Width)과 각 컴포넌트의 Offset 계산 로직을 반드시 검토하십시오. 특정 파라미터 설정에 따라 주소 디코딩 방식이 Sparse하게 변할 수 있습니다.

④ 검증 시 주소 정렬 테스트 추가

RTL 시뮬레이션 단계에서 의도적으로 비정렬 주소를 입력하여 주소 디코더의 동작을 검증하십시오. Assertion을 추가하여 Bit[20:0]이 0이 아닌 경우 경고를 발생시키는 것도 좋은 방법입니다.

🎯 결론

GIC-600에서 PE가 많아짐에 따라 나타나는 2MB 정렬 제약은 하드웨어 디코딩 로직의 간소화와 시스템 성능 최적화를 위한 의도적인(또는 RTL 구현 상의 필연적인) 설계 결과입니다. 공식 문서에 명시되지 않았더라도, 이 제약사항을 설계 규칙(Design Rule)에 반영하는 것이 안전하고 올바른 접근입니다.

📚 참고 자료

→ Arm CoreLink GIC-600 Generic Interrupt Controller Technical Reference Manual

→ Arm Generic Interrupt Controller Architecture Specification (GICv3/v4)

→ Arm CoreLink GIC-600AE Technical Reference Manual

→ Arm CoreLink CMN-700 Coherent Mesh Network Technical Reference Manual

본 글의 내용은 참고 목적으로 제공되며, 실제 설계 시에는 Arm의 공식 기술 문서와 IP 벤더의 가이드를 반드시 확인하시기 바랍니다.