Category Archives: SoC & IP design

마이크로 프로세서가 나아가야 할 방향…

쓰고보니 상당히 거창한 제목입니다.
요즘 프로세서 로드맵 작성중이라는 말씀을 드렸는데, 회사에 중대한 일이 생겨서 전면적으로 홀드 상태입니다. 가용 자원이나 target이 약간 수정되어야 하니 말입니다.
그래도, 마이크로 프로세서가 나아가야 할 방향성은 크게 달라지지 않겠지요. 단지, 현재 상황에서는 targeting하기 어려울 것이라 생각했던 목표를 추가적으로 설정할 수 있게 되었다는 것이 중요하겠지요.


Energy Efficient

현재 microprocessor 개발에 있어서 ([wp]EISC[/wp]나 [wp]ARM[/wp]같은 embedded microprocessor에 한정하지 않더라도) 가장 중요한 목표가 무엇이겠습니까?
아마도 energy-efficient 가 아닐까 생각합니다.
생각보다 많은 분들이 저전력 (low power)프로세서와 에너지 효율이 높은(energy-efficient) 프로세서를 혼용하여 사용하시는데, 사실은 약간 차이가 있습니다.

아시다시피 전력은 소모되는 에너지를 단위 시간으로 나눈 것이지요.
에너지는 일량. 즉 어떤 일을 끝내는데 필요한 힘이라 보시면 되겠습니다.

Low Power와 energy-efficient가 어떻게 다른지 한번 간단한 예를 들어 봅시다.

A라는 프로세서는 123.exe라는 프로그램을 한번 처리하는데 10초가 걸리며 100mw의 전력을 소모하는 반면,
B라는 프로세서는 123.exe라는 프로그램을 한번 처리하는데 2초가 걸리며 200mw의 전력을 소모한다고 생각해 보죠.

어떤 프로세서가 energy-efficient하겠습니까? 당연히 B 프로세서입니다. 전력소모에 있어서는 A라는 프로세서가 더 저전력이지만 말입니다.
Energy 단위의 중요성은 “동일한 일”을 수행하는데 얼마나 적은 에너지를 소모하는냐를 따지는 척도이기 때문에, 단순히 단위 시간당 얼마나 적은 “전력”을 소모하느냐와는 약간 다르다고 생각하시면 됩니다.

다른 관점에서 전력은 power supply가 얼마나 전력을 공급해 줄 수 있느냐와 발열에 영향을 미칩니다. 그래서 desktop/server에서는 평균적인 전력 소모가 얼마나 되는지가 중요합니다.
이에 반하여 Energy는 동일 용량 battery로 얼마나 버틸 수 있느냐를 결정할 때 매우 중요한 요소입니다.
단, 아무리 energy efficient하더라도 전력 소모가 크다면 (예를 들어 C라는 프로세서가 123.exe를 처리하는데 0.0001초가 걸리고 30W가 소모된다고 예를 듭시다), battery를 사용하는 시장 자체에 진입이 불가능할 수도 있습니다. 그런 관점에서는 low power와 energy-efficient가 밀접한 관계가 있는 것이겠지요.

요즘에 low-power보다 energy-efficient가 중요시되는 중요한 이유중의 하나는 dynamic power management 기법의 적극적인 활용입니다. Dynamic power management 기법은 “사용하지 않을때는 해당 유닛에 공급되는 전력을 최소화 한다”라고 생각하시면 되는데, 저전력을 위하여 느릿 느릿 오랫동안 일을 지속하는 것 보다, 빠른 시간에 작업을 끝내고 전력 소모를 더이상 하지 않는 것이 좋다는 것이겠지요.
여담입니다만, Dynamic power consumption 기법이 활성화되지 않았다면, 사실 energy-efficient와 low power는 동일한 언어로 표현되지 않았을까.. 라는 생각도 해봅니다.

또 다른 관점에서…
Enenry-Efficient는 Hardware만의 문제가 아니라 Software도 같이 노력해야 하는 문제입니다. (물론, 저전력도 그렇습니다만) Energy란 “어떤 일”을 수행하는데 소모되는 시간이기 때문에, “어떤 일”을 빠르게 수행할 수 있도록 더 효율적인 코드를 만드는 책임이 소프트웨어에게 있는 것이지요.

프로그래머의 관점에서

프로세서를 사용하는 프로그래머에게는 약간 다른 관점이 있는데, 프로그래밍이 쉬워야 한다는 측면입니다.
프로세서 아키텍쳐는 벌써 dual core, quad core로 발전하고 있으며, GPU들도 programmable shader를 가지고 있으므로, 아키텍쳐적인 형태로 보았을 때는 heterogeneous multiprocessor의 형태를 이미 취하고 있다고 보셔도 됩니다.
문제는 프로그래머들은 아직 multiprocessor를 사용할 준비가 되어 있지 않다는 것입니다. Multiprocessor를 지원하는 OS와 compiler, library의 등장으로 물론 점점 multiprocessor를 효과적으로 사용해 나가는 상황이 되어가고 있는 것은 맞습니다만, 아직 프로그래머들이 multiprocessor가 제공하는 기능을 충분히 활용하고 있는 상태는 아닙니다.  
점차 나아지겠습니다만, 프로그래머의 역량 강화가 매우 시급한 상황입니다.

