ARM이야기(4): 최신 ARM 프로세서의 동향 및 구조

오늘 ARM Connected Community Technical Symposium 2010에 다녀왔습니다.
오랜만에 연구실 후배들을 만날 수 있어서 반가웠고 babyworm님도 만나서 잠시 담소를 나누었습니다. ^^

9월초에 발표했던 Cortex-A15의 소개가 주 내용일 것이란 예상을 깨고 Cortex-A15에 대한 내용은 거의 다뤄지지 않았네요. 개인적으로 궁금했었는데 좀 아쉽습니다.

올해는 작년보다 훨씬 더 많은 분들이 참석해서 의자도 부족하고 늦게 도착하신 분들은 자료집도 못받을 정도였습니다. 그만큼 ARM에 대한 관심이 커진 것이겠죠. 스마트폰, 태블릿의 역할이 컷을 것입니다.

2010년이 ARM이 설립된지 20년이라며 그동안의 발전사에 대한 언급이 많은 편이었습니다. 제가 ARM이야기 1~2편에 썼던 내용이라 반갑더군요. 사실 지난 20년간의 발전보다 지난 2년간의 주가가 더 놀랍습니다만… ㅎㅎ

작년 행사에서는 Cortex-A9의 소개와 함께 Android와 Chrome OS를 통해 ARM이 Mainstream으로 부상하려는 모습이었는데, 올해는 이미 Android를 통해 스마트폰 시장에 자리를 잡은 모습이었고 태블릿 시장의 성장을 기대하는 모습이었습니다.

ARM은 안드로이드를 바탕으로 이미 상당한 ecosystem을 구축했습니다. 안드로이드를 사용하면 ARM프로세서를 이용하는 것이 당연한 상황을 만들어가는 것입니다. 안드로이드가 잘되건 애플이 iOS가 잘되건 ARM이 돈을 버는 상황이니 주가가 오르는 것도 당연한 일입니다.

예상대로 작년 ARM에서 인텔보다 선점하겠다고 하던 Smartbook이라는 장치는 모습을 감추었고 태블릿이 그 자리를 대신하고 있습니다. 반면, 구클 크롬OS 얘기는 쏙 들어갔네요.

한가지 궁금한 건 애플의 iPhone, iPad등이 ARM프로세서를 사용하는데 행사전반에 걸쳐 애플에 대한 언급이 없는게 참 이상하네요. 혹시 이것은 삼성을 의식한 국내 발표용일까요? ^^; (유독 갤럭시S와 갤럭시탭의 사진이 자주 노출되긴 했습니다) 참, 전시부쓰에서 사람들의 관심을 가장 많이 끈 것은 갤럭시탭이더군요. 인기가 많아 전 결국 만져보지도 못하고, ‘갤럭시 탭 앞에서 만나자’며 사람들 만나는 용도로 사용했습니다만…

저는 SoC Design트랙을 들었는데 Cortex시리즈의 성능, Mali GPU, Virtualization 등의 주제였습니다.

관심있게 본 내용중 하나는 동작속도와 소비전력을 최적화에 대한 실례를 엿볼 수 있었던 내용입니다. 850MHz급의 기본 설계를 2GHz급으로 동작속도를 높이기 위한 기술, 4W의 소비전력을 5mW로 낮추는 (수치가 너무 드라마틱하군요 ^^;) 기술에 대해 단계별로 알 수 있었습니다.

ARM11 및 Cortex-A 파이프라인 아키텍쳐
오늘 발표에 다뤄지진 않았지만, Cortex-A15 얘기가 나온 김에 Cortex-A의 제품별 파이프라인 방식을 그림으로 비교해보도록하겠습니다.

Cortex-A5 Pipeline Architecture

 

Cortex-A8 Pipeline Architecture

Cortex-A9 Pipeline Architecture

Cortex-A15 Pipeline Architecture

Cortex-A9에서 비순차실행(Out-of-Order Execution)을 도입하면서 Cortex-A8보다 오히려 파이프라인이 약간 줄어들었었는데, Cortex-A15에서 다시 확 늘어버렸네요. 2GHz 이상 동작하는 것을 위해 아키텍쳐에 손을 많이 댄것 같은데, 과연 효과적인 아키텍쳐인지 아직은 잘 모르겠습니다.

최근 ARM아키텍쳐에 대한 상세한 비교는 아래 논문들에 잘 나와있으니 참고하세요.

최근 몇년간 ARM프로세서의 발전은 눈부시지만, ARMv7아키텍쳐가 도입된 이후로 과거의 심플한 방식이 점점 사라지는 것은 좀 아쉽습니다.

ARM이야기(3): 최초의 ARM프로세서의 구조와 특징

어떻게 ARM프로세서가 만들어졌는가
지난 글에서 ARM프로세서가 만들어지고 발전한 과정
을 간단히 살펴봤지만, 설계자의 입장에서 궁금한 것은 어떤 의도와 어떤 철학으로 ARM 아키텍쳐가 설계됐는가이다. 최근의 ARM프로세서들은 초기의 ARM보다 훨씬 복잡하지만, 기본적인 골격은 유지하고 있다. 그 이유는 초기의 명령어구조(ISA: Instruction Set Architecture)를 유지하고 있기 때문이다.

ARM프로세서는 Steve Furber와 Roger Wilson에 의해 만들어졌다고 알려져있다.

ARM을 개발한 Steve Furber(우)와 Roger Wilson(좌)

Steve Furber는 HW 설계자였고 ARM프로세서의 개발책임자였다. 사실 Steve Furber는 항공역학을 전공했고 마이크로프로세서 설계경험은 전무했다. 단지 대학시절 활동했던 컴퓨터 동아리에서 얻은 약간의 지식만 있었을 뿐이었다. (ARM과 관련된 스포트라이트를 Steve Furber가 독차지하는 것은 개인적으로 좀 불만이다 ^^;)

