Category Archives: SoC & IP design

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을 잘 살려내는 컴파일러가 나타날 것을 기대할 수 있으니까요..) 미래는 알 수 없겠습니다.

검증의 대세는 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에 대해서 약간 실망을 했었는데, 검증의 측면에서는 어떨지 한번 공부해 봐야겠습니다.

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

에이.. 칩 좋다고 성공합니까?

여러가지 칩들 중에 버그가 많은 칩이 존재한다는 건 이미 알려진 이야기지요..
그중에 소프트웨어적으로 회피할 수 없는 심각한 문제를 숨기고 있는 칩도 있구요..

그럼에도 성공하는 칩이 있습니다.

버그 없고 잘 나온 칩인데 실패하는 칩도 있습니다.

성공하는 칩은 적절한 시점에 적절한 가격으로 출시된 경우가 대부분입니다.
칩이 기획되고 나와 상용화까지가는데, 최소 1년, 길면 2~3년이라고 보면 성공한 칩은 “미래에 대한 예측에 성공했다”고 보는 것이 옳을 것입니다.

소위 이야기하는 블루 오션 전략에 성공하는 패턴이겠지요.

국내 비메모리 회사들중에 현재 매출순위 top 10안에 들어가는 회사들이 바로 이 블루오션에 개척에 성공한 케이스라고 생각합니다. (물론, 이 분야가 이제는 심각한 레드 오션으로 바뀌고 있는 상황이니 다른 매출꺼리를 찾아나가고 있는 중이겠습니다. 새로운 시장을 개척하는 방향이 대부분 회사에서 비슷한 방향으로 진행되고 있다는 건 좀 우려되는 상황이긴 하죠..)
사실 국내 비메모리 반도체 회사들이 대부분 벤쳐 기업으로서 출발했으니, 이러한 블루 오션 전략으로 올인하는 방향이 가장 현명한 선택이었음에는 의심의 여지가 없습니다.

시스템 업계에서 새로운 칩을 선택하려고 하는 시점에 시의 적절하게 나온 칩들은 만일 약간의 버그가 있더라도 기능과 가격적인 메리트로 일어날 수 있는 것이지요. 물론, 버그 없는 칩이 같이 있었다면 더 어려운 상황이었겠죠.

그럼 ocean이 점점 피빛으로 물들어 갈때 해야 하는 전략은 무엇이 있겠습니까?
칩 자체의 가격을 낮추는 것이 가장 먼저 떠오를 수 있는 생각이겠지만, 이런 전략은 궁극적으로 어려움을 초래할 가능성이 있습니다.

다른 방법으로는 바로 사용자 측면에서 비용을 낮출 수 있도록 도와주는 것입니다.
소위 이야기되는 bug-free나 platform based가 이런 것이겠습니다.
버그가 없다는 건 어찌보면 시스템 업체에서 고생할 가능성을 최소한으로 줄일 수 있도록 한다는 건데.. 실제적으로는 bug뿐만이 아니라 사용자의 실수를 알려줄 수 있는 기능(칩의 입장으로는 overhead겠습니다만..)까지 넣는 것이 바람직하겠습니다.

Platform-based 라는 것이 상당 시간동안 회자되고 있습니다.
특정 분야의 시스템에 맞추어져 있는 chipset과 소프트웨어를 갖추어 놓고, 이를 시스템업체에 제공하는 방법이 platform based 방법이라 볼 수 있는데, 시스템 업체의 입장에서는 시스템 제작에 따르는 부담을 극적으로 감소시킬 수 있다는 장점이 있겠죠..

칩 업체 입장에서는 해야할 것이 너무 많으니 부담되는 것으로 받아들여지는 경우가 더 많은 것 같습니다.
하지만, 적극적인 플랫폼의 개발이 개발된 칩의 사용 가능성을 한층 넓힐 수 있는 확실한 방법이 됩니다. (만일 버그가 있더라도 제공된 software로 효과적으로 숨길수도 있고 말입니다. ^^;)
게다가, 칩 업체가 시스템 업체에 대한 지원 부분도 아주 효과적으로 줄일 수 있으니, 장기간으로 보았을때는 좋은 플랫폼을 제공하는 칩이 성공하는 칩이 되겠습니다.

에이.. 칩만 좋다고 성공합니까? 칩만 만든다고 되는건 아니라니까요..