𝗦𝗧𝗔 │ capture clock을 늦췄더니 setup은 좋아졌는데 hold가 깨졌다?

타이밍 리포트에서 setup slack이 빠듯한 경로가 보입니다. capture FF에 clock이 조금 늦게 도착하도록 조정하니 setup은 좋아졌습니다. 그런데 같은 경로의 hold slack이 음수로 바뀝니다. 데이터 경로는 그대로인데 왜 그럴까요?

같은 clock의 두 FF를 생각해 봅시다. launch FF의 clock 도착을 기준 0으로 놓고, capture FF의 clock이 얼마나 늦게 도착하는지를 skew S라고 하겠습니다. S가 양수이면 capture clock이 더 늦습니다. setup은 다음 edge에 데이터를 받으므로 시간이 S만큼 늘지만, hold는 현재 edge 직후 기존 데이터를 지켜야 하므로 같은 S만큼 불리해집니다.

숫자로 보면 분명합니다. clock period 1.00 ns, setup time 0.10 ns, hold time 0.08 ns입니다. clock-to-Q를 포함한 데이터 경로의 최대 지연은 0.85 ns, 최소 지연은 0.15 ns라고 하겠습니다. 설명을 위해 uncertainty와 별도의 clock 경로 변동은 잠시 제외합니다.

S=0일 때 setup slack은 1.00−0.10−0.85=+0.05 ns, hold slack은 0.15−0.08=+0.07 ns입니다.

capture clock만 0.20 ns 늦어져 S=+0.20 ns가 되면, 다음 capture edge는 1.20 ns에 옵니다. setup slack은 1.20−0.10−0.85=+0.25 ns로 늘어납니다. 반면 현재 capture edge는 0.20 ns에 오므로 hold slack은 0.15−(0.20+0.08)=−0.13 ns가 됩니다. setup에서 번 0.20 ns를 hold에서 그대로 잃은 셈입니다.

그래서 skew를 이용한 setup 개선은 공짜가 아닙니다. 실제 signoff에서는 setup과 hold에 서로 다른 early/late clock 경로와 max/min 데이터 지연, uncertainty, corner를 적용합니다. 위 숫자는 방향을 이해하기 위한 단순화된 예시입니다.

리뷰할 때는 setup 리포트의 숫자 하나만 보지 말고 같은 경로의 hold와 인접 경로도 함께 확인하세요. hold 보정을 위해 데이터 지연을 추가하면 확보한 setup 여유를 다시 쓸 수 있습니다. 먼저 clock tree의 실제 도착 시각과 timing exception이 의도한 대로 적용됐는지 살펴보는 것이 출발점입니다.

근거: AMD Vivado UG906, Skew Definition / Clock Skew and Uncertainty / Max and Min Delay Analysis (2026.1)
https://docs.amd.com/r/en-US/ug906-vivado-design-analysis/Skew-Definition
https://docs.amd.com/r/en-US/ug906-vivado-design-analysis/Clock-Skew-and-Uncertainty
https://docs.amd.com/r/en-US/ug906-vivado-design-analysis/Max-and-Min-Delay-Analysis
AMD Vivado UG906, Determining if Hold-Fixing is Negatively Impacting the Design (2026.1)
https://docs.amd.com/r/en-US/ug906-vivado-design-analysis/Determining-if-Hold-Fixing-is-Negatively-Impacting-the-Design
Intel Timing Analyzer, Clock Analysis Equations
https://www.intel.com/content/www/us/en/support/programmable/support-resources/design-examples/quartus/tq-clock.html