Category Archives: SoC & IP design

Cygwin1.7에서 Eclipse CDT 사용하기

Leave a reply

요즘 뭐 좀 할일이 있어서 깔아 쓰고 있는데요..

예전에 eclipse CDT를 사용했을 때는 eclipse따로 CDT를 따로 설치해야 했고, CDT도 멋지기는 했어도 아주 매력적인 툴은 아니었는데, 새로 깔아본 CDT는 그때보다 더 멋진 툴이 되어 있군요.
그런데, 문제는 CDT가 cygwin 1.7버전(요즘 배포되는 windows7 호환 버전이죠.)을 사용하면서 cygwin gcc를 정상적으로 인식하지 못한다는 점입니다.
gcc를 인식하더라도, gdb와 연동에 문제가 생긴다거나 하는 문제도 약간씩 있구요.

지금 공식 배포되고 있는 Eclipse Galileo 버전에 붙는 CDT 6.x 버전은 cygwin 1.7 버전과 여러 가지 문제가 있다는 거죠. 

이 문제의 해결 방법(?)을 결론적으로 말씀 드리자면,
이 문제는 CDT의 다음버전인 7.x대 버전, 즉 Eclipse Helios버전에 들어가는 CDT에서 해결되어 정상적으로 동작할 것입니다. (아.. 이거 무슨 허무개그도 아니고..)

여하튼, Helios는 6월에 공개를 목표로 한창 작업이 진행중이죠. 지금 받아 볼 수 있는 버전은 milestone 6 버전(Eclipse Helios M6)입니다. (물론, nightly build도 받을 수 있지만 testing에 문제가 있을 수 있으니 아무래도 milestone 버전을 받는 것이 안전하겠죠)

Cygwin1.7이 깔려 있는 것을 가정하고 말씀 드리죠.

  1. http://www.eclipse.org/downloads/ 에서 development build 탭을 선택하시고, Eclipse IDE for C/C++ Developers (83 MB) 를 선택합니다. (이 링크는 몇 일만 지나도 구 버전을 가르키고 있겠죠. 되도록이면 직접 들어가셔서 최신 버전을 다운로드 받으세요)
  2. GDB를 정상적으로 사용하시려면 Eclipse의 RSE를 받으셔야 합니다. (이걸 몰라서 한참 동안 고생했습니다.) http://download.eclipse.org/dsdp/tm/downloads/drops/R-3.1.2-201002152323/ 요기 들어가면 최신까지는 아니더라도 사용하는데 큰 지장 없는 버전을 받으실 수 있습니다.
  3. 이제 eclipse의 압축을 푸시고, 같은 디렉토리에서 RSE도 압축을 풀어주세요 (음.. 압축 파일 디렉토리 구조를 보시면 아시겠지만, 둘다 eclipse 부터 시작하는 디렉토리 구조를 가지고 있어서 같은 디렉토리에서 풀어 주면 알아서 적절한 위치로 들어갑니다. )
  4. eclipse를 실행시키고 workplace(작업할 디렉토리죠)를 지정하고 실행하면 됩니다.
  5. 즐기세요

아주 간단하죠.

아.. 혹시 cygwin1.dll이 있는 [cygwin설치디렉토리]/bin 디렉토리를 윈도우 환경변수상에 path로 지정하지 않았다면 정상적으로 프로그램을 수행시킬 수 없을 수 있습니다. 되도록이면 환경변수상에 path로 설정하세요. (물론 다른 방법도 있지만.. 흠.. 말하는 것이 더 혼동을 드릴지도)

참고로 Eclipse Galileo버전에 붙는 CDT 6.x를 cygwin 1.7에서 동작하게 하려면 약간 작업이 필요합니다.

느낌상으로는 디버깅이 정상적으로 될 때도 있고, 잘 연결이 안될 때도 있더군요.. 여하튼.

여기에 써 있는 것과 같이 레지스트리에 cygwin의 파일 정보를 써 넣어줍니다. http://dreamlayers.blogspot.com/2010/01/eclipse-incompatibility-with-cygwin-17.html . cygwin에서 예전에는 레지스트리를 통해서 파일 위치에 대한 정보를 전달했는데, cygwin 1.7에서는 mount를 이용하는 방법으로 변경되면서 이 레지스트리가 사라졌다고 합니다. CDT에서 이 부분을 못 찾는 거죠.

수행을 위한 방법
  1. 위와 마찬가지로 RSE를 설치하시고 windows에서 eclipse를 수행시키세요. 끝. 가끔(많이?) 디버깅이 안되고 thread가 죽을 때가 있습니다. (저만 그런지도.. )
  2. cygwin상에서 eclipse를 수행시키세요. compile과 debugging이 쉽게 이루어지는데, 중간 중간 귀찮은 일이 생깁니다.
    1. cygwin상의 directory와 윈도우의 directory 이름이 달라서 디버깅시에 소스를 찾을 수 없는 경우가 있는데, windows->preference->C/C++->Debug->Common Source Lookup Path에 가서 Add Path Mapping에서 /cygdrive/c/ … 이렇게 되어 있는 것을 c:\라고 주시면 됩니다.
    2. clean이 정상적으로 동작하지 않는데, makefile을 확인해보시면 del로 설정되어 있어서 그렇습니다. 별로 큰 일은 아니니
    3. 가끔 잘 안 될때는 그냥 cygwin console에서 직접 해당 디렉토리에 가서 make해 주면 간단하게 해결되는 경우도 많습니다.

에고.. cygwin 1.7은 머 그렇게 변한게 많은지 쉽지 않군요.

