Dreamer GUNDAM의 블로그::무료로 뉴타입이 되는 별까지 앞으로 356광년

Rob Hess의 SIFT 2nd

이번에는 Rob Hess의 SIFT  프로그램 두번째에 대한 내용입니다.

언제나 그렇듯 빌드해 나가면서 발생하는 문제점들을 해결하는 형식으로 진행합니다.

이 과정은 제가 작업하는 내용을 기록하는 방식입니다. 

이렇게 고단한 역사(?) 를 기록하면 예전에 어떻게 했었지 하는 것을 기억하기가 쉽고

어떤 방법으로 이리 저리 했는지 따라하기가 쉽습니다.

RobHess의 SIFT는 크게 3개의 파일로 구성되어 있습니다.

1. siftFeat로서 앞서 컴파일 하였던 SIFT Feature를 Detect 하는 부분이며,

2. match   두개의 이미지를 비교하여 찾아내는 것입니다.

3. 마지막으로 찾아낸 특징점들을 화면상에 보여주는 dspFeat 부분입니다.

이번에는 두번째인 match를 빌드해보겠습니다.

1. Match의 빌드

VC에서 컴파일하면 다음과 같은 오류가 나타납니다.

Cannot open include file: 'gsl/gsl_sf.h': No such file or directory

원래 이 프로그램을 컴파일 하는데는 gsl 이 필요하다고 하였으니 이것을 구해서 컴파일 해야 합니다.

- 당연한 이야기죠~

2. GSL Build

자세한 홈피는 이곳을 참조하였습니다.

http://wiki.originlab.com/~originla/wiki/index.php?title=OriginC:How_to_build_GSL_DLL

http://www.gnu.org/software/gsl/

홈페이지는 위와 같습니다.

윈도우즈 용으로 Config된 소스 코드를 다운 받습니다.

http://gnuwin32.sourceforge.net/packages/gsl.htm

현재 버전은 1.8까지 올라와 있습니다. 음.. 최신 버전이 1.9인데.. 일단 컴파일만 하면 되는것이니

그냥 이것을 쓰겠습니다. 

c:\gsl에 설치한다고 가정하고 소스를 압축을 풀어서 카피해 둡니다.

VC에서 다음 파일을 읽어들여서

c:\gsl\src\gsl\1.8\gsl-1.8\VC8\libgsl.sln

빌드를 합니다.

그러면 차근차근 빌드하고 lib파일들이 만들어진다.

(source code path)\VC8\libgslcblas\Release-DLL

(source code path)\VC8\libgsl\Release-DLL

그럼 이제 이것들을 모두 VC에 등록합니다.

include path : C:\gsl\src\gsl\1.8\gsl-1.8

lib path        : 

C:\gsl\src\gsl\1.8\gsl-1.8\VC8\libgsl\Debug-DLL

C:\gsl\src\gsl\1.8\gsl-1.8\VC8\libgsl\Release-DLL

C:\gsl\src\gsl\1.8\gsl-1.8\VC8\libgslcblas\Debug-DLL

C:\gsl\src\gsl\1.8\gsl-1.8\VC8\libgslcblas\Release-DLL

그리고 빌드를 하면

잘 되네요

아래 그림처럼 나옵니다.

1) 찾고자 하는 이미지의 그림

2) 대상 그림

3) 실행 결과

Rob Hess의 SIFT

1. 살펴 보기

SIFT는 Scale ... 을 의미하는 것이고...자세한 내용은 다음에 기회되는 대로 정리해서 올리도록 하겠습니다.

인터넷에 찾아보면 여러가지 버전의 구현된 코드를 찾아볼 수 있습니다.

귀찮게도 C로 되어 있는것 보단 MATLAB이나 C#같은 것으로 되어 있어서 상당히 귀찬습니다.

이번에 발견하여 분석한 코드는 Rob Hess의 코드이며, C로 되어 있습니다. 

Rob Hess는 오래곤 주립대학의 컴퓨터 공학과 박사과정 학생으로 컴퓨터 비젼을 전공으로 하고 있습니다.

홈 페이지는 이곳에 있습니다.

http://web.engr.oregonstate.edu/~hess/index.html

홈페이지에 보면 몇가지 알고리듬을 공부하고 올려놓았지만, 가장 관심이 가는것은  SIFT입니다.

최신 버전은 2009년 1월에 1.1.1을 만들었습니다. 이전 버전과 바뀐 부분은

라이브러리를 정적으로 만들 수 있도록 Makefile을 수정한 부분과,

Visual C를 VC2005에서 컴파일 되도록 하였다는 부분

