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

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")))))