오늘은 지난번 posting에 이어서 front-end 설계 엔지니어에게 있어서 주요 설계 도구중의 하나인 Design Compiler의 constraint 주는 방법에 대해서 Total negative slack과 Worst Negative slack의 관점에서 간략히 설명해 보겠습니다.
Design compiler는 잘 아시다시피 constraint 기반으로 optimization을 진행합니다.
즉, 설계를 어떤 방식으로 합성하여 최적화시키는지는 사용자가 해당 모듈에 대하여 원하는 목표치들.. 동작 주파수, 크기를 설정하면 그 값에 맞추어 합성 및 최적화을 진행하게 됩니다.
만일 constraint가 존재하지 않는 경우, 더 이상 최적화를 진행하지 않고 mapping으로 끝나게 되죠.
Slack?
모든 함성이 끝난 후 지정된 constraint 대비 합성 결과를 비교하여 slack을 나타내게 되는데, 아래 그림처럼 지정된 것보다 일찍 신호가 도착하면 positive slack이라 하지요. 이런 경우 설계자로서는 행복한 순간이니 바로 호프집으로 가서 뒷풀이하면 되겠습니다.
그 반대의 경우 negative slack이라 하는데, 지정한 constriant을 맞추지 못하는 것입니다.
따라서, 코드를 바꾸던, 툴이 더 힘을 낼수 있도록 스크립트를 작성하던..더 열심히 최적화를 해봐겠죠.
TNS와 WNS
그럼 오늘의 주제인 TNS와 WNS는 무엇일까요?
TNS는 total negative slack이라해서, negative slack의 합입니다. 즉, 설계의 모든 net에서 발생한 negative slack을 더한 값이죠. 전반적으로 설계가 어떻다.. 를 의미합니다.
WNS는 worst negative slack이라해서, negative slack중에 가장 나쁜 값 하나를 이야기합니다.
이 값들이 어떤 의미를 가지냐 하면, WNS는 나쁘지만 TNS는 그리 나쁘지 않은 경우, WNS만 최적화하면 되기 때문에 front-end에서건, back-end에서건 그 path가 잡힐 확률이 아주 높습니다.
반대로 WNS는 별로 나쁘지 않지만 TNS가 매우 나쁜 경우, 설계상의 대부분의 path가 worst case에 몰려 있는 상태이므로, 더 이상 최적화와 P&R을 열심히 돌려도 별로 좋아지기 힘들다고 보시면 됩니다.
WNS와 TNS의 처리
Synopsys DesignCompiler에서 delay를 최적화 시키는 방법은 기본적으로 Worst Negative Slack(WNS)를 하나씩 줄여나가는 방법에 기반을 둡니다.
즉, 로직을 mapping시키고, negative slack이 발생한 net들을 주욱~ 나열한 후, 그중에 가장 나쁜 넘(WNS)에 해당하는 net을 최적화하고,
다시 negative slack net을 주욱~ 나열하고, 또 WNS를 최적화하고.. 이런식의 반복입니다.
단, WNS를 줄이면서 TNS가 늘어나면 안되게 하고 있습니다. 즉, 합성 과정에서 WNS를 줄일 수 있더라도 TNS가 늘어나는 경우라면 synopsys에서 받아들이지 않습니다.
Synopsys의 기본적인 합성 방법이 이해되시나요?
TNS도 같이 줄이기
위의 설명에서 synopsys에서 기본적으로 사용하는 WNS기반의 최적화를 보여드렸는데, 이 경우 전반적인 path가 WNS근처에 몰려 있을 확률이 아주 높습니다. (design_vision이나 primetime에서 histogram으로 확인하실 수 있습니다.)
즉, 이 말은 앞에 설명하였듯이 나중에 P&R이 아주 귀찮아 진다는 거죠..
그래서, TNS를 좀더 빡~시게 고려할 수 있는데.. 이것이 바로 오늘 이야기 하려하는 critical_range에 대한 이야기입니다. 우선 문법.
이 명령은 WNS에서 critical range로 지정된 값 이내의 path에 대해서도 같이 optimization을 수행하도록 합니다.
이렇게 하면 DesignCompiler는
1) 우선 WNS를 줄이려 노력합니다.
2) WNS줄이기가 끝나면 critical range에 해당하는 path들을 줄이기 위해 노력합니다.
이 과정에서 WNS보다는 좋지만 여전히 neagtive slack을 발생시키는 net들에 대하여 더 합성을 하게 되는 것입니다. 따라서, 전반적으로 histogram을 보면 slack이 WNS쪽에 몰리지 않고 약간 더 뒤로 이동합니다.
이는 P&R과정에서 WNS를 해결할 가능성을 높이는 결과는 보여줍니다.
Back-End Tools로 hand-off하기..
지난번에 이야기한 것 처럼, 공정이 미세해지면서 front-end에서 wireload model을 사용하면 합성의 정확성이 떨어지고 P&R과정에서 여러가지로 힘들어집니다.
따라서, P&R을 좀더 쉽게 진행하려면 front-end에서 약간 더 빡세게 합성해줄 필요가 있습니다.
(물론, S사나 L사와 같이 back-end team에서 로직 수준까지 바꿔치기 해줄 수 있는 팀이 회사내에 존재한다면 뭐가 걱정이겠습니까? ^^; )
이때 흔히 사용하는 방법이 over constraint입니다.
즉, 타겟 주파수가 100MHz라면 110MHz에서 돌수 있도록 front-end에서는 합성하는 거죠..
(물론, back-end design house 잘못 만나면 10% 마진.. 어림도 없습니다..! orz)
over-constraint와 더불어 좋은 방법이 바로 TNS를 줄여서 전달하는 겁니다.
예를 들어 110MHz에서 sign-off할 것이라면 약 clock period를 8ns정도주고, critical_range를 1ns정도 주는 것이지요.
그럼, 툴은 좀더 노력하지만, 설계보다 constraint가 너무 심하게 들어가 있으니 WNS는 대략 -0.5이상이 발생할 거고.. TNS도 큰 값이 되어 있을 겁니다. 이때 critical range를 지정하면, 많은 path가 더 좋은 delay를 가지게 됩니다. (물론, sign-off시에는 110MHz로 STA해야겠죠?)
이렇게 보내면, P&R과정에서 WNS로 잡혔던 path에 대한 time-driven placement가 별 고민 없이 최적화를 시킬 수 있으므로, design house를 좀 잘못만나도 빠르게 timing closure를 이룰 수 있습니다.
결론적으로, 디자인 하우스를 잘 만나자! (농담입니다.^^;) critial_range를 이용하여 TNS 줄임으로, back-end에서 P&R에 따른 고민을 적게 하는 것이 좋겠습니다. ^^;
역시 뭐든 타이밍을 잘 맞춰야 합니다.
좋은 글 잘 읽었습니다 ^^
저희는 좀 더 수율을 높이기 위해서
GIO를 좀 더 과도하게 모델링하거나 process skew 값을 좀 더 키우거나 한 후 시뮬레이션을 돌리는 것 같아요…
… 아래 gif 그림은 은근히 중독성 있네요;;
front-end에서도, back-end에서도, 공정에서도 서로 마진 많이 달라고 싸우죠..^^; 마진이 많아야 실수해도 문제가 안 생길 여지가 많으니까요 🙂
안녕하세요. 우연히 들어와 좋은글 많이 읽고 있습니다. 저도 front만 하고(합성도 초보급이라..–; synplify_asic사용했습니다.) backend 를 외부업체에서 진행하고 있습니다. 합성시 clock constaint를 10% over-contrait 적용 후 STA에서도 over-constraint 적용해야 하나요? 제가 많이 미흡해서 그런데 설명을 부탁드려도 될까요? ^^ 앞으로 자주 들러서 많이 배워가도록 하겠습니다. 감사합니다.
일단 결론 부터 말씀드리자면, ‘회사의 정책마다 다르다’입니다.
STA시에는 over constatint를 주지않고 target freq.에 맞추는 것이 정석입니다만, 일부 회사에서는 칩이 나온 이후에 동작을 좀더 보장하기 위하여 충분한 마진을 가져가는 정책을 채택하는 곳도 있습니다.
실제적으로, 클럭에 대해서는 목표 주파수로 놓더라도, uncertainty의 경우 초기에 skew+PLL jitter를 고려한 것에서 skew 성분을 제외하고 PLL jitter 정도만 포함하는 것이 정석입니다만, 이 부분에서 약간의 마진을 포함하는 시키는 것이 일반적입니다.
어짜피 frontend나 backend에서 constraint meet하는 것은 실제 칩이 나왔을때 동작할 것이라는 “추정”이니, 좀더 마진을 가져가는 것이 제품에 입장에서는 좋겠지요.
답변 감사드립니다.^^ 그리고 다시 한번 좋은글 감사드려요..
이제 공부하기 시작한 초보입니다^^ design vision에서 endpoint slack이 어떤 의미인지 잘 모르겠어요.. 그리고 slack의 값이 양수이면서 0에 가까운 것이 좋은건가요, 아님 양수이면서 값이 크면 클수록 좋은건가요??
그 경우에는 합성을 하실때 constraint라는 것을 주셨을 텐데요.
slack은 설정하신 constraint 대비 해당 path의 지연 시간입니다.
예를들어 경로 지연을 10ns로 설정했는데, 해당 경로를 합성해 보니 4ns가 되었으면 +6ns slack이 됩니다.
만일 합성해보니 11ns가 되었다면 -1ns slack이 되겠지요.
어짜피 slack은 자신이 준 constraint와 비교하는 것이므로 크다고 좋은 건 아니고, 자신의 goal에 맞으면 좋은것이겠지요. (물론, 속도만 놓고 보면 slack이 positive로 크게 나오면 좋습니다. 단, 이걸 크게 하려고 -즉, constraint보다 빠르게 하려고- 노력할 필요는 없다는 거지요)
답변 감사합니다~~ 그리고 한 가지 더 질문이 있습니다.
design vision에서 그래프로 slack을 볼 수 있고 또 하나 endpoint slack이라는 것이 있던데
endpoint slack이 무엇인가요?
slack per endpoints 라고 보시면 될것 같습니다.
endpoint라는 용어는 path delay를 계산할 때 마지막 지점(endpoint), 즉 f/f의 입력, 혹은 output port와 같은 부분을 의미합니다.
하나의 endpoint에 대해서는 다수의 path가 존재할 수 있는데요. endpoint slack이라는 건 일반적으로 해당 endpoint에 걸리는 worst path의 path를 의미합니다.
Timing report를 뽑으실때 endpoint 마다 최대 몇개의 path를 뽑을지도 지정할 수 있지요 ^^;
제가 DesignCompiler위주로 작업하다 보니 design vision을 거의 사용을 안해서 기억이 가물 가물 한데, 혹시 endpoint histogram(맞나..)때문에 의문이 생긴 건지도 모르겠군요.
이넘은 전체적인 path delay의 분포를 보여주는 거라고 보면 되요. 이 posting에서 나온 것 처럼 TNS를 좋게 만들면 endpoint histogram이 잘 분포되는 결과를 보이구요, WNS 위주로 합성이 되면 constraint 부분에 histogram이 몰리는 현상을 보여주죠. 🙂
답변 정말정말 감사합니다~~ 정말 많은 도움이 되었어요~~ 감사합니다^^
안녕하세요 간간히 front-end 쪽을 공부하면서 참조하고 있습니다. 좋은 포스팅 감사드립니다.
Front End ASIC-Flow 중 한가지 궁금한것이 있어서요.이게 맞는것인지 제가 이해를 제대로 하고 있는것인지 궁금합니다.
먼저,
Design Compier로 RTL을 합성하고나면 gate level netlist 와 SDF(net delay 정보) ,SDC(디자인 constraint정보) 파일 그리고 DDC 파일을 출력할수 있는것으로 알고 있습니다.
여기서 TNS과 TWS이 전부 기준에 맞춰진경우
Auto P&R 에 SDC 파일을 전달하여 Clock Tree와 design배치 진행, 이후 Auto p&r 을 통해 만들어진 SDF 파일을 PrimeTime에 전달.
Primetime에서는 design compiler의 output인 gate level netlist와 auto P&R로 만들어진 SDF를 이용하여 STA 진행.
이후 STA를 통해서 만들어진 SDF를 Backend 분들에게 전달.
이렇게 이해를 하였는데요. 뭔가 좀 이상하게 제가 알고 있는 것 같아서 혹시 asic front end flow가 어떻게 되는지요?
요즘에 frontend 단계에서 부터 placement를 고려하는 경우가 있다는 점이 좀 다르겠지만, 큰 틀에서는 잘못된 것 같지 않습니다.
자잘하게.. test가 추가될 수 있겠고, prenet 단계에서는 DC의 SDF를 Primetime에서 prenetlist STA를, P&R이후에는 SPEF를 추출해서 PrimeTime에서 SDF를 추출하겠죠.
따로 backend 쪽에 보내주는 건 사실 필요하진 않습니다. (sign-off 이야기겠지요.)
답변 감사합니다. 한가지 더 궁금한것이 있어서 문의드립니다. 각자 설계한 디자인을 합처서 최상단 Top 레벨에서 합성을 하는경우 각 하위 레벨의 디자인의 SDC가 서로 달라서 합치기가 어려울것 같습니다. 예를들어 어떤 블럭은 set_input/output_delay margin을 너무 타이트하게해서 다른블럭에 많은 영향을 줄수 있을것 같은데요. 이렇게 제각각인 디자인 constraints 의 경우 상위 레벨에서 어떻게 관리를 하시는지 궁금합니다. ddc로 다른 분들 디자인을 읽을수 있다는데 top에서 전체 합성을 하려고 보면 전부 다른 SDC 내용으로 합성이 불가능 할것 같습니다. 물론 어느정도 기본 적인 클럭은 공통으로 가져가겠지만 그외 많은 부분들이 서로 안맞을텐데 Top에서는 어떤 방법이 있는지요?