일단 마이크로 프로세서라는 분야에 대해서 설명이 필요할 것으로 봅니다. 학교에서 마이크로 프로세서 구현에 대한 연구는 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인 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도 준비 중에 있습니다.

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

요즘 MPSoC쪽 버스 문제 때문에 GALS(Globally asynchronous Locally synchronous)를 다시 들여다보고 있는데, circuit design을 배제하고 verilog netlist 수준에서 기존의 합성 툴을 이용할 수 있도록 생각하다 보니 자꾸만 생각이 제한됩니다. 조막만한 아이디어가 있긴 한데, 이게 구현 가능한 것인지 생각해 보는 것 자체가 고역인걸 보니 그간 머리를 안 돌리긴 안 돌렸나봐요.
GALS중에 Pausible clock control에서 아이디어를 가지고 오되, 귀찮은 부분은 던져 버려서 latency를 줄이는 것에 주안점을 두고 있는데.. 흠 쉽지 않네요..

요즘 회사에서 superscalar microprocessor/SMT 쪽 강좌(?) 세미나(?) 뭐 이런걸 진행하고 있습니다. 컴퓨터 아키텍쳐란 과목에만 한정되는 이야기는 아닙니다만, 이런 종류의 과목이 비교적 편한 과목이지요. (동의하지 않을 분들도 많을 것이지만. ^^;)
물론, 이런 저런 복잡한 배경과 논리들이 얽혀 들어가지만, 신이 만든 것을 연구하는 생물학이나 화학, 물리학에 비하면 컴퓨터 아키텍쳐 같은 것은 예전 사람들이 만들어놓은 걸 논리적으로 풀어가서 발전시키는 형태의 학문이기 때문에 일종의 퀴즈와 같다는 느낌을 많이 받습니다. (안사람이 분자 생물학쪽을 전공하고 있는데, 이야기 듣다보면 정신이 멍~ 해지지요..) 감탄. 또 감탄! 세상엔 똑똑한 사람이 끝도 없이 있단 말이죠. 젠장..

Android의 Dalvik VM[참고자료]이 공개되었습니다. (원래 되어 있던 건가요? 소스공개는 오늘 되었다네요.. 여하튼). 특징적인건 이 VM에서 사용하는 bytecode가 java와는 동떨어진 형태네요. register 기반의 bytecode니까 말이죠. 아주 좋아요. ^^; 단, 호환성 문제는 어쩔라고 그러는지(살펴보니 .class는 .dex로 바꿔야 한다네요.).. JavaME에서의 Sun license를 피하기 위한 방법이라는데, register 기반이기 때문에 전반적인 성능은 java보다 좋을 확률이 좀 있군요.

SIMD/Vector machine에 관심이 없던 건 아닌데, 좀 의외에 상황에서 건드려야 하는 상황이 발생했습니다. 인력의 문제로 사실 할까 말까를 한 2달 동안 고민했는데, 그냥 고민하고 앉아있는 시간이면 요상한 형태의 SIMD machine은 벌써 하나 만들었겠다라는 생각이 들었어요. 이것 저것 처한 상황 때문에 빠르게 진행될 가능성은 없지만, 간단하게 하나 만들어 봐야겠습니다. 대충 틀만 잡고 누구한테 떠넘겨 버릴지도. ㅋㅋ

회사차원에서 open source진영에 대한 지원을 고려하여, EISC 프로세서 관련 사이트 하나를 개설할까 개인적으로 생각중입니다. EISC processor/system시뮬레이터는 그냥 open source로 공개할 생각이고요. 예전에 작업된 이런 저런 시뮬레이터나 환경, 벤치마크 등도 같이 open해 버릴까.. 하는 생각입니다. 감추어두고 죽느니, 열어두고 살리는 것이 좋겠지요. IDEC과 공동으로 작업하는 MPW 지원 프로그램도 거의 정식 release 직전이고.. 이런 저런 "잡일"로 바쁘네요.

ARM에서 Cortex-A9을 발표하였다고 합니다 [ZDNet 기사]. 일단 저에게 있어서는 한숨 쉬어지는 일이고(ARM의 행보가 점차 빨라지니, 저희같은 업체가 따라잡을 수 있는 여지가 줄어들고 있는 것이 사실이니 말입니다.), 업계에 있어서는 환영할 만한 일이겠습니다. Cortex-A9의 경우 4개 까지 MP로 구성이 가능하다고 하니(MP 구성을 따지는 것으로 보아, cache snooping이 고려된 SMP겠지요..), 대단한 성능을 기대할 수 있겠습니다.

