Synchronizer MTBF 계산기

비동기 입력을 받는 synchronizer가 얼마나 자주 실패하는지를 평균 고장 간격(MTBF, mean time between failures)으로 계산합니다. 받는 쪽 clock 주파수, 데이터가 바뀌는 빈도, FF(flip-flop)의 metastability 특성을 넣으면 FF 단수별 MTBF와 칩 전체, 제품 전체의 고장 간격이 함께 나옵니다.

clock과 데이터

synchronizer FF가 도는 clock입니다

FF 특성

resolution time constant

metastability window

앞 FF의 clk-to-Q 지연

다음 FF의 setup time

배선 지연과 남겨 둘 여유

tco, tsu, 여유를 0으로 두면 Ginosar의 예처럼 clock 한 주기를 모두 settle 시간으로 씁니다. 실제 설계에서는 라이브러리 timing 값을 넣습니다.

개수와 사용 기간

같은 조건으로 도는 synchronizer 수

fleet 전체 고장 간격을 볼 때

이 기간 안에 고장 날 확률을 계산합니다

synchronizer 1개 MTBF
–
초 단위
–
칩 전체
–
제품 전체
–
사용 기간 안에 칩 1개가 고장 날 확률
–
사용 기간 안에 제품 전체에서 고장 날 확률
–

계산 과정

clock 주기 Tclk
–
단 하나의 settle 시간 (Tclk − tco − tsu − 여유)
–
총 resolution time S
–
S ÷ τ
–
초당 metastable 진입 횟수 (T0 × fc × fd)
–
단을 하나 늘릴 때 MTBF 배수
–

같은 조건에서 단수만 바꾼 비교

파란 줄이 위에서 고른 단수입니다. 1년은 365.25일로 계산합니다.

setup/hold 창 안에서 입력이 바뀌면 FF는 0도 1도 아닌 상태에 머문다

FF 안의 latch는 inverter 두 개가 서로의 출력을 붙잡는 구조입니다. clock edge가 latch를 닫는 순간 입력이 바뀌고 있었다면, 두 node는 0과 1의 중간 근처에서 출발합니다. 이 상태가 metastability입니다. 두 node의 전압 차이는 시간이 지나며 지수적으로 커져 결국 한쪽으로 정해지지만, 출발점이 균형점에 가까울수록 오래 걸립니다.

출발 전압이 얼마인지는 clock이 입력을 끊은 정확한 순간과 그때의 noise에 달려 있습니다. 둘 다 미리 알 수 없으니 언제 정해질지도 확률로만 말할 수 있습니다. Ginosar는 latch가 0 시점에 metastable이었다면 t가 지난 뒤에도 그 상태로 남아 있을 확률을 e−t/τ로 적습니다.

비동기 입력은 받는 clock과 관계없이 바뀌므로 이 일을 아예 막을 방법은 없습니다. 할 수 있는 일은 metastable 상태가 logic으로 퍼지기 전에 풀릴 시간을 주는 것이고, FF를 직렬로 이은 synchronizer가 그 시간을 벌어 줍니다. 시간을 얼마나 줘야 실패가 충분히 드물어지는지를 MTBF로 따집니다.

2단을 습관처럼 넣어도 되는지 확인해야 하는 경우

2-FF synchronizer는 대개 따져 보지 않고 넣습니다. 계산이 필요해지는 것은 clock이 빠른 block, 공급 전압을 크게 낮추는 저전력 mode, 온도가 극단으로 가는 제품입니다. Ginosar의 저전압·고온 예는 데이터가 1 kHz로 드물게 바뀐다고 잡았는데도, 2단 MTBF를 약 1분으로 적었습니다.

Cummings는 아주 빠른 설계에서는 2단 MTBF가 너무 짧아 셋째 FF를 더하고, 얼마면 충분한지는 설계자가 정한다고 씁니다. 칩 하나에 synchronizer가 수천 개 들어가면 고장 간격은 그 수만큼 줄어듭니다. 이전 칩에서 쓰던 synchronizer를 더 빠른 clock이나 다른 공정으로 옮길 때도 같은 계산을 다시 해야 합니다.

τ와 T0는 FF가 얼마나 빨리 정해지고 얼마나 쉽게 걸리는지를 나타낸다

metastable 상태의 latch는 선형 영역에서 서로를 증폭하는 inverter 두 개로 볼 수 있습니다. Ginosar의 small-signal 모델에서 두 node의 전압 차이는 V = K·et/τ로 커지고, τ는 대략 node capacitance를 inverter의 gm으로 나눈 값입니다. node에 걸린 부하가 크거나 gain이 낮으면 τ가 커져 정해지는 데 오래 걸립니다. Golson도 첫 FF 출력 net에 부하가 많이 걸리면 resolution time이 줄어 MTBF가 나빠진다고 경고합니다.

