SoC Design

⚡ Glitch-free Clock Divider 설계 완전 가이드 — FPGA/ASIC 클락 분주기의 핵심 디지털 회로 설계 | SystemVerilog | FPGA 클럭 관리 | RTL 설계 기법 FPGA나 ASIC 설계에서 클락 분주기(Clock Divider) 는 거의 모든 프로젝트에 빠짐없이 등장하는 핵심 컴포넌트입니다. 하지만 단순히 카운터로 클락을 나누면 글리치(Glitch) 라는 치명적인 노이즈가 발생하여 시스템 전체의 타이밍 안정성을 무너뜨릴 수 있습니다. 이 글에서는 Glitch-free Clock Divider 의 설계 원리부터 실무 적용까지, 실제 합성 가능한 SystemVerilog 코드와 함께 깊이 있게 다룹니다. 📌 이 글의 핵심: 글리치가 왜 위험한지, 이를 방지하는 3가지 설계 기법, 그리고 짝수/홀수 분주를 모두 지원하는 50% Duty Cycle 분주기 RTL 코드를 제공합니다. 🔧 1. 클락 분주기 — 기본 원리부터 짚고 가자 ▶ 카운터 기반 분주의 기본 동작 가장 직관적인 분주 방식은 카운터 를 사용하는 것입니다. 예를 들어 4분주를 구현하고 싶다면, 소스 클락이 2번 뛸 때마다 출력 상태를 반전시키면 됩니다. 구현이 간단하고 이해하기 쉽다는 장점이 있지만, 이 과정에서 조합 논리(Combinational Logic) 의 게이트별 전파 지연 시간(Propagation Delay) 차이로 인해 아주 짧은 시간 동안 잘못된 값이 출력되는 글리치 가 발생할 수 있습니다. ⚠️ 글리치(Glitch)란? 조합 회로에서 입력이 동시에 변할 때, 각 경로의 지연 차이로 인해 최종 출력이 안정되기 전에 순간적으로 잘못된 값이 나타나는 현상입니다. 이것이 클락 라인에 발생하면 하위 회로가 '가짜 클락 에지'로 인식하여 심각한 오동작을 일으킵니다. ▶ 심화: Clock Skew와 Duty Cycle 이해 🕐 Clock Skew — 클락 신호가 서로 다른 플립플롭에 도달하는...

🔧 AXI 프로토콜의 핵심: Burst Transaction과 4KB Boundary 규칙 완벽 가이드 SoC 설계자와 임베디드 엔지니어를 위한 AXI 버스 프로토콜 4KB 주소 경계 규칙의 원리, 위반 사례, 그리고 Cortex-A 환경에서의 실전 해결 방안을 총정리합니다. 📌 AXI 4KB Boundary 규칙이란? AMBA AXI 스펙(IHI0022)에는 "하나의 Burst Transaction은 4KB(2¹² = 4096 바이트) 주소 경계를 넘어서는 안 된다" 는 명시적인 규칙이 존재합니다. 주소값 기준으로 하위 12비트가 0x000 으로 정렬되는 지점, 즉 0x1000 , 0x2000 , 0x3000 등이 바로 4KB 경계입니다. 🤔 왜 하필 4KB인가? 이 제약의 배경에는 두 가지 핵심 이유가 있습니다. ▶ MMU 페이지 단위 일치 — 현대 프로세서(ARMv8-A, x86 등)의 MMU는 최소 페이지 크기를 4KB로 설정합니다. 버스 트랜잭션이 이 단위를 넘으면 페이지 테이블 매핑이 달라질 수 있어 주소 변환에 혼란이 생깁니다. ▶ 슬레이브 주소 공간 보호 — AXI 인터커넥트에서 각 슬레이브에 할당되는 최소 주소 공간이 통상 4KB입니다. 경계를 넘는 Burst는 의도치 않게 다른 슬레이브 영역을 침범하여 데이터 무결성을 파괴할 수 있습니다. ▶ 디코딩 단순화 — 인터커넥트가 주소의 상위 비트만으로 슬레이브를 결정할 수 있어, 트랜잭션 중간에 라우팅 대상이 변경되는 복잡한 상황을 원천 차단합니다. 📊 AXI Burst 유형별 4KB 규칙 적용 AXI 프로토콜은 세 가지 Burst 유형을 정의하며, 각각에 대해 4KB 규칙이 다르게 영향을 미칩니다. Burst 유형 ARBURST / AWBURST 주소 동작 4KB 위반 가능성 FIXED 2'b00 주소 고정 (FIFO 접근) 없음 ✓ INCR 2'b01 주소 순차 증가...