그외에 API들을 수정하여서 버그들을 정리했다고합니다.

소스 코드는 리눅스 버전과 윈도우즈 버전의 코드를 가지고 있고 각각 이 곳에서 받을 수 있습니다.

리눅스 버전 : TAR.GZ

윈도우즈 버전 : ZIP

이 SIFT 버전은 OpenCV 에 기반하고 있으며  RANSAC 은 GNU Scientific Lib에 기반하고 있습니다.

이제 아래 그램을 보면 SIFT가 무엇을 하는 지에 대해서 알 수 있습니다

왼쪽의 카드를 오른쪽의 그림 더미에서 찾아내는 것입니다.

아래 그림을 다시 보면

이 되어서 원하는 이미지가 있는 위치를 정확하게 찾아 낼 수 있습니다.

1. 코드의 컴파일

컴파일을 할려면 Visual C++에서 먼저 컴파일을 하였습니다.

우선 VC Project 를 로드하여 컴파일을 하면 다음과 같이 에러가 발생합니다.

LINK : fatal error LNK1104: cannot open file 'cvd.lib'

해당 라이브러리를 찾을 수 없다는 의미이고,

이 라이브러리는 opencv debug lib을 의미합니다.

2. OpenCV 설치

2.1 다운로드 및 설치

OpenCV를 다운로드 합니다.

Source Forge에서 다운로드 합니다.

아래 사이트에서 다운 받을 수 있습니다.

http://sourceforge.net/projects/opencvlibrary

여기서 윈도우즈 버전을 다운받아서 설치합니다. 실행 파일로 되어 있으므로 그렇게 어렵지는 않을듯 합니다.

설치 중간에 환경 변수 세팅을 물어보므로, 그때 YES라고 해서 설치를 합니다.

설치가 끝나면 View Documents를 보게 됩니다.

C:\Program Files\OpenCV\docs\index.htm

링크이므로 틈틈히 찾아보면 정보를 얻을 수 있습니다.

2.2 디버깅 라이브러리 만들기

설치된 코드는 실행 코드이다. 개발시에는 디버깅용 코드가 필요하므로 디버깅 버전의 라이브러리를 만드러야 한다.

c:\Program Files\OpenCV\_make

폴더에 가서 opencv.dsw를 클릭합니다.

그러면 버전문제에 대한 문의 다이얼로그가 나타난다. 모두 YES라고 선택하면 된다.

그러면 다음과 같은 창이 나타난다.

그럼 이제 BUILD->Batch Build를 선택하면 다음과 같은 창이 나타난다.

그럼 win32 Release와 Win 32 Debug를 모두 선태한다.

이후에 Build를 눌러서 라이브러리를 모두 컴파일 한다.

경고도 나타나지만 무시하고 진행하면 컴파일이 완료된다.

2.3 라이브러리 오류 수정

실제로 깨끗하게 완료된것이 아니다.

과 같이 오류가 발생합니다. 이전 버전에도 있던 오류인데 아직도 살아있다는게 놀라울 따름입니다.

하여튼 수정합니다.

cvaux.h : 1159 행 부근을 보면

/

이 있습니다. 여기서

을

으로 바꿉니다.

이번에는 잘 진행합니다.

2.4 라이브러리 오류 수정

컴파일 끝에 2개가 컴파일이 안되었다고 나옵니다.

나온것을 보면

으로 되어 있습니다.

이것은 cvcap_dshow.cpp 파일이 highgui project에 포함되어 있지 않아서 생긴 오류이다.

src에 이것을 추가합니다.

위의 그림처럼 추가하면 됩니다.

그래도 오류가 발생하는데 일단 라이브러리를 추가합니다.

C:\Program Files\OpenCV\otherlibs\_graphics\lib

그리고 다시 컴파일을 하면 역쉬 에러가 나옵니다.

과 같이 에러가 발생한다.

소스 파일을 찾아서 잘 보면 모두 VIDEO INPUT을 직접 받을때 사용하는 함수들 입니다. 

현시점에서 외부에서 직접 비디오 입력을 받을 일이 없으므로 그냥 넘어가서

_highgui,h파일에서 다음과 같이 수정한다.

을

#endif

으로 수정해서 막아버리고 컴파일 하면.. 잘 됩니다.

3 OpenCV 환경 설정

할때마다 컴파일 환경을 잡아주는 것이 귀찮으므로 일단 전체 환경 설정을 한번 하여줍니다.

3.1 헤더 파일 폴더의 추가

