Synopsys XG모드로 가야 하나..

사실 logic synthesis에 있어서 synopsys design compiler가 가지고 있는 비중은 정말로 큽니다.

ASIC designer가 거치는 전체 설계 flow에서 logic synthesis는 어찌보면 implementation의 시작지점이기 때문에 아주 중요합니다.
거기서 만들어진 netlist의 질, 지정된 constraint들이 이후의 툴들에 얼마나 효과적으로 반영될 수 있는가.. 등등..

Synopsys가 design compiler라는 툴로, 이 logic synthesis를 잡아버리면서 (90%이상의 점유율이랍니다.. 완전 독점에 가깝지요..), 이 강력한 파급력으로 DFT, Floorplan, P&R까지 이전의 강자들을 무너트리고 있는 상태입니다.

물론, 다른 회사들도 이 황금어장을 그냥 놓아둘수 없었던지, cadence는 build gates라는 툴로, mentor는 percision으로, synplicity는 synplify AISC으로 대항하고 있지만.. 흠.. 안타깝게 아성은 무너지지 않고 있으며 오히려 더 견고해지고 있는 느낌입니다.

여하튼..

지난번에 synopsys의 topographical synthesis에 대하여 잠시 말씀드렸었는데..오늘 말하려 하는 것은 synopsys가 2004.06버젼부터 선보인(혹 틀릴수도 있어요..) XG 모드라는 것입니다.

처음에 XG모드는 memory를 더욱 효율적으로 사용하고, 더 빠르게 분석할 수 있도록 하자는 목적으로 기존의 DB형식을 대치하려 개발된 synopsys의 내부 표현 저장방식입니다.

저는 개인적으로 예전에 XG모드를 썼다가 크게 덴 적이 있습니다.
온갖 수사로 포장된 2004.06에서의 XG모드… SNUG에 tutorial로 설명된 것으로 보고 혹~ 해서 얼마간 썼었는데..DB모드에서는 정상적으로 합성되는 verilog HDL 소스들이.. 죽기도 하고, 운좋으면 합성되는데 netlist가 이상하기도 하고… 온갖 고생을 시겼었습니다.

그 이후 사실 쳐다보지도 않고 있지요..^^; (소심해서..)
새로 구입한 Design Compiler 2006.x 버젼은 실행시키면 바로 XG,TCL모드로 뜨는데, 일부러 db_mode로 띄워서 쓸 정도니까요..

그런데, 얼마전에 DFT compiler 교육에 교양삼아 참가했었는데, XG모드 이야기가 나오더군요..
뭐, 여러가지 “XG 좋네~ 쓰세요~” 이런류의 이야기 말미에.. “2007년부터 DB 모드는 없어집니다.”

캬아악~! DB모드가 없어진다구? orz

1993년 1월호 마이크로 소프트웨어 커버 기사의 이름이 생각납니다.

“이제는 변화에 순응해야 할때…” (C++의 시대가 온다.)

음.. 이제는 XG모드에 맞춰서 스크립트도 작성해야 겠군요..
사실 뭐, 바뀐다고 별일 있겠습니까..
단지, XG모드에 익숙해지고, 믿어가는데 시간이 좀 필요할 뿐이지요.^^;

Synopsys는 꽤 오랜 시간 XG모드로의 전이에 공을 드려왔습니다. 뭐, 여러가지 최적화된 결과를 보이는 모드니까요.. QoR의 관점에서 XG가 월등하다고 보는데, db기반에 익숙한 사람들이 안넘어오니까요..^^;

XG 모드로 이전하기 위한 모든 정보가 있는 곳.

자.. 이제 변화에 순응합시다..

p.s.
DFT Compiler Lab에서 사용해본 DC-XG 모드는 아주 훌륭하더군요.. 속도도 훌륭하고.. ^^;
거기 랩하는 동안 시간이 남아 topographical synthesis도 해봤는데.. 초반에 library 분석하는 데 꽤 오랜 시간이 걸리더군요.. 라이브러리 셋팅이 되고나면, 그 다음 부터는 빠릅니다.

아! 또한가지 design vision 새버젼은 Solaris 버젼을 타더군요.. Solaris 업데이트하시고, DC2006.0x를 깔아야 합니다.

DC Ultra의 Topographical Synthesis

로직 합성에 많이 사용되는 Design Compiler에서는 전통적으로 통계적인 wire load model을 이용하였습니다.
즉, 합성된 로직의 크기가 어느정도라면, 이때 적용되는 wire의 R, C값이 어느정도가 될지 대략 통계값을 통하여 추정하는 방법입니다.

이러한 wire load model은 0.35um 이전의 공정까지는 어느정도 적용하는데 큰 무리가 없었습니다.
왜냐하면, 로직의 지연(delay)에 있어서 대부분이 cell이라 불리는 logic primivie에서 발생하였기 때문입니다.

그러나, 0.18um 이하의 공정으로 내려가면서 wire load model(이후 WLM)을 이용하는 방법은 한계에 부딛히게 되는데요, cell에 의한 경로 못지않게 wire delay의 비중이 커졌으며, 요즘에 와서는 cell보다 wire delay의 비중이 많이 늘어났기 때문입니다.
따라서, 기존의 WLM을 이용해서 합성한 모델은 그 정확성에 문제가 있기때문에 P&R을 하고 난 이후의 결과와 현격한 차이가 발생하여, synthesis -> P&R -> in-place optimization의 과정을 수회 거쳐야지만 정상적인 chip을 만들어낼 수 있게되는 것입니다. 이는 전반적으로 설계 효율시간에 문제를 발생시킵니다.
(보통 synthesis에서 10%이상의 over constraint를 주고 합성해야, P&R에서 비슷한 값을 얻을 수 있곤합니다. 이러한 문제가 발생하는 가장 큰 이유는 WLM의 부정확성에 있습니다.)

이를 극복하기 위하여 처음에 나왔던 방법은 Custom WLM방법입니다.
즉, 시작은 WLM으로 합성하고, P&R을 통하여 Custom WLM을 만들어낸 후 이를 이용하여 synthesis함으로써 해당 칩에 좀더 가까운 wire load model을 사용할 수 있도록 하자는 방법입니다.
이 방법은 0.35um부터는 당연히 사용되어야 하는 방법으로 정착하였습니다.

또다른 방법은 physical synthsis라는 방법인데, physical compiler라는 설계 도구에서 방법적으로 정착되었습니다. 이는 synthesis단계에서 pdef(floorplane정보)를 이용하여 가상적으로 place를 해보고 이를 이용해서 각 cell간에 좀더 정확한 경로 지연을 찾아낸다는 기법이었습니다.

”]
이렇게 발전해 나가던 것이 이제는 DC에 모두 통합되었습니다.
DC ultra에서 topographical synthesis라는 이름으로 모두 통합되었습니다.

이전의 DC ultra는 automatic hierarchycal ungroup과 같은 기능을 가지고 있는 것이었는데, 이제는 physical compiler에서 발전한 topographical synthesis기능까지 추가되어, P&R이후와 가장 근접한 형태로 합성해 낸다고 합니다.

뭐, synopsys의 발표자료는 거의 다 좋다는 것이겠구요..^^;

ESUNG에 보니 상당히 개선된 것 같습니다. (http://www.deepchip.com/items/0457-05.html)
회사에서는 라이센스 비용 관계로 아직 사용하지 못하지만.. (ㅠㅠ) 아주 기대되는 기술입니다.