예전에 소개해 드렸던 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를 좀 더 효과적으로 이용하여 성능을 높일 수 있을테니까요.

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

ZDnet의 기사를 보니 메탈 게이트를 사용하는 트렌지스터가 상용화된다는 이야기가 써 있군요. 이 이야기는 하드웨어 리뷰 사이트들을 통해서 개략적으로 접하고 있었는데, ZDnet의 기사를 통해서 좀더 자세히 알게 되었습니다. (이번 MPR에도 잘 나와 있습니다만, 한글로 읽는 것이 더 편해서 ^^;)

사실 저는 반도체 물성과 같은 부분은 전공이 아니라 잘 모릅니다. 학부와 대학원때 과목을 들은 정도지요.. ^^ 간략하게나마 뭐가 어떻게 돌아가는 건지 설명드리자면, 우선 간단히 CMOS에 대해서 설명드리고 시작하는 것이 편할 것 같습니다.
트렌지스터라는 것이 일종의 스위치와 같은 것입니다. 버튼을 누르면 전류가 흐르고, 누르지 않으면 전류가 흐르지 않는 것이죠. CMOS 트렌지스터에서 이 버튼에 해당하는 부분이 바로 Gate라고 보시면 되겠습니다. 즉, Gate에 일정 전압이 가해지면 가로막혀 있던 부분이 열리는 그런 원리랄까요..

근데, CMOS transitor에는 문턱전압(Vth)이란 것이 있죠. Gate에서 어느 정도 전압이 가해져야 "문턱을 넘어서" 전류가 흐를 수 있는 것이냐는 것인데요.. 가끔 Gate에 전압이 가해지지 않더라도 문턱을 넘어가는 날랜 전자가 있습니다. 이런 넘들에 의해서 게이트의 상태에 변화가 없더라도 흐르는 전류가 바로 "leakage current"라고 보시면 됩니다. 말 그대로 줄줄 세는 거죠..
쉽게 생각해서, 문턱이 높으면 높을수록 게이트에서 전압이 없을때 필요없이 전류가 흐를 가능성이 낮아집니다. 근데, 문턱이 낮으면 낮을수록 게이트에서 전압이 공급되지 않더라도 문턱을 넘어가는 전자의 비율이 높아지죠. 반대로, 문턱이 높으면 높을 수록 Gate에 전압을 가해서 스위치를 켜는 시간이 오래 걸립니다.

이런 원리로 빠른 공정 = 낮은 문턱 전압 = 많은 leakage current로 연결됩니다. (뭐, 설명은 아주 대충했지만 말입니다.)
예전에 0.18um정도까지만 해도 leakage current를 신경쓰는 일은 거의 없었어요.. (사실 0.35um까지는 전혀, 0.18um부터는 조금.. ) 공정이 줄어들면서 문턱 자체를 구성하는 부분도 기껏해서 원자 수십개 수준으로 줄어들게 되었습니다(그것 보다 적나요? 정확하진 않네요.^^;). 그러다보니, 문턱전압도 낮아지고 leakage current라는 것이 동작할때 소모되는 것보다 더 많은 전력을 소모하게 된 거죠.

그래서, High-K라는 것이 나온 건데요.. K라는 것이 유전율(전자가 얼마나 빨리 흐를 수 있느냐)인데요.. K가 높아지면 문턱을 높인 다음에, 문턱을 약간만 내려도 그 좁은 길로 전자가 빨리 빨리 흘러갈 수 있다는 거죠. 좁은 대신 전자의 흐름 자체를 좋게 만들었으니까요.. (역시 쉽게 말하느라고 아주 정확한 표현은 아닙니다만..)

45nm에서 인텔에서는 그동안 사용하였던 poly silicon(지금까지 대부분의 공정은 silicon substrate위에 poly silicon으로 gate 얹어서 사용해 왔습니다. 이때 NMOS냐 PMOS냐에 따라서 N+/P+를 선택하는 거죠)대신에 NMOS나 PMOS에 맞는 Metal gate를 구성했다는 거죠. 아주 대단한 일입니다. 이로 인해서 속도는 유지하면서 leakage current는 잡을 수 있을테니 말입니다. 그리고, 또하나.. 이론대로라면 대부분의 전통적인 공정이 변경될 필요가 없을 것 같습니다. 단지 poly silicon대신 metal(물론 그렇게 쉽게 바뀔 부분은 아니지만 말입니다. ^^;)로 변경되는 정도니까요.

