Author Archives: babyworm

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기반에 익숙한 사람들이 안넘어오니까요..^^;


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

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

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

Fab과 EDA 업체들.. Fab은 울고.. EDA는 웃고?

EETimes의 RSS newsfeed를 보고 있노라면, 때가 때인지라 요즘 3/4분기 매출현황들이 이곳 저곳에서 발표되고 있습니다.

뭐, 공돌이라 사실 매출에 별 관심 없기에 별로 신경 안쓰고 제목정도만 보고 있는데요.. 재미있게도 파운드리 회사들은 대부분 매출 실적이 별로인데 반해서, EDA는 실적이 나쁘지 않더군요.. 그래서 좀 봤습니다.

파운드리쪽을 보면…
SMIC는 적자라고하고, TSMC는 흑자폭이 줄어들었다고 하네요.. 아, UMC는 매출이 늘었다네요..
국내 Fab인 동부 전자는 어떤지 모르겠네요. 작년에는 8위 였는데 말입니다.
종합 반도체 회사인 삼성이나 매그나 칩같은 곳은 따로 매출/수익률 발표가 안되는지 모르겠구요..(매그나 칩은 작년 5위였네요!)
GSMC, Siltera같은 신생 Fab이 어떤지도 궁금한데.. 별 소식은 없습니다. (아 검색해보니 GSMC가 2004년에는 가장 성장한 파운드리사로 선정되어 있네요.. ^^; 저희 회사에서는 GSMC 라이브러리 버그땜에 고생한 경험이 있어서 -_-;)

이에 비하여, 3/4분기 내용을 발표한 EDA는 대부분 나쁘지 않군요..
Mentor는 애널리스트의 예측보다 훨씬 많은 수익을 냈다고 보고되었구요..
Cadence같은 경우도 작년 같은 분기보다 많은 수익을 냈다고 하는군요..

파운드리 회사들이 미세 공정에 투자하는 돈보다, EDA에서 미세 공정을 지원하는 툴로 버는 돈이 더 많은 건 아닌지 모르겠습니다. ^^;
미세 공정으로 가면서 예전에는 고려하지 않아도 되었던 문제들이 더 많아지고, 이는 새로운 EDA툴의 구매로 연결되는 것이니까요..
이에 반해서 파운드리 회사는 NRE나 silicon 비용 더 받더라도, 직접적인 기술 투자라던지 장비에 대한 투자가 무시 못할 정도니.. 이런 경향이 더 심해지는 것이 아닌지 모르겠습니다. ^^;

참고로, 2005년 파운드리 회사 순위가 있기에 EETimes에서 가지고 왔습니다.

