Category Archives: Microprocessor

마이크로 프로세서에 관심 있으신 분을 위한 글.

이 글은 예전에 쓴 “프로세서/비메모리 반도체 설계를 희망하시는 분들께“라는 글과 연관성이 있습니다. 단지 프로세서 설계를 희망하시는 분들께 유용할 수도(?) 있는 내용 위주로 쓰여졌다는 것만 다르겠습니다.

일단 마이크로 프로세서라는 분야에 대해서 설명이 필요할 것으로 봅니다. 학교에서 마이크로 프로세서 구현에 대한 연구는 EE(전자공학)에서 이루어지는 것이 대부분이며, 기업체의 경우 embedded microprocessor는 상당히 많은 업체에서 상용화에 도전하고 있습니다.

하지만, 마이크로 프로세서라는 분야는 그 특성상 몇몇 ISA(명령어 셋 아키텍쳐) 들이 그 점유율을 크게 가져가는 경우가 많기 때문에, 독자적인 ISA를 지닌 마이크로 프로세서를 만들어서 성공한다는 것은 매우 어렵습니다. 이는 사용할 수 있는 프로그램의 수가 많고, 개발자 pool이 튼튼한 프로세서가 계속하여 성장한다는 당연한 이야기(eco-system이라고 보통 표현되는..) 때문입니다.

일례로 PC/서버 계통에서는 x86 ISA가 완전하게 시장을 장악했다고 해도 과언이 아니며, 그 이외의 ISA가 들어오기는 매우 어려울 것으로 봅니다. (그런 측면에서 저는 ARM이 PC 마켓 – netbook이라 불리는 부분에 있어서도..-에서 점유율을 가져 오기는 매우 어려울 것으로 생각하고 있습니다.)

국내에서는 자체 ISA를 가진 프로세서를 설계하는 회사도 거의 없을 뿐 아니라, 이를 지원해 줄 수 있는 컴파일러와 OS를 만드는 회사도 거의 없습니다. 여러가지 여건 상 마이크로 프로세서를 하시는 분들께는 좋지 않은 여건이지요

그럼에도 기업체에서는 학교에서 마이크로 프로세서를 선택하신 분들에 대한 요구가 적지 않은 데요.. 그 이유는 마이크로 프로세서를 만들기 위함이라기보다, 마이크로 프로세서를 이루고 있는 여러 가지 기술을 기반으로 다른 기술에 적응이 빠르다는 장점 때문입니다. 마이크로 프로세서를 만드시는 분들은 소프트웨어와 하드웨어, 모델링 등에 어느 정도 넓은 지식을 갖추어야 하며, 하드웨어에 있어서도 연산기, 제어 유닛, 버스, 캐시 등에도 어느 정도 이상의 지식을 갖추어야 하는데 이런 폭넓은 지식들이 다양한 설계를 하는데 좋은 밑바탕이 되기 때문입니다.

특히 마이크로 프로세서를 공부한다는 건 제어와 연산, 메모리 접근을 최적화 시키는 데 있어서 상당히 깊은 지식을 얻게 되는데, 이러한 지식은 여러 종류의 프로세서 – video, multimedia, audio, network processor등-에 아주 유용하게 사용할 수 있는 기반을 갖추게 된다는 걸 의미합니다.

대충 마이크로 프로세서를 공부한다는 것이 어떤 의미인지는 설명 드렸으니, 그럼 프로세서를 하려면 뭐를 봐야 하느냐 하는 문제에 대해서 설명하겠습니다.

프로세서를 만드는 건 1) 상위 레벨 모델을 기반으로 작업하는 것, 2) RTL 수준까지의 설계, 3) gate 수준에서의 설계 정도로 나누어 생각해 볼 수 있겠습니다. 세 가지 모두 어느 정도 갖추어야 하겠습니다만, 학교에서 논문을 쓰기 위해서는 1)번을 잘해야 하고, 칩을 보고 싶으면 2)번을 잘해야 하고, 우리나라 회사에서 적응하기 쉬우시려면 3)번도 잘해야 합니다.

일단, 프로세서에는 다양한 스펙트럼이 존재합니다. 일례로 프로세서의 구조, 분기 예측, pipeline의 형태, 새로운 연산기나 명령어 적용, 값의 예측 등에 따른 performance변화나 전력 소모의 변화를 연구하게 되는데, 이런 것을 할 때 마다 실제 칩을 설계를 하게 되면 졸업할 수 있는 분이 없으실 테니 일반적으로 C 수준의 simulator를 이용하게 됩니다.