Tools-> Opetions을 선택하여 나타난 다이얼로그 박스에서 Directories 탭을 선택합니다

Tools->Options을 선택하여 나타난 다이얼로그 박스에서 Projects and Solutions 항목의 VC++ Directories를 선택하면 아래와 같은 창이 됩니다.

Platform에 Win 32를 Show Directories에 Includes files를 선택한 후에

새로운 Header File Folder를 선택합니다.

C:\Program Files\OpenCV\_make

C:\Program Files\OpenCV\cv\include

C:\Program Files\OpenCV\cvaux\include

C:\Program Files\OpenCV\cxcore\include

C:\Program Files\OpenCV\ml\include

C:\Program Files\OpenCV\otherlibs\highgui

C:\Program Files\OpenCV\otherlibs\ffopencv

C:\Program Files\OpenCV\otherlibs\_graphics\include

을 모두 설치합니다.

3.2 라이브러리 폴더 추가

이번에는 라이브러리 폴더를 같은 방법으로 추가합니다.

위의 그림과 같이 Library Files를 선택한 뒤에

C:\Program Files\OpenCV\lib

을 추가합니다.

이렇게 하면 준비가 끝났습니다.

4. 다시 컴파일

SIFT를 다시 컴파일 하면 이번엔 잘 된다.

실행하면 다음과 같은 오류가 나타난다.

이것은 환경 변수에 PATH를 다음것을 추가합니다.

C:\Program Files\OpenCV\bin

5. 다시 실행

이제 SIFT를 다시실행한다.

그럼 아래 그림이 나타난다.

이제 정상적으로 컴파일이 되었다.

아래 그림은 약간 수정한 코드로 만든 이미지입니다.

잘 동작하고 있습니다.

한사람의 기사를 맞이 하기 위해서는... 

이전 글을 올려 놓고 한참을 읽었습니다.

웬지 자신은 생각하지 않고 남탓만 하는것 같아서 

이번에는 사람을 맞이하는 우리의 생각에 대해서 써보아야 하겠다고 생각하여 이렇게 글을 올립니다.

회사에서 사람을 채용하기 위해서 맞이하기 위해서  준비해야 할 것 중에서 

우선 필요한 것은

- 기술적인 부분과

- 회사 자체의 네임 벨류

- 그리고 내부적인 관계 (인간관계 포함)

등이 중요할 것 같습니다.

기술적인 부분이야.. 자랑이지만 자신있게 나름 괜찮다고 생각합니다.

  우리회사는 가장 강점이 SoC 플랫폼을 멋지게 구비했다는 점입니다. 

  어설프게 플랫폼하는 것이 아니라 나름 고성능의 SoC 플랫폼을 가지고 개발을 진행합니다.

  예전에 Sonics를 사용해본 뒤에 필요성을 느껴서 개발한 플랫폼입니다.

  물론 기술이 좋다고 무조건 사람을 받아들일 수 있는 것은 아니죠.

  사람을 키울 수 있는 것이 중요합니다. 모든 회사는 회사 나름의 인재 육성법, 사람 육성법, 기사 수련이 있습니다.

  물론 우리도 우리회사만의 도제 시스템으로 육성합니다.

  코스에 대해서는 다음기회에 말씀드리고 결론적으로는 

  하드웨어와 소프트웨어를 동시에 잘 할 수 있도록 많이 신경쓰고 있습니다.

  반도체 설계한다는 사람이 SYSTEM도 모르고 소프트웨어도 모르고 설계할 수 는 없습니다.

  가끔 가다 보면 등한시 하는 사람도 있는데 그러면 정말 한계가 금방 다가 옵니다.

회사 자체의 네임 벨류는

  사실 신생회사에 가깝기 때문에 아직 없습니다. 

  올해 부터 차근차근 개발된 칩이 나올 것이므로 

  이런 것을 잘 기사화 하여 회사의 이미지를 좋게 만들 생각입니다.

  물론 가장 중요한 네임 벨류는 이익을 내는 것이기 때문에

  이익을 낼수 있도록 항상 노력하고 있습니다. 

  자세한 것은 회사의 영업 기밀이므로, 생략하겠습니다.

내부적인 관계야 

  아직까지는 작은 회사의 특성상 정말 좋다고 말할수 있습니다.

  향후에는 커지면 그에 대비한 준비를 해야 하지만, 그때까지도 좋은 형태로 진행할 수 있도록

  계속 준비를 하고 있습니다.

  채용하기 전 부터 이것이 외 중요한 지는 굳이 이야기하지 않아도 다 아시리라 생각합니다.