ARM의 특징을 결정짓는 명령어체계는 Roger Wilson이 만들었다. BBC Micro에 사용된 BBC BASIC을 만들었다. BBC BASIC은 독특하게도 inline assembly를 지원했었다. 상위수준의 언어인 BASIC과 기계어와 같은 수준인 어셈블리를 조합하려는 철학은 ARM명령어에 그대로 반영되었다. 즐겨사용하던 6502프로세서의 명령어의 특징을 살리고 상위수준의 언어의 기능인 조건부 실행하고 한개의 명령으로 복잡한 산술 논리 연산을 수행할 수 있는 명령어체계를 만든 것이다(ARM 명령어는 Data General Nova 미니컴퓨터의 영향을 받았을 것이란 추정도 있다). 그는 BASIC으로 명령어 시뮬레이터(Instruction Set Simulator)를 만들기도 했다.

그리고 실제 VLSI설계를 했던 것은 Robert Heaton이다. 상당히 중요한 역할을 했음에도 거의 알려져있지 않은 인물(심지어 위키피디아에 검색이 되지않는다)로 당시 VLSI design책임자로 datapath와 dataflow를 설계했고 ALU, register file, PLA등 대부분을 직접 설계했고, 3개의 보조칩(memory controller, interrupt controller, video controller)도 만들었다.

버클리 RISC의 영향
ARM을 개발하기 전까진 트랜지스터 2000개 정도의 게이트어레이(gate-array)칩을 만들어본 Acorn이 감히 마이크로프로세서를 만들 수 있게한 결정적인 역할은 최초의 RISC(Reduced Instruction Set Computer)인 Berkeley RISC가 했다.

Berkeley RISC 1 논문 (1981)

Berkeley RISC 1 칩사진 (1981)

1981년 UC버클리 David Patterson의 지도로 몇명의 대학원생들이 모여 1년만에 상용제품에 견줄만한 성능을 갖는 마이크로프로세서를 개발했다. M68000같은 기존 제품들에 비해 훨씬 간단한 구조를 갖고 있었기 때문에, Acorn컴퓨터에서도 만들 수 있겠다는 생각을 하게 되었다.

다음으로 6502프로세서를 개발한 Western Design Center(미국 아리조나 피닉스)를 방문해보고 생각보다 훨씬 열악한 개발환경을 보곤 자신감을 얻었다고 한다.

당시 IBM에서는 수개월동안 대형 컴퓨터를 이용해 명령어 세트를 시뮬레이션했던 반면, Roger Wilson은 그들의 8비트 컴퓨터인 BBC Micro에서 BBC Basic을 이용해 명령어 시뮬레이터와 Event-driven 시뮬레이터를 개발했다. Physical Design Tool은 VLSI Technology의 Custon Design Tool을 제공받아 사용했다.

ARM1 아키텍쳐

첫번째 ARM의 명령어에 대한 자세한 내용은 남아있지 않지만, 현재 남아있는 자료를 토대로 ARM1의 명령어세트를 재현해보면 다음과 같다.

우선 버클리 RISC의 특징 중 32비트의 고정길이 명령어와 각 명령어가 3개의 주소값을 갖는 것을 채용하였다. 모든 명령어에 Condition Code(cond)가 존재하는 것이 가장 독특한 특징인데 이를 이용하여 조건부 실행(Conditional Execution)을 한개의 명령어로 구현가능했다.

ARM1 명령어 (1985)

어셈블리 코드의 가독성을 높인것과 모든 산술논리 연산에 쉬프트 동작을 연동할 수 있는 것도 독창적이다. 조건부 실행과 쉬프트 동작을 명령어 하나에 표현할 수 있도록 한 결과 아래와 같은 코드를 한싸이클에 수행할 수 있게 되었다.

RISC라고 보기엔 무척 복잡한 명령일 수도 있지만, 한싸이클에 수행되고 직관적인 어셈블리 코딩이 가능하다.

버클리RISC의 레지스터 윈도우는 많은 레지스터를 필요로 하기 때문에 비용문제로 채용되지 않았다. 모드별로 2개의 전용 레지스터를 할당하는 형태인 ‘레지스터 뱅크’ 방식을 새로 고안하여 사용하였다. FIQ(Fast Interrupt Request)의 경우 3개의 레지스터를 더 할당하여 인터럽트 반응속도를 높이려고한 노력이 엿보인다.

ARM1레지스터 구성 (1985)

15번 레지스터는 PC(Program Counter)로 사용하는데, 26비트만 명령어주소로 사용하고 8비트는 상태레지스터로 사용하였다. 서브루틴 실행전 명령어 주소를 기억하는(Link Register)에 PC를 복사하면 자연히 상태레지스터도 저장되도록 하여 최소한의 동작으로 기능을 구현하려고한 것이다(ARM6 이후엔 32-bit 주소를 지원하기 위해 별도의 상태레지스터를 사용하도록 변경).

이러한 레지스터뱅크 구조는 이후에도 계속 유지되는데, ARM2에서는 FIQ모드에 레지스터 2개가 추가되고, ARM6부터는 기존 4개의 모드에서 6개로 확장되었다.

전체 아키텍쳐를 그려보면 다음과 같다. 지금도 많이 사용되고 있는 ARM7과 상당히 비슷하지만, 곱셈기(Multiplier)가 빠져있다(곱셈기는 ARM2 부터 지원되기 시작).

ARM1 아키텍쳐 (1985)

ARM1은 3단계 파이프라인 방식을 사용하는데, 3단계 파이프라인의 장점은 Data Forwarding을 고려하지 않아도 되기 떄문에 구현이 간단하다는 것이다 (이 구조는 ARM7까지 유지된다).

ARM1 파이프라인의 또다른 특징은 다중싸이클 명령어 수행을 한다는 것이다. 즉, 명령어 하나를 처리하는데 20개 가량의 클록 싸이클이 필요하다는 것인데, 이것은 전통적인 RISC프로세서가 파이프라인 구조를 사용해 명령어당 한싸이클에 수행하는 형태를 추구한 것과 반대되는 것이다.

ARM1의 파이프라인 구조 (1985)