이러한 연구에 들어가기 위해서는 앞에서 이야기 된 S/W가 어떻게 컴파일 되어서 프로세서에게 인식되는지에 대한 이해(ISA)와 더불어 프로세서를 구성하는 여러 가지 요소 – pipeline, cache, virtual memory –에 대한 이해가 있어야지 연구가 진행될 수 있겠습니다. 생각보다 기본적인 데이터 통신이나 데이터 구조에 대한 이해는 아이디어를 얻어내는데 아주 많은 도움을 줍니다. 또한, 많은 경우에 수학적 모델을 세워야 할 필요가 있으므로, 수학적 모델에 대해서도 알아두실 필요가 있습니다.전력 측정 등을 하게 되면 당연히 기본적인 전자회로에 대한 이해는 필수적일테구요

이러한 상위 수준의 모델을 이용한 연구에 가장 널리 사용되는 것은 simplescalar라는 시뮬레이터지요. 이 시뮬레이터는 alpha 아키텍쳐에 기반을 두고 처음에 만들어졌는데 구조가 유연해서 ARM 버전도 있고, (EISC 버전도 있고..) 전력 측정을 위한 simplepower라던지 여러 variation들이 있습니다. 여러분들이 연구를 진행할 때도 마찬가지로 해당 시뮬레이터에 자기의 아이디어를 적용시켜 modify하고 성능을 보는 형태로 연구를 진행하고, 논문을 쓰는 거죠. 이런 일을 위해서는 기본적으로 “C/C++ 와 기본적인 데이터 구조 및 알고리즘에 대해서는 어느 정도 이상 할 줄 알아야 합니다.” 몇 번 말씀 드렸습니다만, 이쪽 분야 엔지니어에게 있어서 C/C++은 그냥 언어나 다름 없습니다.

두 번째로 자신의 idea가 어느 정도 확정되었으면, 이것을 RTL(register transfer level)로 설계(보통 verilogHDL이나 VHDL을 사용합니다.)해서, 논리 합성이라는 과정을 거쳐야 합니다. 이때 아이디어가 좋았고, 아키텍쳐가 좋았어도 논리 회로에 대한 기본적인 이해가 없다면 좋은 회로를 만들어내기 어렵습니다. 따라서, “논리 회로에 대한 이해“와 “RTL 설계를 위한 언어 – verilog든 VHDL이던“는 기본적으로 필요합니다.

세 번째로 gate 수준의 설계는 국내 대기업에서 프로세서 작업을 할 때 많이 사용되는데요..(gate 수준의 최적화를 많이 하시니..) 저는 이 분야에 교양적인 지식 밖에 없어서 조언을 드릴 부분이 매우 작습니다. J

아.. 책 이야기를 빼 놓았군요.

저는 Architecture에 있어서는 처음 시작하신다면 Hennessy & Patterson의 computer organization & design이라는 책이나 M.Mano의 책으로 시작하시는 것이 무난하다고 봅니다. 이후에 Hennessy & Patterson의 책(CAQA라 불리는)과 Flynn의 책을 추천해 드리고 싶습니다. 쉽게 읽힐 분량도 아니고, 쉽게 읽히는 내용도 아닙니다만 꼭 한번은 완독 하시길 바랍니다. 깊이 있게 보다는 넓게 보시고 싶으시다면 Sima의 책(advanced computer architecture)도 추천해 드릴만 합니다.

설계의 교양이라는 점에 있어서는 ASIC이라는 책을 보시고 난 이후에 Chinnery의 Closing the Gap Between ASIC and Custom이라는 책도 괜찮습니다. 상당히 괜찮은 관점을 보여줍니다.

RTL Design에 있어서는 (VerilogHDL이나 VHDL과 같은 HDL을 아신다는 가정하에 – verilog에 관련된 책은 예전에 제가 추천한 적이 있습니다. ) Reuse Methodology Manual을 “반드시” 읽어보시길 권하고 싶습니다. 학교에서 짜여진 코드가 생각보다 구닥다리 코딩 스타일을 가지고 있는 경우가 많습니다. Software engineering과 마찬가지로 하드웨어에서도 요즘 중요한 문제는 HDL코드의 readability와 reusability 입니다. 아주 critical 한 부분이 아니라면 약간 타이밍과 면적에 손해를 보더라도 요즘 코딩 스타일을 따르시는 것이 지속적으로 코드를 갱신 할 수 있습니다.

Verification에 있어서는 Comprehensive functional verification이라는 책을 권해 드리고 싶습니다. SoC 시리즈 입문서이기도 하고 잘 쓰여진 책입니다.

마지막으로 마이크로 프로세서를 만드시려는 분들께 한가지만 더..

