Case Study · Troubleshooting · intermediate

Post-CTS에서 짧은 register-to-register path의 hold violation

CTS 후 서로 다른 clock branch에 연결된 인접 flop 사이에서 hold violation이 대량 발생한 사례. 원인은 local skew였고, hold buffer 삽입으로 해결했다.

Timing & STA
CTS & Clock
Post-CTS
#hold
#clock-skew

작성 2026-11-11 · 수정 2026-11-11

이 사례는 NDA 준수를 위해 일반화했다. 설계 이름, 경로, 수치는 포함하지 않는다.

문제 요약

CTS 직후 hold violation이 갑자기 늘었다. Violation path는 길이가 매우 짧은 register-to-register path였고, 특정 영역에 몰려 있었다.

조사 과정

분포 확인: violation path의 시작점·끝점 위치를 보니 block 경계 부근 flop에 집중되어 있었다.
Path 상세 확인: report_timing -delay_type min -path_type full_clock_expanded로 launch/capture clock path를 펼쳐 보았다. Data path 지연은 정상 범위였고, capture clock latency가 launch보다 뚜렷하게 컸다.
Clock tree 구조 확인: launch flop과 capture flop이 서로 다른 clock branch(다른 clock gate 아래)에 연결되어 있었다.

Root Cause

Hold slack 식에서 skew 항이 그대로 빠진다.

slack_{hold} = (t_{clk \to q} + t_{comb}) - t_{skew} - t_{hold} - t_{uncertainty}

Data path가 짧은 상태에서 positive local skew가 커지자 hold slack이 음수가 됐다. Global skew 지표는 목표 안이었기 때문에 CTS report만으로는 드러나지 않았다.

해결책

Hold fixing을 활성화한 post-CTS 최적화를 실행해 data path에 delay cell을 삽입했다.
Delay 삽입은 setup slack을 줄이므로, 같은 path의 setup margin을 함께 확인했다.

Lessons Learned

CTS 품질은 global skew뿐 아니라 timing으로 연결된 flop 쌍의 local skew로 봐야 한다.
Hold violation이 특정 영역에 몰려 있으면 data path보다 clock 구조를 먼저 의심한다.