Setup Time과 Hold Time — VLSI 타이밍의 기초 완전 정복

Setup은 캡처할 데이터가 너무 늦게 도착하지 않는지, Hold는 입력이 너무 일찍 바뀌지 않는지 확인하는 타이밍 검사입니다. Setup slack은 required − arrival, hold slack은 arrival − required로 계산합니다.

양수 setup/hold 제약의 기본 예에서 setup time은 캡처 클록 엣지 전의 안정 구간, hold time은 엣지 후의 안정 구간을 뜻합니다. 실제 셀의 제약값과 부호는 라이브러리를 확인합니다.

Setup 또는 hold 제약을 위반하면 의도한 데이터 캡처를 보장할 수 없고 메타스테빌리티가 발생할 수 있습니다. 두 제약을 동시에 위반해야만 문제가 생기는 것은 아니며, 모든 위반이 반드시 메타스테빌리티로 나타나는 것도 아닙니다.

개요: 비행기 도착 비유로 이해하는 Setup과 Hold

비유를 사용한다면 “출발 전 확인할 비행기 탑승 명단이 언제부터 언제까지 바뀌지 않아야 하는가”로 생각해 보세요. 아래의 30분·5분은 개념 설명용 숫자이며 실제 반도체의 시간값이 아닙니다.

1. Setup 조건: 출발 30분 전부터 명단이 준비되어 있어야 한다면, 그 마감보다 늦게 준비된 명단은 조건을 만족하지 않습니다. 정확한 마감 시각과 그 이후를 구분합니다.
2. Hold 조건: 확인 순간 이후 5분간 같은 명단을 유지해야 한다면, 2분 뒤 내용을 바꾸는 것은 너무 빠른 변경입니다.

양수 setup/hold 값을 갖는 플립플롭의 예에서는 입력이 클록 엣지 앞뒤의 요구 구간 동안 안정적이어야 합니다. 실제 수치는 사용한 셀의 라이브러리·전압·온도·입력 slew 조건을 확인해야 합니다.

Setup Time: 기초 개념

Setup Time의 정의

양수 setup time(tsu)은 플립플롭 입력이 캡처 클록 엣지 전에 안정적이어야 하는 최소 구간입니다. 아래 기존 그림에서는 엣지 전후의 안정 구간을 참고하세요. 클록 주기는 T 화살표 끝이 아니라 연속된 같은 방향의 클록 엣지 사이로 측정합니다.

가정한 setup time이 1.2 ns이고 캡처 클록이 10.0 ns에 도착한다면, 불확실성을 생략한 latest required time은 8.8 ns입니다. 데이터 arrival이 8.5 ns이면 setup slack은 0.3 ns, 9.0 ns이면 −0.2 ns입니다. 이는 설명용 산술 예제입니다.

Setup Slack 계산

STA에서 setup은 해당 검사의 최대 데이터 도착 시간과 required time을 비교합니다. 아래의 Clock Time은 목적지에 도착한 캡처 클록 시각이며, 단순히 클록 주기와 같은 값으로 읽으면 안 됩니다. 실제 보고서는 클록 경로 지연과 uncertainty 등을 반영합니다.

Setup Slack = Required Time - Arrival Time
= (Clock Time - Setup Time) - Data Arrival Time

• Required time: 해당 setup 검사의 최신 허용 도착 시각. 단순 예에서는 capture clock arrival − setup time입니다.
• Arrival time: 해당 launch edge에서 출발한 데이터가 목적지에 도착하는 최대 시간입니다.
• Slack > 0: 분석한 조건에서 여유가 있습니다. Slack = 0: 여유 없이 경계에 있습니다.
• Slack < 0: 해당 setup 제약을 위반합니다. 양수 slack 하나만으로 전체 설계의 검증 완료를 판단하지 않습니다.

Setup Violation이 발생하는 이유

Setup Violation은 다음과 같은 상황에서 발생합니다:

• 조합 논리·배선의 최대 지연이 시간 예산보다 큽니다.
• 설정한 launch/capture 관계가 너무 짧거나 SDC 조건이 실제 동작과 맞지 않습니다.
• Clock skew·uncertainty 또는 라이브러리/분석 조건이 사용 가능한 시간을 줄입니다.
• 버퍼 추가·셀 크기 변경의 효과는 부하·slew·배선에 따라 달라집니다. 버퍼가 부족하다는 이유만으로 원인을 단정하지 않습니다.

Hold Time: 기초 개념

Hold Time의 정의

양수 hold time(th)은 플립플롭 입력이 캡처 클록 엣지 이후에도 안정적으로 유지되어야 하는 최소 구간입니다. 아래 그림의 th 구간을 보세요. 라이브러리가 음수 hold 제약을 제공할 때의 해석은 뒤의 FAQ에서 별도로 설명합니다.