중요한 것은 이러한 것을 어떻게 대외적으로 발표하고 연결시켜 나가겠냐는 것입니다.

결국 시간을 가지고 성과를 보이는것이 이것은 너무 밍밍한 정답입니다만 

최고의 방법입니다.

우선 우리만의 고유의 도제 시스템을 어떻게 잘 확립 할 것인지가 중요한 부분이 되곘네요

그리고 회사의 네임 벨류를 올리는 것도 같이 해야 할 부분입니다.

-----------

저번에도 그렇지만 회사의 지리적인 것도 중요합니다.

 (?) 좋은 장소로 이전을 계획중입니다.

사람을 찾습니다.

어디에 

C  언어 이해하고 있으면서

Computer Architecture를 이해하는 사람을 보셨나요 ?

취업 사이트에 올린 구인 광고나 회사 홈피에 있는 구인 광고는 정말 거창한것 같지만 사실 딱 두가지만 바라는 겁니다. C언어와 Computer Architecture 입니다. (신입은 C만 잘해도 됩니다. ^^)

몇년 전부터 사람을 찾느라고 매달 2~3명씩 면접을 보는 것 같습니다.

그런데 아직도 사람을 찾고 있습니다. 

거듭 말씀드리지만, 신입사원이라면 C언어만 이해해도 좋은데 사람 찾기가 쉽지 않네요

회사가 크고 작고의 문제가 아닌듯 합니다.

사상 최대의 취업 난이네 하여도 회사는 사상 최대의 구인난에 시달리고 있으니 아이러니 합니다.

그동안 면접 본 사람이 못해도 000명은 넘은 것 같습니다만, 실제 채용된 사람은 3명 정도입니다.

그렇다고 회사가 정말 고난도의 인력을 요청하는 것도 아니라는 생각을 합니다.

정말 기본적인 것이죠.

채용 기준을 낮추라는 압력(?)이 조언이 주변에서 들어오지만, 이미 이정도의 채용 기준이면 한껏 낮추었다고 생각합니다.

요새는 왜 이렇게 사람뽑기가 힘들까요 ?

생각해보면 

1. 반도체 설계라는 직업군이 사실은  3D업종 이라는 비밀이 만천하에 공개 되었고

2. 공대 기피현상의 여파가 구인난까지 밀려들어온것 같습니다.

1번에 대해서는

3D직군이라는 것은 재론의 여지가 없이 사실입니다. 엄청 몸빵하는 직군임에 틀림이 없습니다. FAB-IN할때에는 모두 신경이 곤두서서 밤을 새며 지내기 일쑤이기 떄문에, 엄청 고로운 직군입니다. 이건 사실이기 때문에 변명할 거리가 없네요 하지만 다른 직군을 좀 봐주세요.. 다른 직군도 힘들기는 매 한가지 입니다.

2번에 대해서는 

사실, 지금은 영업, 연구, 마케팅의 구분이 없는 시대가 되기 시작했습니다.

직군의 구분은 있을런지 모르지만, 생각과 행동은 구분이 없습니다. 

엔지니어가 마케팅을 이해하여야 하고, 세일즈를 이해해야 하는 것 처럼

마케팅이 엔지니어링을 이해하지 못하고는 발 붙이기 힘든 시대입니다. 

시작할때야 차이가 존재하지만 점점 차이가 없어지고, 결국 종합적인 능력을 가진 사람이 더 높은 세상을 향해 

나아가게 되어 있습니다.

아무것도 모르는 사람이 마케팅을 한다고 자리에 눌러 앉아서 기울어가는 회사를 보는게 한두군데가 아니어서

더욱 그런 시대라는 것을 절감하게 됩니다.

그렇지만~~!!!! 버뜨...

자신이 만든 칩이 움직이는 것을 보는 것이 

얼마나 신기한 것인지,

얼마나 두군거리는 것인지 

얼마나 황홀한 것인지

느낄 수 있는 사람이라면, 느껴보고 싶은 사람이라면 연락을 주세요.. 

얼마전에 연구 결과물을 보니 국내에 약 150개 정도의 FAB-Less가 있고 인력은 4000명 정도 된다고 합니다.

마치 F.S.S( 파이브 스타 스토리의 약어죠.. 유명한 애니)에 보면 

기사는 숫자가 늘지도 줄지도 않는다는 대사가 나옵니다.  한사람의 기사가 만들어질려면 한사람의 기사가 죽어야 하는것 처럼

한사람의 엔지니어가 은퇴할때가 되어야 한사람의 엔지니어가 탄생하는게 아닌가 하는 생각이 듭니다.