이러한 다중 싸이클 방식은 장단점이 존재한다. 장점은 코드의 집적도가 높아진 다는 것이다. 즉, 여러가지 명령을 한개의 명령으로 수행할 수 있다. 예를 들어 16개의 레지스터를 메모리에 저장하는 것을 한개의 명령어로 나타낼 수 있다. 16개의 명령어를 사용하는 것과 수행시간은 동일하지만 명령어 메모리의 공간을 훨씬 적게 사용할 수가 있다는 장점이 있다.

반면 한번 시작한 명령어가 끝날 때까지 기다리는 시간이 길어지기 때문에 인터럽트 반응시간(interrupt latency)가 늘어난다는 단점도 있다. ARM프로세서는 데이터 처리 명령어는 대부분 한싸이클에 수행이 가능하며, 일부 명령어들만 여러싸이클이 필요하고, 레지스터뱅크 구조를 이용해 인터럽트 반응속도를 개선하였다.

이전 글에서도 언급하였지만, ARM을 개발하는데 중요한 모티브가 된 것중에 하나가 인터럽트 반응시간이다. 당시 새로운 프로세서를 찾던 Acorn컴퓨터가 16비트 프로세서들의 낮은 성능에 실망하고 워크스테이션에 사용되던 32비트 프로세서인 NS32016(National Semiconductor)을 검토하였으나 결국 사용하지 않은 이유도 인터럽트 반응속도였다.

National Semiconductor NS32016

NS32016은 6MHz에서 동작하는 CISC프로세서였다. NS32016의 명령어 중 메모리간에 나눗셈 연산은 360클록싸이클이 필요했고 그 시간 동안은 인터럽트에 반응하는 것이 불가능했다. Acorn에서 인터럽트 반응속도에 민감했던 이유는 이것이 가격에 큰 영향을 주었기 때문이었다. 예를 들어 인터럽트 반응속도를 32uS로 만들 수 있으면 2D Floppy Disk를 별도의 컨트롤 칩없이 제어할 수 있었다.

ARM 아키텍쳐의 특징
ARM 아키텍쳐는 명령어 집적도와 실행속도를 높이면서도 인터럽트 반응속도를 짧게 하는 CISC와 RISC의 장점을 모두 취하려고 노력했다.

조건부 실행과 산술논리연산의 조합으로 어셈블리언어를 직관적으로 사용할 수 있도록 하였다. 오랜기간동안 6502 어셈블리와 베이직을 사용한 경험과 통찰력이 명령어 구조에 반영된 것이다.

또한, 8비트 6502프로세서로도 80286 IBM PC보다 빠른 컴퓨터를 만들던 최적화된 하드웨어 설계기술도 반영되었다. 빠른 인터럽트 반응 속도는 리얼타임 환경에 적합하여 임베디드 시스템에 활용되었다.

적은 인력으로 짧은 시간에 개발하기위해 최대한 단순화한 구조는 적은 비용과 낮은 소비전력을 가져와 모바일환경에 최적화 된 프로세서로 발전하게 되었다.

ARM1 프로세서 (1985)

ARM이야기(2): ARM 프로세서의 탄생

최초의 상용 RISC프로세서
1999~2001년에 ARM7, ARM9호환 프로세서를 설계하면서 느꼈던 의구심은 “과연 ARM이 아키텍쳐관점에서 좋은가?” 였다. Instruction Set도 뭔가 허술하고, RISC라고 하기엔 다중싸이클(multi-cycle) 동작도 많고, 뭔가 부족한 느낌을 지울 수 없었기 때문이다.

이 후 ARM은 엄청난 성장을 이루어냈지만, 개인적으론 어떻게 ARM의 아키텍쳐가 만들어졌는지가 더 궁금하다.

관련자료를 찾던 중 몇가지 새로운 사실을 알게 되었다.
먼저 ARM이 최초의 상용 RISC 마이크로프로세서라는 것이다. 그동안 RISC프로세서의 효시는 Berkeley RISC-I(1981)이고 최초의 상용 RISC는 MIPS R2000(1985)로 알고 있었던 사실을 뒤집는 것이었다. 이 부분은 이견이 있을 수 있는데 RISC는 관점에 따라 1970년대에도 존재했기 때문이다.

어째됐건 최초의 ARM이 80년대 초반에 만들어졌다는 것은 상당히 놀라운 일이다. 8비트 컴퓨터가 대부분이고 16비트 마이크로프로세서인 인텔 80286이 막 개발된 1983년에 32비트 마이크로프로세서를 만들려고 했다는 시도 자체가 매우 놀랍다.

어떻게 ARM프로세서가 만들어졌는가?
ARM 프로세서는 Acorn Computers에서 개발하였다. Acorn Computers는 1979년에 영국에서 만들어진 회사로 애플컴퓨터에 사용했던 6502프로세서를 이용한 BBC Micro란 컴퓨터를 1982년 개발하여 큰 성공을 거두었다.

Acorn BBC Micro (1982)

1983년 BBC Micro로 성공 거둔 Acorn Computers는 보다 높은 성능의 컴퓨터를 개발하기 위해 ARM(Acorn RISC Machine, ARM의 현재 이름인 Advanced RISC Machine과 다르다)프로세서를 개발하기 시작한다.

애플 매킨토시에 사용되었던 Motorola 68000이 이미 1979년에 만들어졌고, IBM PC에 사용된 Intel 80286도 1982년에 출시되어 사용할 수 있었는데도 불구하고 새로이 프로세서를 만들 생각을 한 배경이 궁금하지않을 수 없다.

Acorn으 BBC Micro는 애플1, 애플2와 같이 MOS Technology의 8비트 6502프로세서를 사용하고 있었으므로 이들의 기준은 6502였다. 이들은 80286을 사용한 IBM-PC가 8비트 컴퓨터인 BBC Micro보다 오히려 더 느리다는 사실을 발견했다. 특히 80286의 인터럽트가 6502의 인터럽트에 비해 엄청 느리다는 것을 알게 되었는데 그것은 사실 6502의 interrupt latency는 8비트 프로세서중에서도 가장 빠르기 때문에 그렇게 느끼는 것도 당연했다.

인터럽트의 개념 (출처: 6502.org)

당시의 16비트 프로세서의 성능에 크게 실망한 Acorn은 획기적인 시도로 32비트 프로세서를 개발하기로 결정하였다.