기사에서처럼 당연히 metal의 혼합비는 극비겠죠.. 뭘 물어보고..

IBM에서도 high-K를 채택한다고 하던데.. (이것도 어디 기사에서 봤는데 말이죠..), AMD와 IBM이 비교적 가까우니..이쪽 진영에서도 금방 바뀌지 않을까 생각합니다.

Moore 선생님.. 기쁘시겠어요.. ^^;

Cell 프로세서의 초기 형태를 지닌 PS3가 출시 되었습니다.

이미 여러 블로그에서, PS3와 XBOX360에 대해서 여러 측면에서 분석을 하여주셨는데요.. 저는 나름대로 프로세서 만드는 사람이니 프로세서의 입장에서 설명을 드려볼까 합니다. Cell에 대한 초기 논문과 기사만을 보고 "감"만 잡고 있는 상태이니 그리 좋은 글은 아닐 것입니다만..^^;

Graphic processor.. 발전..

초창기 graphic processing이라는 것이 CPU가 전담하고 있던 일이었다는 건 뭐 다 아시는 사실이겠죠.
CGA/EGA/VGA를 거치는 graphic card는 frame buffer에 있는 내용을 모니터로 전달하는 역할(소위 이야기하는 graphic triple DAC의 역할과 DMA정도의 역할)이 주된 일이었습니다. 사실 DMA도 없던 그래픽 카드가 대부분이었지요. 한마디로 CPU가 그림 다 그려주면 이걸 화면에 잘 뿌리는 동작이 제일 중요했고, 그래서 RAMDAC의 속도가 좋은 그래픽 카드를 선택하는 기준이었습니다.
하지만, windows 3.1 운영체제가 많이 배포되면서 그림을 그려야 할 일이 너무도 많아졌죠.
그 시절에 2D graphics accelerator라는 addon카드가 따로 나온적도 있었습니다만, 얼마지나지 않아서 그래픽 카드가 이 기능들을 포함하면서 조용히 사라지게 되었습니다. 이때부터 그래픽 카드는 processing 능력을 지니게 된것으로 보면 될것 같습니다. 사실 2D graphics acceleration이라는 건 별거 없구요.. 좋은 DMA기능에 간단한 조작 기능을 갖춘 것이랄까요.. 이정도 였던 것이 맞을 듯 합니다.

하지만, 3D 게임이라는 것이 발생하면서 상황은 너무 많이 바뀌게 됩니다. CPU에서 과도한 연산을 수행해야 하는 것이지요. 따라서, CPU에서 처리하는 integer 연산의 일부를 graphics card에서 처리하는 형태로 발전하게 됩니다. 그래픽 연산이라는 것은 기본적으로 데이터의 속성상 parallelism이 매우 뛰어나며, 하나의 처리가 전체 화면에 대해서 적용되므로 SIMD(Single Instruction Multiple Data)/vector processing이 가장 쉽게 적용될 수 있는 연산입니다.

당연스럽게 integer SIMD unit이 graphics card안에 내장되고, 이후에 floating SIMD unit이 내장되고, 속도를 높이기 위하여 좀더 넓고/깊은 파이프라인이 추가되는 국면을 맞게 됩니다. 이때부터 앞을 다투어 GPU라는 이름을 붙이게 되지요. (graphics processing이 vector processing을 이용하므로 branch가 거의 없다는 특성이 있고, 따라서 CPU에서는 꺼려지는 넓고/깊은 파이프라인을 구성하는 것이 용이합니다. CPU보다 많은 tr을 집적한 graphics processor에 대한 이야기가 많은데, GPU의 경우 처리하는 데이터의 속성상 넓고/깊은 파이프라인을 구성하는 것이 대부분 "항상" 유효하므로, CPU보다 더 많은 집적이 가능한 것입니다.)

