[CDC] 1_Single bit CDC: 2-FF Synchronizer

 

2-FF Synchronizer

 

CDC를 할 때, Single Bit냐 Multi Bit냐에 따라 방법이 달라진다.

 

Single Bit 신호를 클락 도메인 간에 안전하게 전달하는 가장 일반적이고 기본적인 방법은 2-Flip-Flop Synchronizer를 사용하는 것이다.

 

 

 

이 방법은 수신 측 클럭 도메인에서 동작하는 두 개의 FF을 직렬로 연결하여 사용한다.

1. 첫 번째 플립플롭 (FF1): 송신 클럭 도메인의 데이터 신호를 수신 클럭의 첫 번째 엣지에서 포착하려고 시도한다.
   • 여기서 메타안정성이 발생할 수 있다. 데이터가 수신 클럭의 Setup/Hold 시간 창 내에서 변경되면 FF1의 출력(Q1)은 불안정한 상태에 빠진다.
   • Q1이 불안정한 상태에 있더라도, 대부분의 경우 하나의 수신 클럭 주기 내에는 안정적인 '0' 또는 '1' 값으로 정착된다.
2. 두 번째 플립플롭 (FF2): FF1의 출력(Q1)이 안정화된 후에, 수신 클럭의 다음 엣지에서 이 값을 포착한다.
   • FF1의 출력이 FF2의 Setup/Hold 시간을 위반할 확률은 극도로 낮다.
   • 따라서 FF2의 출력(Q2)은 안정적이고 동기화된 신호가 된다.

 

SystemVerilog Code

// source domain flop
always_ff @(posedge clk_src) begin
  src_reg <= async_in;
end

// destination domain 2-FF synchronizer
always_ff @(posedge clk_dst) begin
  ff1 <= src_reg;
  ff2 <= ff1;
end

assign sync_out = ff2;

 

2-FF Synchronizer Code이다.

 

 

MTBF(Mean Time Between Failures)

 

MTBF는 평균 고장 간격을 말한다. 이는 시스템이 평균적으로 얼마나 오래 버그 없이 동작할 수 있는지를 나타내는 값을 의미한다. CDC에서 2-FF Synchronizer를 사용하는 주된 목적은 시스템의 MTBF를 증가시키는 것이다.

 

CDC에서는 메타스테이블 상태를 완전히 제거할 수 없다. 하지만 2-FF Synchronizer를 사용하면 첫 번째 FF에서 생긴 메타스테이블이 충분한 시간 동안 안정화되도록 기다려줄 수 있다.

 

• MTBF = 100 년 → 평균적으로 100년에 한 번 CDC failure가 발생한다고 보는 것
• MTBF = 10⁹ 시간 → 사실상 “영원히” 안 난다고 봐도 되는 수준
• CDC 설계의 목표는 보통 MTBF를 시스템의 전체 수명(10년 이상) 보다 훨씬 큰 값으로 만드는 것.

즉, MTPF는 Metastability가 실제 시스템에서 얼마나 드물게 발생하는지를 나타내는 지표가 된다.

 

 

항	의미
F_data	송신 신호가 변화하는 빈도. 많이 바뀔수록 실패 확률이 올라감
F_clk	수신 클럭 도메인 클럭 주파수. 동기화 샘플링이 자주 일어남으로 실패 확률이 올라감.
T_res	해결 시간 (Resolution Time) → 메타스테이블 상태에서 안정화될 수 있는 시간. FF2가 샘플링하기 전까지 기다릴 수 있는 시간. 즉 FF1이 안정화될 수 있는 시간적 여유.
τ(tau)	공정(Process) 고유의 시간 상수

 

 

 

MTBF는 해결 시간 T_res​가 조금만 증가해도 지수적으로 증가한다.

 

 

 

빨간색 원으로 표시된 영역이 FF의 해결 시간(T_res)을 나타낸다. FF 출력이 유효한 논리 상태('0' 또는 '1') 중 하나에 도달하는 데 걸리는 시간 또는 Metastability 출력의 지속 시간이다.

 

대부분의 경우 2개의 FF으로 해결되지만, FPGA 설계나 최신 공정을 사용하는 경우 더 3-FF, 4-FF로 늘어날 수도 있다.

 

 

2-FF Synchronizer 사용 시 주의할 점

1. CDC 경계에 조합논리를 두지 말 것

 

 

조합논리는 글리치를 만들 수 있다. 이 글리치가 수신 클럭 도메인에서 샘플링되면 치명적인 오동작 발생할 수 있다. 글리치가 낀 a 신호를 2-FF Capture를 했는데 수신 클럭의 bdata가 원치 않는 결과가 나온다.

 

 

 

2. Synchronizer(2FF, 3FF 등) 내부에도 조합논리를 넣지 말 것

 

 

 

FF 사이에 조합논리를 넣으면 메타스테이블 상태의 resolution time이 줄어든다. 즉, MTBF가 낮아져서 훨씬 위험해진다. 반드시 FF1 → FF2 → FF3 구조는 직결 배선이어야한다.

3. 빠른 클럭 → 느린 클럭으로 보내는 신호는 그냥 동기화만 하면 안 됨

빠른 클럭 도메인에서 만든 신호는 짧은 시간 동안만 1이 되었다가 0으로 돌아갈 수 있다. Level Signal은 괜찮을 수 있으나 특히 Pulse Signal이 위험하다. 

 

