용's

[Chap 9] ARM Processor Cores 본문

Computer Science/Embedded System

[Chap 9] ARM Processor Cores

TaeYOng's 2014. 12. 16. 01:42

이번 챕터에서는 각 ARM 버전의 프로세서 코어를 비교해보자


9.1 ARM7TDMI

- ARM7은 가장 유명하게 쓰였던 코어로서, TDMI은 다음과 같은 뜻을 지닌다.

.T: Thumb 16bit 명령어를 지원

.D: On-Chip 디버그를 지원

.M: 향상된 Multiplier를 지원

.I: 임베디드 ICE(In Circuit Emulator)가 내장되어 있다.


- 3단계 파이프 라인을 채택함

- 임베디드 시스템 디버깅을 지원하기 위해 임베디드 ICE를 내장함

.scan chain0은 이동하면서 프로세서 코어에 나오고 들어가는 신호들을 모두 스캔

.scan chain2는 버스들을 관통하지 않고 밑으로 지나가므로 버스와는 상관 없이 임베디드 ICE가 필요로하는 정보를 주고 받을 수 있음

- ARM7 코어의 인터페이스 신호들을 보면 디버그와 JTAG Boundary Scan을 위한 핀이 거의 반 이상 사용됨

.상당히 많은 인터페이스를 디버깅을 위해 할애했다는 것을 알 수 있음


9.2 ARM8

- ARM7보다 코어의 성능 더 향상되었다(실행시간이 줄어듦)

- 더 높은 성능을 내기 위해서는 CPI(명령어당 클락 사이클 개수)를 줄이거나 클락 사이클을 자체를 높여야 한다.


- CPI를 줄이는 것

.ARM8에서는 64비트(32비트 이상)의 명령어를 가지고 오기 위해, 더블 밴드위스(double bandwidth)메모리로 줄임(즉, 버스는 늘리지 않고 64비트를 끄집어 내기 위해, 클락 양쪽엣지를 다써서 보내겠다는)

.버스를 64비트로 올려버리면 상당히 비용이 크기 때문에


- Prefetch unit이 사용되어, 브랜치 예측을 하기에 매우 유리하게 만듦(미리 뭐가 들어오는지 보게 됨으로)

- Backward Branch는 주로 루프 같은 것으로 'taken'으로 처리

.Forward Branch는 주로 예외처리 같은 부분으로 'not taken'으로 처리


- 5 단계 파이프 라인을 사용함



9.3 ARM9TDMI

- AMR8과 같이 5단계 파이프라인을 이용하며 명령어와 데이터를 위한 메모리(캐시)를 완전히 가름

.Fetch - Decode - Execute - Memory -  Write


- 성능개선 부분으로 스트롱암(StrongARM)와 비교했을 때, 

.StrongARM은 디코딩(decoding) 스테이지에 별도의 simple branch adder(비교연산을 위한 하드웨어)를 하나 둠으로써 분기에 대한 패널티를 줄었다.

.하지만, ARM9은 별도의 adder를 두지 않고 위의 분기 패널티를 수용하기로 함(매인 ALU를 그냥 사용)

.대신에, 코어가 더 작고 단순해 졌으며 디코드 단계의 길이(클락사이클)가 길어짐을 방지함



9.4 ARM10TDMI

- ARM9의 성능을 2배로 늘이고자 함. 방법은 두 가지 똑같다

.Clock Rate를 증가시키고, CPI를 줄이자


- Clock rate를 증가시킨다는 면에서 본다면, 한 스테이지를 여러 스테이지로 늘려서 한 스테이지가 하는 일을 줄읾으로써 Clock rate를 증가시킬 수 있겠다. 또한 슈퍼파이프라인과 같이 스테이지를 왕창 늘려버리면 파이프라인 디펜던시(Pipeline Dependency)가 증가하여 CPU를 더 악화시킬 수 있다


- Clock rate를 높이기 위해 6 단계 파이프 라인이 사용됨

- Clock rate를 높일 때, 가장 걸림돌은 메모리 엑세스하는 명령어(fetch & memory stage)이다

.Fetch&memory stage는 약 1.5배의 길이로 유지하였음. 어떻게?

메모리 단게에서 load, store할려고 하면 이전 단계인 execute 단계에서 ALU를 이용하여 주소를 계산하는데, ALU를 사용하지 않고 별도의 에더(separate adder)를 둠으로써 반 사이클 만에 계산하게 만들고 나머지 반을 메모리 단계에서 쓰도록 함. Fetch같은 경우는 가장 앞부분의 스테이지로 길어져도 다른 stage에 영향을 주지 않기 때문에 별다른 문제가 없다

.Load&Store만 하는 Memory 단계는 Multipier부분에서 놀게되므로 메모리 스테이지에 에더를 추가함으로써 Partial 들을 더하는 계산을 할 수 있도록 함


.Write단계에서는 0.5만큼만 쓰는데, 데이터 디펜던시(Data dependency)를 위해 나눠서 사용하는 것


- 위와 같이 Clock rate를 증가 시킴으로써 성능 2배 향상의 50퍼센터는 만족시켰으므로 나머지는 CPI를 줄임으로써 목표에 도달하도록 함

.64비트 버스와 함께 64비트 메모리를 사용함으로써 한 클락에 2개의 명령어가 fetch되도록 하였음

.따라서 브랜치 예측을 쉽게 할 수 있어 branch 패널티를 패치 단계에서 바로 없애게 되었음


- Non Blocking load & store 실행(Execution)을 채택하고 있음

.Load/Store 명령어들을 오퍼랜드 디펜던시가 발생할 때 까지 stall 하지 않음

.이는 다수의 load&store 명령어들이 각 클락안에 두개의 레지스터로 전송할 수 있도록 함

.non blocking load/store는 독립적인 레지스터 파일 읽기 포트와 쓰기 포트를 요구한다



Comments