Category Archives: SoC & IP design

Synopsys의 Synplicity 인수!

EDA Design Line 오늘자 기사를 보니 ASIC 합성분 야에서 압도적인 market share를 확보하고 있는 Synopsys가 FPGA 분야에서 가장 유명한 합성툴인 Synplify를 가지고 있는 Synplicity를 인수했군요. 현금으로 주당 $8으로 인수한 것이고 시장가 대비 약 50% 프리미엄을 주고 인수한 것이랍니다.


이제 논리 합성분야에 있어서는 Synopsys가 ASIC과 FPGA 양 분야에서 압도적인 영향력을 행사할 수 있게 되었군요. 몇 차례 언급한 바가 있습니다만, 논리 합성이라는 시장이 비메모리 분야에서 가장 중요한 분야 중의 하나이고, idea 단계를 실질적인 physical design으로 넘기는 일차적인 관문이므로, 이후의 P&R 시장 뿐 아니라, RTL 설계에 있어서의 coding style이라던지, DFT등에 미치는 영향이 아주 큰 부분입니다.


예전부터 Synopsys가 FPGA-express라던지 DC-FPGA등등의 툴로 FPGA 시장을 넘본 적이 있습니다만, 현재로서는 상당히 지지부진해진 상태였는데, Synplify의 인수를 통해서 급격히 성장하고 있는 FPGA market을 노리는 것으로 생각해 볼 수 있겠습니다.


Technorati : , ,

Coding style; 잘 사는 방법

예전에 C 언어를 한참 할때, 코딩스타일이란 이야기를 처음 들었었습니다. K&R style이라느니, ansi style이라느니.. 그런 것이지요. indent를 2를 써야 한다.. 아니다 4를 써야 한다 등등도 있었구요.
Windows API에 와서는 이게 좀 더 복잡해져서 hungarian 표기법이 등장했습니다.
그런데, Verilog HDL에서는 이 Coding Style이라는 것이 아주 중요한 요소로 등장하고 있지요.

코딩 스타일이란 쉽게 이야기하자면, 어떤 설계를 하고자 할때, 혹은 어떤 표현을 하고자 할때 사용할 수 있는 방법이 여러가지가 있겠지만, 이런 형태로 표현 하는 것이 어떠냐~ 라는 식의 일종의 가이드입니다.
HDL에서는 FSM에서 one-hot을 표현하는 방법이라던지, mux를 합성하는 방법이라던지와 같은 언어적인 특성을 잘 표현하기 위한 가이드도 있고, negative edge신호는 n으로 끝나고, 플립플롭의 출력은 _r로 끝난다는 등의 이름 정하기 규칙(네이밍 룰), 그 이외에 indent(들여쓰기)는 tab이 아닌 2칸의 공백 문자로 한다는 등등일 일반적인 가이드를 포함합니다.

HDL에서 코딩 스타일이 중요한 이유는 여기에서도 간단히 말씀드렸습니다만, 생각하면서 따져나가야 하는 약간은 미묘한 문제들을 쉽게 (머리쓰지 않고 기계적으로.. 혹은 습관적으로) 해결할 수 있는 방법이 되는 경우가 많기 때문입니다. 또한, HDL의 경우 궁극적으로 “하드웨어를 만들기 위한 언어”이므로, 어떤 방식으로 기술하는 것이 로직 합성기에서 가장 잘 이해하도록 만들어서 원하는 하드웨어의 형태로 가장 효과적으로 만들어질 수 있도록 잘 기술하는 것이 필요한 것이지요.

대부분의 문제는 좋은 코딩스타일로 해결 가능합니다. 그리고, 코딩 스타일과 코딩 가이드를 적절히 조합한 문서가 제 블로그에서 몇번 소개해 드린바 있는 Reuse Methodology Manual 입니다.

하지만, 가끔은 코딩 스타일로 부족할 때가 있지요. 이럴 때 보통 synthesis directive를 줍니다.
synopsys툴은 ‘//synopsys 어쩌구’.. synplify는 ‘//synthesis’ 로 시작되고, verilog 2001에서는 이 synthesis directive주는 방법이 통일 되었지요.. 그래도 저는 synopsys를 사용할 때 //synopsys 어쩌구를 계속 사용하고 있습니다..  ^^;

