Author Archives: babyworm

Cell의 VPU, AMD의 ATi GPU 통합

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의 4×4보다 더 좋은 결과를 보일 수 밖에 없습니다. 마찬가지로 추후에 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을 잘 살려내는 컴파일러가 나타날 것을 기대할 수 있으니까요..) 미래는 알 수 없겠습니다.

캐논의 IXUS 400. 비공개 리콜?

그 동안 서브 카메라로 잘 사용해온던, IXUS 400이 1~2달 전부터 메모리 카드 에러가 발생하기 시작했습니다.
뭐, 대수롭지 않게 생각했지요.
카드 에러가 났을때 메모리를 뺐다가 다시 끼우면 정상으로 돌아올때도 있었고
몇일 지나면 괜찮아질때도 있었으니까 말입니다. (제가 좀 무신경한지라.. ^^;)


그런데, 얼마전부터는 메모리 카드 에러의 빈도가 부쩍 높아졌고, 메모리 카드 포맷을 하면 E50이라는 에러 메시지가 발생하고, 메모리의 용량 인식도 이상해지는 현상이 많아졌습니다.


메모리를 바꾸어도 동일한 증상이 발견되고, 해당 메모리 카드를 PC에서는 잘 인식하고 하는등.. 아무래도 A/S를 받아야 할 거 같아서 A/S 센터를 찾았지요.


A/S센터 직원분께서 한번 쓰윽 살펴보시고 증상을 보시더니만,



이건 메모리 문제는 아닙니다. 메모리와 카메라를 연결하는 인터페이스 부분에 결함이 발견되어서 이 부분은 A/S 기간과 관계없이 무료로 서비스됩니다. 해당 부품을 일본에서 가지고 와야 하므로, 가지고 오는데 시간이 걸리는데 맡기시겠습니까?


당연히 맡기는거 아니겠습니까? 카메라를 못쓸 지경인데요..


그런데, 캐논측에서 해당 부분에 결함이 있음을 발견하였고, A/S하시는 분의 응대로 보았을 때, 상당히 많은 분들이 이 문제로 A/S를 요청하러 오시는 듯 했습니다. 하지만, 아쉽게도 저는 DCinside, LG 상사쪽의 공지에서 IXUS 400의 인터페이스 부분에 대한 결함에 대한 이야기도, 해당 부분에 대한 공개 리콜에 대한 이야기도 찾을 수 없었습니다.  오늘(12월22일) Cannon A/S 홈페이지에서 위의 내용을 발견했습니다. 따라서 비공개 리콜이 아닌가 하는 의혹은 지웠습니다. ^^;
제가 카메라를 구입한 LG상사쪽의 응대에 문제라고 생각하는 것이 더 맞을것 같습니다. Cannon의 A/S가 이전의 LG상사에서 Cannon-Korea로 변경되었는지도 모르고 있었는데, 이런 일이 있으면, LG상사쪽의 A/S page에서 cannon A/S 페이지로 연결을 해주었으면 좀더 매끄로웠을텐데 말입니다.
여하튼.. 아래 내용은 취소~!


결론적으로 결함을 발견해서, 문제가 발생하는 고객에 대해서만 처리해 준다는 것 같은데요..
이런 문제라면 리콜 사실을 알리고, 적극적으로 응대하는 것이 맞지 않을까 생각합니다.


뭐, 문제없이 잘 사용하시는 사람들의 것도 일부러 부품을 바꿔주면 돈이 많이 들겠지.. 라는 생각이 드는 것은 알겠지만, 결함을 발견하고도 지금 당장 문제없으니… 라고 생각하는 것도 좀 아닌듯 하네요..

2006년 12월 22일 추가—————-


