STA(Static Timing Analysis) (3) - Timing 분석

 

timing을 분석하기 위한 준비가 모두 끝났다면 이제 timing analysis를 진행합니다.

Lab을 통해 timing을 분석해 보았습니다.

 

1. Ideal Clk

먼저 report_timing을 통해 ideal clk에 대하여 분석한 결과입니다.

 

report_timing을 통해 결과를 보면, 가장 큰 violation이 난 path 하나만을 보여주게 됩니다.

 

따라서 report_constraint –all_violators 옵션을 통해 violation이 난 모든 constraint들을 보게 되면 다음과 같습니다.

setup, hold, max_cap, max_trans, max_fanout 과 같이 많은 violation들이 존재하게 됩니다.

※ max_cap, max_trans, max_fanout violation이란? - chip을 디자인할 때 사용되는 대부분의 standard cell들은 기본적으로 파운드리에서 전부 테스트를 진행합니다. 그 뒤, 소자의 특성을 table로 만들어 놓습니다. (예를 들어, input transition이 x라는 값이고, output capacitance가 y라는 값일 때, 이 소자의 delay는 z이다. 라는 식으로 table을 만들어 놓습니다.) 하지만 만약 transition이나 capacitance 값이 이 table의 값을 벗어난다면 어떻게 될까요? 이 때에는 tool이 소자의 특성을 예측하여 그 값을 산출하게 됩니다. 하지만 그런 예측된 값은 실제값과 다를 가능성이 높습니다. 즉 max_cap, max_trans 와 같은 violation들은 파운드리에서 제공한 cell의 특성 table을 벗어났기 때문에 발생하는 violation 입니다. 이런 violation들은 소자의 신뢰성을 보장할 수 없기 때문에 반드시 잡아주어야 합니다.

 

이 violation들 중 몇 개를 집어, 분석을 해보았습니다.

먼저, report_timing –to endpoint –cap –tran –net 옵션을 통해서 특정 endpoint의 path를 분석해보았습니다.

ideal clk임으로 clock network delay가 존재하지 않음을 확인할 수 있습니다.

report를 보면 다음과 같이 특정 net의 cap값이 어떻게 되는지, 특정 cell의 transition 값이 어떻게 되는지 확인할 수 있습니다. 이를 통해 path에서 delay가 얼마나 추가되는지를 확인할 수 있었습니다.

위의 경우, required time은 3.5372인 반면에, 실제로 data가 도착한 time은 3.7453으로 0.2081만큼 setup time violation이 난 것을 확인할 수 있었습니다.

sd_DQ[0] net의 경우 cap값이 상당히 큰 것으로 보아, net길이가 매우 길 것을 예측할 수 있습니다. 

 

 

다음으로 ideal clk임에도 불구하고 hold time violation이 있는 point가 있었기에, 도대체 어떻게 hold time violation이 발생하였는지 궁금하여 hold time violation이 발생한 point를 가져와 분석해 보았습니다.

분석결과 clock network delay는 ideal clk이기 때문에 0이 나옴을 확인할 수 있었습니다. 그렇다면 어떻게 hold time violation이 발생했는지 알아보기 위해 자세히 살펴보니, libaray hold time 값이 data required time보다 느려서 발생한 hold time violation임을 알 수 있었습니다.

즉, endpoint의 특정 cell이 data를 안정적으로 hold하기 위해 요구되는 시간은 0.3621인 반면에, data의 도착시간이 이 cell이 요구하는 시간보다 빠르게 도착하여 ideal clock임에도 불구하고(network dealy가 0임에도 불구하고) hold time violation이 나타났습니다.