T0는 문헌에 따라 TW로도 씁니다. clock의 sampling edge 주변의 짧은 구간으로, 데이터가 그 안에서 바뀌면 FF가 metastable에 들어갈 수 있습니다. setup/hold 창과 닮았지만 Golson에 따르면 라이브러리의 최소 setup time과 hold time을 더한 값보다 훨씬 좁습니다.

두 값은 cell library 문서에 거의 나오지 않습니다. Golson은 test chip을 측정하거나 transistor netlist로 SPICE를 돌려 뽑으라고 권합니다. 그가 65nm 단순 D FF를 typical 조건에서 시뮬레이션한 결과는 τ 44ps였고, T0는 master latch만 보면 60ps, clk와 Q pin 사이에서 재면 350ps였습니다. Ginosar는 28nm 고성능 공정을 가정해 τ 10ps, TW 20ps를 쓰면서, 경험상 두 값이 그 공정의 typical gate delay에 가깝다고 적습니다.

τ는 고정된 값이 아닙니다. Ginosar는 공정 편차만으로도 τ가 시뮬레이션보다 몇 배 커질 수 있고, 낮은 공급 전압이나 아주 높거나 낮은 온도에서는 몇 자릿수까지 커진다고 씁니다. 계산기에 넣을 τ는 제품이 실제로 도는 가장 나쁜 corner의 값이어야 합니다.

공정이 미세해지면 τ도 줄어들 거라고 기대하기 쉽습니다. Golson은 Beer 등의 측정을 인용해, 65nm 무렵부터 τ가 gate delay만큼 줄지 않고 오히려 나빠지는 경향을 보인다고 씁니다.

MTBF 식은 metastable에 들어갈 확률과 빠져나오지 못할 확률의 곱이다

데이터가 clock 한 주기 안 아무 때나 같은 확률로 바뀐다고 하면, 한 번 바뀔 때 그 순간이 T0 안에 들어갈 확률은 T0 ÷ Tclk, 곧 T0 × fc입니다. 데이터가 초당 fd번 바뀌니 FF는 초당 T0 × fc × fd번 metastable에 들어갑니다. Ginosar의 예처럼 fc 1 GHz, fd 100 MHz, T0 20ps면 초당 200만 번, 500주기에 한 번꼴입니다.

metastable에 들어간 FF가 S만큼 지난 뒤에도 풀리지 않았을 확률은 e−S/τ입니다. 두 사건은 서로 독립이라 초당 고장 횟수는 둘의 곱이고, MTBF는 그 역수입니다.

초당 진입 횟수 R = T0 × fc × fd 초당 고장 횟수 = T0 × fc × fd × e^(−S/τ) MTBF = e^(S/τ) ÷ (T0 × fc × fd)

S = metastable 상태가 풀리는 데 쓸 수 있는 시간(resolution time), τ = resolution time constant, T0 = metastability window, fc = 받는 쪽 clock 주파수, fd = 데이터가 초당 바뀌는 횟수

식에서 S만 지수 안에 있습니다. fc나 fd를 10배 바꾸면 MTBF도 10배 바뀌는 데 그치지만, S를 τ의 2.3배만 늘려도 MTBF가 10배가 됩니다. τ가 10ps라면 23ps입니다.

S는 clock 주기에서 clk-to-Q, setup, 배선 지연을 빼고 단 수만큼 더한 시간이다

2-FF synchronizer에서 첫 FF가 metastable에 빠지면, 둘째 FF가 다음 edge에서 그 출력을 받기 전까지가 정해질 시간입니다. 한 주기를 다 쓰지는 못합니다. 첫 FF 출력은 clk-to-Q 뒤에야 나오고, 둘째 FF는 setup time 전에 값을 받아야 하며, 그 사이 배선도 시간을 씁니다. Ginosar는 이것을 S = TC − tpCQ(FF1) − tSETUP(FF2) − tPD(wire)로 씁니다.

FF를 하나 더 붙이면, 둘째 FF가 metastable에 빠지더라도 셋째 FF가 받기 전까지 한 주기를 더 기다립니다. Golson은 다단 synchronizer의 실패 확률을 단마다 아직 metastable일 확률의 곱으로 쓰고, 단의 특성이 같다면 resolution time이 단 수만큼 더해진다고 봅니다. Ginosar의 예도 FF 3개는 두 주기, FF 4개는 세 주기를 S로 씁니다. 그래서 계산기는 다음 식을 씁니다.