우리나라 반도체 인력 종사자가 4000명일지에 대해서는 약간 의문이긴 합니다만,  (실상은 더 적을것이라 생각합니다.)

4000명의 엔지니어로 이 넓은 세상을 커버하기는 버거울 것 같습니다.

지금 있는 회사에서도 사람을 채용하기 위해서는 기존의 방법으로는 안된다고 생각이 됩니다.

뭔가 다른 방법과 대안을 찾아서 준비를 시작해야 합니다.

개인적으로도

회사에서도

국가에서도

다른 방안이 필요한 때입니다.

===========================

오해의 소지가 좀 있을것 같아서.. 

- 우리회사 대우가  낮지는 않습니다. 

- 다른 것들도 잘 해주는 편입니다.

- 위치가 불리한 것은 인정.. 음.. 얼렁 이사가야지..

DSP Design [2]

앞서의 글에서 공개된 아키텍쳐를 이용해서 만드는 것이 좋다고 말씀드렸습니다.

공개된 아키텍쳐 중에서 당장 눈에 뛰는 것은 4가지 입니다.

- OpenCores 와

- SUN Sparc Processor

- Core-A

- MIPS-I

각각의 프로세서를 간략하게 정리하였습니다.

2-1 OpenCore - 1000/1200

Damjanl Lampret 라는 사람이 만든 OpenCores에서 공개한 프로세서로서 32비트 및 64비트까지 지원하는

명령어 세트를 가지고 있습니다.

오픈 코아는 명령어 자체가 걸려있는 것이 아닌것으로 생각되어, 구현 해도 큰 문제는 없을 것으로 생각합니다.

다만 현재 있는 것도 잘 되어 있어서 큰 문제는 없고, 실제 사용한 적도 있기 때문에

굳이 구현할 필요까지는 없을 것 같습니다.

무엇보다 공짜인데.. 라는 생각이 강한 오픈 코아이기 때문에 개인적으로는 위화감이 있습니다.

2-2 SUN Sparc

요게 맘에 들긴 합니다.

뭣보다도 정식 라이센스도 가능하고, 컴파일러와 O/S도 다 갖추고 있기 때문에 구현후에 좋습니다.

선에서 구할 수 있는 것은  T1과 T2프로세서 입니다.

T2는 서버를 원칩에 담겠다는 개념으로 만들어서 코드네임도 “NAIAGARA"로 명명했습니다.

결과물을 보면 물량전에서 절대 지지 않는 울트라 리스크 러쉬라고 할까요 ?

그런 정도의 엄청난 물량을 가지고 있습니다.

T1도 잘 만들었고 실제 이넘에서 프로세서 하나를 떼서 사업화 하겠다던 회사도 있었습니다.

그후에 소식은 못들어서 또 역사의 물결 속으로 사라진게 아닌가 하는 의구심도 듭니다.

하여튼 개인적으로는 이러한  레지스터 윈도우 방식은 참으로 좋은 아이디어로 생각합니다.
일정 수준까지의 함수의 호출에서는 스택을 건드리지 않고 파라미터와 내용을 전달하기 때문에
속도가 아주 빠릅니다.

다만 일정 수준을 넘어가면 Exception이 발생하고, 그 후에 다시 처리하는 것이 조금 시간이 걸린다는 단점이 있습니다.

개인적으로는 Embedded IP에서 게이트 카운트에 압박을 벗어나는 시대이므로, 용량이 좀 되는 어플리케이션에서는 좋은 어프로치라고 생각합니다.

 2-3 Core-A

작년 여름께 발표된 것으로, 특허청과 국내 대학 연합에서 만들어서 발표한 아키텍쳐입니다.

아키텍쳐가 공개된는지는 모르겠습니다만, 명령어 세트를 구하는 것은 쉬운 것이라서

구현이 가능한 범주에 넣었습니다.

NOP를 명령어 비트에 집어넣은 발상으로 만들었기 때문에 Data forwarding이 필요 없다는

개념을 가진 아키텍쳐로 보입니다.

컴파일러와 시뮬레이터가 아직 완전하지 않은것으로 보여 이 부분에 대한 보완이 시급한 것 같습니다.

하지만, 이제 시작이고  국내에서 EISC외에 새로운 아키텍쳐가 나왔다는 점에서 의미가 있다고 생각합니다.

2-4 MIPS-I

위의 사진은 도시바에서 만든 MIPS-4400입니다.

MIPS WIKI페이지에서 옮겼습니다.