Vector processing은 더 이상 특수한 일부를 위한 기능이 아니다.

graphic procssing unit에서 강력한 processing 기능을 처리할 수 있게 되었는데, CPU에서는 필요한 경우에 이 강력한 processing기능을 사용하고 싶은 마음이 들겠지요. ^^;

멀티미디어 측면에서의 graphics processing unit의 유용성에 대해서 이야기해 볼까요?
nVidia에서 Cg라는 언어를 이용해서 자사의 강력한 shader에 존재하는 넓은 파이프의 floating point processing기능을 그래픽 처리 이외의 일반적인 산술연산(실제적인 application은 물리 연산이겠습니다만..)에 사용할 수도 있도록 길을 열어 두었습니다.

게다가 한발 더 나아가 예전에 올렸던 peakstream이라는 벤쳐회사는 다양한 floating point 연산을 GPU를 사용하여 수행할 수 있도록 하는 compiler 통합시키는 기술(실제적으로는 library가 더 중요하겠습니다만..)을 선보여서 주목을 받고 있습니다.

한마디로, 이러한 경향을 예전에 supercomputer에서 수행하던 vector processing이라는 것이 더 이상 특수한 일부를 위한 기능이 아닌 시대가 오고 있다는 것을 보여주고 있습니다. 사용자들은 다양한 그래픽 처리를 당연하듯이 사용하고 있고, 좀더 정교한 물리 엔진이 적용된 게임을 하고 있습니다.

CPU와 GPU/VPU

Graphics Processing Unit에서 처리하는 데이터의 양이 많아짐에 따라, CPU와 GPU간에 더욱 더 넓은 대역폭이 요청되는 건 당연한 사실이겠습니다만, CPU에서는 이런 현상을 최대한 줄이기 위해서 local memory를 사용해서 GPU에서 필요한 정보들을 대부분 local memory에 담고 연산하는 방식을 취하게 됩니다. 하지만, graphics application이외의 연산에 GPU를 이용할때는 문제가 그리 쉽게 풀리지 않는 경우가 많이 생깁니다. 그림그려서 monitor로 출력하는 것이 아니라, 다시 main memory로 옮겨야 하고, 그 데이터를 필요한 경우 다시 CPU에서 참조하여 program flow를 결정하는 등의 연산이 필요하게 되므로, CPU와 GPU/VPU간의 데이터 대역폭이 급격히 증가하게 되는 것입니다.

저도 칩 쟁이입니다만, 칩간의 데이터 교환은 1) pin수의 제약을 많이 받습니다. 즉, 일정 수준 이상으로 대역폭을 늘리는 것이 불가능합니다. 2) PAD를 통과하며 예측 이상의 power를 소모하게 됩니다. 3) offchip에서는 PCB를 통과할 것을 가정해야 하므로 latency가 느려지게 됩니다.
(여담입니다만, 이런 연유로 package에 두개의 core(실은 각각 dual core지만..)를 때려박은 intel core 2 duo extreme이 AMD의 4x4보다 더 좋은 결과를 보일 수 밖에 없습니다. 마찬가지로 추후에 AMD의 real Quad core가 나온다면 이 현상은 역전될 가능성이 아주 높습니다만.. processing core의 능력은 별개이니 어찌될지 모르겠습니다. system 적인 architecture만으로만 따지자면 real Quad가 역전할 가능성이 높은 것이 사실입니다.)

따라서, CPU와 GPU/VPU를 on-chip에 통합하자는 이야기가 나오는 것은 아주 아주 당연한 이야기입니다.

칩 좋다고 성공합니까?

얼마전에 이런 글을 적은 적이 있죠? (여기).
Processor Architecture로는 Cell이 좋아보입니다. 우선 VPU와 CPU간의 interconnection도 그렇고 상당이 잘 짜여져 있습니다. (예전 standford의 모 프로세서 구조랑 비슷해 보이는데.. 차용한 것인지는 잘 모르겠네요.)
하지만 칩 좋다고 성공합니까?
칩이 아무리 좋아서 사용하는 사람을 힘들게 하면 성공하기 어려울 것입니다. Cell은 SIMD가 아닌 VPU가 general processing/Consumer 시장에 (제대로) 등장한 첫 칩입니다.