S = (N − 1) × (T_clk − t_co − t_su − t_wire)

N = synchronizer FF 단수, T_clk = 1 ÷ fc, t_co = 앞 FF의 clk-to-Q, t_su = 다음 FF의 setup time, t_wire = 단 사이 배선 지연과 남겨 두는 여유

이 식은 모든 단의 τ와 T0가 같다고 보는 근사입니다. Golson은 다단 synchronizer를 정확히 분석하면 더 복잡하고, FF 안 latch 사이의 back edge 효과 때문에 신뢰도가 조금 낮아질 수 있다고 덧붙입니다.

배선 지연은 S에서 그대로 빠집니다. synchronizer FF를 서로 붙여 배치하고 그 사이에 logic을 넣지 않는 이유입니다. Ginosar는 이 배치를 놓쳐 예상하지 못한 실패를 낸 synchronizer가 적지 않다고 씁니다.

단을 하나 늘리면 MTBF는 eT_clk/τ배쯤 늘어난다

단 하나가 S에 더하는 시간은 Tclk − tco − tsu − twire입니다. 이 시간을 τ로 나눈 만큼 지수가 커지므로 MTBF는 e(T_clk − t_co − t_su − t_wire)/τ배가 됩니다. tco와 tsu가 주기에 비해 작으면 대략 eT_clk/τ배입니다. 결과 상자의 ‘단을 하나 늘릴 때 MTBF 배수’가 이 값입니다.

Ginosar의 저전압·고온 예가 이 효과를 보여 줍니다. fc 1 GHz, fd 1 kHz, τ 100ps, TW 200ps이고 단마다 한 주기를 온전히 쓴다고 보면, 한 단의 배수는 e10으로 약 22,000배입니다. 계산기로 돌리면 2단 110초, 3단 28.1일, 4단 1,693년이 나옵니다. Ginosar는 같은 조건을 각각 약 1분, 약 한 달, 1,000년으로 적었습니다.

τ가 clock 주기에 비해 아주 작으면 한 단만 더해도 수십 자릿수가 늘어납니다. 같은 3단이라도 typical 조건에서는 넘치게 길고 저전압 corner에서는 모자랄 수 있으니, 단수는 가장 나쁜 corner의 τ로 정해야 합니다.

fd는 데이터가 초당 바뀌는 횟수이고, 모르면 보내는 쪽 clock으로 잡는다

fd는 clock 주파수가 아니라 데이터가 바뀌는 횟수입니다. 0에서 1로, 1에서 0으로 바뀔 때마다 한 번씩 셉니다. Golson은 분모에 2·fd가 들어간 MTBF 식을 종종 볼 수 있는데, 데이터 파형을 clock처럼 보고 그 주파수를 적었기 때문이라고 설명합니다. 주파수 f인 clock 모양 신호는 초당 2f번 바뀝니다. 계산기의 fd는 바뀌는 횟수 기준이라 2를 따로 곱하지 않습니다.

값을 모르면 최악으로 잡습니다. 보내는 쪽 FF가 매 주기 값을 바꾸는 경우로, 이때 fd는 보내는 쪽 clock 주파수와 같습니다. enable이나 mode 신호처럼 가끔 바뀌는 level 신호는 실제 변화 빈도로 잡아도 됩니다. Ginosar의 첫 예는 데이터가 받는 clock 10주기에 한 번 바뀐다고 잡았고, 계산기의 ‘k주기에 한 번’ 입력이 이 방식입니다.

보내는 쪽 신호가 combinational logic을 거쳐 나오면 값이 정해지기 전에 glitch가 생겨 변화 횟수가 늘어납니다. Cummings가 CDC(clock domain crossing) 신호를 보내는 쪽 FF에서 바로 내보내라고 하는 이유 가운데 하나가 이것입니다.

fd가 fc보다 크면 데이터가 받는 쪽 한 주기 안에 두 번 이상 바뀝니다. 식으로 MTBF는 나오지만 받는 쪽은 중간 값을 놓칩니다. async FIFO의 gray code pointer처럼 놓쳐도 되는 신호가 아니라면 handshake나 FIFO로 넘겨야 하고, 계산기는 이때 경고를 함께 띄웁니다.

synchronizer 개수와 제품 대수만큼 고장 간격이 줄어든다

칩 안 synchronizer들이 서로 독립으로 실패한다고 보면 고장 횟수는 더해집니다. Golson은 칩 전체 MTBF를 각 synchronizer MTBF 역수를 모두 더한 값의 역수로 쓰고, 모두 같다면 MTBF ÷ M이 됩니다. Ginosar도 synchronizer가 1,000개인 시스템이라면 하나하나를 전체 신뢰도 목표보다 세 자릿수 이상 길게 설계하라고 권합니다.