마이크로 프로세서를 만들 때 가장 중요한 것이며, 가장 간과하기 쉬운 것이 ISA 입니다. 사실 ISA의 설계가 마이크로 프로세서에 있어서 절반 이상이라고 봅니다. 마이크로 프로세서에 있어서 ISA는 이 프로세서가 지향하고 있는 점(철학이라고 하면 좀 거창하고…)을 가장 잘 표현합니다. 학교에 계신 많은 분들은 “어떻게 하면 쉽게 프로세서가 설계 될 것인가?”라는 관점에서 ISA를 설계하시는 경우도 많지요 ^^; 또한, 어떤 프로세서의 경우는 표면적으로 지향하는 바와 ISA가 전혀 매칭이 안되는 경우도 있구요.

EISC의 경우는 ISA를 설계할 때 다양한 실험을 통해서 “프로그램의 크기와 메모리 접근이 가장 줄어들도록 하려면 어떻게 해야 하는가?” 라는 관점에서 모든 명령어 셋이 설계 되었습니다. 이는 임베디드에서는 프로그램의 크기 = cost라는 공식이 성립하기 때문이기도 하고, processor와 memory간의 속도 차가 점점 벌어질 것이라는 관점, memory접근으로 인하여 발생하는 전력 소모의 문제 등을 고려하여 잡은 목표입니다(EISC의 요즘 마케팅 포인트 중의 하나가 energy efficient microprocessor 이지요). 이를 위하여 다양한 실험이 수행되었고, 이중에 가장 적합하다고 생각하는 명령어 형태가 결정된 것이지요. 한 비트 한 비트 설계가 쉽게 이루어진 것은 아니고, 모두 의미가 있지요. 이후에 추가된 DSP 확장 명령어들도 각기 다양한 DSP 커널을 분석하고 이를 기반으로 ISA가 정해졌고, 구현할 때도 이런 부분이 고려되었습니다. 이런 목표 하에 설계되어 명령어의 형태가 일반적인 compressed code RISC들 보다는 약간 더 복잡하고, 이는 디코더 복잡도를 높이는 단점으로 바뀝니다. 달리 이야기하면, ISA를 설계할 때 어떤 결정은 어떤 면에서는 장점이 되지만, 다른 측면에서는 단점이 되는 부분이 있으니 조심해서 결정해야 할 부분이 많은 거죠.

마이크로 프로세서를 공부하고자 하시는 분들께 마지막으로 말씀 드리자면, 최소한 1년 정도는 넓게 공부하시고, 되도록 책을 많이 읽으시라는 “아주 지극히 일반적인” 말씀만을 드릴 수밖에 없네요. ^^; 또 한가지는 프로세서를 하실 분들은 DSP, 데이터 통신에 대해서는 어느 정도 알고 계신 것이 여러모로 도움이 됩니다.

결론 없는 “공부하세요”라는 글이 되었군요. 아.. 요즘 나 왜 이래.. orz

새로운 EISC processor

저희 팀에서 이번에 새로 만든 EISC processor인 Empress에 대한 기사가 많이 나오고 있습니다. 단신을 제외하고도 꽤 많이 나왔군요.

 

 

일단 정말 승질 머리 디러운 팀장의 강력한 태클과 갈굼을 이겨내고 좋은 결과를 거둔 팀원들에게 최고의 찬사를 보내고 싶습니다. 짝짝짝~! (제가 그 팀을 알아서 하는 이야긴데, 제가 그 팀장 밑에 있었으면 아마 회사 때려쳤을 겁니다. ㅋㅋㅋ)

여하튼, 새로운 프로세서에 많은 관심이 보여지고 있다는 점에서 상당히 기쁘긴 하지만, 대부분의 기사가 속도에 방점을 찍는 관점에서 많이 기술되어 있다는 점은 약간 아쉬운 점이지요. 사실 속도를 높이는데 여러 가지 요인이 있겠지만, 마이크로 아키텍쳐적인 접근을 제외한다면, 가장 중요한 것이 좋은 공정 + 좋은 cell library + 좋은 macro block을 사용하는 것이 중요합니다. 근데, 저희는 그다지 큰 회사가 아닌 관계로 좋은 공정은 물론이요 좋은 cell library(고속 cell library는 따로 비용 청구가 되지요)나 좋은 macro(특히 cache tag에 사용되는 CAM이 아닌 일반 High density single port SRAM을 사용하게 되면 속도차이가 심하죠..)를 사용하는 것이 비용의 문제로 쉽지 않다고 인식하고 있습니다. 따라서, 속도는 마이크로 아키텍쳐에서 할 수 있는 수준까지만 잡아놓자는 것이 저의 일관된 접근 방법입니다.