가장 유명한 synthesis directive는 바로 Donny님의 posting에 나온 SNUG99논문(Sunburst의 Cumming씨 논문으로 기억되는데요..Cumming씨의 SNUG논문들은 synopsys툴을 이용해서 verilog를 사용하시는 분들에게 아주 좋은 아이디어를 많이 제공해 줍니다. – 설계적인 측면이 아니라 코딩의 기술적인 측면에서 말이지요)에서 언급된 case문을 지배하는 evil twins이지요.
case문에서 parallel case는 MUX와 같이 priority가 없는 로직을 만드는 순서 없는 case를 만들어 낼 때 사용이 되고, full case는 그야 말로 fully covered case를 나타내지요.. 근데, 좋은 약도 남용하면 독이 되듯, 이 좋아보이는 synthesis directive도 잘 알지 못하고 쓰면 오히려 독이 되어 불필요한 latch를 만들 수도 있는 법이지요. 자세한 것은 도니님이 남겨주신 문서를 참조하세요. ^^;

제가 회사에서 강조하고 있는 건, “합성시에 case문에 대한 분석이 auto로 나오도록 만들 것입니다.”
auto 로 나온다는 것은 코딩 자체에서 “parallel case”혹은 “full case”를 cover 하고 있다는 의미이거든요. 즉, one-hot FSM과 같이 특별한 케이스로 directive의 사용을 제한하고 있지요.

이런 코딩 스타일은 궁극적으로 설계자들에게 불필요한 고민을 줄여주어, 1분이라도 시간을 더 확보하게 함으로써 삶의 질을 높일 수 있는 기회가 될 수 있겠습니다. (혼자만의 논리적 비약일까요?)
귀찮고, 당연한 이야기 같더라도 코딩 스타일.. 꼭 숙지하세요.

p.s. 여담인데, 저의 경우 excel도 훌륭한 코딩 툴로 사용됩니다. 약간 복잡한 case를 다룰때 말이죠 ㅎㅎ, csv format으로 뽑아내는 재미가 쏠쏠하죠.

동기가 가장 중요합니다.

가끔은 여러가지 경로(직접, 메일로, 게시판으로..)로 진로에 대하여 상담해 오시는 분들이 계십니다. 제가 아직은 배우는 과정에 있는 사람이고, 수많은 값진 경험을 가진 선배님에 비하면 습자지 한장 두께도 되지 않는 얇팍한 지식과 일천한 경험을 가졌을 뿐이지만, 질문해 오신 후배님들께 도움이 되었으면 하는 바람으로 답변을 장황하게 해 드릴때가 많습니다.
원래 많은 것을 아시는 분들은 간단하고 명료한 말로 잘 설명해 주시지만, 저처럼 아직 부족한 사람들은 빈깡통 소리를 내는지라, 주저리 주저리 말이 많은 거죠.

여하튼, 이때 빠지지 않고 드리는 이야기가 “즐길 수 있는 것을 선택하라“는 것입니다.

남은 생활동안 상당 기간을 이 일을 하면서 지내게 될 것인데, 그 선택의 기준으로 이것보다 좋은 것이 있을까요?

돈을 잘버는 것. 중요합니다.
다른 사람에게 존경 받는 것. 중요합니다.
편한 것. 중요합니다.
성취감을 얻어내는 것. 중요합니다.
재미 있는 것. 중요합니다.

“비전”이 있나요? 라는 질문에 대한 답이 가장 어렵습니다. 그 기준에 따라 비전이 있는지 잘 모르겠으니까요. 엔지니어라는 대부분 돈과는 좀 거리가 있는 듯 해요. (물론, 박봉에 시달린다는 이야기는 하지 않겠습니다. 하지만, 요즘 후배분들의 기준이 워낙 높으니까요 ^^;)

계속 공부해야 하고, 계속 습득해야 하는 분야이다보니, 자신의 현재 모습에서 할수 있는 능력을 소모만 해서는 안되는 분야지요.

이런 조건을 충족시키자면,  “Self Motivation을 가진 사람이 되어야 하는 것[1]이 이야기는 사실 제가 연구실에 들어가서 가장 먼저 교수님으로 부터 들은 조언들 중의 하나입니다. ”이지요. 제게 있어서는 self motivation을 충족시키는 가장 큰 요소가 “재미”와 “성취감”이라고 생각합니다.

재미란 건 모든 사람이 다른 기준을 가지고 있는 법이니, 제가 조언해 드릴 수 없는 부분이고..

제가 말씀 드릴 수 있는 건, 이쪽 업계에 들어 오시고 싶어하시는 분들께 어떤걸 공부하는 것이 좋은지, 여러분이 지금 배우고 있는 것이 이쪽 분야에서 얼마나 중요한 것인지 정도만 이야기 할 수 있는 것이지요. ^^;
주변에 계신 선배분들과 교수님과 적극적으로 상담하세요.

Notes & References

Notes & References
1 이 이야기는 사실 제가 연구실에 들어가서 가장 먼저 교수님으로 부터 들은 조언들 중의 하나입니다.