지금과 같이 클록주파수나 MIPS(Million Instruction per Second)와 같은 프로세서의 성능을 나타내는 기준이 없던 시절에 이들이 세운 목표는 “BASIC으로 작성한 프로그램이 6502에서 기계어로 작성한 프로그램의 속도로 동작하는 것”이었다.

하지만 가장 큰 문제는 Acorn은 마이크로프로세서를 개발할 능력을 갖고 있지 않았다. 프로세서를 개발한 경험도 없었을 뿐만아니라 당시 마이크로프로세서를 만들던 회사들 처럼 수백명의 개발인력을 프로세서 개발에 투입할 수 있었던 것도 아니었다. ARM을 개발했던 Steve Furber와 Sophie Wilson이 주목한 것은 대학원생 몇명이 1년만에 개발한 Berkeley RISC-I이었다.

Acorn의 사장이었던 Hermann Hauser는 ARM 프로세서의 성공비결은 당시 돈도 없었고 개발인력도 없었기 때문에 단순한 구조로 개발 할 수 밖에 없었기 때문이라고 회고한다.

ARM설계에 대한 내용은 추후 연재글에서 다시 한번 자세히 다뤄보도록 하겠다.
7명이 1년반동은 첫번째 ARM프로세서를 설계하였고, 당시 ARM의 기술에 관심을 가졌던 VLSI Technology에서도 칩셋개발을 지원하였다. 첫번째 ARM프로세서 역시 VLSI Technology에서 제작되었다.

첫번째 ARM프로세서(1985)

1985년 첫번째 ARM프로세서 개발이 성공하고, 1987년에는 ARM2를 이용한 Acorn Archimedes도 출시한다. 애플의 매킨토시(1984) 보다 시기적으로 늦긴 했으나 GUI환경을 갖추고 있는 것이 인상적이다.

Acorn Archimedes (1987)

Acorn의 Desktop PC는 Unix와 유사한 강력한 OS인 ARX를 개발하는데 너무 많은 시간을 소비하여 뒤늦게 출시되어 80년대 말 IBM PC, 매킨토시와 경쟁에서 뒤쳐져 자취를 감추었다.

그동안 Acorn을 창립한 Hermann Hauser는 1988년에 Active Book이라는 PDA개발 사업을 시작했다. 그리고 ARM2 Processor를 개선하여 저전력 프로세서인 ARM2aS를 개발하였다. 빠른 처리속도에 저전력 기능까지 추가된 ARM프로세서는 당시 PDA개발을 하던 애플 컴퓨터의 관심을 사게 되었고 애플의 뉴튼 메시지패드에 사용되게 되었다.

애플 뉴튼 메시지패드(1994)

애플 뉴튼은 본래 AT&T의 Hobbit 프로세서를 사용할 계획이었으나 속도, 저전력, 저가이고 커스텀 설계가 가능한 ARM을 채택한 것은 어쩌면 당연한 일이었다. 애플의 뉴튼은 실패로 끝났으나 결국 아이폰으로 재탄생하였고 여전히 ARM프로세서를 사용하고 있다.

ARM의 독립 그리고 발전
애플이 뉴튼을 개발하는 동안 상당히 많은 영향을 만들었는데, 첫번째는 ARM프로세서를 Acorn 컴퓨터로부터 독립시킨 것이다. 앞서 설명한 것처럼 당시 Acorn 컴퓨터는 애플의 경쟁사였기 때문이었고, ARM의 약자도 Acorn RISC Machine에서 Advanced RISC Machine으로 바뀌게 된다. 1990년에 ARM이 창립되게 되고 애플과 VLSI Technology의 지원을 받게 된다.

ARM610 (1993)

애플의 지원을 받기 시작하며, 애플 뉴튼에 사용하기 위한 프로세서를 본격적으로 개발하기 시작한 ARM은 ARM3 프로세서의 성능을 개선한 ARM6를 만들고 캐쉬메모리와 메모리관리기능(MMU)을 추가한 ARM610을 개발하여 뉴튼에 탑재하게 된다.

애플 뉴튼에 사용된 ARM프로세서에 관심을 갖게된 DEC(Digital Equipment Corportation)에서는 1995년 ARM 명령어를 license하여 StrongARM을 개발하기 시작한다. 1995년에 개발된 StrongARM SA-110은 최대 200MHz까지 동작했다. DEC의 경영위기로 인해 StrongARM은 1997년 인텔에 매각되었으며 인텔은 StrongARM을 바탕으로 StrongARM-2와 XScale을 개발한다. 하지만 인텔은 XScale을 제대로 활용하지 못하고 결국 2006년 Marvell에 다시 매각한다.

DEC에서 개발한 StrongARM(1995)

한편 뉴튼에 사용된 ARM6는 훗날 백억개이상 판매한 ARM7TDMI로 발전하고 애플 iPod에 사용되기 시작했으며, ARM9, ARM11, Cortex아키텍쳐로 발전하여 아이폰, 아이패드까지 ARM 프로세서를 사용하기에 이른다. 그리고 머지않아 ARM프로세서를 사용한 맥킨토시를 볼 수 있을 것이라 예상해본다.

ARM Cortex-A8을 사용한 A4프로세서(2010)

ARM이야기(1): ARM과 인텔 x86 아키텍쳐

지난 15년간 ARM에 대해 가졌던 여러가지 생각들, 기술적인 내용, 개인적인 추억 등을 ARM 호환 프로세서를 설계했던 설계자 입장에서 써보려고 합니다. 2010.11. 0donny

ARM과의 첫 만남

ARM(Advanced RISC Machine)에 대해 처음 알게 된 것은 1996년이었다. 당시 GEC-Plessey의 GPS Chipset과 호환 되는 칩셋 개발에 참여했었는데 ARM60이라는 생소한 프로세서를 사용하는 것을 알게 되었다. 아주 작은 칩이었는데 인텔 80386 보다 빠르다는 것이었다.