[#M_파운드리 순위보기|less..|2005년 파운드리 회사 순위

1. Taiwan Semiconductor Manufacturing Co. Ltd. (TSMC) remained as the world’s largest foundry with 44.8 percent market share in 2005. TSMC’s sales hit $8.22 billion in 2005, up 7.2 percent over 2004.

2. Taiwan’s United Microelectronics Corp. (UMC) remained as the world’s second largest foundry with 15.4 percent market share in 2005. UMC’s sales hit $2.82 billion in 2005, down 19.3 percent over 2004.

3. SMIC jumped from fourth place in 2004 to the third spot in the 2005 rankings with 6.4 percent market share. SMIC’s sales hit $1.17 billion in 2005, up 20.1 percent over 2004.

4. Chartered fell from third place in 2004 to the fourth spot in the 2005 rankings with 6.2 percent market share. Chartered’s sales hit $1.13 billion in 2005, up 2.6 percent over 2004.

5. IBM Corp. remained as the world’s fifth largest foundry with 4.5 percent market share in 2005. IBM’s foundry sales hit $832 million in 2005, down 2.1 percent over 2004.

6. South Korea’s MagnaChip Semiconductor Ltd. jumped from seventh place in 2004 to the sixth spot in the 2005 rankings with 2.2 percent market share. MagnaChip’s foundry sales hit $396 million in 2005, up 10 percent over 2004.

7. Taiwan’s Vanguard International Semiconductor Corp. fell from sixth place in 2004 to the seventh spot in the 2005 rankings with 1.9 percent market share. Vanguard’s foundry sales hit $354 million in 2005, down 9.8 percent over 2004.

8. South Korea’s Dongbu Semiconductor Ltd. jumped from ninth place in 2004 to the number eight spot in the 2005 rankings with 1.9 percent market share. Dongbu’s sales hit $347 million in 2005, up 4.2 percent over 2004.

9. China’s Shanghai Hua Hong NEC jumped from tenth place in 2004 to the ninth spot in the 2005 rankings with 1.7 percent market share. The company’s foundry sales hit $305 million in 2005, down 5.7 percent over 2004.

10. U.S.-based Jazz Semiconductor Inc. jumped from 12th place in 2004 to the tenth spot in the 2005 rankings with 1.1 percent market share. The company’s sales hit $210 million in 2005, down 4.5 percent over 2004.

_M#]

신입생에게 C/C++은 독인가?

CN님의 블로그에서 “가장 어리석은 선택: C언어“라는 약간은 자극적인 글을 보고나니, 제목자체에서는 약간 거부감이 있었습니다만, 본문과 댓글을 보고는 여러가지 공감도 가고 그렇습니다. 여하튼..

제 입장에서 생각하면, C언어는 배울만한 충분한 이유가 있는 언어이나 학교에서의 교육 방법에 문제가 있는것 아닌가 생각하는 것입니다.

컴퓨터 공학 교육이 언어 및 머신에 대하여 독립적이면 좋다는 것은 맞습니다만, 컴퓨터 공학 분야의 대부분의 이론이 언어를 사용하지 않고 수학적 이론으로 풀면 상당히 어려운 수준에 도달합니다. (저 같은 경우 대학원 과정에서 컴퓨터에서의 덧셈 연산 수행 과정을 수학적으로 모델링하고 분석하는 법을 배웠을때 솔직히 머리 터지는 줄 알았습니다. ^^; ) 따라서, 예가 될 수 있는 언어를 사용하는 것이 좋겠지요.

그 예제 언어로서 가장 많이 사용되는 것이 C/C++/java 시리즈인데요..
CN님의 비판 포인트는 C 형제들이 이런 목적에 부합하냐.. 이것이시겠죠.. ^^;
다른 좋은 언어도 많은데.. 교육적으로..

네.. 제 생각에도 학생들이 C언어라는 것을 배우는 것은 매우 이른 시점이며, 대부분 컴퓨터 시스템에 대한 이해가 없는 상태에서 컴퓨터 시스템에 대한 이해가 필요한 C언어를 배운다는 것이 비극의 시작이라고 생각합니다.
더 중요한 문제는 많은 교수님들/강사님들께서 문제 출제를 위하여, 별 필요없는 문법적 지식에 목을 매서, 아주 희안한 코드를 그려넣고 이게 어떻게 동작할지 맞춰보라는 문제를 내기 때문에 좌절스러운 것이라 생각합니다.
예를 들어, printf의 그 많은 format을 알아서 뭐하겠습니까.. 간단히 훓고 지나가서 나중에 필요할때 reference manual보면 되죠.. 포인터의 포인터의 포인터, 포인터의 괄호 결합 순서를 배워서 뭐하겠습니까? ^^; 물론 필요 있습니다만, 이거 쓰는 경우 거의 없잖아요.. 근데, 문제내기 좋은 항목들이니 자세히 알려줍니다.
많은 학생들이 C 언어의 pointer 부분에서 절망하는 가장 큰 이유는 컴퓨터 구조에 대한 이해가 없는 상태에서 pointer를 무지막지하게 가르킨다는 점때문이라 생각합니다.

C언어를 가르키는 이유가 절차적 언어에 대한 감각을 익히고, 컴퓨터 시스템에 대한 전반을 이해하는 것으로 목표를 두어야 하고, 거기에 C를 배우는 가치가 있다고 생각하는데.. 현실의 교육은 언어적 테크닉에 집착하는 경우가 많으니까요..(사실 말이 쉽지 가르킬때 쉽지 않을 것이라는 것을 너무도 잘 압니다.)

Computer architecture를 전공한 입장에서 이야기드리자면..

Computer architecture라는 개념적인 과목보다 C가 앞에 있어야 하냐는 판단하기 어렵습니다. 단, C에 익숙한 친구들은 computer architecture 과목에서 많은 부분을 쉽게 따라오는 것이 사실입니다.

그럼 computer architecture가 1학년 과목으로 가면… 너무 가혹하겠지요.. ^^;
포인터에 사용되는 memory system도 머리가 아픈 판국에 register니, bus니 배우는 건 아무리 봐도 좀 무리가 있습니다. 게다가 assembly 언어를 고급언어에서 배웠을 개념적인 도움없이 직접 들어가는 건 설명하기가 너무 어렵더군요..
3학년 과목으로 간다면.. computer architecture가 기반이 되어야 할 compiler 이론이나(물론 machine dependent optimization을 고려하지 않은 RTL상태의 최적화만 다룬다면 가능하겠습니다만..), OS 이론, digital system쪽은 4학년으로 이동해야 하는 불행이 있겠구요..

여러면으로 보았을때 컴퓨터 시스템에 대한 기반을 알려줄수 있는 C가 선두에 서는 것이 유리하죠..
단지 문제는 받아들일 준비가 안된 학생들에게 C가 튀어나오면서 “언어”와 “구조” 두가지를 모두 강요하다 보니 벅차다는 것이 문제겠죠.. 그걸 잘 연계해서 알려주시는 분들도 부족하구요..

C 언어의 효용성 부분인데요..
우선, C 언어를 배우면서 컴퓨터 시스템 전반에 대한 이해를 얻을 수 있구요(제대로 배웠을때 이야기지요..^^;)
(제가 소프트웨어직에 종사하지는 않습니다만)소프트웨어 분야에서 C/C++/java의 위상이 그렇게 떨어지지는 않았을것이라고 생각하구요..^^;
제가 종사하는 ASIC, SoC 쪽이나 관련있는 embedded 쪽은 C/C++를 모르면 좀 살아가는 것이 어렵겠다 싶을 정도로 중요합니다. 정말 “언어”처럼 사용되거든요.. 문서로 수십장 적어서 동작을 기술하는 것보다 C로 간단히 함수 하나 던져주는 것이 더 명백하거든요.(executable spec이라해서, 매우 일반화되어 있답니다.)

C 언어는 computer architecture로 가는 길을 열어주는 언어이기 때문에 어찌보면 최선의 선택이라 할수 있지만, 학생의 입장에서는 부담되는 언어임이 확실하고.. 만일 C 언어의 교육 이유를 이해하지 못하는 교육자분들께서 수업을 맡으신다면 최악의 선택이 되겠습니다.

역시 최선과 최악은 붙어있는 건가요..^^;

p.s.
그러고보니, computer architecture에 대한 이해가 필요없는 분야에서는 뭐 굳이 C가 필요없지 않을까요?
교양과목으로서의 컴퓨터 언어로는 정규식도 배울수 있고 제어구조도 나쁘지 않은 perl, python 형제같은 것이 훨씬 더 편하지 않을까 생각되네요..(다른 많은 언어가 있겠습니다만.. 제가 아는 언어는 몇개 없는 관계로..)
그런데.. computer architecure의 기반이 필요치 않은 CS쪽 과목이 많나요? ^^; (직접적인 출신이 CS가 아닌 EE다 보니..^^;)