clock uncertainty를 더하기 전에 이미 반영한 시간을 확인하기
클록 uncertainty를 크게 주면 여유 있게 설계할 수 있다는 생각은 절반만 맞다. 이미 모델에 들어간 클록 배선 차이를 다시 같은 목적의 여유로 넣으면, 보고서의 위반은 실제 요구보다 엄격해질 수 있다. uncertainty의 수치를 정하려면 먼저 latency와 skew로 표현한 시간부터 구분해야 한다.
도착 시간과 도착 시간의 흔들림
latency는 기준점에서 클록이 레지스터에 도착할 때까지의 시간이다. 두 레지스터의 latency 차이가 skew다. uncertainty는 사용하는 에지 사이의 시간 관계에 남아 있는 불확실성이나 의도적인 여유를 나타낸다. OpenSTA는 setup과 hold에 서로 다른 uncertainty를 지정할 수 있고, 특정 출발·목적 클록 쌍에도 적용할 수 있다. 클록 불확실성의 지정
출발 클록이 기준점 뒤 0.6ns, 목적 클록이 0.9ns에 도착하는 가상 회로를 보자. 목적이 0.3ns 늦다. 같은 주기 안의 setup에서는 이 차이가 데이터에 시간을 더 주지만, hold에서는 목적의 늦은 캡처가 이전 데이터를 더 오래 보존하도록 요구한다. 같은 skew가 두 검사에서 반대 방향으로 작용한다.
주기 T=2ns, 데이터의 최대 clk-to-Q와 조합 지연 합 dmax=1.8ns, setup=0.1ns, setup uncertainty=0.15ns로 놓자. 출발 에지 기준 데이터 도착은 0.6 + 1.8 = 2.4ns다. 목적의 다음 캡처 기준 필요한 시각은 2 + 0.9 − 0.1 − 0.15 = 2.65ns여서 slack은 +0.25ns다.
같은 관계를 식으로 쓰면 setup slack = T + (목적 latency − 출발 latency) − setup − Usetup − dmax다. uncertainty를 뺀다는 것은 허용하는 최대 데이터 시간을 줄인다는 뜻이다. 위의 0.3ns skew를 도착 시간 차이에 이미 반영했음을 식에서 볼 수 있다.
hold도 같은 수치로 대충 채우지 않기
이 회로의 최소 데이터 시간이 dmin=0.2ns, hold=0.05ns, hold uncertainty=0.05ns라고 하자. 새 데이터는 현재 기준 에지 뒤 0.6 + 0.2 = 0.8ns에 도착한다. 이전 데이터를 보존해야 하는 끝은 0.9 + 0.05 + 0.05 = 1.0ns다. hold slack은 −0.2ns다.
식으로는 hold slack = dmin − (목적 latency − 출발 latency) − hold − Uhold다. setup에 도움을 준 양의 skew가 여기서는 0.3ns를 빼앗는다. 주기를 길게 해도 이 같은 에지의 최소 지연 문제를 그대로 남길 수 있다.
시간 단위가 ns이고 위 불확실성 모델을 쓰는 경우의 명령은 다음처럼 나뉜다.
set_clock_uncertainty -setup 0.15 [get_clocks core]
set_clock_uncertainty -hold 0.05 [get_clocks core]
두 값은 가상 예제의 입력이다. 어떤 장치의 권장 숫자가 아니며, 지터 통계를 변환할 때 그대로 적용할 공식도 아니다. setup은 서로 다른 주기의 에지 관계를, hold는 같은 캡처 주변의 에지 관계를 볼 수 있어, 공통 성분의 상관과 남은 오차가 같지 않을 수 있다.
이상적 클록에서 전파 클록으로 넘어갈 때
클록 트리를 아직 만들지 않은 이상적 분석에서는 앞으로 생길 skew를 모른다. 잠정적으로 예상 skew를 uncertainty 예산에 넣어 구현을 유도할 수 있다. 클록 트리와 배선 지연을 얻은 뒤에는 실제 도착 차이를 경로에 반영하고, 잠정 예산의 무엇이 여전히 필요한지 다시 정해야 한다.
OpenSTA의 set_propagated_clock은 이상적 클록 대신 계산되거나 주석으로 제공된 셀·배선 지연을 사용한다. set_clock_latency는 이상적 모델의 예상 지연을 표현하므로, 어떤 모델이 활성화되는지와 명령 순서도 확인해야 한다. 이상적·전파 클록 모델
가령 구현 전의 0.45ns uncertainty가 예상 skew 0.3ns와 남은 여유 0.15ns의 합이었다고 하자. 앞서 계산한 도착 시간 0.6·0.9ns를 전파 모델에 넣고도 0.45ns를 계속 쓰면 setup slack은 2 + 0.3 − 0.1 − 0.45 − 1.8 = −0.05ns다. 남은 0.15ns를 쓰는 +0.25ns와 0.3ns 차이가 난다. 추가 여유를 의도적으로 유지할 수는 있지만, 그때는 구현 전 skew 추정치를 계속 보유할 새로운 이유가 있어야 한다.
도구가 지터를 따로 계산하는 경우도 확인해야 한다. AMD Vivado 문서는 도구의 계산 불확실성에 사용자 uncertainty를 더한다고 설명한다. 따라서 해당 도구에서 계산된 지터를 사용자 값에 그대로 한 번 더 넣으면 총 여유의 의도가 달라진다. OpenSTA와 다른 도구의 자동 계산 방식을 동일하다고 가정해서는 안 된다. Vivado의 사용자 여유와 계산 지터
uncertainty 검토는 값을 키우거나 줄이는 선택부터 시작할 필요가 없다. 현재 경로에 반영한 도착 시간, 자동으로 계산한 오차, 별도로 남길 여유를 각 숫자의 출처와 함께 적으면 된다. 그러면 +0.25ns가 −0.05ns로 바뀐 이유도 설명할 수 있다. 여유는 충분히 확보하되, 각 시간이 어떤 현상을 대표하는지 알고 더해야 타이밍 보고서를 설계 판단으로 사용할 수 있다.