여기서 재미있는 것이 Intel의 대응인데요. 기존에 ARM 기반의 프로세서를 만들다가 해당 부분을 과감히 정리하였지요. 근데, EETimes에 의하면 Intel이 ARC의 프로세서를 라이센스했다고 합니다[EETimes 기사]. ARM 기반을 정리할 때는 x86기반의 embedded processor쪽으로 무게를 둔다고 생각했는데, 범용쪽은 x86기반, 저전력이 요구되는 application specific한 부분은 configurable processor인 ARC쪽에 무게를 두는 느낌입니다. 그래도, x86기반에서도 충분히 configurable하게 만드는데 어려움이 없을 것인데.. 저전력을 위해서 이런 결정을 내린 것이 아닌가 하는 생각입니다.

이러한 행보에 맞추어 저희 회사에서는 Heterogeneous MPSoC쪽에 무게를 두고, 여기에 적합한 lightweight/low power processor와 interconnection에 무게를 두고 있습니다[네이버]. 몇 가지 재미있는 아키텍처적인 시도를 구상하고 있는데, 보도 자료에는 좀 이상하게 나간 느낌이 있습니다. 물론, 마케팅적인 측면을 위해서 빠른 프로세서를 만들어야 겠다는 생각은 변함이 없습니다만.. 실제로 MPSoC에서 중요한 것은 적절한 성능의 작은 footprint를 지닌  low power 프로세서들이니까요. (적절한 성능이란 것이 task에 따라 바뀌는 것이므로, 아주 강력한 프로세서를 개발해야 할 필요성도 있는 것이지요)

뭔가 흥미 진진해질 것 같아요.

ISSCC'07에서 Intel에서 80개의  core를 집적한 Tera-FLOPS급 프로세서를 발표했었지요. 이번 HOT Chips 19에서는 Tilera라는 회사에서 TILE64 프로세서를 발표한 것이 화제가 되었습니다. 약간 비스므리한 과제를 기획하고 있어서 관심있게 몇 가지 프로젝트를 지켜보고 있었는데, TILE64는 사실 제가 알고 있던 프로세서는 아니었지요.

이는 NoC(Network-on-a-Chip)에 기반을 두고, 다수의 프로세서를 묶은 형태로 볼 수도 있겠는데요 (이런 프로세서가 처음은 아니지요. 기존의 intel의 network processor들이 이런 형태를 가져간 적이 있습니다). 사용하려는 application의 task parallelism이 상당한 경우에 유용한 형태라 볼 수 있습니다.

[TILE64의 구조; 일본 MYCOM에서 Tilera의 것을 인용한 것을 재인용합니다.]

이렇게 다수의 프로세서를 집적하는 경우, processor 개개의 속도보다는 area와 전력 소모가 중요한 요소가 됩니다. 프로세서의 속도를 올리는 것 보다 프로세서의 수를 증가시켜 성능 향상을 도모하는 것이니까요.

사실, 성능 향상에는 clock frequency를 증가시키는 것이 더 유용할 수 있습니다.(예전에 speed-demon approach를 말씀드린 것 처럼) 어짜피 전력 소모는 동작 주파수에 비례하니, 전력소모가 급증하지도 않을 테구요. 클럭 주파수를 2배 올려서 얻는 전력의 불이익보다, 코어 2개를 써서 얻는 전력의 불이익이 클 수도 있겠지요? 클럭 주파수를 2배로 올리면 performance가 2배가 되는데, 코어 2개를 쓰더라도 parallelism이 없으면 소용 없으니 말입니다.

그럼에도 왜 클럭 주파수를 높이지 않고 multicore를 사용할까요?

우선, 클럭 주파수를 높이는 것이 그렇게 녹녹하지 않다는 것이지요. 클럭 주파수를 높이기 위하여 합성을 심각하게 하면 area는 exponetial로 증가하며, 클럭 주파수를 높이기 위해서 미세 공정을 적용하면서 leakage current가 심각한 문제로 나타나고, 클럭 주파수를 높이기 위해서 dynamic gate를 쓰다보니 clock frequency 조절에 문제가 생기고, 클럭 주파수를 높이기 위해서 pipeline을 깊게 만들다보니 명령어 처리 효율(insturction per cycle:IPC)이 떨어지고, 이를 회복하려다보니 복잡한 dynamic branch prediction을 적용시켜야 하고.. 등등등..