그런데, 그 상황에서 느린 클럭 도메인은 그 짧은 순간을 샘플링하지 못하고 그냥 지나쳐버릴 수 있다. 그래서 단순히 2-FF synchronizer만 붙이면 데이터 자체가 사라지는 문제를 못 막는다.

 

해결 방법은 여러 가지가 있지만 2가지만 정리한다.

 

 

Pulse Stretching (Open-loop 방식) 

 

1. 빠른 도메인에서 펄스를 강제로 충분히 길게 늘리는 방식
   • 보통 느린 도메인 2~3 클럭 이상으로 설정
   • 그래야 느린 도메인이 최소 1번은 반드시 샘플링할 수 있음
2. 단점
   • 클럭 비율이 고정되어야 하고
   • 설계가 바뀌면 다시 계산해야 해서 안전성이 떨어짐

 

 

 

 

Handshake (Closed-Loop 방식)

 

 

1. REQ → sync → ACK → sync 구조
   • 느린 클럭이 신호를 받았다는 확인 신호(ACK)를 빠른 클럭에게 돌려줌
   • 빠른 도메인은 ACK를 받기 전까지 REQ를 내리지 않음
   • 절대 신호를 놓칠 수 없고, 클럭 비율과 무관하게 항상 안전함
2. 단점
   • 왕복 지연이 생기므로 Latency가 증가

위 자료엔 생략이 많이 되어서 추가 설명이 필요할 것 같다.

 

Handshake 방식에서는 Fast domain에서 발생한 짧은 펄스를 즉시 사용하지 않고, 먼저 레벨 신호(REQ)로 변환하여 hold해 둔다. Slow domain은 2-FF synchronizer를 통해 안정적으로 REQ_sync를 수신하고, 이를 감지하면 ACK을 Fast domain으로 반환한다. Fast domain은 ACK_sync를 받을 때까지 REQ를 절대 내리지 않기 때문에, Slow domain이 펄스를 놓칠 위험이 없다. ACK_sync를 확인한 뒤 Fast domain은 REQ를 0으로 내리고, 전체 handshake cycle이 종료된다.

 

이 방식은 클럭 비율과 무관하며, 신호 손실이 절대 발생하지 않는 가장 안전한 single-bit CDC 방식이다. 단, REQ ↔ ACK 왕복 지연으로 인해 latency가 증가한다.

 

 

N-FF Synchronizer 사용 이유

CDC의 핵심 목표를 다시 상기해보자.

 

1. Metastability의 격리
2. 신호/데이터 전달의 무결성 보장

이 중 N-FF Synchronizer가 담당하는 역할은 “Metastability 격리”이다.

 

 

 

 

1) 메타안정성 전파 방지

Metastability는 0과 1 사이의 불안정한 상태로, 이 상태가 후단 로직까지 전달되면 예측 불가능한 시스템 오류를 일으킨다.

N-FF Synchronizer는 원래 값이 1인데 0으로 잘못 잡힐 수 있는 위험을 감수하더라도 메타 상태가 다음 단계로 넘어가지 않도록 막는 것이 핵심이다.

 

즉, 매우 낮은 확률로 잘못된 값일 수는 있지만, 최소한 메타 상태는 아니다.

 

메타 상태 전파는 치명적인 시스템 오류이고, 잘못된 값이 넘어가는 것은 기능 오류이다. 둘은 완전히 다른 레벨의 위험도를 가진다. 잘못된 0/1 값은 최악의 경우 버그지만, 메타 상태는 칩을 날려버리는 물리적 오류다.

 

2) 모든 CDC를 고급 CDC로 처리할 필요는 없음

Handshake, FIFO 같은 고급 CDC는 추가 FF, FSM/제어회로, 더 큰 면적, 더 높은 전력, 더 긴 latency를 요구하므로 모든 CDC에 쓰기 비효율적이다.

 

적재적소에 필요한 곳에서만 사용해야 한다.

 

3) Single Bit 제어 신호에는 N-FF로 충분

enable, flag 같은 level 기반 single bit 신호는 신호 변화가 느리고, 1~2 클럭 지연은 기능에 문제가 없으며 한 번 놓쳐도 다음 사이클에서 다시 잡히기 때문에 N-FF만으로도 충분한 안정성을 제공한다.

 

4) 반대로, 데이터 무결성이 필요한 경우에는 다른 CDC 기법 사용

 

N-FF는 single bit 제어 신호에는 괜찮지만 데이터, 주소, multi-bit 값에는 사용할 수 없다. multi-bit는 비트 간 타이밍(skew)이 달라 중간 쓰레기 값이 잡혀서 복구가 불가능하다. 게다가, pulse 신호는 아예 사라질 수도 있다. 이런 경우는 반드시 Handshake, Toggle sync, Async FIFO 등을 사용해야 한다.

 

정리하면, N-FF는 불완전하지만, 적절한 곳에서는 가장 효율적이고 충분한 CDC 기법이다.

 

가장 중요한 것은 다음 기준을 판단하는 것이다.

• 언제 N-FF로 충분한가? (단일 비트 level control 신호)
• 언제 고급 CDC가 반드시 필요한가? (multi-bit, pulse, fast → slow freuqency, 데이터 등)

이 판단이 CDC 설계의 핵심이다.

 

 

Reference

https://www.agnisys.com/blog/automatic-handling-of-register-clock-domain-crossings/

Automatic Handling of Register Clock Domain Crossings - Agnisys, Inc.

https://funrtl.wordpress.com/2018/12/12/cdc-clock-domain-crossing/

CDC (Clock Domain Crossing)