Category Archives: CAD tools

Precision이 Synplify Pro보다 좋은 성능을 낸다고 하네요.

2 Replies

Mentor의 FPGA 합성 툴인 Precision.

FPGA 합성 도구.. 삼파전?이라는 글에서 잠시 다룬적이 있는데, 사실 그 글을 사용할때는 예전 FPGA Advantage에 번들링 되어 있던 Precision을 생각하고 썼었는데요..

ESNUG의 글을 보니 Precision이 Synplify Pro보다 더 좋은 결과를 내준다는 보고가 최근에 들어왔네요.

게다가 가격은 Synplify Pro의 1/3 이라고하니 가격 경쟁력도 있습니다.

나중에 한번 evaluation을 해 볼까.. 하는 생각이 드네요..
회사에서 FPGA는 prototyping정도로 밖에 안쓰는 관계로 그리 심각히 필요치가 않다는 것이 문제지만요..

FPGA design을 많이 하시는 분들은 Precision을 고려해 보시는 것도 좋겠네요.
IDEC의 지원을 받으시는 학생 분들은 두 가지 좋은 툴을 골라 쓸 수 있으니 얼마나 행복하십니까. ^^;

IDEC의 사업을 통해서 tool에 익숙한 엔지니어들이 많이 배출되는 건 아주 긍정적입니다. 학생때 왜 좀더 열심히 툴을 쓰지 않았나 몰라요..^^;

FPGA 합성 도구.. 삼파전?

8 Replies

[wp]FPGA[/wp]의 사용이 늘어나면서 이쪽 합성 분야에 눈독을 들이는 회사들이 늘어나고 있군요..

사실 FPGA 설계/합성 도구는 무료로 제공되는 경우가 많아서.. ([wp]xilinx[/wp] webpack이나 [wp]altera[/wp]의 quartus II web version과 같이 말입니다.)비교적 돈이 덜 됩니다만.. 무료로 제공되는 설계도구가 비교적 약한 편이라, 다른 툴을 많이 찾아다니게 되지요..

게다가 많은 FPGA 업체들이 simulation과 logic 합성 자체는 3rd party툴에 도움을 받고, P&R쪽만 in-house 툴을 사용하는 방향으로 나아가고 있는데.. 각 회사의 입장에서는 아주 합리적인 선택입니다.

Simulation에서는 가장 많이 번들링 되고 있는 것이 아무래도 [wp]Mentor[/wp]의 [wp]Modelsim[/wp]이지요. (사실 modeltech의 것이지만..)
국내에서 학생 유저들이 가장 많이 사용하는 시뮬레이터일텐데요.. 윈도우 환경에서 안정적인데다, verilog/VHDL/SystemC까지 가리지 않고 컴파일해서 single kernel로 시뮬레이션하는 능력을 지닌 좋은 시뮬레이터 입니다. 산업체에서는 아직 Golden simulator로 받아들여지는 NCsim에 밀리지만, 많은 엔지니어가 사용하고 있는 좋은 시뮬레이터입니다. (이 이야기는 주관적인 내용이 아니고 ESNUG 설문 결과인데 modelsim은 폭 넓은 사용자에 비해서 golden simulator라기 보다, secondary simulator느낌으로 사용되고 있습니다.)

FPGA 합성툴로는 우선 xilinx나 altera의 자체 툴이 있겠지요.

사실 저는 altrea툴을 max-plusII 시절에 많이 사용하고, quartus는 초기 버젼만 잠시 다루어봐서 평가하기 어렵습니다만.. 좋은 인상은 받기 어려웠습니다.
Xilinx의 XST도 역시 뭐 그리 잘 만들어진다 볼 순 없겠습니다. 물론, 예전에 비하면 아주 좋아졌습니다만 말입니다.

오늘 제목에 FPGA 합성도구 삼파전이라는 약간 “찌라시틱”한 제목은 사실 FPGA 제조사의 툴은 제외하고 3rd party의 FPGA합성도구 3가지를 보려고 합니다.

첫번째로 FPGA 합성 시장에서 가장 많이 사용되고 있는 synplicity의 synplify가 있습니다. 얼마전에 보니 국내 지사도 생겼더군요.. SCOPE라는 손쉬운 constraint editor도 있고, 그림도 이쁘게 보여주더군요..
가장 좋은 점은 합성 결과가 만족스럽다는 점입니다. 특히, DSP function을 지정하는 경우 이것을 각사의 macrocell로 변환을 아주 잘하는 편입니다.
최근에 synplicity가 synplify의 힘을 믿고 synplifyAISC을 발표해보았습니다만.. 합성시에 오류가 몇개 발견되고 있다네요…아직은 ASIC진입은 좀 이르지만, 시간이 지나면 어찌 될지 모르겠습니다.

약간 민감하긴한데.. 현재로서는 FPGA합성 부분에 있어서는 가장 좋은 방법이 아닐까 생각합니다.





[image source: synplify homepage]

두번째는 합성 시장의 절대 강자.. synopsys의 DC-FPGA입니다.
사실 synopsys는 예전에 FPGA-Express라는 툴을 갖추고 있었고 Xilinx에 번들로 제공했던 적도 있었습니다. 하지만, 명성에는 조금 못 미치는 툴이였는데, 이를 자사의 flagship tool인 Design Compiler에 접목하려는 노력을 하더니만(ASIC to FPGA migration guide가 있었지요..), 결국 DC-FPGA라는 이름으로 나왔지요.
DC에 익숙한 엔지니어가 워낙 많아서 이것도 비교적 많이 사용되고 있다고는 합니다만, 새로운 디바이스에 대한 지원이 좀 느린것이 단점이랄까요.. 요즘에는 약간 시들한 느낌입니다.
하지만, 워낙에 ASIC flow상에서 강하니까, script상에 별 변경없이 FPGA를 만들수 있다는 건 큰 장점이겠지요.




세번째는 이글을 쓰게된 직접적인 계기인 mentor의 precision이라는 합성도구 입니다.
사실 precision은 예전에 mentor의 FPGA advantage를 evaluation해보면서 처음 접해봤었는데.. Le사실 사라진줄 알았습니다. ^^;
그런데, EETimes의 기사를 보니 아직도 건재하고, 많은 기능이 추가된 것 같습니다. DesignWare의 지원이나 Clock Gating지원, DSP/Memory macrocell inference기능들을 지원한다는 것으로 보아 상당한 수준으로 올라왔군요..


Precision Physical
[image source: mentor homepage]

ASIC logic합성쪽은 DesignComiler가 압도적인 우위를 점하고 있는 가운데.. BuildGates, Synplify ASIC같은 것들이 도전하는 형국이고..

FPGA 합성쪽은 Synplify가 가장 우위를 점하고 있지만, DC-FPGA, Precision의 추격도 가속화되고 있는 느낌입니다.

뭐.. 사용자야 즐겁지요..^^;

Design Compiler의 TNS, WNS..

13 Replies

오늘은 지난번 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에 따른 고민을 적게 하는 것이 좋겠습니다. ^^;

역시 뭐든 타이밍을 잘 맞춰야 합니다.