클럭 주파수를 높이기 위해서 얻는 이득보다, 잃는 것이 많아지고 있는 것이지요. 즉, (parallelis이 어느 정도 존재한다면) 느린 코어를 여러개 쓰는 것이 유리한 시점까지 와버린 거라고 볼 수 있습니다. 문제는.. task 수준의 parallelism을 얻을 수 있는 application이 (현재로서는) 통신과 미디어 처리 부분이라는 것입니다. 이 문제의 극복은 쉽지 않아보이긴 합니다 ^^;

프로세서 하는 사람으로 할 소리는 아닌듯 하지만, 사용자 입장에선 dual core 2개를 MCP하던, true quad core나 밥 적게 먹고, 일 잘하는 프로세서가 좋은 프로세서입니다.

예전에 포스팅에서 적은 적도 있지만, Intel의 전략은 일견 영악한 구석이 없잖아 있는 것이 사실이지만 사용자의 입장에서 그런 걸 따질 필요도 없으니, AMD가 굳이 "우린 true quad"라고 이야기할 필요도 없습니다.

단지, true quad의 장점을 보이면 되는 것이겠지요. 여기서는 잠깐 Quad core가 2x2보다 좋을 것 같은 부분을 짚어 보면,

• processor 간의 bandwidth가 아무래도 PAD의 제약을 받고 있는 2x2전략보다는 높을 것이고,
• PAD간에 소모되는 전력도 무시할 수 없을테니, 전력 소모도 적겠습니다. (그리, 크지는 않겠습니다만..)

장점만 있는건 아니니, 단점은

• area가 그만큼 커진다는 말이니 아무래도 수율에 문제가 존재하겠고, 이는 단가 싸움에서 불리하게 작용할 가능성이 있습니다. 물론 2x2전략도 pad의 크기를 고려하면 마냥 행복한 전략은 아닙니다만..

같은 코어를 집적한다면 2x2보다 quad가 좋을 것이라고(가격은 둘째 치고) 말씀드릴 수 있겠습니다만, 현재로서는 뭐라 말할 수 없는 것이 intel과 AMD의 microarchitecture가 다르니 좀 애매한 부분이 있습니다.

물론, 발표된 barcelona자료에서는 몇 가지 장점(특히 대역폭에서)이 보이지만, 이것이 실제 performance로 연결될지는 좀 의문입니다. core당 1MB내지는 2MB의 L2 cache를 내장하고 나면, L2 이후의 traffic은 많이 줄어들지 않을까 생각도 됩니다.

결론은 시장 출시후에 나오겠지요

착찹한 마음에 적은 글에 많은 분들이 격려해 주셔서 진심으로 감사드립니다.  착찹한 마음을 걷어내고 다시 나아기기 시작했습니다. 몇 번 적었듯이 쉽지 않은 길을 가는 것을 지지해 주고, 지원해 주는 회사에도 감사드리고 있습니다. 저희 프로세서에 부족했던 부분을 채울 수 있었던 좋은 기회였으므로, 너무나도 아쉽지만 EISC는 쉬운 길을 갈 운명은 아닌가 봅니다 ^^;

