Author Archives: babyworm

SPEC과 EEMBC

4 Replies

이런 저런 벤치마크가 있습니다만, 컴퓨터 아키텍쳐를 하는 사람들에게 가장 관심이 집중되는 벤치마크는 바로 [[Standard Performance Evaluation Corporation]]의 SPEC 벤치마크이지요.

SPEC이 범용 마이크로 프로세서, 특히 서버와 데스크탑에 초점을 맞추고 있다면, [[EEMBC]]는 [[ARM]], [[MIPS]], [[ARC]], [[xtensa]], [[EISC]]와 같은 [[embedded microprocessor]] system을 위한 벤치마크 입니다.

벤치마크에 있어서 가장 중요한 것은 그 시스템/CPU가 사용될 환경을 착실하게 반영하는 것이겠습니다.

그래서, EEMBC는 요즘에 전력에 관한 부분이 점차 강화되고 있는 추세이고, SPEC은 멀티 미디어 분야가 추가되는 형태로 진화하고 있더군요.
이번에 MPR에 소개된 기사는 올해 새로나온 SPEC2006에 대하여 소개하고 있는데, SPEC2000이후에 7년만의 업데이트인 만큼 여러가지가 변했습니다. 특히 눈에 띄는 것은 cache bursting application의 데이터 셋이 엄청나게 커졌습니다. 예전의 CPU들에서 캐쉬가 대략 256K정도여서 이정도를 피할 수 있게cache bursting application이 작성되었는데, 요즘엔 뭐 4M cache도 흔하니 이러한 application에서 cache miss가 발생하지 않아서 제대로 평가할수 없게 된거죠.
눈에 띄는 다른 변화는 H.264에 대한 추가와 같이 멀티미디어 분야의 추가, 그리고 압도적인 run time의 증가를 들수 있겠습니다.

저로서야 SPEC95이후에 SPEC [[benchmark]]를 사용해본적이 없어서 특히 더 뭐라 붙일 말이 없네요.. 예전에 있던 compress나 go같은 것에 익숙한 사람이니 말입니다.  오히려 [[EEMBC]]/[[Mediabench]]/MiBench에 익숙하죠. ^^;
(Mediabench나 MiBench의 경우 초기에는 아주 의욕적이었지만… 학교에서 만든것이다 보니 업데이트가 안되는 것이 문제기는 하네요.. 그래도 MiBench의 경우 다양한 분야의 embedded 어플리케이션을 잘 조합했다는 생각입니다. 실제적으로도 EEMBC와 유사점도 많구요.)

올해내에 CPU simulator만드는 기술적인 내용을 좀 써볼 예정(요즘에 블로그가 너무 뉴스 위주로 써나가서리..)인데, 거기서 MiBench를 하나 포팅해서 돌려볼까 합니다. 그때 좀더 자세한 내용을 쓰도록 하죠..

Hooked on microprocessor

2 Replies

제가 마이크로 프로세서에 맛을 들이게 된 직접적인 계기는 초등학교 시절 집에 있던[[MSX]]였던 것 같습니다.  제가 초등학교 5학년 정도 되던해(1984년인듯 한데..)는 아마도 국내에 본격적으로 컴퓨터 교육이라는 말이 퍼지고, TV에서도 퍼스널 컴퓨터라는 말이 광고로 나오던 시기였던것 같습니다.  Apple ][ 컴퓨터는 당시 컴퓨터 학원을 평정하고 있었지요.. 저도 첫 시작은 친구들의 apple ][이었습니다.
당시 처음으로 세운상가라는 곳도 가서 프로그램도 모으고, (참 이상한 일도 많이 겪은 세운상가입니다만.. ^^;) 여러가지 만들고 했었습니다.

당시에 획기적인 게임기 컴퓨터가 나왔니.. 바로 MSX였습니다.
그리고, 대우전자에서 MSX기반의 IQ1000이라는 것을 대대적으로 선전했었는데, 그 선전 문구.. 그리고, 뒤쳐지면 안된다는 부모님들의 염원으로, 어느날 집에 MSX PC가 와 있더군요..
열약한 카세트 테잎을 이용한 drive장치.. 십자 드라이버로 이리 저리 헤드를 돌려가면서 맞추기도 하고..

MSX는 초기에 뭐가 어쩌구.. 표준화된 어쩌구 했던 선전이 기억나는데 실은 Microsoft와 일본의 ASCII에서 합작으로 만든 z-80 기반을 컴퓨터죠.
[[z-80]]은 [[zilog]]에서 나온 초기 8bit CPU로 참 잘 만든 CPU 입니다. MSX에서는 시스템에서 booting이후에 바로 MS basic interpreter로 진입하지요..
이제는 아래와 같이 FPGA(사진을 보니 altrea cyclon이군요.. ^^;)에 z-80 CPU와 graphics engine, I/O를 포함한 전체 시스템이 구현가능한 정도의 간단한 구성입니다. (Z-80은 몇번 봤으니 쉽게 만들듯 한데.. 시뮬레이터도 해봤으니.. 그래픽쪽도 뚝딱뚝딱하면 될듯하고요.. 저도 한번 만들어 볼까요.. ^^; 이게 장사가 될 줄 알았으면 만들어보는건데 그랬네요.Z80시뮬레이터 만들때 생각도 해봤었는데…)

”]당시의 MSX에서 저는 베이직과 어셈블러를 배웠고, 지금도 유용하게 생각하는 I/O에 대한 기본 개념.. 더 중요한 건 흥미를 얻었다는 것이 중요한 거 같습니다. 어셈블리 뿐입니까.. 그야말로 닉모닉 모드에서 머신 코드로 값을 때려넣어서 I/O를 제어한다고 난리 쳤던 기억도 있는데요..^^;

