반도체 Tape-out 후 가장 괴로운 버그 중 하나는 이런 형태다.
Function simulation도 완벽, Silicon Bring-up에서도 대부분 정상, 그런데 “가끔” 비정상 동작을 한다. 교수님 앞에서 재현하려고 하면, 또 잘 동작한다.... 재현성이 낮아 디버그 로그도 희미하다. 이때 끝까지 파고들면 종종 같은 결론으로 모인다.
- “어딘가에서 Timing이 깨졌다.”
- 그 “어딘가”가 Clock/Reset 같은 global control인 경우가 많다.
- 특히 Clock을 MUX로 바꾸는 지점에서 아주 얇은 pulse(Glitch) 가 튀었다.
Clock path에서의 Glitch는 data glitch와 급이 다르다. data 경로의 glitch는 대개 combinational logic 안에서 소모된다.
반면 clock glitch는 플립플롭에게 “추가 clock edge” 로 인식될 수 있고, 그 순간부터는 한 번의 비정상 edge가 시스템 상태 전체를 뒤틀 수 있다. 그래서 등장하는 단골 해법이 Glitch-Free Clock MUX(GFCM) 다.
1) 일반 Multiplexer (MUX)에서 Glitch가 생기는 이유
가장 단순한 2:1 MUX의 논리식은 깔끔하다.
out = (~S & A) | (S & B)RTL에서는 sel이 0→1로 바뀌면 곧바로 A에서 B로 바뀌는 것처럼 보인다.
게이트 레벨에서는 얘기가 달라진다.
- (~S & A) 경로와 (S & B) 경로는 서로 다른 cell delay / wire delay 를 가진다.
- S의 signal propagation이 두 경로에 동시에 도착하지 않는다.
- 그 짧은 틈에 OR 입력 조합이 잠깐 바뀌면서 잠시 동안 신호 switching이 발생한다. (static hazard / dynamic hazard)
Clock MUX에서는 A, B가 보통 asynchronous clocks 다. A와 B의 위상 관계가 고정되어 있지 않으니, sel 전이가 “나쁜 순간”에 걸릴 확률은 생각보다 높다. 결과적으로 “가끔” 실패하는 실리콘 버그가 된다.
2) Clock Glitch가 꼭 필요한 이유
- Pulse width가 짧아도 FF가 clock으로 인식할 수 있다
클럭 트리의 slew/threshold, 라이브러리 FF의 internal pulse filtering에 따라 “원치 않는 edge”가 유효하게 들어갈 수 있다. - Setup/Hold를 동시에 망가뜨리기 쉽다
정상 edge 직전에 Glitch가 붙으면 hold가 깨지고, 직후에 붙으면 setup이 깨진다. 어느 쪽이든 결과는 random하다. - DVFS/Fail-over/Power domain 시대엔 Clock switching이 일상이다.
3) Glitch-Free의 핵심 정의: “Glitch 0”이 아니라 “전이 조건을 봉인”
Glitch-Free Clock MUX의 핵심은 간단하다.
출력 clock을 바꾸는 동안에는 어떤 clock edge도 통과시키지 않는다.
Select signal(Enable)은 clock의 안정 구간에서만 바뀐다.
여기서 중요한 인사이트 하나:
GFCM은 “매끄럽게 이어붙이는 회로”가 아니라 일시 정지(pause)를 이용하는 회로인 경우가 많다.
즉, Glitch-Free의 대가로 cycle이 한두 개 사라질 수 있다. 이게 설계 스펙으로 명시되어야 한다. “끊김 없는” switching이 목표면 MUX만 바꿔서는 안 되고, PLL/clocking architecture 레벨에서 접근이 필요하다.
4) 가장 널리 쓰이는 구조(정석): “Mutual-Exclusion + Safe-Window Update”
Glitch가 이전 clock이랑 완전 가까이 붙어 있으면, Timing violation이 일어나게 됩니다.
그래서 이런 Glitch가 안 나도록, 잠깐 clock toggle을 잠시 하지 않는 로직이 필요합니다.
앞부분과 뒷 부분을 보면 MUX랑 같은 구조인데,
- 내부에 2단 Synchronizer 있고,
- SELECT signal 바뀔 때에 반대쪽 clock에 동기화시키는 feedback loop가 있습니다.
결국 아래와 같은 기능을 합니다.
- enable1과 enable2는 동시에 1이 되지 않는다 (mutual exclusion)
- 한쪽을 끄고 난 뒤에 다른 쪽을 켠다 (break-before-make)
전환 구간에 clock을 잠깐 막고, 안전 구간에서만 다른 쪽을 연다.
이 “멈춤”이 바로 Glitch-Free의 비용이자 안정성이다.
Electronicspedia 채널에 Glitch에 대한 아주 좋은 예시가 있어서 첨부했다.
5) 파형으로 보는 “Glitch vs Glitch-Free” (핵심만)
(1) naive MUX (Glitch 발생 가능)
그림에 설명된 것 처럼,
Sel이 0일 때에는 CLK1을 출력하다가,
Sel이 1일 때에는 CLK2를 출력합니다.
CLK Out의 점선 부분처럼 튀어나온, Designer가 원치 않았던 clock toggle을 glitch라고 부릅니다.
6) SDC와 CDC 분석에서는?
Clock MUX 출력은 “CLK1이기도 하고 CLK2이기도” 하다. 그래서 output pin에 대해 generated clock을 2개 겹쳐 정의하는 패턴이 흔하다. 그리고 두 generated clock이 동시에 활성일 수 없음을 exclusive로 알려준다.
- GFCM 내부의 sync FF는 CDC 성격이다. 그래서 CDC tool(SpyGlass-CDC 등)로 기능적 안전성을 별도로 확인한다.
7) CTS/PnR 인사이트: GFCM은 “논리 블록”이 아니라 “Clock Root 장치”
GFCM은 placement 하나로 품질이 갈린다. 현대 노드(advanced node)에서 특히 그렇다.
- 가능한 Clock source(PLL/OSC) 가까이: MUX 앞뒤로 clock net이 길어지면 SI/EM/IR-drop 영향이 커지고 skew 관리 난이도가 높아진다.
- Select/control은 data가 아니라 control: fanout이 커지면 glitch-free 구조가 “전환 지연”을 키운다. 이런 경로에 set_case_analysis를 줬다가 Gate level simulation에서 엄청나게 큰 Violation 발견되는 경우가 있다. 여기도 constraint 걸릴 수 있도록 관리가 필요하다.
- CTS와의 역할 분리: GFCM의 출력 이후가 진짜 clock tree다.
- Duty cycle / pulse integrity: 단순 AND/OR gating은 duty 왜곡을 만들 수 있다. 그냥 RTL으로 GFCM를 만들기보다는 Foundry-qualified cell을 선호한다.
한 줄로 요약하면:
GFCM은 clocking architecture의 일부로 취급해야 하고, PnR에서 “보호 대상”이다.
8) DFx(Scan/ATPG/Bring-up) 관점: GFCM은 “테스트의 문”이다
Scan에서는 보통 shift clock과 capture clock 요구가 다르고, at-speed test는 더 까다롭다. 여기서 GFCM이 잘못 설계되면 DFx가 이렇게 망가진다.
- test mode에서 clock switching이 허용되지 않아 scan이 멈춘다
- capture 구간에서 pause가 생겨 pattern이 깨진다
- reset/test_en 전환 시 glitch가 생겨 오동작한다
그래서 실무 패턴은 대개 이렇다.
- test_en으로 test_clk를 직접 bypass (위 RTL처럼)
- 또는 scan 전용 clock mux를 별도로 두고, function clock mux와 분리
이런 Glitch Free Clock Mux만 만드는 전문가들도 있다!
Glitch-Free Clock MUX를 “glitch 안 나는 mux”라고만 설명하면 너무 얇다.
현대 SoC에서 GFCM은 DVFS/Fail-over/Power domain/DFx를 관통하는 clocking infrastructure다.
이 작은 블록이 설계의 성숙도를 드러낸다.
- 학생 설계는 “RTL이 맞는가”를 본다.
- 주니어 설계는 “STA가 통과하는가”를 본다.
- 시니어 설계는 “양산 가능한가”를 본다.