----
프로세서 설계에 있어서 두 가지 중요한 갈래가 있습니다.
바로 속도를 높이는 것이 최고라고 생각하는 접근 방법(소위 speed demon approach -  이후 SDA)와 클럭당 수행되는 명령어의 수를 높이는 방법(소위 brainiac approach  - 이후 BA -라 이야기하는)이 존재하는 것이지요.
두 가지 모두 아주 의미있는 접근이라고 할 수 있습니다. 예를 들어 SDA는 파이프라인 프로세서에서 명령어 수준의 병렬성(Instrcution level parallelism -ILP)를 하드웨어가 동적으로 찾아내는데는 어짜피 한계가 있으므로, 전반적인 클럭 스피드를 높이는 것이 좋다라는 생각입니다.
이 SDA를 기조에 두고 있는 아키텍쳐로 유명한 것이 Alpha였는데, 얼마전까지의 Intel의 Netburst microarchitecture 역시 SDA를 기반에 둔 것입니다. 최대한 파이프를 잘게 쪼개서 높은 클럭 주파수를 얻어냄으로써, 좋은 성능을 얻자는 것입니다.
두 번째 갈래인 BA의 경우 파이프라인을 잘게 나누어 속도를 높이는 것도 중요하지만 ILP를 최대한 찾아내서 IPC(instructions per cycle)를 높이는 것도 중요하다라는 관점입니다. 전통적인 컴퓨터 아키텍트들이 선호하는 관점이기도 하지요. 제가 AMD를 더 선호하는 이유도 IPC의 관점에서 좋은 프로세서를 만든다는 점 때문입니다. (물론, 인텔도 아주 아주 뛰어납니다. 코어2듀오를 보십시오!)
마케팅의 관점에서는 누구나 쉽게 이해할 수 있는 clock frequency를 따지기 때문에 SDA를 선호하기도 합니다. 이러한 관점은 IPC가 더 좋은 프로세서들에게는 좋지 않은 마켓 상황이므로 AMD가 처음에 (performance rate던가요? 기억이) 클럭 속도보다 높은 값(P4에 비교하면 어느정도 클럭에 해당한다는 의미의)을 사용하기도 했습니다.
이런 생각은 처음에 전혀 먹혀들어가지 않았지만, 인텔에서 코어 듀오 시리즈를 사용하면서 이제 폭넓게 먹혀 들어가고 있지요.

사실 SDA기반으로 프로세서를 만든다는 것은 마케팅의 입장에서 대부분 매우 유리합니다. BA는 benchmark 결과를 보여주어야 하니까요. 그런데, benchmark를 따져 보는 사람이 생각보다 없습니다. ^^; 아쉽게도
요즘들어서는 energy efficiency가 중요해지면서 BA가 더 각광받는 분위기이기는 합니다. :)
embedded도 마찬가지지요.

여담입니다만, 항상 BA라는 측면을 두고 설계해 왔는데요, 우선 뭐가 되었던 SDA가 필요할 때도 있습니다. :)

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 선생님.. 기쁘시겠어요.. ^^;

들어가기전에: 이 포스팅은 MPR 12월 11일자 내용을 읽고나서 감상 비슷하게 적은 것입니다. 

1971년 11월 15일에 최초의 상용 마이크로 프로세서인 intel 4004가 발표되었으니, 올해로 마이크로 프로세서가 발표된지 35주년입니다. 마이크로프로세서 아키텍트를 하고 있는 사람에게는 어느정도 의미가 있는 해라 할 수 있겠지요. (4004를 최초의 마이크로 프로세서로 보는 것은 최초의 상용화된 one-chip standard part microprocessor라는 의미로 해석할 수 있습니다. )

2250 transistor(equ gate로 약 500게이트쯤..), 740KHz 동작 속도, 10um PMOS 공정에서 제작된 4004에 비하여 지금의 마이크로 프로세서는 충실히 인텔 설립자인 무어의 법칙을 따라 성장해왔으니 격세 지감입니다. (사실, 무어의 법칙이란게 자연 법칙이 아닌 CEO가 세운 사업 목표 같은거라.. 그 밑에 있는 엔지니어들의 노력을 바탕에 두고 있는 것이지요. 요즘 NAND flash에서 적용되는 황의 법칙도 마찬가지입니다. 삼성 엔지니어들의 고생은 너무도 많이 듣고 있습니다. )
게다가, 4004 마이크로 프로세서는 요즘 PC/Server를 지배하고 있는 x86 아키텍쳐의 직접적인 선조가 되는 것이니, 참 기나긴 생명력을 지속해 오고 있다 말할 수 있겠습니다.

4004 마이크로 프로세서의 설계를 통해서 메모리 반도체를 만들던 인텔은 일약 비메모리 반도체의 최전선에 서는 프로세서를 만드는 회사로서 성공적인 변신을 하게 되었구요.

4비트 ALU와 데이터 패스, 12비트 주소, 8비트/16비트 명령어 46개로 이루어진 4004는 요즘 학부 마이크로 프로세서 시간에 과제로 내 주기에도 너무 쉽다고 생각할 정도입니다. 집적회로 시간에 모든 회로를 그리도록 하는 과제라면 약간 재미있겠습니다만...

아직 진행형인 마이크로 프로세서의 진화에서 i4004를 회고해보는 것도 의미있는 일이군요. 여기에서 여러가지 재미있는 내용을 더 보실 수 있습니다.