임베디드(embedded)라는 개념조차 없던 시절. 당시에 추측하기론 80386의 인터럽트 반응이 느리기 때문에 반응이 빠른 ARM60의 성능이 높은 것뿐이지 복잡한 연산은 당연히 386이나 486이 빠를 것이라고 생각했었다. 불과 조금 전까지…

혹시나 해서 자료를 찾아보니 ARM60의 성능이 80386 보다 높고, ARM60에 4K cache를 추가한 ARM610486 초기 제품과 동등한 수준이었다. 회로적인 복잡도의 차이를 생각하면 이것은 엄청난 성능이다. 게다가 인터럽트 반응은 ARM이 월등히 빠르니 이후 리얼타임 임베디드 분야(real-time embedded application)에 ARM이 승승장구한 것은 자연스러운 일이었다.

초기 ARM코어(ARM1 ~ ARM6)는 겨우 트랜지스터 3만개로 이루어져있다.
트랜지스터 7만개의 모토롤라 68000의 절반, 27만개가 넘는 80386의 10분의 1밖에 안되니 ARM Architecture는 상당히 간결하다는 사실을 짐작할 수 있다.

ARM1의 구조(1985)

80386의 구조(1985)

ARM1과 80386의 실제 칩 내부를 비교해보면, ARM Core에는 없는 MMU(Memory Management Unit)가 존재한다. 본래 x86은 16-bit 구조이었기 때문에 64Kbyte(=2^16) 보다 큰 메모리의 접근을 위해 MMU가 불가피한 반면, ARM은 32-bit 구조(초기엔 26-bit 주소)라 MMU가 없어도 4Gbyte까지 메모리 접근이 가능했다.

MMU를 배제하고 Core부분만 비교해도 ARM1의 면적은 80386의 4분의 1정도밖에 되지않는다.
RISC 명령의 간결함이 명령어 디코더(Instruction Decoder)의 크기와 명령어 시퀀서(Instruction Sequencer)의 크기에 얼마나 큰 차이를 만드는 지 알 수 있다. ARM1은 PLA한개를 이용해 명령어 를 해석(decode)하고 또다른 PLA하나로 실행(sequence)하는 반면, 80386은 3개의 PLA로 명령어를 해석하고 커다란 Microcode ROM을 이용하여 명령어를 실행하도록 설계되어있다.

ARM초기설계에 대한 상세한 내용은 The History of ARM Architecture를 참고하기 바란다.

15년이 지난 지금…

놀랍게도 ARM은 Intel과 전쟁을 벌이고 있다.
작년 11월 ARM Technical Symposium에 참석했을 때, ARM은 Intel과의 전면전을 선언한 듯 보였다. “꿈에도 생각 못한 상황이 벌어진다”, “게임의 법칙이 바뀌고 있다”며 Windows/Intel를 상대로 승산이 있다고 했다.

Smartphone의 붐과 Android와 Chrome OS의 선전을 바탕으로 Smartphone과 Netbook의 중간에 새로운 시장이 생길 것으로 보고 이를 선점하기 위한 Ecosystem을 구축하기 위해 막대한 투자를 하고 있는 것으로 보였다.

ARM과 Intel중 누가 승리할 것인가에 대해 많은 추측들이 있고 ([1],[2],[3],[4],[5])
ARM이 Mobile Market에서 승리할 것이라고 예견하는 견해도 적지않다.([1],[2],[3]) 개인적으로는 ARM의 승리를 응원한다.

지난 9월 ARM은 최신 프로세서 아키텍쳐인 Cortex A-15를 발표했다.
이미 ARM의 Cortex-A8과 Cortex-A9이 동일 클록주파수 기준으로는 Intel의 Atom 프로세서보다 성능이 빠르지만, 2.5GHz까지 동작하는 Cortex-A15의 발표로 Intel에 확실한 비교 우위를 차지하려는 것으로 보인다.

마이크로프로세서, ASIC, 설계방법론의 역사

어제 발견한 Computer History Museum에 재미있는 내용들이 있어서 소개합니다.

공교롭게도 어제가 부울(Boole)이 태어난지 195년째 되는 날이었군요. 컴퓨터를 포함한 모든 논리회로는 부울 연산(Boolean Algebra)을 사용하죠.

이전 글에서 언급했듯, 1970년대에 이미 지금의 마이크로프로세서 설계기술이 거의 완성이 되었습니다.

1979년에 만들어진 M68000 프로세서의 각 기능블록들을 표시해보았습니다. Anceau의 책을 보고 직접 표시해 본 것입니다.

모토롤라 M68000 Die Photo 및 각 기능블록 [크게보기]

공정기술의 한계로 복잡도가 제한되었지만 2000년대에 만들고 있는 프로세서에 비해 그 설계기술은 크게 떨어져보이지 않습니다.

그렇다면 저 당시에는 어떤 방법으로 저런 설계를 했을까요?
지금은 당연시 사용하고 있는 설계방법론, 설계툴은 언제부터 존재 했던 것일까요?

그 해답도 Computer History Museum에서 찾을 수 있었습니다. (1960년에 강대원 박사의 이름도 찾아볼 수 있습니다)

EDA (Electronic Design Automation) 툴은 처음부터 IC를 위해 개발한 것은 아니고, 1950년대 후반부터 IBM에서 연구하기 시작했습니다. 60년대에 Logic Simulator도 개발되고 P&R(Place & Route) 소프트웨어도 만들었다고 합니다.

1967년 Fairchild의 CAD시스템

그리고 1967년에 드디어 게이트어레이와 Standard Cell이 처음 개발되었다고 합니다. 그리고 UC버클리에서 60년대에 SPICE 시뮬레이터도 개발 되었습니다.

당시 EDA툴이 어떤 것인지 또 어떻게 설계를 했는지 궁금해서 자료를 찾다가 발견한 1978 MIT의 VLSI System Design 수업자료로 당시의 모습을 상상해볼 수 있습니다.

Layout: CAD 환경이라고는 하지만 Layout 좌표를 일일히 CIF format에 맞춰 입력한 다음, 펜 플로터로 출력해서 확인해보는 것입니다.

Layout

DRC(Design Rule Check): 잘은 몰라도 자(ruler)를 가지고 Design Rule을 Check했을 것 같습니다.

