PD 엔지니어가 RTL을 알아야 하는 이유

30초 요약

• Physical design의 고통 대부분은 RTL에서 시작된다. 배선을 아무리 잘해도 망가진 microarchitecture는 못 고친다.
• Synthesis와 P&R 툴은 최적화기이지 마법사가 아니다. 큰 mux, 깊은 combinational chain, 잘못된 clock gating은 툴이 못 고치는 구조적 문제다.
• PD 엔지니어가 RTL을 "설계"할 필요는 없다. 하지만 읽고, 냄새 맡고, front-end 엔지니어와 싸울 수 있을 정도는 되어야 한다.
• 최소 요구사항: always_ff/always_comb 읽기, blocking vs non-blocking, case/generate, inferred latch 식별, fanout과 mux depth 감각.
• Late RTL change의 비용은 단계가 늦어질수록 기하급수적으로 뛴다. 마스크셋 하나에 수백만~수천만 달러가 드는 시대에, "RTL을 몰라서" 생긴 ECO는 죄다.
• Chase의 결론: front-to-back를 다 만져봐라. RTL부터 시작해서 verification, synthesis/PD, STA/signoff까지. PD만 파고 있으면 천장이 낮다.

인트로: 백엔드 엔지니어가 RTL을 모르면 벌어지는 일

Physical design(PD) 엔지니어들 사이에는 오래된 농담이 있다. "RTL은 front-end 사람들의 문제고, 우리는 netlist만 받으면 된다." 이 말을 믿고 netlist만 보고 살아온 엔지니어가 결국 마주하는 건, 밤샘 congestion 디버깅과 설명할 수 없는 timing violation, 그리고 테이프아웃 일주일 전 날아오는 RTL ECO다.

나는 지금 Synopsys에서 PrimeTime(STA/signoff 툴)을 만드는 Product Engineer로 일한다. 플로우의 가장 끝, 즉 칩이 되기 직전의 타이밍을 다루는 자리에 있다. 그리고 SiFive Korea(현 SEMIFIVE)에서는 Samsung 5nm부터 14nm까지 RTL-to-GDS 풀오너십으로 5번 이상의 테이프아웃을 했다. 플로우의 양 끝을 다 경험한 입장에서 단언할 수 있다. RTL을 읽지 못하는 PD 엔지니어는, 지도 없이 운전하는 것과 같다. 목적지(netlist)는 보이지만, 왜 그 길이 막혔는지, 어디서 돌아가야 하는지 모른다.

이 글은 설교가 아니다. 실제로 벌어진 전쟁 이야기 4개를 먼저 보여주고, 그다음 PD 엔지니어에게 정말 필요한 최소한의 RTL 지식이 무엇인지 정리한다. 디자이너가 되라는 얘기가 아니다. 읽을 줄 알고, 위험한 패턴을 알아보고, front-end 엔지니어와 같은 언어로 대화할 수 있으면 된다.

Episode 1. 거대한 mux가 만든 congestion 지옥

어떤 프로젝트에서 crossbar 하나가 전체 블록의 routing을 집어삼킨 적이 있다. RTL을 열어보니 이런 코드였다.

