⚙️ 플립플롭 vs 래치 — 디지털 IP가 래치를 두려워하는 진짜 이유
반도체 디지털 설계에서 값을 기억하는 두 소자, 플립플롭(Flip-Flop)과 래치(Latch)는 면적·전력에서 래치가 유리한데도 현대 칩 설계는 래치를 강하게 통제한다. 이 글은 두 소자의 동작 원리와 트랜지스터 구조 차이부터, IEEE 1800 산업 표준과 합성 권위자의 가이드라인, 전력·지연 트레이드오프, 그리고 의도치 않은 래치를 막는 올바른 SystemVerilog 코딩까지 한 번에 정리한다.
🔍 본질의 차이: 레벨 민감 vs 엣지 민감
순차 논리회로에서 이전 값을 기억하는 소자는 무엇에 반응하는가에 따라 갈린다. 이 한 가지 차이가 이후 모든 설계 방법론을 가른다.
▶ 래치(Latch) — 레벨 민감(Level-sensitive)
클럭(또는 인에이블)이 특정 레벨(예: High)을 유지하는 동안 입력 D의 변화가 출력 Q로 그대로 투과(Transparent)된다. 레벨이 반전되면 그 직전 값을 유지(Hold)한다. 문이 열려 있는 동안엔 물이 계속 흐르는 셈이다.
▶ 플립플롭(Flip-Flop) — 엣지 민감(Edge-triggered)
클럭이 변화하는 찰나의 순간(예: 상승 엣지)에만 입력을 샘플링하고, 나머지 구간에서는 입력 변화를 철저히 무시한다. 셔터가 찰칵 닫히는 순간의 장면만 찍는 카메라와 같다.
핵심은 플립플롭이 마법 같은 별도 소자가 아니라, 두 개의 래치를 직렬로 묶어(Master-Slave) 엣지 트리거 동작을 만들어낸다는 점이다. 마스터와 슬레이브에 서로 반대 위상의 클럭을 공급하면, 어느 순간에도 둘 중 하나만 투과 상태가 되어 데이터가 한 클럭 엣지에 정확히 한 번만 통과한다. 즉, 플립플롭의 안정성은 래치 두 개의 협업에서 나온다.
🔗 다이어그램 요약: 플립플롭 한 개는 마스터 래치와 슬레이브 래치를 직렬로 연결한 구조다 — 마스터는 클럭이 Low일 때, 슬레이브는 High일 때 투과되며 둘에 반대 위상 클럭이 들어가 데이터가 엣지마다 딱 한 번만 D에서 Q로 빠져나간다.
🧱 구조·면적·트랜지스터 개수 비교
CMOS 표준 셀 레벨에서 두 소자의 트랜지스터 수는 면적과 전력 특성을 그대로 드러낸다. 다만 자료에 따라 래치의 트랜지스터 수치가 엇갈리므로 양쪽 견해를 그대로 병기한다.
| 항목 | 래치 (D-Latch) | 플립플롭 (D-FF) |
|---|---|---|
| 동작 방식 | 레벨 민감(투과형) | 엣지 민감(샘플링) |
| 트랜지스터 수 | 견해 A: 약 8~10개 견해 B: 약 6~8개 |
약 16~20개 |
| 구조 | 크로스 커플드 인버터 + 전송 게이트 | 래치 2개 직렬(Master-Slave) + 내부 클럭 인버터 |
| 면적 | 작음 | 큼 (래치의 약 2배) |
아래는 두 소자의 대략적인 트랜지스터 규모를 시각화한 것이다(래치는 견해 중간값 ~8개, 플립플롭 ~18개 기준).
💡 엇갈리는 수치, 일치하는 결론: 한쪽 자료는 일반 CMOS D-Latch를 전송 게이트와 크로스 커플드 인버터 기반 약 8~10개로, 다른 쪽은 동일 구조를 약 6~8개(유지용 인버터 4개 + 전송 게이트 스위치 2~4개)로 본다. 두 견해가 공통적으로 동의하는 결론은 “래치가 플립플롭의 절반 수준”이라는 점이다. 절대 개수는 라이브러리·공정·구현 방식에 따라 달라진다고 보는 것이 정확하다. 플립플롭은 양쪽 모두 약 16~20개로 일치한다 — 마스터·슬레이브 두 래치에 상보 클럭 위상을 만드는 내부 인버터 버퍼가 추가되기 때문이다. (TSPC 등 특수 고속 회로는 14개 이하로 줄이기도 하나 노이즈 마진을 희생한다.)
⚡ 전력과 지연 — 래치가 이론상 유리한 영역
🟢 전력(Power) 관점
• 래치는 트랜지스터와 내부 스위칭 노드가 적어 동적 전력(Dynamic Power)과 누설 전류(Leakage)에서 효율적이다.
• 플립플롭은 면적이 클 뿐 아니라 클럭 핀의 입력 정전용량(Capacitance)이 크다. 수백만 개의 FF로 구성된 ASIC에서는 클럭 분배망(Clock Tree)에서만 칩 전체 전력의 상당 부분이 소모된다. 역설적으로 이 문제를 풀기 위해 다시 래치가 동원된다(후술하는 클럭 게이팅).
💼 지연(Delay) 관점
• 래치는 투과 모드에서 입력이 곧장 출력으로 빠지므로 D-to-Q 지연이 짧다. 이 성질을 이용하면 느린 조합 로직이 다음 단의 시간을 빌려 쓰는 타임 보로잉(Time Borrowing, Cycle Stealing) 설계가 가능하다.
• 플립플롭은 엣지 전 입력이 안정되어야 하는 셋업 타임(Setup)과 엣지 후 출력까지의 클럭-대-출력 지연(Clock-to-Q)을 반드시 수반해, 타이밍 마진이 상대적으로 빡빡하다.
📡 파형으로 보는 데이터 전환 타이밍
아래 파형은 동일한 D/CLK 입력에 대해 레벨 민감 래치와 엣지 민감 FF가 언제 출력을 바꾸는지를 대비시킨다.
📊 다이어그램 요약: 래치(Latch)는 CLK이 High인 동안 D가 바뀌는 즉시 출력이 따라가 글리치까지 새어 나가지만, 플립플롭(FF)은 CLK이 Low→High로 오르는 엣지 순간의 D 값만 포착하고 나머지 구간의 요동에는 전혀 흔들리지 않는다.
• Latch: CLK이 High인 동안에는 D가 바뀌는 즉시 출력이 따라간다(투과). High 구간 중 입력의 요동이 그대로 새어 나가는 것이 보인다. 하강도 그 순간 CLK이 High면 엣지를 기다리지 않고 즉시 따라 내려가므로, 이 파형에서 Latch는 High 구간 내내 D와 동일하게 움직인다(레벨이 Low로 반전되면 직전 값을 유지).
• FF: 오직 CLK이 Low→High로 오르는 엣지 순간의 D 값만 포착하고, 그 외 구간의 데이터 글리치에는 전혀 흔들리지 않는다. 이 “방파제” 특성이 동기식 설계의 안정성을 만든다.
🚫 왜 래치를 그토록 엄격하게 통제하는가
래치가 면적·전력·속도에서 이론상 유리함에도, 현대 EDA 설계 방법론은 래치 사용을 강하게 금지하거나 극소수로 제한한다. 구조적 이유는 셋이다.
🔴 1. 정적 타이밍 분석(STA)의 폭증하는 복잡성
플립플롭은 클럭 엣지라는 명확한 시간 장벽을 제공해 레지스터 간 경로 분석을 단순하게 만든다. 반면 래치는 클럭이 열린 반(半) 주기 동안 데이터가 다음 단으로 계속 흘러갈 수 있어, 경로가 여러 사이클에 걸쳐 얽힌다. 수백만 게이트 칩에서 타이밍 클로저를 사실상 불가능에 가깝게 만들고 연산 자원을 기하급수적으로 소모시킨다.
🔴 2. 글리치(Glitch) 전파
조합 로직을 지난 신호는 게이트 지연 차이로 짧은 펄스(글리치)를 만든다. 투과 상태의 래치는 이를 출력으로 그대로 흘려보내 하류 로직을 오작동시킨다. FF는 글리치가 엣지 순간과 겹치지 않는 한 무시한다.
🔴 3. 테스트 용이성(DFT) 제약
양산 결함을 잡는 스캔 체인(Scan Chain)은 내부 레지스터를 직렬로 엮는다. 일반 FF는 손쉽게 Scan FF로 바꿀 수 있으나, 래치를 스캔에 엮으면 구조가 복잡해지고 고장 검출률(Fault Coverage)이 크게 떨어진다.
여기에 더해, 설계자가 의도하지 않았는데 합성 과정에서 래치가 추론(Inference)되는 사고가 빈번하다. if에 else가 없거나 case에 빠진 분기가 있으면, 툴은 “그 조건에서는 이전 값을 유지해야 한다”고 해석해 래치를 만들어버린다. 이 의도치 않은 래치(Unintentional Latch)가 래치를 더욱 경계하게 만드는 실무적 이유다.
🔁 다이어그램 요약: 조합 always 블록에서 모든 분기에 값을 대입하면 정상 조합 논리로 합성되지만, 한 경로라도 값을 안 주면 합성 툴이 “이전 값을 유지”로 해석해 의도치 않은 래치를 만들어 버린다 — 갈림길은 “분기 완전성” 하나다.
📜 IEEE 1800-2017과 Cliff Cummings의 가이드라인
IEEE Std 1800-2017(SystemVerilog) 은 범용 always 블록의 모호함을 없애려고 설계 의도를 못 박는 전용 블록을 도입했다.
| 전용 블록 | 의미와 강제 규칙 |
|---|---|
always_ff |
순차 논리 전용. 감지 목록에 클럭 엣지 같은 이벤트 제어가 반드시 하나 이상 있어야 하고, 블로킹 지연(#10)은 금지된다. 순차 논리로 합성될 수 없는 코드면 툴이 에러/경고를 낸다. |
always_latch |
래치를 의도적으로 설계할 때 사용. 감지 목록은 always_comb처럼 자동 추론하되, 코드가 래치 동작을 나타내지 않으면 경고한다. 즉 의도한 래치가 제대로 만들어졌는지를 툴이 검증해 준다. |
출처: IEEE Std 1800-2017; Verification Academy, “SystemVerilog Procedural Blocks”
합성 분야 권위자 Cliff Cummings(Sunburst Design) 의 SNUG 논문 가이드라인은 다음을 강조한다(출처: Sunburst Design, SNUG Papers).
✓ 의도의 명시화: 범용 always 대신 always_ff/always_comb/always_latch를 써서 시뮬레이터와 합성 툴 양쪽에 동일한 의도를 전달하라.
✓ 합성 지시어 배척: 래치 추론을 제어하려고 // synthesis full_case·parallel_case 같은 프라그마를 쓰는 것을 “Evil Twins”(악마의 쌍둥이)라 부르며 강력히 금지한다. 이 지시어는 합성 툴에만 영향을 주고 시뮬레이터는 무시하므로 시뮬레이션-합성 불일치(Mismatch)라는 치명적 버그를 부른다. SystemVerilog 전용 블록을 쓰면 양쪽이 같은 시맨틱 규칙을 받아 불일치가 원천 차단된다.
✓ 의도적 래치의 격리: 클럭 게이팅처럼 래치가 꼭 필요하면 일반 always에 숨기지 말고 반드시 always_latch로 명시해 툴과 동료에게 “이건 의도된 래치”임을 알려라.
💻 올바른 SystemVerilog 코딩 (IEEE 1800 기반)
아래 세 패턴은 각각 플립플롭의 정석, 가장 위험한 안티패턴, 의도적 래치의 올바른 명시를 보여준다.
// 1) 플립플롭의 정석 — always_ff는 이 블록을 오직 FF로만 합성하도록 강제한다.
// 래치/조합으로 유추될 여지가 생기면 즉시 에러를 낸다.
always_ff @(posedge clk or negedge rst_n) begin
if (!rst_n)
q_ff <= 1'b0;
else
q_ff <= d;
end
// 2) 의도치 않은 래치 (매우 위험한 Bad Practice)
// 조합 블록에서 분기가 완전하지 않으면 래치가 추론된다.
always_comb begin
if (enable)
bad_q = d;
// [위험] else가 없어 enable==0일 때 값을 '유지'해야 하므로 Latch 추론
end
// 3) 의도적인 래치 — 반드시 always_latch로 명시한다.
always_latch begin
if (enable)
latch_q <= d;
// ↑ 래치도 FF처럼 상태를 유지하는 '순차' 소자라 non-blocking(<=)이 정석.
// 조합(always_comb)만 blocking(=); always_ff·always_latch는 non-blocking으로 통일해야
// 래치 출력을 동시에 읽는 블록과의 시뮬레이션 race(= sim-synth 불일치)를 막는다.
end
🧠 래치를 막는 단 하나의 규칙: 조합 블록에서 모든 분기에 기본값을 주거나(else/default 채우기), 블록 첫머리에서 출력에 기본값을 먼저 대입하면 어떤 경로에서도 “유지”가 강제되지 않아 래치가 추론되지 않는다. 이것이 실무에서 가장 자주 쓰이는 방어 코딩이다.
🎯 결론: 어디에 무엇을 쓰는가
🟢 플립플롭 — 설계의 99% 이상
모든 동기식 데이터패스, 제어 로직, 파이프라인 레지스터의 기본 골격이다. PPA(전력·성능·면적) 페널티가 있지만, 이를 압도하는 타이밍 검증 자동화·설계 안정성·양산 테스트 용이성을 제공한다.
🟡 래치 — 특수 목적 한정
• 클럭 게이팅 셀(ICG, Integrated Clock Gating): 동적 전력을 줄이려 블록 클럭을 끌 때, 클럭 라인에 글리치가 끼지 않도록 래치+AND 게이트로 구성한 검증된 표준 셀 내부에서만 사용한다. 현대 ASIC에서 가장 안전한 래치 활용법이다.
• 극저전력/초소형 커스텀 데이터패스, SRAM 인터페이스 등 타이밍을 수동으로 완벽히 통제할 수 있는 영역.
요컨대 래치 vs 플립플롭의 선택은 트랜지스터 레벨의 “면적·전력 이점”과 칩 전체의 “검증 가능성·안정성” 사이의 거대한 트레이드오프다. 래치는 작고 빠르고 적게 먹지만 타이밍 클로저·글리치 제어·양산 테스트의 복잡도를 감당 불가 수준으로 키운다. 그래서 실무의 황금률은 두 문장으로 요약된다.
🏆 실무의 황금률
① RTL에서 래치를 직접 코딩하지 말고, 꼭 필요하면 파운드리가 검증한 ICG 표준 셀을 통해 우회하라.
② always_ff/always_comb/always_latch 규약을 엄격히 지켜 의도를 컴파일러에 명확히 전달하라.
본 콘텐츠는 디지털 IP 설계 일반론과 공개된 산업 표준(IEEE Std 1800-2017) 및 합성 가이드라인을 정리한 기술 참고 자료로, 특정 EDA 툴·공정·라이브러리의 동작을 보장하지 않습니다. 실제 설계 적용 시에는 사용 중인 합성 툴의 매뉴얼과 표준 셀 라이브러리 문서를 반드시 확인하시기 바랍니다.
본 글은 공개된 데이터와 출처를 바탕으로 작성했습니다. 최종 업데이트: 2026-06-17