Parallel processor, Multi-processor, VLIW가 세상을 지배할 것이라 말한 것이 벌써 몇십년전입니다. 그렇게 되지 못한 가장 큰 이유는 바로 "parallel processing을 이해하는 programmer의 부재"입니다.
사람이 원래 순차적으로 생각하는 것에 익숙하니, 이를 뜸금없이 parallel processing에 적응해라~!라고 해봤자 별로 효용성은 없는 이야기입니다. jrouge님의 블로그에서도 이에 대해서 언급하셨는데요..

예전과는 좀 다른 희망이 몇가지있기는 합니다. 우선 컴파일러 기술의 진화입니다. 아직 미비하기는 하지만, parallelism을 찾아낼 확률이 높아지고 있지요. 두번째로 가장 중요한 것은, VPU에서 처리하고자 하는 내용이 parallel processing이 가능한 application이라는 것이지요. (사실 parallel programming의 경우 다수의 프로세서에 각각 job을 할당하고 이를 merge하는 형태로 진행되는데, 이때 사용되는 알고리즘들은 순차적인 생각이었을때와 완전히 달라지게 됩니다. 단, cell같은 경우 powerPC와 VPU를 분리한것으로 보아 VPU에서는 다수의 VPU에서는 특정 application만을 사용하겠다.. 라는 생각을 가진 것으로 보입니다. )

예를 들어, 2D/3D의 graphics processing, MPEG과 같은 video encoding/decoding, 물리 연산은 모두 matrix 연산을 기반으로 합니다. Vector processor라는 것이 matrix operation에 특화되어 있기 때문에, 해당 분야에 대한 API를 작성하는 것이 어렵지 않을 것이며, 이를 이용하여 고 수준의 API를 작성하는 것도 생각보다 어렵지 않을 것이라 생각합니다. (물론, 쉽다고 생각하지도 않습니다. 만일 Sony에서 이런 API/Compiler의 제공없이 parallel progrmming을 강요하는 상황이 온다면, 여지 없이 실패할 것입니다.)

CPU/GPU의 통합은 어떨까요?

뭐, 이 상황은 Cell과는 다르죠. 개발자의 입장에서야 같으니까요. 사용자의 입장에서는요?
CPU/GPU의 통합이 처음 있는 일은 아니지요. 저가형에서 간혹 있어왔고(VIA였던지 SiS였던지 기억은 나지 않습닉다만), 연구 수준에서도 있었습니다.(예전에 말씀드렸던 과거 ETRi에서 진행했던 4개의 IPU와 1개의 GPU를 통합하는 MPU도 그렇구요)

근데, 왜 아직까지 제대로 빛을 본 GPU통합 칩이 없을까요? 이유는 간단합니다.

"사용자의 요구는 아주 다양하다"라는 점 때문입니다.
같은 CPU와 같은 graphics card를 붙이고 계신 분이 몇분이나 되시겠습니까? CPU는 괜찮은것 같아서 graphics card만 업그레이드 해본적이 있으시겠지요?

만일 CPU/GPU가 통합된 경우 이런 것은 불가능하겠습니다. 하지만, 일정 수준이상의 CPU/GPU통합은 mass market에서는 통할 확률이 높습니다. (이런 점에서 예상외의 graphics chip set 판매의 강자가 intel이라는 점을 잊지말아야 겠지요 ^^; intel은 통합 칩셋을 팔아서 매우 많은 이득을 남기고 있지요.. 알게 모르게)

Cell.. parallel vector processing

Sony가 cell processor를 PS3라는 콘솔에 투입한 것은 매우 영리합니다. 개발자 이외에는 고민할 필요가 없는 마켓이며, 비교적 새로운 플랫폼이 먹힐 가능성이 높으니까요. (단, XBOX360은 개발자가 가장 편하게 여기는 PC의 환경을 그대로 가지고 있으므로, 개발 편의성 측면에서는 비교가 안되겠지요. )