가정한 hold time이 0.8 ns이고 캡처 클록 도착 시각이 10.0 ns라면, uncertainty를 생략한 earliest required time은 10.8 ns입니다. 새 데이터가 11.0 ns에 도착하면 hold slack은 0.2 ns이고, 10.6 ns에 도착하면 −0.2 ns입니다.

Hold Slack 계산

Hold 검사는 데이터가 너무 일찍 바뀌어 기존 캡처를 방해하지 않는지 봅니다. 해당 launch/capture edge 관계에서 최소 데이터 도착 시간을 사용하며 setup과 뺄셈 순서가 반대입니다.

Hold Slack = Arrival Time - Required Time
= Data Arrival Time - (Clock Time + Hold Time)

• Required time: 해당 hold 검사의 가장 이른 허용 변경 시각. 단순 예에서는 capture clock arrival + hold time입니다.
• Arrival time: hold 검사에서 선택된 launch edge가 만든 새 데이터의 최소 도착 시간입니다. “이전 사이클 데이터의 도착”으로 고정해서 해석하지 않습니다.
• Slack > 0은 여유, 0은 경계, 음수는 해당 hold 제약 위반입니다.

Hold Violation의 메커니즘

같은 클록의 같은 상승 엣지를 비교하는 단순 경로에서는 source FF에서 새로 바뀐 값이 destination FF에 너무 빨리 도착하면 hold를 위반할 수 있습니다. 짧은 데이터 경로뿐 아니라 clock skew와 edge 관계도 함께 확인해야 합니다.

목적지에서 유지해야 할 기존 입력값이 요구 시각 전에 바뀌는 것이 핵심입니다. 실제 timing engine은 가능한 setup/hold edge 관계 중 제한적인 조건을 선택하므로, 서로 다른 클록·multicycle 경로를 같은 엣지의 단순 예로 처리하지 마세요.

보고서에서 확인할 순서는 다음과 같습니다.

• Startpoint와 endpoint, launch/capture clock 및 선택된 edge를 확인합니다.
• Data arrival의 min/max와 clock path delay, uncertainty, 라이브러리 제약을 확인합니다.
• Slack의 부호와 required/arrival의 기준 시각을 비교합니다.
• 위반이 있으면 분석 조건과 수리 방법을 함께 검토합니다. STA 음수 slack만으로 아날로그 메타스테빌리티의 실제 발생을 관측했다고 말할 수는 없습니다.

숫자로 확인하는 타이밍 보고서

실제 예: Setup Time 분석

• Required time = 5.0000 ns: 이미 계산된 데이터 도착 마감입니다. 이 값만으로 클록 주기가 5 ns라고 단정할 수 없습니다.
• Arrival time = 5.3274 ns라면 setup slack = 5.0000 − 5.3274 = −0.3274 ns입니다.
• 최대/최소 경로, 기준 edge, 단위와 분석 corner를 같은 조건으로 읽어야 합니다.

Setup Violation 해결 방법

1. 분석 조건부터 확인: 실제 clock 관계·입출력 지연·예외 경로와 SDC가 일치하는지 확인합니다.
2. 데이터 경로 개선: 논리 깊이·배선 지연·셀 선택·부하를 검토합니다. 실제 도구가 제안한 변경 뒤에 timing을 다시 계산합니다.
3. 아키텍처/주기 검토: 허용되는 설계에서 파이프라인이나 더 긴 주기를 검토할 수 있지만 기능·latency·성능 요구 변경을 수반합니다. 제약만 바꾸어 위반을 숨기지 않습니다.

Hold Violation 해결 방법

1. 필요한 데이터 경로에 지연을 추가하는 hold buffer 등 도구의 수리 방법을 검토합니다.
2. Clock skew·선택된 edge·uncertainty도 함께 확인합니다. 큰 셀로 바꾸면 항상 느려진다는 일반 규칙은 없습니다.
3. 수리 뒤에는 setup을 포함한 관련 검사와 corner를 다시 확인합니다. OpenROAD 문서도 hold buffer가 setup 위반을 만들 수 있음을 다룹니다.

자주 묻는 질문 (FAQ)

1. Setup Time과 Hold Time을 동시에 위반할 수 있나요?

서로 다른 경로·corner·검사 조건에서 setup과 hold 위반이 함께 보고될 수 있습니다. 최대 데이터 지연이 문제인 경로와 최소 지연이 문제인 경로를 구분해서 분석하세요. 한 보고서의 수치만으로 전체 설계의 근본 원인을 단정하지 않습니다.

2. Setup과 Hold 중 어느 것이 더 중요한가요?