당시에 배웠던 절차적 언어의 개념은 대학에 들어와서 프로그래밍과 친해질 수 있는 기반이 되었고..
고등학교 3학년때 배우고, 잠시 미쳤던 C언어는 그 예전의 MSX assembly언어는 컴퓨터 아키텍쳐를 배우는데 아주 튼튼한 기반이 되어주었습니다.

물론, 제가 프로세서 아키텍트라는 직종을 선택하게 된 큰 이유중의 하나는 디지털 시스템 시간에 만든 얼기 설기 만든 CPU에 있습니다만.. 그 기반에는 예전에 제가 배우고, 흥미를 가지고, 즐거워 했던 많은 시스템들..
[[Apple]], [[MSX]], [[IBM XT]], AT, [[Mac classic]], 그리고, 책으로만 공부한 [[NeXT]]와 NeXT step (이 컴퓨터가 세상을 평정할 것이라는 믿음에 92년도에 한창 봤었는데.. 결국은 망하고.. 스티브 잡스는 apple로 복귀했죠.. 혁신적인 기술도 세상을 잘못 만나면 쫄딱 망한다는 교훈을 얻은 사건입니다.. 개인적으로.. )
이것들이 있었기 때문이라고 생각합니다.

ENTClic님의 포스팅의 광고들을 보면서 기억이 나서 끄적거려 봤습니다.

DC Ultra의 Topographical Synthesis

2 Replies

로직 합성에 많이 사용되는 Design Compiler에서는 전통적으로 통계적인 wire load model을 이용하였습니다.
즉, 합성된 로직의 크기가 어느정도라면, 이때 적용되는 wire의 R, C값이 어느정도가 될지 대략 통계값을 통하여 추정하는 방법입니다.

이러한 wire load model은 0.35um 이전의 공정까지는 어느정도 적용하는데 큰 무리가 없었습니다.
왜냐하면, 로직의 지연(delay)에 있어서 대부분이 cell이라 불리는 logic primivie에서 발생하였기 때문입니다.

그러나, 0.18um 이하의 공정으로 내려가면서 wire load model(이후 WLM)을 이용하는 방법은 한계에 부딛히게 되는데요, cell에 의한 경로 못지않게 wire delay의 비중이 커졌으며, 요즘에 와서는 cell보다 wire delay의 비중이 많이 늘어났기 때문입니다.
따라서, 기존의 WLM을 이용해서 합성한 모델은 그 정확성에 문제가 있기때문에 P&R을 하고 난 이후의 결과와 현격한 차이가 발생하여, synthesis -> P&R -> in-place optimization의 과정을 수회 거쳐야지만 정상적인 chip을 만들어낼 수 있게되는 것입니다. 이는 전반적으로 설계 효율시간에 문제를 발생시킵니다.
(보통 synthesis에서 10%이상의 over constraint를 주고 합성해야, P&R에서 비슷한 값을 얻을 수 있곤합니다. 이러한 문제가 발생하는 가장 큰 이유는 WLM의 부정확성에 있습니다.)

이를 극복하기 위하여 처음에 나왔던 방법은 Custom WLM방법입니다.
즉, 시작은 WLM으로 합성하고, P&R을 통하여 Custom WLM을 만들어낸 후 이를 이용하여 synthesis함으로써 해당 칩에 좀더 가까운 wire load model을 사용할 수 있도록 하자는 방법입니다.
이 방법은 0.35um부터는 당연히 사용되어야 하는 방법으로 정착하였습니다.

또다른 방법은 physical synthsis라는 방법인데, physical compiler라는 설계 도구에서 방법적으로 정착되었습니다. 이는 synthesis단계에서 pdef(floorplane정보)를 이용하여 가상적으로 place를 해보고 이를 이용해서 각 cell간에 좀더 정확한 경로 지연을 찾아낸다는 기법이었습니다.

”]
이렇게 발전해 나가던 것이 이제는 DC에 모두 통합되었습니다.
DC ultra에서 topographical synthesis라는 이름으로 모두 통합되었습니다.

이전의 DC ultra는 automatic hierarchycal ungroup과 같은 기능을 가지고 있는 것이었는데, 이제는 physical compiler에서 발전한 topographical synthesis기능까지 추가되어, P&R이후와 가장 근접한 형태로 합성해 낸다고 합니다.

뭐, synopsys의 발표자료는 거의 다 좋다는 것이겠구요..^^;

ESUNG에 보니 상당히 개선된 것 같습니다. (http://www.deepchip.com/items/0457-05.html)
회사에서는 라이센스 비용 관계로 아직 사용하지 못하지만.. (ㅠㅠ) 아주 기대되는 기술입니다.