사실 지금의 논의는 PS2의 개발 환경과 XBOX의 개발 환경을 비교하던 것과 비슷한 논란입니다.
XBOX는 PS2에게 처절하게 당하고 말았는데, 문제는 killer title에 있었습니다.
비싼 교훈을 얻은 Microsoft가 그냥 당하고 있지는 않겠지요.

궁극적으로 게임기는 그 성능에 관계없이 게임성이 가장 중요하다는것이 진리이니까요.
게임기의 성능을 보고 사는 사람은 얼마안되지만, 재미있는 게임을 하기 위해서 게임기를 사는 사람은 많으니까요.  PS3, XBOX360보다 훨씬 하드웨어적으로 열등하지만, Wii가 주목받고 있는 이유이기도 합니다.

processor하는 입장에서 cell의 성공을 바라지만(cell의 성공에 힘입어 좀더 parallelism을 잘 살려내는 컴파일러가 나타날 것을 기대할 수 있으니까요..) 미래는 알 수 없겠습니다.

요즘에 리퍼러 로그를 보니, 검색을 통하여 들어오시는 분들이 상당하시군요..
(덕분에 gzip 플러그인을 통해 전송량을 절반으로 줄여놨었지만, 다시 트래픽이 차오르고 있습니다. ㅠㅠ; 물론, 많은 분들이 찾아주시는 건 좋은 일이지요.. 이 분야에 관심 있는 분들이 많다는 것이니까요..)

이 포스팅은 리퍼러 로그에 남은 검색어를 통하여 살펴본, 제 블로그에 방문하시는 분들이 관심을 가지는 것에 대한 친절(?)한 답변들입니다. ^^;

verilog 관련
가장 많은 검색어는 verilog/VHDL 입니다. 요즘에 이걸로 수업받으시는 분들이 많고, 요즘이 term project 철이라서 검색 순위가 급증하고 있는 것이 아닌가 생각합니다.

* Verilog와 VHDL중에 어떤것이 더 좋은가..
둘 다 좋은 언어입니다. verilog가 "설계"라는 목적에 좀더 부합하고, VHDL이 "검증"에 더 편리한 기능을 제공합니다. 개인적으로 생각하기에 verilog가 설계만 따진다면 더 편하다고 생각합니다.

* VHDL -> verilog변환, verilog ->VHDL 변환
가끔 뉴스 그룹에서 이거 변환 프로그램 찾으시는 분들도 봤는데, vhdl2v 같은 전용 변환 프로그램이 있기는 합니다만, 시도해보시면 상당한 스트레스를 받을 것이라 생각합니다.  ESNUG에 나온 내용을 붙이자면, 잘 안된다! 입니다.

ESNUG내용보기

대안으로는 verilog나 vhdl이나 동일한 중간 포맷으로 해석해서 사용하는 툴을 쓰는 건데..
제가 사용해본 것은 Summit design의 visual HDL로 변환하는 것이었는데, 역시 structural 설계는 잘되는데 약간 behavioral하게 설계된건 잘 안되었습니다.

만일 동작만 보면되고, 안의 내용은 필요없다! 라고 생각하신다면, synopsys에서 합성한 후에 원하는 format으로 netlist를 출력해서 시뮬레이션에 사용하는 것이 제일 속편합니다. 물론, simulation용 라이브러리를 물어야 하지만 말입니다.
(뭐, 요즘엔 ncsim이나 modelsim이나 모두 VHDL/Verilog를 single kernel에서 시뮬레이트해서 이런 필요는 없겠지만.. 라이센스 문제가 아닌 이상엔 말이죠..)

* verilog에서의 #
위의 문법은 원하는 만큼 지연을 발생시키는 것입니다. 합성시에는 무시됩니다.