Design Rule Check

Floorplan: 블록의 크기별로 종이를 잘라서 배치했었군요.

Floorplaning

참, 펜 플로터가 뭔지 잘 모르시는 분들도 계실 것 같네요.

Pen Plotter

90년대엔 VLSI를 개발하는 회사나 연구실엔 꼭 Plotter로 출력한 Layout이 벽에 걸려있었습니다. 저는 이게 그냥 장식용인 줄 알았는데, 원래는 마지막으로 전체 칩을 출력하여 문제가 있는지 확인하기 위한 절차였네요. 인텔에서 큰 방 가득하게 레이아웃을 출력해놓고 검토했다는 말도 생각납니다.

Final sanity check

한가지 더 놀라운 사실은 MIT에서 1979년과 1980년에 MPC(Multi-Project Chip)을 만들었다는 것입니다. 그리고 나중에 MOSIS로 발전하게 됩니다.

최초의 MPC(Multi-Project Chip)

MOSIS는 적은 비용으로 좋은 공정에서 칩을 만들 수 있는 MPW(Multi-Project Wafer)를 운영하고 있습니다. 반도체교육센터(IDEC)에서 운영하고 있는 MPW도 MOSIS를 모델로 한 것입니다.

Xerox PARC의 EDA환경

MIT의 교과 수업환경은 아무래도 회사보다 열악할테고, 당시(1979년) Xerox PARC에서 MPW용 DB들을 Merge하고 있는 것으로 보이는 사진을 보면 회사의 EDA환경은 Layout을 마우스와 GUI환경으로 하는 것처럼 보입니다. (Xerox PARC의 마우스와 GUI환경은 애플 Machintosh가 채택한 것으로 유명하죠)

설계환경은 열악하지만 당시 강의자료를 살펴보면 그 내용만큼은 정말 훌륭합니다.
The MIT’78 VLSI System Design Course: A Guidebook for the Instructor of VLSI System Design

지금은 거의 찾아볼 수 없는 직접 글씨를 쓰고 그림을 그려가며 만든 강의자료도 인상적이지만, 그 내용은 지금 대학원 강의교재로 써도 전혀 손색이 없겠네요.

당시 수업을 했던 Lynn Conway의 저서 “Introduction to VLSI Systems“는 김보관교수님이 갖고 계신걸 본 기억이 있는데, 그저 오래된 책이라 생각하고 지나쳤었습니다. 책 내용(draft)을 살펴보니 1979년 책이라고는 상상할 수 없는 그 방대한 지식에 놀랐습니다.

그리고 Computer Architecture에 대한 내용도 눈에 띄어 Lynn Conway의 경력을 살펴보니 Supercomputer/Superscalar의 원조겪인 IBM ACS의 Architect였더군요. Dynamic Instruction Scheduling, Multithreading 등의 자료를 보면 지금의 컴퓨터 구조는 정말 70년대에 이미 완성 되었다는 생각이 듭니다.

1979년에 Single Chip DSP(Digital Signal Processor)도 등장합니다.

로직 합성(Logic Synthesis)는 1980년대에 UC버클리의 SIS, UCLS의 RASP 그리고 콜로라도대학의 BOLD 등의 연구가 기반이 되었습니다. UC버클리의 espresso는 상당히 성능이 좋았고, 저도 예전에 PLA설계에 사용했었습니다.

이러한 연구의 영향을 받아 1986년에 Synopsys가 창립하고 케이던스의 전신인 Automated Integrated Design Systems(1983년창림, 1985년에 Gatewaey Design Automation으로 개명)에 의해서 1984년에 Verilog언어가 만들어 졌습니다.

1984년으로의 시간여행 (CPU, 애플, 카라테카)

요새 다시금 CPU의 역사를 되돌아보는 중입니다. 구글로 검색하다보니 시간 가는 줄 모르겠네요.

어제는 1974년부터 2004년까지의 CPU들을 체계적으로 정리해 놓은 cpu-collection.de를 발견했었는데, 오늘은 각종 CPU의 칩사진(die photo)까지 정리 해 놓은 CPU World를 발견했습니다.
인터넷에는 참 좋은 자료가 많이 있군요.

제가 컴퓨터 구조를 공부할 때 보던 책이 Francois AnceauThe Architecture of Microprocessors (Addison-Wesley 1986) 였습니다. 이 책을 보면 모토롤라의 M68000이 개발된 1979년에 이미 마이크로프로세서 설계기술이 거의 완성이 되었다는 사실을 알 수 있습니다.

Anceau책과 M68000 die photo

CPU World에서 M68000을 비롯한 70~80년대에 개발한 CPU들의 die photo를 보면서 현재 사용되고 있는 CPU/마이크로프로세서들이 공정기술을 제외하고 80년대의 프로세서보다 더 나은게 과연 무엇인가… 하는 생각을 했습니다.