집중이 안되는 여름

연일 30도를 넘나드는 더위가 계속되고 있습니다.


이럴때 항상 문제가 되는 것이 집중력이 떨어진다는 건데요.. 저도 마찬가지 입니다.
(실은 개인적으로 좋은 일이 생겨서 그럴지도 모르겠습니다만 ^^;)


오늘만해도 gcc-MinGW에서 mti vpi 연결시키는 거 때문에 잠깐 modelsim userguide를 보다가, 딴짓을 하기 시작해서 대략한 5시간동안 딴짓을 했습니다.


뭐 딴짓이라고 해도 모레쯤이나 하려던 processor market forecasting자료 정리였는데, 어짜다보니 하고 있더군요. 이건 뭐, 원래 하려던 일은 까맣게 잊고 나중에 하려던 일을 한참하다가 “아.. 내가 오늘 하려던 일은 이게 아닌데.. ” 뭐 이런 시나리오라고나 할까요.


VPI 이야기가 나와서 그러는데요.. (또또.. 옆길로 빠집니다요) 회사 툴이 System Verilog-verification feature를 지원해주지 않아서, C/PLI나 만들어야 겠다는 이야기를 했었죠? 요즘 teal library를 분석하고 있는 중인데, 이거야 원.. 보면서 몇 번을 감탄한 것인지 모르겠습니다.


사실 뭐 PLI 연결하는 것이야 별 차이있겠습니까? 뭐 thread를 사용하는 것도 그렇다치구요.. 근데, PLI 연결 부분을 teal_synch.cpp라는 몰아두고, 이걸 class로 덮어씌우고 연산자 오버로딩을 해버리니 예술적인 경지에 이르르더군요. 사용하는 사람 입장에서는 이 부분이 verilog랑 붙기 때문에 어쩌구 저쩌구 생각할 필요가 거의 없도록 만들어졌더군요.


아쉽게도 저는 유연성 보다는 빠른 동작을 즐기기 때문에 teal을 그대로 이용하지는 않겠지만, (처음에는) 재미삼아 분석해 본 라이브러리인데 아주 많은 걸 배웠습니다. 천재성이 담긴 코드에요.. 저에겐 ‘이 정도쯤은 해야 verification engineer가 되는 건가.. 에효..’ 라는 상념에 빠지게 하더군요..


C++에 익숙하시고, PLI를 공부중인 분들은 상당히 도움을 받으실 수 있을 것 같습니다. 혹시라도 관심있으신분은 http://www.trusster.com/ 에서 다운 받아보실 수 있습니다. 이거 관련된 책도 있는데, 아직은 저도 본 상태가 아니라 뭐라 말씀드리기는 어렵습니다. (TRUSS도 아직 사용해보지 못했습니만, Teal만으로도 괜찮습니다 ^^;)


아.. 그러고보니 관련 기사도 있었군요.. EETimes Korea의 기사입니다.


위의 부분까지는 MS Writer에서 썼는데, 평소처럼 publish하려니 좀 허전하네요.. ^^;

혹시라도 PC환경에서 cygwin/modelsim하에서 사용하시는 분들을 위하여 몇 가지만

1) Makefile.Windows를 만듭니다. 이 파일은 Makefile.linux를 복사하시는 것이 편합니다.
2) 아래와 같이 고칩니다. (필요에 따라 더 고치셔도 됩니다.)


ARCH_LIB_OPT = -L/cygdrive/c/Modeltech_6.0/win32 -lmtipli
ARCH_SHARED_SUFFIX = dll
SYS_ARCH_CC = g++
              

3) Makefile을 수정합니다.


SIMULATOR_HOME = /cygdrive/c/Modeltech_6.0
ARCH    = Windows
SIM     = mti_2_0



대략적인 힌트만 드렸습니다만, 이 정도면 필요한 부분을 추가적으로 수정하셔서 verification_top()함수를 작성하신 다음에 linking하시는데 문제 없을듯 합니다.

Google의 PeakStream사 인수!

예전에 소개해 드렸던 PeakStream이 Google에 인수되었습니다 (EETimes 뉴스). Multicore/GPU를 이용한 programming 방법론과 라이브러리, Toolkit을 갖추고 있는 peakStream이 강력한 배경인 Google에 인수됨으로써 Multiprocessor와 GPU를 위한 프로그래밍 API가 좀더 원활하게 개발 되고, 사용 될 가능성이 높아졌다고 봅니다.

 

PeakStream에 투자한 Nvidia에게는 많은 이익이 되는 일이겠고, 아이러니할 수 있지만 AMD/ATi는 뜻밖에 강력한 원군을 만난 느낌일 수 있겠습니다. PeakStream이 지원하는 GPU가 ATi 위주이며, 제대로 된 Single-Chip Multiprocessor/GPU의 조합을 가장 먼저 선 보일 가능성이 높은 것이 AMD이니까 말입니다. 아무래도 중소 벤처의 지원보다는 Google의 여러 software와 opensource project에 PeakStream의 multicore library가 적용되는 경우 많은 소프트웨어에서 Multiprocessor-GPU를 좀 더 효과적으로 이용하여 성능을 높일 수 있을테니까요.

 

하드웨어의 발전에 따라 소프트웨어의 분발도 놀랍습니다. 🙂