같은 식에서 MTBF가 가장 짧은 synchronizer 하나가 전체를 좌우한다는 점도 나옵니다. 아주 좋은 synchronizer를 많이 더해도 전체 MTBF는 거의 그대로지만, 나쁜 하나는 전체를 끌어내립니다. 계산기의 M은 같은 조건으로 도는 synchronizer 수이므로, clock이나 fd가 다른 경로는 따로 계산해 고장 횟수를 더해야 합니다.

제품을 많이 팔면 같은 계산이 한 번 더 붙습니다. 칩 하나의 MTBF가 1만 년이어도 10만 대가 돌면 제품 전체에서는 평균 36.5일에 한 번 어딘가에서 고장이 납니다.

MTBF를 수명으로 읽으면 안 됩니다. 고장이 일정한 비율로 무작위로 난다고 보면, 기간 T 안에 한 번이라도 고장 날 확률은 1 − e−T/MTBF입니다. Golson이 신뢰도 목표를 설명하며 쓴 식입니다. MTBF가 10년이면 10년 안에 고장 날 확률은 63%입니다. 사용 기간을 넣으면 계산기가 칩 하나와 제품 전체에 대해 이 확률을 보여 줍니다.

칩 MTBF = MTBF ÷ M 제품 전체 MTBF = MTBF ÷ (M × K) P(기간 T 안에 고장 1회 이상) = 1 − e^(−T ÷ MTBF)

계산기는 이 순서로 계산한다

  1. clock 주기를 ps로 바꿉니다. Tclk = 1,000,000 ÷ fc(MHz)입니다.
  2. 단 하나의 settle 시간 Tclk − tco − tsu − twire를 구합니다. 0 이하이면 여기서 멈추고 결과 자리에 이유를 띄웁니다.
  3. S = (N − 1) × 앞 단계 값입니다.
  4. 초당 진입 횟수 R = T0(ps) × fc(MHz) × fd(MHz)를 구합니다. ps는 10−12초, MHz는 106이라 단위끼리 곱하면 1이 되고, 숫자를 그대로 곱한 값이 초당 횟수입니다.
  5. log10 MTBF(초) = S ÷ (τ × ln 10) − log10 R을 계산합니다.
  6. 칩 전체는 log10 M을, 제품 전체는 log10 K를 더 뺍니다.
  7. 초를 1년 31,557,600초(365.25일)로 나눠 년으로 바꿉니다. 2년이 안 되면 일로, 2일이 안 되면 시간으로, 2시간이 안 되면 분으로, 2분이 안 되면 초로 씁니다.
  8. 사용 기간 T를 넣었으면 x = T ÷ MTBF로 1 − e−x를 구합니다. x가 아주 작을 때 정밀도를 잃지 않도록 JavaScript의 Math.expm1을 씁니다.

eS/τ를 바로 계산하지 않는 이유는 숫자가 넘치기 때문입니다. JavaScript의 Number는 약 1.8 × 10308까지 담는데, ex는 x가 709.78을 넘으면 Infinity가 됩니다. τ 10ps인 FF로 4단을 쓰고 단마다 한 주기를 다 쓴다고 보면, 1 GHz에서 S ÷ τ가 300이고 200 MHz에서는 1,500입니다. 그래서 모든 계산을 log10 값으로 하고 결과를 지수 표기로 보여 줍니다.

손으로 따라 하는 예제

예제 1. Ginosar의 28nm 2단 synchronizer는 4.26 × 1029년

Ginosar 튜토리얼의 첫 예입니다. 28nm 고성능 공정, τ 10ps, TW 20ps, fc 1 GHz이고 데이터는 10주기에 한 번 바뀝니다. S는 한 주기 전체로 잡아 clk-to-Q와 setup을 빼지 않았으므로 tco, tsu, 여유를 모두 0으로 둡니다. 계산기를 처음 열었을 때의 값이 이 조건입니다.

T_clk = 1,000,000 ÷ 1000 = 1,000 ps S = (2 − 1) × 1,000 = 1,000 ps S ÷ τ = 1,000 ÷ 10 = 100 fd = 1000 MHz ÷ 10 = 100 MHz R = 20 × 1000 × 100 = 2,000,000 회/초 log10 MTBF = 100 ÷ 2.302585 − log10(2,000,000) = 43.4294 − 6.3010 = 37.1284 MTBF = 1.34 × 10^37 초 ÷ 31,557,600 = 4.26 × 10^29 년