이번 Empress 프로세서는 단순한 MHz 단위의 클럭 속도보다는 면적이나 전력 소모를 줄이고, 클럭당 명령어 수를 높일 수 있는 방법, 그리고 자바 언어 가속 기술에 무게를 두고 만든 버전입니다. 그래서, 적은 면적(대략 동급 ARM의 절반 크기)에서 좀더 정교한 분기 예측기와 loop 처리 기법, out-of-order completion 방법, non-blocking cache등의 주요 기술을 저희 프로세서를 위하여 개발하는데 공을 많이 들였습니다. 물론 부족한 부분이 아직 많아서 좀 더 노력해야 할 부분이 많지요.

보도 자료 상에서도 위의 이야기가 많이 있었는데, 실제적으로는 거의 다루어지지 않아서 좀 아쉽습니다. (기자 분들께서 비 전문가를 위해서 가장 이해하기 쉬운 부분을 발췌하신다는 것은 알고 있습니다만..)

앞으로도 저희 프로세서는 특별한 일이 없는 이상(예를 들어, 가끔 정말 모르시는 분께서 ‘어찌되어도 좋으니 xxxMHz를 맞추어야 한다’라고 외압을 넣으신다던지..) 단순히 클럭 끌어올리기는 없으며, 1) 명령어 수준의 병렬성과 쓰레드 수준의 병렬성을 찾아가는 방향과 2) 자바와 같이 intermediate language를 이용하는 환경을 가속하는 방향으로 발전할 예정입니다.

특히 2009년, 자바 언어와 2D 벡터 그래픽은 embedded 분야에서 매우 중요한 명제가 될 것으로 예측하고 있습니다. 그래서, 저희 팀에서는 프로세서의 자바 가속뿐 아니라 2D 벡터 그래픽 분야도 같이 병행하고 있지요. 2009년 요맘때쯤 또 한번 재미있는 소식을 전해 드릴 수 있기를 바라고 있습니다. ^^;

내년 상반기 중에는 사내에서 사용하고 있는 linux수준의 OS 구동이 가능한 시스템 수준의 시뮬레이터인 ESCAsim(EISC System Cycle Accurate Simulator)의 소스 코드를 좀 정리해서 Open Source로 배포하는 것도 계획 중이며, IDEC과의 작업도 성공적으로 진행 중에 있고, EISC 개발 지원을 위한 Community site도 준비 중에 있습니다.

사람도 없는데, 참.. 벌이는 일은 많고 해서 걱정이긴 합니다. 어려울 때 한발자국 더 뛰는 사람이 내일을 기약할 수 있을 것이라 믿고, 힘들지만 몸땡이를 더 굴려보렵니다.

Intel의 새로운 GPU

제가 자주 그렇게 하고 있습니다만, 이 글은 MPR의 기사와 몇몇 논문을 기반으로 하고 있습니다. 읽고 제 맘대로 쓰는 글이라 항상 그렇듯 모두 맞는 내용을 쓰고 있다는 보장은 없어요.



Intel이 새로운 UFO를 주워서 새로운 장난감을 만들었습니다 ^^; 사실 인텔에게 GPU는 생소한 분야가 아닙니다. 이미 GPU 분야에서 상당한 – 실제적으로는 모든 마켓을 고려했을 때는 가장 큰- 마켓 쉐어를 가지고 있으니까요.. (근데, 아직도 이런가요? 몇년전엔 맞는 이야기인데, 아직도 이런지는 확신이 없네요. )



돌아가는 상황


Intel이 x86 기반으로 데스크 탑과 서버 시장을 장악하고 있다는 것이야 다들 아는 사실이고, 예전에 예상했듯이 strongARM과 XScale 사업을 버린 이유가, x86기반으로 embedded 시장에 도전하려는 것이라는 것도 실제로 나타났지요. 오히려 예상보다 느린 행보라 약간 의아할 뿐입니다. 실제적으로 ARM과 불꽃 튀게 붙게 될 시점은 2010년 정도로 보고 있습니다. ARM에서 저전력을 가지고 이러니 저러니 해도 Intel은 아직 SoC를 만든 것이 아니라, mobile processor를 embedded 시장에 맞도록 한번 바꾼 정도라고 보시는 것이 맞을 것입니다. 즉, ARM에서 내세우는 저전력의 우세는 ARM에서 그러하듯이 intel이 대부분의 peripheral을 on-chip화 시켜 SoC를 만들어내는 2010년 정도에 따져볼 일입니다. 게다가 이전에 썼듯이 ARM의 Cortex-A9의 경우 기존의 A8과 비교하여 여전히 energy-efficient할 것인지 의문입니다. (물론, 2-way까지는 Instruction Level Parallelism 가 충분하므로 어느 정도 까지는 문제가 없겠지요 ^^;)




