최악의 slack이 좋아져도 TNS가 나빠질 수 있는 이유

타이밍 개선안을 비교할 때 최악의 slack 하나만 보고 우열을 가리기 쉽다. −0.8ns를 −0.1ns로 줄였다면 큰 진전처럼 보인다. 하지만 나머지 수십 개 목적지가 새로 −0.05ns를 기록했다면 전체 설계의 상태는 어떨까? Total negative slack, TNS는 가장 나쁜 한 곳의 깊이와 별개로 여러 목적지에 퍼진 위반을 읽게 해 준다.

목적지마다 가장 나쁜 값 하나를 더한다

이 글에서는 같은 분석 조건의 setup 결과를 비교한다. 목적지 i의 최악 slack을 s_i라고 하면, TNS는 음수인 값들을 더한 것이다. 수식으로는 Σ min(s_i, 0)이다. WNS는 그중 가장 나쁜 음수 slack이고, 모든 slack이 양수라면 0으로 보고한다. OpenSTA도 report_tns와 report_wns를 구분하며, 후자의 설명에서 최악 slack이 양수일 때 0을 반환한다고 명시한다. OpenSTA 보고 명령

여기서 목적지마다라는 말이 중요하다. 어떤 입력 핀에 도달하는 세 경로의 slack이 −0.3, −0.2, +0.1ns라면 그 목적지의 기여는 −0.3ns다. 보고서에 나열한 두 음수 경로를 더해 −0.5ns로 계산하지 않는다. 같은 목적지에 도달하는 경로를 많이 출력했다는 이유로 TNS가 커지면 분석이 출력 옵션에 좌우될 것이다.

OpenSTA 구현은 endpoint별로 slack을 얻은 뒤 음수 항목을 합산하고, endpoint에 대응하는 값을 저장한다. 여러 분석 scene이 있으면 각 scene의 합을 따로 계산하며, 전체 질의에서는 그중 가장 음수인 합을 선택한다. 그러므로 여기서 쓰는 단일 조건의 수식을 모든 코너와 모드를 한꺼번에 합한 값으로 확대해서는 안 된다. Search.cc의 totalNegativeSlack과 findTotalNegativeSlacks

깊은 한 곳과 얕은 마흔 곳

가상 설계 A와 B를 비교해 보자. 두 결과는 같은 주기, 같은 코너, 같은 setup 제약을 사용하며 비교할 목적지 집합도 같다고 가정한다. A에서는 한 목적지가 −0.8ns이고 나머지는 모두 양수다. B에서는 마흔 목적지가 각각 −0.05ns이고 나머지는 양수다.

A: WNS = −0.8 ns,  TNS = −0.8 ns, 위반 목적지 = 1개
B: WNS = −0.05 ns, TNS = −2.0 ns, 위반 목적지 = 40개

B의 가장 나쁜 경로는 A보다 훨씬 가볍다. 그러나 위반이 넓게 퍼져 있다. 이때 TNS가 더 큰 음수라고 B가 반드시 더 고치기 어렵다고 단정할 수도 없다. 마흔 목적지가 하나의 공통 드라이버에 연결되어 있다면 한 번의 부하 분할로 여러 곳이 개선될 수 있다. 반대로 서로 다른 지역의 짧은 경로들이 각각 부족하다면 손봐야 할 지점이 많다. TNS는 분포의 합을 보여 주지만 원인의 공통성까지 담지는 않는다.

개선의 방향도 두 수치가 다르게 보여 준다. A의 한 위반을 0으로 고치면 TNS는 0.8ns 개선되어 0이 된다. B의 마흔 목적지를 각각 0.04ns 개선하면 TNS는 1.6ns 개선되어 −0.4ns가 된다. 두 번째 작업의 합계 개선은 더 커도 마흔 목적지가 여전히 −0.01ns로 남는다. 위반 수가 줄지 않았다는 이유로 이 개선을 무의미하다고 할 수는 없지만, 타이밍 완료라고 부를 수도 없다.

큰 합계가 여러 사이클의 지연을 뜻하지는 않는다

TNS의 단위가 ns라고 해서 −2ns를 “시스템이 총 2ns 늦다”로 해석하면 안 된다. 서로 다른 목적지의 부족 시간을 합산한 평가값이지, 하나의 데이터가 차례대로 겪는 지연의 합이 아니다. 어느 경로가 기능상 실행되는 빈도나 실패 확률도 이 숫자에서 직접 계산할 수 없다.

최적화 도구가 WNS와 TNS를 함께 사용하는 이유는 이 차이에서 나온다. OpenROAD의 repair_timing 설명은 최악 setup 경로를 먼저 다루고, 이후 다른 위반 목적지의 경로를 개선해 TNS를 줄인다고 설명한다. -repair_tns도 개선할 위반 목적지의 비율을 지정한다. 특정 단계에서는 가장 깊은 위반을 먼저 제거하는 전략이 유용하고, 다른 단계에서는 넓게 남은 작은 부족을 처리하는 것이 필요하다. OpenROAD의 타이밍 개선 설명

비교표를 만들 때는 WNS, TNS, 위반 목적지 수를 함께 적으면 판단이 쉬워진다. 여기에 주요 위반이 같은 셀·배선·클록 분기에서 비롯되는지도 확인하면 개선 후보가 구체화된다. 단, 경로를 예외로 제외하거나 제약을 완화해 TNS가 줄어든 경우는 동일 조건의 회로 개선과 구분해야 한다. Hold의 TNS도 setup 합계와 섞지 않고 따로 읽는다.

임계 경로 하나는 설계의 가장 심한 부족을 보여 주지만 모든 목적지의 상태를 대표하지 않는다. TNS를 함께 읽는 목적은 하나의 새 점수로 우승자를 고르는 데 있지 않다. 깊은 위반 하나를 해결해야 하는지, 여러 곳의 작은 부족을 줄여야 하는지 파악하고, 남은 위반을 모두 닫기 위한 다음 수정을 정하는 데 있다.