캐논 A/S센터에서 수리가 끝났다는 이야기를 듣고, 몇시까지 영업하는지 찾다가 Cannon A/S 홈페이지를 찾게 되었습니다. 여기에 보면, LG-캐논에서 운영하는 홈페이지상에서는 위의 버그에 대한 언급이 없었습니다만, Cannon A/S 홈페이지의 4월 6일자 공지사항에는 위의 내용이 명시되어 있습니다.
(참고: Cannon A/S 홈페이지 http://support.canon-ci.co.kr/)

위의 증상은 IXY-400, Powershot-S400에서 발생할 수 있다고하니, 확인해보시고 수리 받으세요..

검증의 대세는 system verilog?

검증 작업을 시작했다는 포스팅을 얼마전에 했었습니다.
뭐, 일단 검증 시나리오 짜고, function coverage 전략 세우고.. 이런것 부터 시작했습니다만..

verilog로 약간 검증 마인드로 이런 저런 것을 작성하다보니, synthesizable subset의 틀이 얼마나 옭죄고 있었나라는 생각이 심각히 들더군요..

verilog 표준에서 정의된 동작에 대해서 어느정도는 알고 있다고 자부하고 있었는데, 좀더 깊이 알게 되는 기회가 되고 있는 것 같습니다. 얼마전 gil님께서 class와 비슷한 verilog를 말씀하신 이유도 납득이 가구요..
사용자 삽입 이미지
하지만, verilog는 추상화 레벨을 높이기에 약간 무리가 있기는 하더군요.. 물론, 어짜피 regression vector쪽에는 PLI위주로 가게될 것으로 구상해두었지만, 일반적인 경우에는 PLI사용을 꺼리시는 분들도 있는 관계로 왠만하면 verilog만으로도 어느정도 coverage를 보일 수 있도록 구상하고 있는데… 약간 까다로운 점이 있습니다.

그래서, 대안 처럼 생각하고 있는 부분이 SystemVerilog인데, 아직 제가 본격적으로 공부해본것이 아니라 스펙 수준에서 표준 문서만 한번 훓어본 정도에서 멈추어 있던 상태라 약간 깨름직 했었습니다.
그런데, verification guild에서도 그렇고, comp.lang.verilog도 그렇고 system verilog에 대한 내용과 비중이 점점 높아가는 것을 알 수 있겠더군요.

사실 verification guild의 guild master가 vmm-sv의 저자이기도 하니까 그렇겠지요..
하지만, writing testbench 책이 HVL이 아닌 system verilog만을 이용해서 다시 작성할 수 있을 정도로 system verilog의 verification기능이 강력하다는 것은 아무래도 끌리는군요.
(옆에 보이는 책이 writing testbenches using systemverilog책이 바로 예전에 제가 다시 읽고 있다는 writing testbenches의 새 버젼이지요. 요즘에 가장 사고 싶은 책입니다. 하지만, 가격이… 가격이.. orz)

Verification Methodolgy Manual for SystemVerilog와 같은 책이 나온것도 사실 system verilog가 대세가 되는 것 아냐? 라는 생각을 가지게 하는 이유이기도 하지만 말입니다. (또한권의 가장 사고 싶은 책입니다. 역시 가격이.. 에휴… ) 사용자 삽입 이미지책의 홈페이지에는 system verilog를 이용한 verification에 대한 개략적인 정보는 얻을 수 있습니다.

사실 초기에 저는 cadence의 SCV를 필두로한 systemC에 대항하기 위해서 synopsys가 선택한 카드가 system verilog일 것이라는 곱지 않은 시선을 가지고 있었습니다.
하지만, 요즘에 와서는 system verilog를 native로 지원하는 simulator들이 속속 등장하고 verilog표준에 system verilog가 포함될 것으로 예정되어 있는 상태이니.. 정말 systemverilog가 HVL을 대체할 정도로 강력하다면, 대세가 될 확률이 높아지겠지요.

여하튼, 지금 가지고 있는 system verilog for design(stherland저)책이라도 한번 봐둘 필요는 있을 것 같습니다. ^^;
사실 예전에 이 책 봤을때는 systemverilog에 대해서 약간 실망을 했었는데, 검증의 측면에서는 어떨지 한번 공부해 봐야겠습니다.

이 부분은 역시 작업 마치면 한번 정리하죠..나~~~중에