ARM과 쌍벽을 이루면서, 미국에서 자존심을 걸고 지켜주는 프로세서이죠

프로세서 아키텍쳐 바이블 서적인 Computer Organization and Design: The Hardware/Software Interface 에서 설명하는 구조입니다.

프로세서 공부하시는 분들은 모르는 사이에 한번 공부한 아키텍쳐죠..

MIPS의 클론 프로세서를 검토한다면 렉서라라는 회사에 대해서 알아야 합니다. 이것에 대해서는  아래 링크를 한번 읽어보시면 좋겠습니다.

(눈물 없이는 읽을 수 없는 글입니다.)

http://jonahprobell.com/lexra.html

LEXRA는 MIPS-I 클론을 만들었고, 특허를 피해가기 위해서 노력을 했습니다만,  MIPS의 현질 공세에 밀려서 사라진 회사입니다.  저자는 MIPS가 Lexra에 대항했을 때의 그 노력으로 ARM에 대항했다면, 훨씬 좋은 결과를 만들었을 거라는 아쉬움을 이야기합니다.

MIPS-I에서 특허로 보호받는 부분은 명령어중 4개 정도 입니다. 그리고 이 명령어들은 Memory Miss Alignment에 대한 것들입니다.

이 것에 대해서는 우여 곡절이 많지만 하여튼 2006년 12월에 특허가 완전히 풀렸습니다.

관련해서 오픈 코아의 Plasma프로세서가 MIPS-I을 이용해서 구현했습니다.

http://www.opencores.org/projects.cgi/web/mips/overview

앞서 말씀드린 바와 같이 MIPS-I의 특허는 완전히 풀렸기 때문에 이것을 이용해서 프로세서를 만드는 것이 가능합니다.

2-5 어떤 아키텍쳐를 ??

어떤 것을 구현하는게 좋은지는 법적인 문제와 실제 문제 그리고, 프로세서의 개발 환경 문제도 검토해야 합니다.

그리고  컴파일러의 최적화 문제에 대해서 고민을 해봐야 하고 또, 프로세서의 용도에 따라서 선택해야 하는 문제입니다.

이번에 만들고 싶은 프로세서는 고성능 DSP프로세서이기 때문에 명령어 확장도 가능한 형태로 가야 합니다. 이 부분을 고려하여서 위의 4가지 아키텍쳐 중에서 하나를 선택해서 구현합니다.

---------

그외에 공개된 아키텍쳐가 있다면 좋겠습니다.

이 자료는 현재까지 알고 있는 아키텍쳐에 대해서 검토한 과정을 정리한 것입니다.

언제나 그렇듯 제가 알고 있는 부분과 사실과 틀릴수도 있습니다. ㅋㅋ

아래 글은 EE에서 발췌한 글입니다. 원문을 그대로 옮깁니다.

마이크로 프로세서IP를 어떤 모델로 라이센싱할 것인가에 대한 의견을 개진한 글입니다. 여러가지 방법이 있지만 FPGA라는 특성을 반영하여 라이센스하는 것을 말하고 있습니다. 이 글에서는  프로세서를 어떻게 파느냐의 글입니다. 어떻게 시장에서 자리매김하는가에 대해서는 언급하지 않고 있습니다. 파는것 보다도 중요한 부분은 자리매김이라고 생각합니다. 자리 매김이 되어야 파는 부분에 대해서도 성립하기 때문에 자리매김에 대한 내용이 정리되어야 합니다.   

소프트 마이크로프로세서의 네 가지 라이선싱 모델

Gordon Hands

Director of Strategic Marketing 

Lattice Semiconductor Corp.

FPGA 설계자들은 점점 더 많은 디자인에 소프트 마이크로프로세서를 내장하고 있다. 이에 따라, FPGA 벤더들과 써드파티 IP 벤더들은 가장 최신 모델인 오픈소스를 비롯하여 여러 가지 방식의 라이선스를 갖는 다수의 소프트 마이크로프로세서를 개발해왔다.

설계자들은 보통 자신들의 소프트 마이크로프로세서를 위한 소프트웨어 코드 개발에 상당한 시간을 투자한다. 때문에 이들이 관련 라이선싱 모델들이 무엇을 의미하는 지 이해하는 것은 중요한 일이다.

어려운 결정

일단 소프트 마이크로프로세서를 구현하기로 결정되었으면 설계자들은 어떤 라이선싱 모델이 자신들의 요구에 가장 잘 맞는지를 결정해야 한다. FPGA 벤더들이 소프트 마이크로프로세서와 MCU에 이용하는 기본적인 라이선싱 모델에는 네 가지가 있다.

