Tag Archives: 마이크로 프로세서

Asynchronous는 어려워

4 Replies

요즘 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 프로세서.

Leave a reply

[wp]ARM[/wp]에서 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에 따라 바뀌는 것이므로, 아주 강력한 프로세서를 개발해야 할 필요성도 있는 것이지요)


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

Tilera Processor.. 병렬성을 통한 성능 향상

2 Replies

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이 (현재로서는) 통신과 미디어 처리 부분이라는 것입니다. 이 문제의 극복은 쉽지 않아보이긴 합니다 ^^;