cygwin 1.7의 gcc는 exe파일이 아닌 gcc-4.exe를 가르키는 symbolic link죠. 만일 minGW 형태로 컴파일하려면 예전에는 gcc –mno-cygwin 이라는 좋은 옵션이 있었는데, 아직 gcc 4 용 minGW가 없어서 해당 옵션이 정상동작하지 않습니다. cygwin에서 minGW로 컴파일하려는 경우에는 gcc-3 –mno-cygwin 명령을 주셔야 하는 거죠.

쩝.. 대략 귀찮음

AMBA 4.0 공개

3 Replies

다들 아시겠지만, 혹시 모르시는 분이 있으실까봐 적습니다.

AMBA 4.0이 공개되었지요.

AMBA 4.0에서는 드디어(?) AHB가 사라졌어요. 일견 그렇지요.
하지만, AMBA 4.0은 AMBA 3.0위에 프로토콜이 추가된 것이므로, 사실은 AHB-lite가 아직 포함되어 있습니다.

새로 추가된 라인업!

AXI 4.0
AXI-Lite
AXI-Stream

예전의 라인업

AXI 3.0
AHB-Lite
APB 3.0

이를 모두 포함하여 AMBA 4.0이 되는 것이지요.

AXI 4.0은 beat 수가 256으로 늘어난 것이 눈에 띄구요. QoS 관련된 부분등이 바뀌었군요
AXI-Lite는 APB를 대체할 목적을 가지고 있는 느낌인데.. 흠.. APB의 latency문제 때문일까요.. 여하튼
AXI-Stream은 사실 좀 무겁군요. 버스에서 뭐 이런걸 다.. 라는 느낌이 드는데, 아직 스펙을 잘 본것이 아니라..

나중에 한번 소개해 드릴 시간이 있을거라 생각해요.

스펙은 당연히 ARM에 🙂

그러게 진작에 잘하지

5 Replies

1.

얼마 전에(워낙에 요즘에 업데이트를 안하고 있어서 좀 그렇지요?) VMM과 OVM의 interoperation kit이 나왔지요. Accellera에서 추가적인 자료가 나왔다고도 하지요 (여기).

결국 이렇게 될 것을 진작에 합쳐서 잘 만들지, Synopsys가 주도하는 VMM과 Mentor와 Cadence가 주도하는 OVM 진영으로 나뉠 때부터 좀 그랬어요 J 그래도 지금이라도 공동 작업이 이루어지니 좋은 결과가 나올 것으로 봅니다. 가장 좋은 것은 그냥 하나로 묶는 건데, 각 회사의 정치적인 부분이 조금 첨예해서 왠지 합쳐지지는 않을 듯 하죠.

아무래도 Synthesis 부분에 있어서는 Synopsys의 강세인 반면에, Functional Simulation & verification에 있어서는 Cadence가 많이 앞서나가고 Mentor도 학생들에게는 많이 퍼져 있으니 전반적으로 OVM이 좀 더 세력을 더 많이 가지고 있다고 생각됩니다. 아마존 같은 데서 나오는 책의 양을 봐도 그렇구요.

2.

인텔이 TSMC를 통해서 Atom Core License를 한다는 말이 있었는데, 하기는 하나 보군요.

이 이야기는 3rd party에서 인텔 Atom Core가 들어간 SoC를 만들 수도 있다는 이야기인데요. 이 경우에 현재 ARM에 내주고 있는 시장을 많이 Intel 계열로 되찾아 올 수 있는 가능성이 있습니다. 사실 모바일 시장이 인텔의 입장에서는 그다지 매력적인 시장은 아니죠. 시장은 크지만 가격 경쟁이 심하다보니 그간 우주선을 주워서 비싼 CPU를 만들던 인텔이 만족할 만한 것은 아니죠. 어찌보면 Atom의 성능을 제한하고, Integration level을 제한하고 있는 것도 좀더 높은 마진을 가지고 있는 노트북 용 CPU 시장을 잠식당하는 것을 원하지 않기 때문이지요.

따라서, Atom Core License 이야기가 나왔을 때도, 이 부분에 대한 business model에 대한 이야기가 많았는데 사실 공개된 것만 보면 super 갑의 형태를 보여주는 라이선스 모델을 가지고 있군요.

예전에 MPR에서도 이 부분에 대해서 아주 실랄하게 깐 적이 있기는 한데, 이번에 EE-Times에서도 실랄하게 깠군요 (EETimes; Six reasons why no one wants an Atom-based SoC).

사실 인텔 입장에서는 아쉬울 것이 별로 없고, 혹시라도 3rd party의 칩에서 너무 좋은 결과가 나오면 노트북용 시장이 직접적으로 영향을 받을 수도 있는 상황이고, 그렇다고 손을 놓고 있자니 ARM 기반의 칩들이 스멀 스멀 netbook 부분을 잠식해 와서 윈텔 시장에 위해를 가할 수도 있는 위협이 눈에 보이는 상황인 것이지요.

Intel 계통에서 가장 강력한 힘은 전세계 데스크탑 PC 시장의 93%를 잠식하고 있는 Windows 운영체제가 돌아가며, 그 위에 구축되어 있는 강력한 소프트웨어가 있다는 점이지요. 하지만, ARM에서 정말 공략을 잘해서 netbook 시장에서 any-operating system과 web-based application을 가진 생태계 구축에 성공하면 그때부터는 이야기가 달라지게 되지요(현재로서는 쉬운 이야기가 아닙니다. 개인적인 예상으로는 2012년 정도까지 대략 1%~2% 정도만 잠식할 수 있다고 해도 성공으로 봐주겠습니다. 참고적으로 현재 MacOS의 점유율은 5%도 안됩니다.)

여하튼, 인텔의 다음 행보가 기대가 되기는 합니다. 공격을 받고만 있을만한 회사는 아니니까요. J