// Combinational, unregistered crossbar — no pipeline register
assign data_out = (sel == 3'd0) ? data_in0 :
                  (sel == 3'd1) ? data_in1 :
                  (sel == 3'd2) ? data_in2 :
                  (sel == 3'd3) ? data_in3 :
                  (sel == 3'd4) ? data_in4 :
                  (sel == 3'd5) ? data_in5 :
                  (sel == 3'd6) ? data_in6 :
                  (sel == 3'd7) ? data_in7 : 32'd0;

완벽히 legal한 RTL이다. Simulation도 통과한다. 그런데 synthesis는 이걸 수천 개의 게이트로 풀어놓고 칩 전체에 흩뿌린다. 8개의 32-bit 입력이 모두 한 점으로 모이는 구조 — placement 입장에서는 모든 입력 버스를 한 지점으로 끌어와야 하고, 결과는 routing congestion hotspot이다. 실제로 업계에서는 4,000-to-1 mux 하나가 "routing and timing nightmare"를 만들었다는 기록도 있다. 합법적인 RTL이 합법적인 재앙을 만드는 셈이다.

RTL을 읽을 줄 아는 PD 엔지니어라면 netlist 단계가 아니라 RTL handoff 리뷰 단계에서 이걸 잡는다. "이 crossbar는 왜 unregistered인가? 한 스테이지 pipeline을 넣으면 congestion이 절반으로 준다"는 한마디가, 3주간의 P&R iteration을 3일로 줄인다.

Episode 2. Synthesis가 못 고치는 타이밍 — 문제는 microarchitecture다

STA 리포트를 받아든 PD 엔지니어의 일상: slack -320ps짜리 setup violation 수백 개. Buffer를 박고, gate를 키우고, retiming을 돌려도 안 잡힌다. 왜냐하면 문제가 구조에 있기 때문이다.

전형적인 패턴은 이렇다. 한 clock cycle 안에 128-stage짜리 combinational logic이 들어 있다. Wide mux 뒤에 carry chain이 붙고, 거기에 high-fanout net까지. Synthesis 최적화는 local minima에 갇힌다. Buffer insertion도, gate resizing도, retiming도 소용없다. 수학적으로 그 클럭 안에 들어갈 수 없는 양의 로직이 한 사이클에 들어 있기 때문이다.

이때 필요한 건 툴 세팅이 아니라 microarchitecture 변경이다. Pipeline stage를 하나 더 넣거나, mux를 쪼개거나, 아예 데이터패스를 다시 그리는 것. 그런데 PD 엔지니어가 RTL을 읽지 못하면, 이 판단 자체를 못 한다. Front-end 팀에 "이건 구조 문제니까 RTL을 고쳐달라"고 말해야 하는데, RTL을 못 읽으니 증거를 못 댄다. 결국 몇 주를 툴 옵션만 돌리다가, 나중에 RTL 팀이 pipeline을 넣고 1시간 만에 해결되는 걸 구경하게 된다.

PrimeTime을 만드는 입장에서 덧붙이자면, signoff 단계에서 보는 최악의 violation들은 대개 "툴이 더 열심히 하면 잡히는" 문제가 아니라 "RTL 단계에서 막았어야 할" 문제다. STA 툴은 진실을 말해줄 뿐, 진실을 바꿔주진 않는다.

Episode 3. 늦은 RTL 변경과 ECO 지옥의 경제학

칩 개발에서 버그 수정 비용은 단계가 늦어질수록 기하급수적으로 뛴다. RTL 단계에서 한 줄 고치는 것과, P&R이 끝난 뒤 ECO로 고치는 것과, 마스크를 다시 만드는 것은 차원이 다른 비용이다.

공개된 추정치를 보면 감이 온다. 90nm 시절 마스크셋이 약 100만 달러, 65nm가 약 150만 달러였고, 5nm급 이하에서는 마스크셋 하나에 천만 달러를 훌쩍 넘는 수준으로 알려져 있다. 테이프아웃 일주일 전에 RTL 변경이 들어오면, 선택지는 두 개다. Metal-layer ECO로 버티거나, 풀 리스핀을 감수하거나. 둘 다 비싸고, 둘 다 일정이 깨진다.

여기서 PD 엔지니어의 RTL 독해력이 돈으로 직결된다. ECO를 할 때, 변경된 RTL이 정말로 그 정도의 변경을 요구하는지 판단할 수 있어야 한다. 가끔 front-end에서 내려오는 ECO RTL을 보면, 기능상으론 같은데 코딩 스타일만 바뀐 경우가 있다. RTL을 읽지 못하면 "바뀐 부분이니까 다 다시 돌리자"가 되고, 읽을 줄 알면 "이건 functionally equivalent하니 spare cell로 흡수 가능하다"는 판단이 나온다. 그 한 줄 판단이 수백만 달러와 수주를 가른다.

Episode 4. Clock gating 하나 잘못 건드리면 생기는 power-grid 악몽

RTL 레벨의 clock gating 실수는 PD 단계에서 가장 찾기 힘든 버그 중 하나다. 예를 들어, 수동으로 짠 gated clock이 있다.

// DANGEROUS: hand-rolled clock gating — glitch risk
assign gclk = clk & en;

Glitch가 생기면 clock으로 쓰는 net에 원치 않는 edge가 생기고, downstream flop들이 오동작한다. Synthesis가 integrated clock gating cell로 바꿔주길 기대하지만, 코딩 스타일에 따라 툴이 인식을 못 하는 경우가 있다. 그러면 PD 단계에서 clock tree가 이상하게 합성되고, CTS는 고생하고, dynamic power는 튀고, IR drop 분석에서는 엉뚱한 hotspot이 뜬다.

RTL을 읽는 PD 엔지니어는 clock 구조를 보자마자 묻는다. "이 enable 신호는 glitch-free한가? Synthesis가 ICG로 인식했나? Clock gating check는 STA에서 커버되는가?" 이 질문을 P&R 전에 던지느냐, 실리콘에서 디버깅하느냐의 차이다.

PD 엔지니어가 정말로 알아야 할 최소한의 RTL

다시 강조한다. 설계할 줄 알라는 게 아니다. 읽고, 위험을 감지하고, 대화할 수 있으면 된다. 범위는 다음과 같다.

1. 읽어야 할 constructs (Verilog/SystemVerilog)

• always_ff / always_comb / assign — sequential과 combinational의 구분이 곧 timing 구조의 구분이다.
• Blocking (=) vs non-blocking (<=) — simulation과 synthesis mismatch의 고전적 원인. 남의 RTL을 리뷰할 때 제일 먼저 보는 것.
• if-else / case — priority encoder vs parallel mux. case 안에 default가 없으면 latch가 추론된다.
• generate / parameter — 파라미터화된 모듈이 실제로 몇 개 instance로 풀리는지 감각적으로 알아야 area/congestion 추정이 된다.
• interface / modport (SystemVerilog) — 요즘 RTL은 port가 수백 개인 모듈이 interface로 묶여 있다. 못 읽으면 hierarchy 추적 불가.
• Reset 스타일 — synchronous vs asynchronous reset, reset domain이 몇 개인지. Reset은 PD에서 high-fanout net의 주범이다.

2. 알아봐야 할 synthesis-hostile 패턴

• 거대한 unregistered mux / crossbar (Episode 1)
• 깊은 combinational chain — 한 사이클에 로직 레벨이 수십 단 이상이면 microarchitecture 문제 (Episode 2)
• 수동 clock gating (clk & en) — ICG 미인식, glitch 위험 (Episode 4)
• Inferred latch — if에 else가 없거나 case에 default가 없으면 latch. Timing 분석의 암흑지대.
• High-fanout reset/enable — 수만 개의 flop에 걸리는 global net. CTS와 power에 직접 타격.
• Flop으로 추론된 큰 배열 — SRAM으로 가야 할 메모리가 수천 개 flop으로 풀리면 area/congestion 폭발. RTL에서 memory inference를 읽을 줄 알아야 한다.
• Clock domain crossing — synchronizer 없이 넘어가는 신호. STA에서 false path로 잘못 자르면 실리콘에서 죽는다.

3. Front-end와 대화하는 법

RTL을 읽을 수 있게 되면 대화가 바뀐다. "Timing이 안 나와요"가 아니라 "이 경로의 mux depth가 6단이라 1GHz에 안 들어갑니다. Pipeline을 한 단 넣거나 mux를 쪼개주세요"가 된다. 전자는 불평이고, 후자는 엔지니어링이다. Front-end 엔지니어도 후자에는 반응한다. 같은 언어를 쓰기 때문이다.

다음 단계: edu.vlsi.kr에서 front-to-back 로드맵 따라가기

RTL 읽기는 혼자 끙끙대며 배울 게 아니다. 순서가 있다. VLSI Edu의 RTL2GDS 로드맵은 RTL부터 GDS까지 전체 플로우를 커리어 패스로 정리해둔 출발점이다. 특히 PD로 가는 사람이라면, RTL → verification → synthesis → PD → STA/signoff 순서로 밟아보는 걸 권한다.

전체 커리어 패스 지도는 44개 반도체 커리어 패스 개요에서 확인할 수 있다. Architecture & RTL, Verification, Implementation & Signoff 카테고리로 나뉘어 있고, 각 역할마다 단계별 스킬과 학습 리소스가 정리되어 있다. (참고: 현재 해당 페이지는 베트남어 로케일로 렌더링되고 있으며, 한국어(/ko/roadmaps)와 영어(/en/roadmaps) 페이지는 2026-10-11 현재 404/렌더링 오류 상태다. 사이트에 한국어판 RTL→PD 커리어 패스 상세 페이지와 STA/signoff 심화 튜토리얼 페이지가 추가되어야 한다.)

Chase's Take

솔직히 말하면, 나도 처음부터 RTL을 잘 읽었던 건 아니다. SiFive Korea에서 RTL-to-GDS를 풀오너십으로 맡았을 때, 처음 몇 달은 netlist만 보고 P&R을 돌렸다. 그러다 Samsung 5nm 프로젝트에서 congestion 때문에 3주를 날린 적이 있다. 원인은 Episode 1과 똑같은 unregistered crossbar였다. 그때 RTL 팀 리드가 내 자리로 와서 코드를 펼쳐놓고 말했다. "이거 pipeline 한 단만 넣으면 돼." 그 한마디에 3주가 증발했다. 그날 이후로 나는 RTL을 먼저 읽는다.

지금은 Synopsys에서 PrimeTime을 만드는 쪽에 있다. 매일 보는 게 timing violation 리포트다. 재미있는 건, signoff 단계에서 가장 고치기 힘든 violation일수록 원인이 RTL에 있다는 점이다. 툴은 정직하다. 숫자를 보여줄 뿐이다. 그 숫자를 바꾸는 건 결국 사람의 설계 판단이고, 그 판단의 재료는 RTL이다.

그래서 나는 후배들에게 항상 같은 말을 한다. "전반적으로 다 해봐야 한다." RTL부터 시작해라. 그다음 verification, 그다음 synthesis와 PD, 그다음 STA와 signoff. PD만 파고들면 당장은 편하다. 툴 돌리는 법만 알면 되니까. 하지만 천장이 낮다. 진짜 문제는 항상 경계에 있고, 경계를 넘나들려면 양쪽 언어를 알아야 한다.

PrimeTime의 가장 끝단에서 일하는 내가 RTL부터 시작하라고 말하는 게 아이러니하게 들릴 수도 있다. 하지만 플로우의 끝에서 일할수록 시작이 더 잘 보인다. 모든 고통의 뿌리는 RTL에 있다. 그러니 거기서부터 배워라.

FAQ

Q1. PD 엔지니어가 RTL을 직접 "설계"할 수 있어야 하나요?

아니다. 목표는 readability다. 남이 짠 RTL을 읽고, timing/congestion/power 관점에서 위험한 구조를 찾아내고, front-end 엔지니어에게 구체적으로 설명할 수 있으면 충분하다. 직접 모듈을 설계하는 능력은 보너스다.

Q2. RTL을 배우는 데 얼마나 걸리나요?

읽기 수준까지는 2~3개월이면 된다. Verilog/SystemVerilog 기본 문법 1개월, synthesis가 RTL을 어떻게 해석하는지(latch inference, mux 구조, resource sharing) 1개월, 실제 프로젝트 RTL 리뷰 참관 1개월. 이 글의 체크리스트를 손에 들고 리뷰에 들어가면 가장 빨리 는다.

Q3. Synthesis 툴이 좋아지면 RTL 지식이 불필요해지지 않나요?

반대다. 툴이 좋아질수록 남는 문제는 툴이 못 고치는 구조적 문제뿐이다. AI 기반 툴이 routine 최적화를 가져갈수록, microarchitecture 판단 같은 인간의 몫이 더 중요해진다. RTL 이해는 depreciate되지 않는 자산이다.

Q4. STA/signoff 엔지니어에게도 RTL 지식이 필요한가요?

더 필요하다. STA는 timing을 "판정"하는 단계라서, violation의 근본 원인이 RTL 구조에 있는지 툴/제약 문제인지를 가려내야 한다. PrimeTime 리포트를 읽고 "이건 SDC 문제가 아니라 pipeline 문제"라고 말할 수 있는 STA 엔지니어가 가장 비싸다.

이 글은 저자의 실무 경험을 바탕으로 한 커리어 관점의 글입니다. 특정 프로젝트의 수치는 설명을 위해 단순화되었습니다.