둘 다 만족해야 합니다. Setup 위반은 늦은 도착, hold 위반은 너무 이른 변경과 관련된 별도의 제약입니다. 어느 쪽이든 의도한 캡처를 보장할 수 없으며 메타스테빌리티가 발생할 가능성도 있습니다.

같은 엣지를 쓰는 단순 hold 검사에서는 clock period를 늘려도 hold 여유가 늘어나지 않습니다. 그러나 “hold 위반은 해결 방법이 없다”는 뜻은 아닙니다. 설계 단계의 지연 삽입·clock 경로 조정 등을 검토하며, 제조 후 가능한 대응은 실제 하드웨어와 시스템의 변경 가능성에 따라 달라집니다.

3. 클록 주기를 줄이면 항상 Setup만 위반되나요?

같은 클록·single-cycle setup에서 다른 조건이 그대로라면 주기를 줄일수록 setup 예산이 줄어듭니다. 같은 엣지 hold 관계에는 그 주기가 직접 들어가지 않습니다. 실제 clock 관계나 구현이 바뀌었다면 두 검사 모두 다시 확인해야 합니다.

4. 메타스테이블 상태(Metastable State)란 정확히 무엇인가요?

메타스테빌리티는 레지스터 출력이 유효한 0 또는 1로 결정되는 데 예상보다 오래 걸릴 수 있는 현상입니다. 허용된 시간 안에 안정되지 않으면 다음 논리의 캡처에 문제가 생길 수 있습니다. 비동기 입력에는 CDC 설계와 동기화 구조·MTBF 검토가 필요하며, 이 글의 slack 산술만으로 그 위험을 모두 평가하지 않습니다.

5. Hold Time이 음수(negative)인 플립플롭도 있나요?

라이브러리에 음수 hold 제약이 있다면 부호를 그대로 식에 넣어 해석해야 합니다. 예를 들어 capture 시각 10.0 ns, hold = −0.2 ns라면 단순 required 시각은 9.8 ns입니다. 즉 hold 경계가 클록 엣지 이전으로 이동한다는 의미이지, setup 조건까지 없어지는 뜻은 아닙니다. 특정 공정이 항상 더 유리하다고 일반화하지 마세요.

실무 관점: PrimeTime에서 setup/hold violation 디버깅하기

2026년 10월 업데이트 — STA 실무 관점 추가. 위의 정의와 산술이 "무엇"이라면, 이 섹션은 signoff 현장의 "어떻게"다. 아래 순서는 PrimeTime 기반 STA 플로우에서 통용되는 디버깅 순서다.

1. report_timing을 읽는 순서

Violation 리포트를 받으면 slack 숫자부터 보지 말고 startpoint–endpoint와 launch–capture clock 관계부터 확인한다. 같은 -0.1 ns라도 launch 경로가 긴 경우와 capture skew가 큰 경우는 수리 전략이 정반대다. report_timing -delay_type max로 setup을, -delay_type min으로 hold를 따로 본다. Path group별 최악 slack 하나만 보지 말고 violating endpoint의 분포를 본다. 한두 개 endpoint에 몰려 있으면 로컬 문제, 수백 개에 퍼져 있으면 구조 문제다.

2. Setup violation 디버깅

원인은 셋 중 하나다. (a) data arrival이 늦다 — 콤비네이션 로직 단수가 깊거나, wire가 길거나, drive가 약하다. (b) capture clock이 늦다 — useful skew가 필요한지 본다. (c) required time 계산의 입력(SDC, clock 정의)이 틀렸다 — 가장 흔하면서 가장 비싼 실수다. 수리는 arrival을 당기거나 required를 미루는 두 방향뿐이다. Buffer insertion·gate sizing·logic restructuring이 전자, clock skew 조정(useful skew)·clock 주기 완화가 후자다. ECO 단계에서는 바꾸는 셀 수를 최소화하는 것이 원칙이다. 하나를 고치다 hold를 깨는 일이 비일비재하기 때문이다.

3. Hold violation 디버깅 — 왜 hold가 더 까다로운가

Hold는 "너무 빠름"의 문제라 클록을 늦춘다고 해결되지 않는다. 데이터 경로에 지연을 의도적으로 추가해야 한다. 그래서 hold 수리는 buffer/delay cell 삽입이 정석이고, 물리적 위치가 중요하다. 같은 버퍼라도 launch 쪽에 박느냐 capture 쪽에 박느냐에 따라 결과가 달라진다. 실무의 철칙: setup은 CTS 이전에, hold는 routing 이후에 잡는다. Hold를 너무 일찍 잡으면 나중 단계에서 다시 깨진다. 그리고 hold fix는 면적·전력을 먹으므로, "최소 삽입으로 전체 endpoint 커버"가 숙련도의 척도다.