써드파티 IP 벤더들은 보통 IP 구매 모델을 이용한다. 여기서 이들이 취한 접근 방식을 논하지는 않겠지만 그 대부분은 FPGA 벤더들의 접근 방식과 유사하다.

모델 1: IP 구매─FPGA에 소프트 마이크로프로세서를 공급하는 전통적인 모델은 IP 구매이다. 

    이 모델은 네 가지 해결 과제들을 가져다준다.

・ 마이크로프로세서 개발툴과 생성된 HDL 코드의 사용권에 비용을 지불해야 한다. 

    툴을 계속 사용한다든가 소프트웨어 유지 관리를 하는 경우 이 비용은 매년 들어가게 된다.

・ 마이크로프로세서의 HDL 디스크립션은 보통 암호화되어있다. 

     이는 설계자가 이 구현물을 제한적으로만 최적화시킬 수 있도록 하며, 버그를 수정하기 위해서는 FPGA 벤더에 의존해야 한다.

・ 마이크로프로세서를 지원하는 개발 자원들은 FPGA 벤더가 선택한 것으로 제한된다.

     설계자가 아니라 벤더가 자원들의 우선순위를 정하게 된다.

・ IP 구매 시의 라이선싱 조항으로 벤더의 FPGA 디바이스에 대한 구현이 제한된다. 

     이 마이크로프로세서에 대해 개발된 코드가 축적될수록 설계자가 다른 FPGA 벤더로 옮겨가기는 더 어려워진다.

・ 설계자가 벤더를 전환하지 못함으로 인하여 벤더에게 경쟁 상의 이유로 압박을 가하지 못하게 된다. 

     이는 최종 제품이 고객들의 관심을 덜 끌게 만든다. 또한, 미래에 FPGA 벤더로부터 가격 상의 양보를 제한적으로만 받게 한다.

모델 2: 무료 레퍼런스 디자인─무료 레퍼런스 디자인 접근 방식은 IP 구매 모델과 관련된 두 가지 문제를 없애준다. 

     업프론트 비용이 없다는 것은 분명 매력적이다. 

     그리고 이러한 디자인들이 변함없이 소스 코드 포맷으로 제공됨으로 인해 이 디자인의 스트럭처에 접근할 수 있다.

    하지만, FPGA 벤더가 이 디자인의 소유권을 갖기 때문에 이 디자인에 대한 추가적인 코드 개발의 인센티브가 없어진다. 

    마지막으로, IP 구매 방식에서와 같이 레퍼런스 디자인의 구현은 벤더의 디바이스 아키텍처로 제한된다.

모델 3: IP 암호화─IP 암호화는 IP 구매 방식의 몇 가지 문제를 해결하려는 새로운 시도이다. 

     이 모델에서 FPGA 설계툴들과 생성된 암호화 비트스트림을 이용한 디자인에 IP가 통합된다.

    이 비트스트림을 이용하려면 미리 프로그램된 특수 FPGA를 복호화 키와 함께 표준 FPGA보다 비싼 값에 구매해야 한다. 

    이 접근 방식은 업프론트 비용을 없애주며, 표준 마이크로프로세서 아키텍처가 FPGA 내에 사용될 수 있게 해준다.

표준 아키텍처의 이러한 사용은 코드가 독립 칩과 ASIC 같은 다른 비 FPGA 솔루션에 구현될 수 있게 해준다. 하지만, 설계자들은 다시 한 벤더의 디바이스에 묶이게 된다. 코드를 눈으로 볼 수 없다는 문제와 벤더가 개발 우선순위를 정하게 된다는 문제는 이러한 접근 방식으로는 풀 수 없다.

모델 4: 오픈소스─오픈 소스 접근 방식은 다른 라이선싱 모델들과 관련된 고통스러운 문제들을 해결해 줄 것을 약속한다. 이것은 코드를 눈으로 볼 수 있게 해주어 설계자가 디자인의 기능을 이해할 수 있게 해주고, 자신들의 사용에 최적화시킬 수 있도록 한다.

이것은 설계자들이 코드를 수정할 수 있도록 융통성을 제공해 주며, 사용자들이 코드를 개선하여 더 넓은 개발 커뮤니티가 사용할 수 있도록 장려하는 IP 권리를 제공한다.

오픈 소스는 무료이며, 아마도 더 중요한 것은 이것이 어떠한 FPGA 아키텍처에도, 심지어는 ASIC 같은 비 FPGA 구현물에도 구현될 수 있게 해주는 이식성을 제공한다는 것일 것이다.