다가 문득 Apple ][에 사용되었던 MOS Technology 6502 프로세서가 궁금해져서 찾아보니, 이 40년된 프로세서에 아직도 애착을 갖고 있는 분들이 많다는 사실을 발견했습니다. www.6502.org 에 많은 자료들이 있습니다.

이 자료들을 찾다가 애플2의 에뮬레이터가 있다는 것도 알게 되었고 애플2 컴퓨터를 Java로 구현해놓은 virtualapple.org 도 발견하였습니다. 그 중에서도 제일 반가웠던 것은 바로 초등학생때 하던 카라테카를 그대로 다시할 수 있었던 것입니다. 25년이 지났는데 아직까지 기억이 생생하다는 사실에 놀랐습니다.

그런데 주인공캐릭터의 모습과 움직임에서 IBM XT게임인 페르시아의 왕자가 겹쳐보이기 시작하는 것이었습니다. 특히 달려가는 모습… 결정적으로 문에서 철창에 찍혀죽는 모습(위 사진 중 마지막)에선 확신을 갖게 되었습니다. 문을 통과하면서.. “어 여기 그냥 지나가면 칼날이 나와서 잘려죽을 것 같은데? 아참? 그건 페르시아의 왕자인가?”하면서 지나가다 찔려 죽었습니다. ^^;;

게임이 끝나고 나오는 화면을 보니 “Broderbund Software”라는 이름도 굉장히 익숙해 보이더군요. 검색을 시작했고 카라테카나 페르시아왕자가 모두 동일 개발자 Jordan Mechner 의 작품이었습니다. 그리고 페르시아의 왕자가 Apple 2 용으로 개발되었다가 IBM XT용으로 컨버젼 됐다는 사실도 알게 되었습니다. (Apple2 버젼도 virtualapple.org에서 실행가능합니다.) 애플2버젼은 그래픽이 다소 떨어지지만, 자연스러운 움직임은 그대로네요. 애플에서 이정도의 움직임을 구현하다니 정말 대단합니다.

Apple2용 페르시아의 왕자

왜 어릴적에는 같은 사람이 만든 게임이란 사실을 몰랐을까 생각해보았습니다. 지금이야 1984년이나 1989년이나 그때가 그때 같지만, 당시엔 카라테카를 했던 것은 초등학생 시절이었고, 페르시아의 왕자는 고등학생때 였으니 중간에 큰 시간적 공백이 있었던 것이죠. 페르시아의 왕자를 처음보고 카라테카를 떠올렸던 것은 같습니다만, 구글이 없이 검색해 볼 방법도 없고 애플컴퓨터를 다시 찾아 실행해서 제작자 이름을 비교해볼 수도 없었던 것이죠.

아무튼 컴퓨터의 역사를 공부하다 기억속에 끊어진 연결 고리를 발견하니 참 재미있군요.

Computer Architecture 공개 강의 추천

1년 전 David Harris교수의 강의자료를 추천드린 적이 있었는데, 오늘 우연히 또 발견한 강의가  상당히 좋아서 추천드립니다.

인도 IIT의 S. Raman교수의 컴퓨터 구조론 동영상 강의입니다. (따라서 인도식 영어 엑센트는 감안하시고 보셔야합니다)
http://nptel.iitm.ac.in/video.php?courseId=1050

Flip-flop보다 마이크로아키텍쳐를 먼저 가르치는 상식 파괴의 접근법이 놀랍습니다. 그리고, Textbook없이 모든 그림을 직접 그리면서 설명하는 것도 멋지군요. 슥슥 컴퓨터 구조를 그리면서 별것 아니라는 듯 가르치는게 KAIST 조규형 교수님을 떠올립니다.

Raman교수의 Datapath 구조 강의 중

제가 작년에 사용했던 강의 자료 중

Youtube 검색 중 저 Datapath그림이 썸네일에 눈에 띄어서 살펴본 것인데요. 작년에 제가 충남대에서 강의할때 이해를 돕기위해 고민해서 만든 자료와 상당히 유사합니다. 같은 접근방식을 사용한다는게 반가웠고, 한학기 컴퓨터 구조 강의가 모두 제가 추구하는 방식으로 설명되어있을 것을 생각하니 벌써 행복해지네요. 아직 몇시간 분량 밖에 못보았는데 틈틈이 다 봐야겠습니다.

NPTel이 무엇인가 찾아보니 인도 정부에서 지원하는 “국가 기술향상 교육 프로그램”이라고 합니다.
다른 과목에 대한 강의도 공개되어있습니다. (모두 동영상 강의가 있는 것은 아니더군요)
http://nptel.iitm.ac.in/courses.php?branch=Comp

내친김에 공개 강의 정보를 검색해보았더니 잘 정리해 둔 글이 있네요.
http://blog.naver.com/csps2010/130093140514

국내에도 KOCW라는 싸이트에 공개 강의가 많이 있습니다. 최근 TED/TEDx로 인해 공개 강의에 관심이 많아지는 것 같습니다.

이제 의지만 있다면 인터넷에 공개된 강의자료 만으로도 상당한 수준의 지식을 얻을 수 있을 것 같습니다. 저도 유용한 자료들을 찾아 틈틈히 공부를 하고 또 공유해야겠다는 다짐을 해봅니다.

OpenSparc Coding Style

OpenSparc을 좀 들여다 보기로 하고선 진도가 잘 안나가네요.

제가 OpenSparc에서 관심 가졌던 부분은 몇가지가 있습니다. 그중 한가지가 코딩 스타일입니다.
참고로, 소스코드를 다운로드하지 않아도 Web으로도 간단히 T1T2의 코드를 직접 확인하실 수 있습니다.

먼저 Naming Convention입니다.
방대한 분량 (T1의 경우 33만6천라인)의 설계를 하기 위해선 분명 적지않은 개발자가 참여했으므로 체계적이고 명확하고 효율적인 Naming Convention이 존재하리라 기대했으나 기대했던 수준은 아닌 것 같습니다.

인상적인 부분 몇가지는 signal name과 module name이 상당히 깁니다. 특히 module name이 긴데 ‘sparc_exu_aluadder64′ 정도의 길이는 보통입니다. 명확한 대신 한눈에 안들어온다는 단점, module name을 입력할 때 수동으로 입력하면 틀리기 십상이라 반드시 자동완성 기능을 사용해야 되겠더군요.

특징적인 부분은 always문이 매우 적은 빈도로 사용되어있습니다.
flip-flop이 필요한 곳은 아래와 같이 D flip-flop을 가져다가 사용하고 있기 때문이긴 하지만 상당히 의외네요. 그렇다면 FSM(Finite State Machin)을 어떻게 구현했나 찾아보니, 일반적인 FSM 형태로 구현된 부분은 Thread State Machine과 Miss Instruction List State Machine 두개 밖에 없군요.

wire [1:0] thrid_m, thrid_g ;
dff #(2)  stgm_thrid (
       .din    (
ifu_tlu_thrid_e[1:0]),
       .q      (thrid_m[1:0]),
       .clk    (
clk),
       .se     (1′b0),       .si (),         
.so ()
       );

dff  #(2) stgg_thrid (
       .din    (
thrid_m[1:0]),
       .q      (thrid_g[1:0]),
       .clk    (
clk),
       .se     (1′b0),       .si (),         
.so ()
       );