* verilog에서의 <=과 = 의 차이
blocking assignment와 non-blocking assignment를 혼동하시는 분들이 생각보다 많은데요..(저도 verilog 처음에 잘 몰랐습니다.) blocking assignment는 "시간이 흐르지 않는 상태(흐르지 않게 block하면서)에서 값이 저장된다"이구요.. non-blocking assignment는 "시간이 흐르면서 값이 저장된다" 입니다.
즉, 아래와 같은 연속된 assign의 경우 위의 blocking을 사용하였을때 d는 a의 값을 가지게 됩니다. 값의 할당 자체에 시간이 소모되지 않도록 하나의 할당이 끝날때까지 시간을 멈추기 때문입니다...
그런데, 밑의 nonblocking 예에서는 "값을 할당하자"라는 것은 현 시점에서, 값이 갱신되는 것은 delta delay이후에 이루어지게 됩니다. 왜냐하면, 값이 할당되든 안되든 값을 할당하겠다는 3개의 문장을 모두 보고나서 delta delay이후에 값이 갱신되기 때문이죠.

이해 되시려나요?

* verilog PLI 관련
예전에 계속쓰려다 잠시 중단되었는데, PLI 관련 내용은 요즘에 제 작업 관계로 앞으로 1~2개월동안 자주 올라올 확률이 높습니다. 테스트 벤치 생성 유닛과 scoreboard를 C로 만들고 이걸 verilog PLI로 연결할 예정이거든요..
기대하셔도 좋을듯..


다른 검색을 통한 리퍼러 로그..
Design Compiler와 VCS, Modelsim에 대한 검색이 많았습니다.
사실, 툴에 대해서는 소개나, 새소식만 하고 있어서 별다른 내용이 없었는데 말이죠.. ^^;
참.. 시뮬레이션 하는 방법은 quick reference guide를 살펴보시면 쉽게 하실 수 있습니다. ^^;

프로세서에 대한 검색으로 들어오신 분들도 많았습니다. intel, AMD, ARM, calmRISC, M-Core, EISC(감사합니다.)
블로그에 좀더 프로세서에 관련된 좋은 내용을 적을까 싶기도 한데.. 이쪽 분야 하시는 분이 워낙 적어서 누가 관심이 있을까.. 라는 씨니컬한 마음이 될때도 있습니다. ^^;

아.. 특이한것이 virtual UART를 검색해서 들어오신 분이 계시던데..
제가 이 블로그에서 PLI + TCL/TK를 조합한 virtual UART라는 걸 만든적이 있다고 말씀을 드린적이 있는데, 검색해서 들어오신분은 아마 회사분이 아니실까 생각합니다. 회사분이시라면 인트라넷에 올라간 virtual UART 관련 메뉴얼을 참조하세요.. 소스코드와 작성법이 다 있으니까요..^^;

찾아주신 분들 모두 감사드립니다.

MPF fall에서 여러가지 재미난 소식들이 전달되고 있습니다.
이번에 전해드릴 소식은 EEtimes에 나온 AMD Quad Core processor( codename: barcelona) 관련 소식입니다.

Intel에서 core 2 quad를 2007년 상반기에 내놓겠다고 IDF에서 큰소리 빵빵쳤더랬습니다.
이에 질새라 AMD는 true quad core processor인 barcelona에 관한 소식을 MPF fall에서 발표했습니다.
사실 AMD의 quad코어 전략은 desktop에서는 4x4를 기반으로, 즉  dual core processor 두개를 하나의 칩에 내장하는 형태로 공략하고, 이후에 QUAD코어로 간다는 것이었습니다.
서버쪽은 바로 true quad코어로 간다는 전략이구요.

TRUE quad core라고 강조하는 것은 사실 AMD의 전략(?)이라고 보이는데, 비교적 열등한 형태의 인텔 CMP의 형태를 겨냥한 느낌이 다분합니다.
인텔의 core 2 duo의 경우 사실 single core가 대규모 L2 cache에 merging되어 있는 형태라 전통적인 MP의 형태와는 좀 다른 면이 있습니다.

거기에 비해서 AMD의 quad core는 4개의 분리된 single core가 Direct Connect된 corssbar switch형태의 버스로 연결된 형태를 지니고 있습니다.

[이미지 출처: http://i.cmpnet.com/techweb/features/quadcore/amdquadcore_420b.jpg]