4. Corner의 함정

Setup은 보통 slow corner(SS, 저전압·고온)에서, hold는 fast corner(FF, 고전압·저온)에서 최악이다. 그런데 advanced node에서는 온도 역전(temperature inversion)과 low-voltage corner가 이 공식을 깬다. Signoff corner 셋을 "관성"으로 쓰지 말고, 매 노드·매 라이브러리마다 어떤 corner가 setup/hold를 지배하는지 실측으로 확인한다. 이 확인을 건너뛰면, 통과한 리포트와 실패한 실리콘을 동시에 얻는다.

5. 디버깅 체크리스트

• SDC가 최신 netlist·모드와 일치하는가 (가장 흔한 false violation 원인)
• Clock 정의(생성·분주·gating)가 실제와 같은가
• False path·multicycle 예외가 과도하게 잡혀 있지 않은가 (예외는 곧 리스크다)
• Violating endpoint가 클러스터링되는가, 산발적인가
• 같은 경로가 여러 corner에서 깨지는가, 특정 corner에서만 깨지는가

정의는 교과서에서 배우지만, violation을 고치는 감각은 리포트 수백 장에서 나온다. 위 체크리스트는 그 수백 장을 압축한 것이다.

>고급 개념: Clock Skew와 타이밍

Clock Skew의 영향

여기서는 clock skew를 “목적지 clock delay − 출발지 clock delay”로 정의합니다. 같은 경로·edge 관계에서 다른 값이 고정되어 있을 때 이 부호를 기준으로 설명합니다.

• Positive skew: 목적지 클록이 더 늦게 도착합니다. Setup 여유는 늘고 hold 여유는 줄어듭니다.
• Negative skew: 목적지 클록이 더 일찍 도착합니다. Setup 여유는 줄고 hold 여유는 늘어납니다.

예를 들어 skew가 +0.1 ns 늘고 다른 항이 그대로라면 setup slack에는 +0.1 ns, hold slack에는 −0.1 ns가 반영됩니다. 이는 AMD UG1388의 단순 slack 식에서 유도한 비교이며, 실제 수리 결과는 다시 STA로 확인해야 합니다.

PVT (Process, Voltage, Temperature) Variation

공정·전압·온도와 라이브러리 조건에 따라 데이터·클록 지연이 달라집니다. Setup과 hold에 제한적인 corner가 같다고 가정하지 말고 제품의 signoff 조건에 맞춰 분석합니다.

PrimeTime 등 STA 도구의 보고서를 읽을 때는 사용한 라이브러리, corner, derating, uncertainty와 예외 조건을 함께 기록하세요. 한 번의 worst-case 분석이 가능한 모든 물리 상황을 증명하는 것은 아닙니다.

요약

• Setup slack = required − arrival: 해당 max 경로의 늦은 도착을 확인합니다.
• Hold slack = arrival − required: 해당 min 경로의 너무 이른 변경을 확인합니다.
• Skew를 destination − source로 정의하면 positive skew는 setup에 유리하고 hold에 불리합니다.
• 수리 방향과 효과는 실제 부하·배선·clock 관계에 따라 달라지므로 변경 뒤에 다시 분석합니다.
• 0 slack은 여유가 없는 경계입니다. 모든 관련 경로·corner·제약 및 CDC 검토를 구분하세요.

직접 확인하는 계산 순서

위 예제의 required time과 arrival time을 적고 setup은 required − arrival, hold는 arrival − required로 계산해 보세요. 그다음 capture clock arrival만 0.1 ns 늦춰 어느 쪽 여유가 늘고 줄어드는지 비교하면 skew의 부호를 확인할 수 있습니다. 이 산술 연습은 실제 netlist·clock tree·SDC·corner를 분석하는 STA를 대신하지 않습니다.

확인한 공식 자료와 정정 기록

2026년 9월 30일: clock skew 영향 방향, hold arrival 해석, required time과 주기 구분, 위반 수리 설명을 정정했습니다. 숫자 예제는 설명을 위한 가정이며 제조사 측정값이 아닙니다.

AMD UG906 — Timing Path Details

AMD UG1388 — Reviewing Timing Slack

Intel — Understanding Metastability in FPGAs

OpenROAD — Gate Resizer: Repair Timing

함께 읽으면 좋은 반도체 핵심 글

• 반도체 완전 가이드 — 반도체란 무엇인가: 원리부터 산업·투자 지도까지
• 한국 반도체 기업 순위 TOP 20 (2026년 최신) — 삼성전자·SK하이닉스부터 팹리스까지
• 세계 반도체 기업 순위 TOP 10 (2026년) — TSMC·NVIDIA·삼성전자