dff  stgw_ivld (
       .din    (
flush_w_inst_vld_m),
       .q      (lsu_inst_vld_tmp),
       .clk    (
clk),
       .se     (1′b0),       .si (),         
.so ()
       );

이렇게 버스 단위로 D flip-flop을 instanciation하거나

dff  #(4) ivld_stgw2 (
       .din    ({
ld0_inst_vld_g,ld1_inst_vld_g,ld2_inst_vld_g,ld3_inst_vld_g}),
       .q    ({ld0_inst_vld_w2,ld1_inst_vld_w2,ld2_inst_vld_w2,ld3_inst_vld_w2}),
       .clk  (
clk),
       .se     (1′b0),       .si (),         
.so ()
  );

dff  #(4) th_stgm (
       .din    ({
thread0_e,thread1_e,thread2_e,thread3_e}),
       .q      ({thread0_m,thread1_m,thread2_m,thread3_m}),
       .clk  (
clk),
       .se     (1′b0),       .si (),         
.so ()
  );

dff  #(4) th_stgg (
       .din    ({
thread0_m,thread1_m,thread2_m,thread3_m}),
       .q      ({thread0_g,thread1_g,thread2_g,thread3_g}),
       .clk  (
clk),
       .se     (1′b0),       .si (),         
.so ()
  );

dff  #(4) th_stgw2 (
       .din    ({
thread0_g,thread1_g,thread2_g,thread3_g}),
       .q      ({thread0_w2,thread1_w2,thread2_w2,thread3_w2}),
       .clk  (
clk),
       .se     (1′b0),       .si (),         
.so ()
  );

이렇게 concatenation해서 flip-flop을 연결합니다.

이런 coding style은 datapath의 pipeline register를 기술할때 특히 효과적이겠네요.

OpenSparc T2는 어떤가 하고 조금 살펴보니, T1보다 훨씬 module name이 길고 직접 dff을 가져다 쓰는게 아니라 module을 한겹 덧씌워서 unique하게 만들어 사용하는군요.

module spc_lb_ctlmsff_ctl_macro__width_15Index (
 
din,
 
l1clk,
 
scan_in,
 
siclk,
 
soclk,
 
dout,
 
scan_out);
wire [14:0] fdin;
wire [13:0] so;

  input [14:0] din;
  input l1clk;
  input scan_in;

  input siclk;
  input soclk;

  output [14:0] dout;
  output scan_out;

assign
fdin[14:0] = din[14:0];

dff #(15)  d0_0 (
.l1clk(
l1clk),
.siclk(
siclk),
.soclk(
soclk),
.d(
fdin[14:0]),
.si({
scan_in,so[13:0]}),
.so({
so[13:0],scan_out}),
.q(
dout[14:0])
);

endmodule

또 한가지, T2는 제가 알고 있던 상식을 깨고 있었는데, 위의 macro module을 잘 보면 scan input, scan output까지 연결하고 있습니다.

네 그렇습니다. 이런 식의 register macro들을 모두 연결하여 RTL상에서 scan chain을 구성하고 있었습니다. T1만 하더라도 scan chain은 합성단계에서 auto insertion하고 있었던 것으로 보이는데, 다음 세대인 T2는 RTL에서 scan chain을 모두 stich해두었는데… 이것 참 어떻게 받아들여야할지?(T1, T2가 모두 그렇다면 Sun의 전통(?)이겠거니 할텐데 그것도 아니고 말입니다.)

혹시 수십,수백만 게이트 짜리 디자인의 scan-chain을 manual stitch한다는 얘기 들어보신분?

Building OpenSPARC T1

둘째아이도 퇴원하고나니 이제 마음에 여유가 좀 생겼습니다.

지금 다니고 있는 회사는 곧 퇴사할 예정이고 10월부터 새로운 곳으로 이동할 계획이었는데, 일정에 변화가 생겨서 시간이 생겼네요.

몇년만에 찾아온 휴식시간인 셈인데… 무엇을 할까 생각하다가 그동안 미루던 ‘취미활동(?)’을 하기로 했습니다.

오래전에 babyworm님 블로그에서 OpenSPARC을 알게되어, 당시 download만 받아놓고 살펴보지 못하고 있었는데 이번 기회에 한번 들여다 보려고 합니다. 회사에서 웹서핑하고 노는 것도 금방 질리고 하고 놀만한 일도 마땅이 없는 지금 상황에서 아주 적당한 놀거리입니다. 공부도 되고요.

박사학위과정에선 마이크로프로세서 설계를 공부했으나 실제 졸업 후에는 마이크로프로세서 관련된 업무와는 다소 거리가 있는 일을 하고 있었습니다. 마이크로프로세서 설계는 원래 좋아하던 일이니 취미활동이라고 봐야지요..

작심삼일이 될 가능성이 농후하지만 시작이 반이라고 일단 시작은 했습니다.

www.opensparc.net 에서 최근 release의 OpenSPARC T1을 받아서, 제가 사용하는 계정에 옮겼습니다. 제 환경이 Solaris 9이라 Sun Studio 11 도 새로 설치했습니다.

NC-Verilog환경으로 Setup하려고 했는데 Compile중에 Error가 발생하여, VCS환경으로 설정했습니다.

압축파일에 담겨있는 OpenSPARCT1_DVGuide.pdf를 보고 그대로 따라하니 큰 문제 없이 진도가 나가네요.

$ sims -sim_type=vcs -group=core1_mini -novera_build -novera_run

첫번째 단계로 single core에 minimum regression으로 돌렸는데 꽤 오래걸리네요.

일단 시동은 걸었으니 조금씩 뜯어보고 눈에 띄는 내용은 블로그에 메모할 예정입니다.

Logic 설계와 Microprocessor 설계의 역사

Logic 설계와 Microprocessor 설계의 역사를 한눈에 볼 수 있는 ISSCC 50주년 Virtual Museum.
http://www.sscs.org/History/isscc50/micropr-logic/index.html

Memory 분야
http://sscs.ieee.org/images/files/aboutus/history/ISSCC50/memory/index.html

Analog분야
http://sscs.ieee.org/images/files/aboutus/history/ISSCC50/analog/index.html