🔌 SoC 피드쓰루(Feed-through) 완벽 가이드 — 물리 설계와 파워 플랜의 핵심 전략 SoC Physical Design · Power Planning · Signal Integrity · 2026 최신 트렌드 반영 SoC(System on Chip) 물리 설계에서 피드쓰루(Feed-through)는 배선 혼잡도를 해소하고 타이밍을 최적화하는 핵심 기법입니다. 수십억 개의 트랜지스터가 집적된 현대 SoC는 거대한 도시와 같아서, 블록 간 신호를 효율적으로 전달하는 '관통 고속도로'가 반드시 필요합니다. 이 글에서는 피드쓰루의 개념부터 파워 플랜 리스크, 그리고 실무 운용 전략까지 깊이 있게 다룹니다. 📌 1. 피드쓰루(Feed-through) 방식이란? 피드쓰루란 특정 기능 블록(IP 또는 Macro)을 물리적으로 가로질러 다른 블록으로 신호를 전달하는 배선 방식입니다. A 도시에서 C 도시로 가기 위해, 중간에 있는 B 도시의 상공이나 지하를 관통하는 '고속도로'를 건설하는 것과 같은 원리입니다. 블록 B의 내부 로직과는 전혀 무관하지만, 물리적으로 블록 B의 영역을 통과하여 목적지에 도달합니다. Top-level에서 라우팅 공간이 부족하거나, 타이밍 최적화를 위해 경로를 단축해야 할 때 주로 사용됩니다. 🟦 Source Block A → 🟨 Block B (Signal just passes through) → 🟦 Destination Block C ⚡ 2. 피드쓰루의 장점과 리스크 ✅ 주요 장점 ▶ 배선 혼잡도(Congestion) 완화 — 블록 사이의 좁은 채널에만 배선을 집중시키지 않고, 블록 내부의 빈 레이어를 활용하여 전체적인 배선 효율을 높입니다. ▶ 타이밍 최적화 — 신호가 블록을 우회하지 않고 직선으로 가로지르므로 와이어 길이가 짧아지고, 신호 지연(Latency)이 크게 감소합니다...

🛠️ Xcelium 시뮬레이션 파일 리스트 작성법 — SystemVerilog 컴파일 에러를 막는 5가지 골든 룰 SoC 검증 엔지니어를 위한 실전 가이드 | Cadence Xcelium · SystemVerilog · UVM Xcelium 시뮬레이션 환경에서 SystemVerilog 파일 리스트(f-list)를 올바르게 구성하는 것은 컴파일 에러의 80% 이상을 사전에 차단 하는 핵심 스킬입니다. 특히 ARM Cortex 시리즈나 Synopsys DesignWare 같은 대형 IP를 통합할 때, "모든 파일이 리스트에 있는데 왜 에러가 나지?"라는 상황을 자주 만나게 됩니다. 이 문제의 근본 원인은 SystemVerilog의 컴파일 단위(Compilation Unit) 메커니즘과 선언-참조 간의 의존성 구조에 있습니다. Cadence 공식 가이드와 업계에서 검증된 골든 룰(Golden Rule) 을 바탕으로, 에러 없는 시뮬레이션 환경 구축 전략을 정리했습니다. 💡 핵심 요약: Xcelium(xrun)은 파일 리스트를 위에서 아래로 순차 컴파일합니다. "참조 대상은 참조 시점 이전에 컴파일되어 있어야 한다" 는 원칙만 확실히 지키면 대부분의 에러를 예방할 수 있습니다. 📌 1. SystemVerilog 컴파일 메커니즘: 선(先) 선언, 후(後) 참조 SystemVerilog 시뮬레이터는 파일 리스트의 첫 줄부터 마지막 줄까지 순차적으로 파싱 합니다. 이 과정에서 가장 중요한 규칙은 단 하나입니다. ⚠️ "사용하기 전에 먼저 정의하라" (Define Before Use) 예를 들어 Module A 가 Package P 에 정의된 typedef 를 사용한다면, f-list에서 Package P 는 반드시 Module A 보다 앞에 위치해야 합니다. 순서가 뒤바뀌면 컴파일러는 해당 타입을 인식하지 못해 에러를 발생시킵니다. 2026년 현재 Xcelium 24....

🔧 폐쇄망 SoC 설계 환경을 위한 가볍고 강력한 Vim 구축 가이드 SoC(System on Chip) 설계 엔지니어라면 폐쇄망 서버 환경 에서 수백만 라인의 RTL 코드와 씨름하는 일상이 익숙할 것입니다. 외부 인터넷이 차단된 환경에서 VSCode나 LSP 기반 IDE는 사실상 무용지물. 이 가이드에서는 외부 의존성 제로 로 Vim을 최강의 SoC 개발 도구로 만드는 전략을 단계별로 소개합니다. 특히 Xcelium, VCS 같은 시뮬레이터와의 연동이 어렵고, LSP 서버를 띄울 수 없는 보안 환경에서도 '속도' 와 '탐색' 두 마리 토끼를 잡는 방법에 집중합니다. 대용량 로그 파일(수백 MB~수 GB)까지 거뜬히 처리하는 성능 최적화 팁도 함께 담았습니다. 💡 이 가이드의 핵심 원칙: 모든 설정은 인터넷 없이 동작하며, Python/Node.js 등 외부 런타임에 의존하지 않습니다. 🏷️ 1. 코드 탐색의 핵심 — Universal Ctags LSP를 사용할 수 없는 환경에서 대규모 Verilog/SystemVerilog 프로젝트 의 모듈 인스턴스를 추적하는 가장 확실한 방법은 Ctags 입니다. 단순히 파일을 여는 것을 넘어, 함수 정의나 모듈 선언부로 즉시 점프 할 수 있습니다. ⚡ Universal Ctags vs Exuberant Ctags → Universal Ctags는 Exuberant Ctags의 후속 프로젝트로, SystemVerilog 2017 구문 을 완벽 지원합니다. → interface, class, constraint, covergroup 등 최신 SV 키워드를 정확하게 파싱합니다. 폐쇄망에서는 외부에서 바이너리를 다운로드한 뒤 USB 등으로 서버에 옮겨 설치합니다. 설치 후 프로젝트 루트에서 태그 파일을 생성하세요: # 프로젝트 루트에서 tags 파일 생성 ctags -R . # SystemVerilog 전용 옵션 (더 정확한 파싱) ctags ...