Ginosar의 글에 적힌 값은 4 × 1029년입니다. 이 조건이면 synchronizer가 1,000개 있어도 칩 MTBF는 4.26 × 1026년이라 단을 늘릴 이유가 없습니다.

예제 2. Golson의 65nm FF를 600 MHz에서 2단으로 쓰면 33.7시간

Golson이 SNUG 2014 논문에서 계산한 예입니다. 65nm 단순 D FF를 SPICE로 돌려 얻은 τ 44ps, T0 350ps를 쓰고, fc 600 MHz, fd 125 MHz입니다. 두 FF 사이 setup과 전달 지연은 합쳐서 400ps로 잡았습니다. 계산기에는 합만 쓰이므로 tco에 400을 넣고 tsu와 여유는 0으로 둡니다. fd 입력 방식은 MHz로 바꿉니다.

T_clk = 1,000,000 ÷ 600 = 1,666.67 ps S = 1,666.67 − 400 = 1,266.67 ps S ÷ τ = 1,266.67 ÷ 44 = 28.788 R = 350 × 600 × 125 = 26,250,000 회/초 log10 MTBF = 28.788 ÷ 2.302585 − log10(26,250,000) = 12.5024 − 7.4191 = 5.0833 MTBF = 1.21 × 10^5 초 = 33.7 시간

Golson은 122 × 103초, 약 34시간으로 적었습니다. 이틀이 안 돼 고장이 나니 lab에서 바로 드러날 수준입니다.

같은 조건에서 N만 3으로 바꾸면 S가 2,533.33ps로 늘고 MTBF는 3.85 × 1017초, 1.22 × 1010년이 됩니다. 단 하나가 MTBF를 e28.788배, 약 3.18 × 1012배 늘렸습니다.

여기에 Golson이 신뢰도 목표를 설명하며 든 규모를 넣어 봅니다. 칩 하나에 synchronizer 1,000개, 제품 10만 대, 사용 기간 5년입니다. 3단이면 칩 MTBF는 1.22 × 107년이고, 10만 대 전체로는 122년에 한 번 고장이 납니다. 5년 동안 10만 대 가운데 어디서든 한 번이라도 고장 날 확률은 4.01%입니다. 2단으로 두면 칩 MTBF가 121초, 약 2분으로 떨어집니다.

이 계산기가 다루지 않는 것

조건설명
전압·온도·공정에 따른 τ 변화넣은 τ와 T0 하나로만 계산합니다. τ는 저전압, 극단 온도, 공정 편차에서 몇 배에서 몇 자릿수까지 커지므로 가장 나쁜 corner의 값을 넣어야 합니다.
단마다 다른 FF모든 단의 τ, T0, tco, tsu가 같다고 봅니다. 단마다 다르면 Golson의 식처럼 단별 resolution time ÷ τ를 따로 구해 더해야 합니다.
빠른 clock에서 FF 안 latch끼리 이어지는 경우master latch가 반 주기 뒤에 정해지면 slave latch가 다시 metastable에 들 수 있습니다. clock이 빨라 단 사이 시간이 FF 자체 지연에 가까워지면 이 back edge 효과가 커지고, 단순 지수 식은 이를 담지 못합니다.
서로 관계있는 clock식은 데이터가 clock 주기 안 아무 때나 같은 확률로 도착한다고 가정합니다. 두 clock이 같은 source에서 나와 주파수 비가 고정되면 도착 시점이 몇 곳에 몰리고, Golson은 이때 MTBF가 몇 자릿수 나빠질 수 있다고 씁니다.
multi-bit 신호synchronizer는 1비트의 metastability만 다룹니다. 여러 비트를 비트마다 동기화하면 비트마다 도착 주기가 달라 존재한 적 없는 값이 나옵니다. gray code, handshake, async FIFO가 필요합니다.
짧은 pulse빠른 쪽의 한 주기짜리 pulse는 받는 clock edge 사이에 끼어 아예 잡히지 않을 수 있습니다. MTBF와는 별개의 문제입니다.
전용 synchronizer cell라이브러리의 synchronizer 전용 cell은 내부 단수와 τ가 일반 FF와 다를 수 있습니다. Golson은 이런 cell을 쓸 때 operating condition 전 범위의 metastability 특성을 받았는지 확인하라고 씁니다.

synchronizer 회로 구조와 handshake, async FIFO는 CDC의 metastability와 synchronizer, async FIFO의 gray code 글에서 다뤘습니다.

참고 자료

모든 계산은 브라우저 안에서만 이루어지며 입력한 값은 어디에도 전송되거나 저장되지 않습니다. 결과는 위 식의 근사값입니다. 제품의 신뢰도 판단에는 공정과 cell의 실제 metastability 특성을 써야 합니다.