Intel의 새로운 GPU; Larrabee


이러한 상황에서 Intel이 새로 내놓은 GPU는 기존의 3D accelerator와 차이가 많습니다. 각core당 16-lane SIMD 와 4개의 thread를 지원하고, NoC를 기반으로 하여 필요에 따라 다수의 코어를 연결할 수 있는 형태의 범용성 높은 프로세서를 만든거죠. Larabee는 일종의 NoC 기반의 array/vector processor 형태를 취하고 있는 것으로 보시면 되겠습니다. GPU가 GPGPU를 내세우니, 그동안 잘 알려진 general processor형태로 GPU를 공략했다고 할까요 ^^;


이런 형태나 시도가 없었던 건 아니죠. 약간 모양이나 형태가 다르긴 합니다만, media processor도 이런 형태의 접근이죠. dedicated engine을 사용하지 않고, 범용성 높은 vector processing unit으로 시장을 공략했었던 것이지요. 단지, 그 당시에는 여러가지 이유로 이러한 시도가 실패했는데, 뭐 다들 짐작하시듯 전용 엔진이 범용 엔진보다 전력 소모, 효율 면에서 앞서기 때문이죠(게다가, 당시 3D accelerator는 rasterizer 부분에 포커싱 되어 있어서 범용성이 매우 떨어졌습니다). 그런데, 이번에 이런 시도는 어찌보면, GPU 가 이런 저런 기능을 GPU에 넣다보니, 파이프라인과 연산의 형태가 GPGPU를 시도할 만큼 범용성을 갖춘 시점이기 때문에 가능한 한번 싸워 볼만한 시점이 된 것이기 때문이라 보입니다. GPGPU를 하느니 첨부터 vector-array processing을 해서 programmability를 높이는 접근이 좋지 않냐..라는 거겠죠.


게다가, 명령어 셋을 x86 기반으로 가져가니, 어렵게 GPGPU를 위한 언어를 따로 쓸 필요도 없지요. (병렬 프로그래밍이나 컴파일 문제는 따로 이야기하더라도..). 이 부분은 기존에 이미 multiprocessor를 위하여 작성된 대부분의 x86 기반의 프로그램이 아주 잘 동작할 것이라는 것이고, multiprocessor를 위한 것이 아니라도 recompile이 필요하진 않을 거라는 거죠. 즉, 이미 잘 구성되어 있는 x86의 컴파일러들과 multicore를 위한 지원등을 그대로 이용할 수 있다는 아주 큰 장점을 지닙니다. (GPGPU의 가장 큰 진입 장벽이 새로운 renderer 명령을 배워서 써야 한다는 점을 생각하면 이해하기 쉽습니다.)



상황에 대한 이야기는 대충 된 것 같고, 전체 구조는 아래와 같습니다. (인터넷 찾으니 그림이 많군요 ^^; 원본 그림은 watermarking 된것 처럼 TECHARP.com에서 온 것 같습니다. google image검색에서 따 온거라 ^^;)




각 코어의 scalar/vector processing datapath의 그림은 위와 같구요. 위의 두 그림을 보고 알 수 있는 것은 dedicated L1의 형태를 지닌 vector 프로세서를 NoC(interprocessor ring network) 기반으로 array 형태로 배치한 것을 알 수 있습니다. 첫 그림을 보면 shared 형태의 L2처럼 보이는데, 실은 coherent L2 cache입니다. 코어의 수가 늘어나면 다수의 NoC를 배치한다고 하네요. 그래픽(visual computing)을 타켓으로 하다보니 dedicated accelerator와 몇몇 블록들이 존재 하구요.


형태상으로는 전반적으로 thread level parallelism과 data parallelism을 극대화시키기 위한 형태라고 생각됩니다. 흠.. 근데, snooping에 의한 traffic문제는 어떻게 할지 좀 궁금하긴 해요. NoC 에서 snooping에 의한 traffic이 만만치 않을 것 같은데, 주된 application이 vector processing이라 생각하면 그다지 많지 않을 것 같기도 하구요.



자세한 정보를 얻으실 분은 이 논문 을 읽어 보시는 것이 도움이 되실 것입니다.



요즘 흘러가는 것을 보면, 예전에 한번 실패했던 재미있는 테마들이 새로운 응용 분야, 기술의 발전에 힘입어 재미있게 융합되어 부활하는 것 같아서 흥미진진합니다.