오픈소스 소프트웨어를 위한 GPL

오픈소스 운동은 소프트웨어 영역에서 시작되었다. 소프트웨어 영역에서는 많은 오픈소스 라이선싱 접근 방식들이 취해지고 있는데, 그 중 유명한 것 하나가 GNU General Public License (GPL)이다.

기부자가 자신의 작업을 인정받을 권리와 그 작업이 퍼블릭 도메인에 남아있도록 하는 것, 그리고 미래 사용자의 필요요건 간에 GPL이 취하고 있는 균형이 소프트웨어 개발 커뮤니티에서 이것이 인기있는 이유의 하나이다. 하지만 GPL은 궁극적으로 하드웨어에 구현될 IP에는 불완전한 라이선스이다.

구매자가 알아야 할 것들

FPGA 내에 임베딩되는 소프트 마이크로프로세서가 널리 유행함에 따라 설계자들은 라이선싱 조항에 세심한 주의를 기울일 필요가 있다. 이 기사에서는 네 가지 라이선싱 접근 방식을 살펴보았다. 그 중 오픈소스 접근 방식을 제외한 나머지는 향후 설계자들의 FPGA 디바이스 선택을 제한시켰다. 또한 이 접근 방식의 일부는 설계자가 코드에 접근하는 것을 제한함으로써 버그 수정을 IP 공급업체의 손에 맡길 수 밖에 없게 하고 있다.

소프트 마이크로프로세서의 오픈소스 라이선싱은 설계자에게 FPGA 아키텍처를 바꿀 융통성을 제공하고 그들이 필요로 하는 프로세서 아키텍처를 눈으로 볼 수 있게 해준다.

하지만, 오픈소스라 하더라도 라이선싱 세부 사항에 대해 세심한 주의가 필요하다. 이는 소프트웨어 영역에서 인기있는 많은 오픈소스 라이선스들이 하드웨어를 대상으로 하는 IP에 적용될 때는 심각한 문제들을 드리우는 경우도 있기 때문이다. 라이선스 없이 하드웨어를 배포해야 할 필요나 단일 하드웨어 구현물에 공개 코드와 고유 코드를 혼용해야 할 필요가 그러한 문제들에 포함된다.

패러럴즈는 맥에서 사용하는 아주 좋은 가상화 프로그램입니다.

코드 퓨전과 패러럴즈를 비교하면 아무래도 패러럴즈가 더 빠르게 동작하기 때문에 점수를 더 줄 수 있습니다.

코드 퓨전의 극악에 가까운.. 성능이 문제가 되죠.. 아무래도 맥에서의 시스템 프로그래밍은 패러럴즈가 

더 좋은듯 합니다.

그런데 좋은 프로그램이라도 사용하는데 문제가 하나 있습니다.

바로  Emacs를 사용할 때에, SET-MARK-COMMAND가 안먹힌 다는 겁니다.

이유는 Control-SPACE가 맥에서 spotlight 단축키로 할당되어 있기 때문에 지정을 안한것 같습니다.

코드 퓨전에서는 이 키가 먹히는 것으로 보아서 패러럴즈를 만드는 사람들이 Emacs를 사용하지 않는다는 

추측이 가능하게 됩니다.

아래 구문을 .emacs에 추가하시면 control + , (콤마) 키가 SET-MARK-COMMNAD를 대치하게 됩니다.

꿩대신 닭이라고 이렇게 사용해야 하곘지요..

패러럴즈 프리퍼런스에 보면, 키 매핑을 할 수 있도록 되어 있는데 SPACE키만은 단축키로 사용하지 않도록 지정되어 있습니다. 아무래도 패러럴즈는 SPACE 키의 용법에 대해서는 조금 둔감한것 같습니다.

(global-set-key (kbd "C-,") 'set-mark-command) ;

(custom-set-variables

  ;; custom-set-variables was added by Custom.

  ;; If you edit it by hand, you could mess it up, so be careful.

  ;; Your init file should contain only one such instance.

  ;; If there is more than one, they won't work right.

 '(inhibit-startup-screen t))

(custom-set-faces

  ;; custom-set-faces was added by Custom.

  ;; If you edit it by hand, you could mess it up, so be careful.

  ;; Your init file should contain only one such instance.

  ;; If there is more than one, they won't work right.

 '(default ((t (:stipple nil :background "black" :foreground "white" :inverse-video nil :box nil :strike-through nil :overline nil :underline nil :slant normal :weight normal :height 98 :width normal :family "outline-courier new"))))

 '(cursor ((t (:background "blue")))))