SoC 설계기술개발 현황
2005-10-12
유승주
- 3462
- 0
1. 서론: SoC 설계 현황
System-on-Chip (SoC)은 기존의 전자보드(board) 상에 구현하던 하드웨어 칩들(프로세서, 메모리 등)을 하나의 칩상에 구현한 것이다. SoC 설계문제를 이해하기 위해서는 다음과 같이 크게 4가지 사항을 이해할 필요가 있다.
- 시스템 집적도 향상으로 인한 멀티프로세서(multiprocessor) SoC 설계문제의 등장
- 시장출시시간의 중요성
- 설계능력 향상을 위한 플랫폼기반 설계의 필요
- 플랫폼 설계에서의 소프트웨어 복잡도 문제 등장
서론에서는 이들을 설명하고, 본론에서는멀티프로세서 SoC와 소프트웨어 복잡도 문제를 해결하기 위한 network-on-chip 및 hardware-dependent software 기술을 설명하고자 한다.
반도체 공정기술의 발전에 의한 시스템 집적도 향상
시스템집적으로 SoC 설계가 가능해 진 것은 최근의 반도체 칩 공정기술의 발전에 기인한다. 공정기술의 발전을 이해하기 위해, 칩 공정기술수준의 척도로 사용하는 gate length를 알아보자. 그림 1에서 왼쪽은 칩 사진이고 오른쪽은 칩의 한 부분을 설계도(layout)로 예시한 것이다. 설계도 상의 가운데 부분의 분홍색 선을 gate라고 하고, 그 선의 폭을 gate length라고 한다. Gate length는 그림에서는 가로 세로로 그려진 눈금의 한 단위길이에 해당한다. 그림 상에서 노란색과 초록색 부분이 반도체에서 동작의 기본 단위인 트랜지스터들이다. Gate length는 트랜지스터의 최소 크기를 결정한다. 따라서 주어진 칩 면적에서 구현 가능한 트랜지스터의 개수, 즉 칩 상에 구현할 수 있는 시스템의 크기를 결정하게 된다.
그림 1 Gate length
최신 칩에서 gate length는 0.13m (130nm) ~ 0.090m (90nm)가 주로 사용된다. 길이의 단위로 예전부터 m를 사용했는데, gate length가 아주 작아진 최근의 기술을 표현할 때deep submicron (DSM)이라는 용어를 사용한다. Gate length는 앞으로 계속 줄어들 것으로 예상하는데 2013년 경에는 13nm 정도의 수준이 될 것으로 예상한다 [1]. 이 경우는 Si 원자의 크기가 0.1nm 수준이므로 대략 130개 정도의 Si 원자를 일렬로 배열한 것이 하나의 gate length에 해당하게 된다.
멀티프로세서 SoC 설계문제의 등장
SoC 설계에서 이러한 공정기술의 발전은 새로운 설계문제를 설계자들에게 주게 된다. 최근까지 대부분의 SoC 는 하나의 프로세서를 가지고 그 주위에 하드웨어 블록들이 특정한 기능을 수행하는 구조, 즉 uniprocessor 구조가 대부분이었다. 그러나 DSM 기술의 발전은 설계자들에게 멀티프로세서 구조 설계를 요구한다. 예를 들어 SoC 설계에서 많이 사용하는 내장형 프로세서로 ARM 프로세서가 있는데, ARM 프로세서의 최신버젼인 ARM11[2]을 130nm 공정기술로 구현할 경우 ARM11 하나가 7.75mm2 의 면적을 가지므로, 2cmx2cm 크기의 칩 상에 대략50여개의 ARM11 프로세서를 구현할 수 있다. 물론, 이들 프로세서들간의 통신을 위한 면적을 고려하면 실제로는 이보다 적은 숫자의 프로세서를 구현할 수 있겠지만, 여전히 몇십개 단위의 프로세서를 가진 SoC 즉 멀티프로세서 SoC 구현이 가능하게 된다. 이러한 멀티프로세서 SoC설계는 기존의 uniprocessor 설계와 상당히 다르고 더욱 복잡한 설계이다.
설계의 제한조건 시장출시시간
이러한 상황에서 설계자를 더욱 어렵게 만드는 것은 이러한 설계복잡도의 증가에 비해 제품출시시간은 늘어나지 않고, 때로는 줄어든다는 점이다. 설계의 복잡도 증가로 이러한 제품 출시시간을 맞추지 못하고 경쟁사에 비해 조금이라도 늦게 제품을 출시 할 경우는 기업이 원하는 매출을 올리기 어렵다는 다음과 같은 분석을 보면 제품출시시간의 중요성을 이해할 수 있다. 그림 2는 제품출시시간이 경쟁사에 비해 늦을 경우의 시장매출손실을 간단하게 계산하는 모델이다 [3]. 그림에서 두 경쟁사 A, B가 있을 때, A에 비해 B가 시간 D 만큼 제품출시를 늦게 했다고 가정하자. 시장기간(market window)를 2W이다. 이 경우 B 사가 겪을 매출손실액은, 예를 들어, 시장기간의 6개월이고, 300M$의 총 시장매출을 A가 올릴 경우, B는 1달 늦게 제품을 시장 출시할 경우 133M$의 매출을 손해 (그림에서는 두 삼각형의 면적차이) 보게 된다. 즉, 1달 지연출시로 40%이상의 매출을 손해 보게 된다.
그림 2 Time-to-market delay effects
Design productivity gap: 설계능력향상속도와 시스템복잡도증가속도의 차이
설계자를 더욱 더 어렵게 하는 상황은 더욱 복잡해신 시스템 설계를 주어진 시간조건 내에서 수행해야 한다면 설계능력의 향상이 필수적인데, 현재의 설계능력(design productivity) 향상속도는 시스템의 구현능력(즉 시스템의 복잡도, complexity) 증가속도에 비해 현저히 낮다는 점이다. ITRS roadmap에 의하면 시스템 복잡도의 증가속도(58%/년)와 시스템설계능력 향상속도(21%/년)는 큰 차이를 보인다 [1]. 설계능력을 향상시키기 위한 새로운 설계방법을 개발하지 않으면 이러한 설계복잡도와 설계능력 간의 격차는 시간이 갈수록 더욱 더 심화될 것으로 예상된다.
설계능력향상방안: 플랫폼 기반 설계
설계능력향상방안으로 최근 등장한 설계방법론은 플랫폼 기반 설계이다. 이는 하드웨어 아키텍처를 가능한 미리 고정시켜 놓고 그 위에 소프트웨어를 제품에 맞게 다르게 설계하는 방법이다. 즉, 하드웨어 아키텍처를 여러 다른 제품설계에서 재 사용하는 개념이다.
그림 3은 ST Microelectronics의 멀티미디어 SoC 플랫폼 Nomadik의 블록도를 보인다. 그림에서 보인 것처럼 가운데 위치한 ARM9 프로세서가 전체 아키텍처 동작을 제어하고, 멀티미디어 동작을 위한 비디오 및 오디오 프로세서(DSP와 하드웨어 가속기)가 설계에 따라 재사용 또는 새로이 설계되어 부착될 수 있다. 이러한 플랫폼을 재 사용해서 새로운 시스템을 구현할 경우 새로운 기능은 소프트웨어(Nomadik의 경우 ARM9과 비디오, 오디오 프로세서상에 동작하는 소프트웨어)로 주로 구현한다.
그림 3 Nomadik architecture
소프트웨어 설계 복잡도 증가
SoC에 구현되는 기능이 더욱 더 복잡해 짐에 따라 (예를 들어 무선휴대폰의 경우 3/4G, MPEG4 등의 사용으로 복잡도 증가), 플랫폼상에 구현되는 소프트웨어의 복잡도 역시 증가하게 된다. 최근의 조사에 의하면 소프트웨어 복잡도 증가의 속도는 10개월에 2배(소프트웨어 코드의 크기를 비교할 때) 증가한다고 한다. 코드 크기를 예로 들면 DVD player나 HDD 칩의 경우 이미 1백만 라인 이상의 소프트웨어 코드를 설계해야 한다. 따라서 소프트웨어 설계의 복잡도 문제가 심각하게 된다.
그림 4 Software cost dominates hardware cost.
그림 4는 소프트웨어 복잡도 문제의 단면을 보여준다. 그림은 공정기술이 130nm 에 이르르면 전체 SoC 설계비용에서 소프트웨어 관련비용이 하드웨어 관련비용보다 더 커지는 것을 보인다. 이는 소프트웨어 설계의 복잡도 증가로, 소프트웨어 IP의 구입, 소프트웨어 설계기간 증가로 인한 소프트웨어 개발팀의 관리비용 증가 등으로 인한 것이다.
이상과 같이 SoC 설계 현황을 살펴보면, 설계자가 직면한 큰 문제는 멀티프로세서 설계문제와 소프트웨어 재사용 문제이다. 이 문제들을 해결하기위해 최근의 연구개발방향은 멀티프로세서 설계문제 해결을 위한 network-on-chip (NoC), 소프트웨어 재사용문제 해결을 위한 hardware-dependent software (HdS) 이다.
2 Network-on-chip 설계기술
NoC 개념이 필요한 이유로는 크게 다음과 같은 두 가지 이유를 들 수 있다.
(1) 칩상의 구현능력 향상
(2) 물리적인 문제의 심화
칩상의 구현능력은 서론에서 설명한 바와 같이 하나의 칩 상에 수 십개의 프로세서를 구현할 수 있게 된 상황이다. 이 경우, 기존의 uniprocessor 기반 SoC 설계에서 사용하던 통신 아키텍처인 bus 구조의 확장이 필요하게 되는데, 이때 설계자의 문제는 “어떻게 수 십개의 프로세서를 지원할 수 있도록 통신 아키텍처를 확장할 것인가?”이다. 이를 위해서 네트워크개념을 칩상의 통신에 도입하게 되었다.
물리적인 면에서는 통신시간과 DSM 효과를 고려해야 한다. 통신속도의 물리적 한계는 진공에서의 빛의 속도(300mm/psec) 라고 볼 수 있다. 22mmx22mm 칩의 종단지연시간을 빛의 속도로 계산해 보면, 대각선길이가 대략30mm 이므로 100psec 즉 10GHz 클럭으로 한 클럭 싸이클에 통신이 가능할 것이다. 하지만 실제는 반도체 상에서의 빛의 속도의 감소, 칩을 가로 지르는 하나의 클럭 wire가 10GHz의 동작을 가지기는 어려우므로, 대략 5-10 clock cycles의 통신지연시간을 예상하게 된다. 즉, 기존의 bus 기반 통신에서 하나의 bus 클럭 싸이클에 통신을 하던 상황과는 통신지연시간 면에서 큰 차이를 볼 수 있다.
DSM 효과는 long wire 간의 capacitive coupling에 의한 상호간섭으로 인한 noise 및 signal integrity 문제와 soft errors (alpha particle, neutron scattering으로 인한 저장정보의 오류발생) 문제이다. 상호간섭 문제는 예를 들어 여러 개의 wire가 칩을 가로질러 아주 길게 배선되는 경우 이들 wire 간의 간격이 가까울 경우 상호간섭이 심해져 신호전달에 오류가 나는 것을 의미한다. 이를 해결하는 방법으로는 long wire를 사용하지 않는 것이 가장 효과적일 것이다. Soft error 문제는 DRAM에서는 이미 문제되어 왔었고, 최근에는 SRAM, register file로 그 영향범위가 확대되고 있다.
이러한 물리적 문제는 공정기술이 발달할수록 더욱 문제가 될 것이다. 따라서, 이들을 해결하기 위해서는 wire의 배선을 짧고 구조적으로 할 필요가 있다. 즉, 규칙적인, 정형화된 통신 아키텍처가 필요하다.
위의 두 가지 요구조건, 즉 네트워크 개념과 규칙적인 통신아키텍처의 필요성은 칩상에 통신을 위해 규칙적인 네트워크를 필요로 하게 되었다. 그림 5는 규칙적인 NoC를 예시한 것이다 [4]. 이 아키텍처 예제는 각각 가로 세로 10개의 행과 열을 가진 타일의 2차원 배열을 구조로 가진다. 각 타일은 시스템 자원(프로세서, 메모리, 하드웨어 가속기 등), 네트워크 인터페이스(Network Interface, NI)로 구성된다. 타일들은 라우터 (그림에서는 S로 표현됨)를 통해 다른 타일들과 통신을 수행한다. 그리고 라우터 간에는 링크로 연결된다. 이러한 네트워크는 플랫폼 기반 설계에서의 플랫폼으로 사용될 수 있다.
그림 5 A regular NoC example : 2D mesh
네트워크 기술은 컴퓨터네트워크 및 병렬컴퓨터 분야에서 지난 30여년간 많은 기술발전이 있었다. NoC 분야에서는 이러한 기존 기술들을 SoC 설계에 응용하는 것이다. 이러한 응용을 위해 기존의 컴퓨터네트워크 및 병렬컴퓨터설계에서 다루었던 다음과 같은 문제들을 SoC 설계의 관점에서 다시 다루게 된다. 괄호 안에는 관련주제의 대표적인 연구 내용들을 예시하였다.
- Topology (기존의 병렬컴퓨터의 네트워크 구조인 mesh, torus, cube, k-ary n-cube 등등의 구조들의 응용가능성에 대한 연구)
- Routing (deadlock free routing 등의 기존의 routing 알고리즘의 응용에 관한 연구)
- 라우터 구조 (SoC에 적합한 라우터 구조에 대한 연구)
- 네트워크 인터페이스 (기존의 bus 구조와 연동 가능한 네트워크 인터페이스 연구)
- 통신프로토콜 스택 (기존의 OSI 7 layer 모델 및 기타 모델의 NoC 적용의 적합성 연구)
- 병렬프로그램 모델 (message passing, shared memory 모델등의 기존의 모델를 SoC 설계에 응용하는 방법에 관한 연구)
기존의 컴퓨터네트워크와 병렬컴퓨터 설계에 비해 SoC 상의NoC설계에서 특별히 나타나는 문제들을 구현 및 동작비용 및 quality of service 측면에서 보면 다음과 같다.
비용면에서는 SoC설계가 칩면적 및 소모전력 제한조건을 가지므로, NoC가 칩상에서 차지하는 면적과 NoC가 소모하는 전력을 감소시키는 것이 아주 중요하다. 면적 면에서 보면, 칩 상에서는 메모리가 많은 면적을 차지할 수 있는데, 컴퓨터네트워크의 라우터 구조중 메모리를 많이 요구하는 경우 (예를 들어, output buffered 구조)는 NoC 상의 라우터로 적합하지 않게 된다. 또한, 전력 소모면에서도 저전력을 위해 topology, 라우터 구조, 패킷크기 등의 네트워크 설계의 가능성들을 검색해서 저전력 구현이 가능한 조합을 찾아 내야 한다.
컴퓨터 네트워크 상에서 통신의 quality of service (통신 대역폭, 지연시간, 지연시간 jitter 등)는 네트워크 설계자가 확정적으로(deterministically) 보장해 줄 수 없고, 대체로 통계적인 기준으로 보장이 가능하다. 이는 근본적으로 한 네트워크 사업자 또는 하나의 통신 프로토콜(예를 들어, ATM)이 네트워크의 모든 영역을 다 제어하지는 못하기 때문이다. 반면에 NoC의 경우 SoC 설계자가, 네트워크, 인터페이스, 프로세서 상의 소프트웨어/하드웨어 동작등 모든 관련 동작을 설계시에 결정할 수 있다. 따라서 NoC 상의 통신의 예측성 및 제어능력이 100%에 가깝다고 할 수 있다. 따라서, 통신의 quality of service 보장을 확정적으로(deterministically) 할 수 있다는 장점이 있다. 최근에 이러한 점을 이용하여, 통신의 quality of service 를 보장하는 네트워크 라우터 및 인터페이스에 관한 연구가 활발히 진행되고 있다 [5].
앞으로의 전망
NoC 설계문제는 SoC설계자들이 현재 실제 설계에서 만나고 있기 때문에, 대학연구소 뿐만 아니라 SoC설계기업에서도 NoC 설계기술에 대한 수요가 높은 상황이다. 앞으로 개발 및 응용될 NoC 설계기술은 앞에서 언급한 바와 같이 기존의 컴퓨터네트워크 및 병렬컴퓨터 분야의 연구결과를 SoC에 응용하는 기술일 것이다. 또한, NoC를 앞으로 설계에 사용한다고 해서 현재 사용중인 버스구조를 NoC로 완전히 대치할 수는 없을 것이다. 새로운 칩 설계에서 기존의 설계를 재사용하는 측면에서 볼 때, 앞으로 설계될 SoC는 재사용되는 버스구조를 가진sub-system 들, 새로이 개발되는sub-system 들 및 이들간의 통신을 수행하는 NoC 로 구성될 것으로 예상해 볼 수 있다.
3. Hardware-dependent Software 설계 기술
Hardware-dependent software (HdS)는 “하드웨어 아키텍처에 종속적인 소프트웨어 (all software that is directly dependent on the underlying HW)”이다. HdS 의 예를 들면, 부팅코드, 하드웨어 디바이스 테스트 코드, 하드웨어 디바이스 드라이버, (통신 시스템의 경우) 하드웨어에 의존하는 통신프로토콜 부분, DSP (digital signal processor)에 구현되는 소프트웨어 알고리즘 등이다. 이들 중, 부팅코드, 하드웨어 디바이스 테스트 코드, 하드웨어 디바이스 드라이버는 흔히 ‘시스템 소프트웨어’로 알려져 있다.
HdS API가 제공하는 내장형 소프트웨어의 Portability
이러한 HdS를 정의하는 이유는 HdS 보다 상위에 위치한 소프트웨어(예를 들어 응용소프트웨어)가 하드웨어와의 통신을 정해진 API (Application Programming Interface) 를 통해서만 할 수 있도록 하려는 것이다. 이 경우, HdS API는 상위에 위치한 소프트웨어에게 하위 하드웨어 아키텍처에 대한 일종의 추상(abstraction)을 제공한다. 따라서, 그 소프트웨어는 같은HdS API를 지원하는 서로 다른 하드웨어 아키텍처 상에 자유롭게 porting이 가능하다.
이러한 portability는 내장형 소프트웨어가 여러 다른 하드웨어 아키텍처, 즉 다른 SoC설계에 재사용될 수 있도록 한다. 이러한 재 사용은 서론에서 언급한 소프트웨어 설계의 복잡도문제를 설계자가 해결할 수 있는 방법이다. 범용 소프트웨어의 경우 이러한 portability 개념은POSIX API, Windows OS API 등의 OS API를 이용해 이미 널리 이용되어 왔다. 내장형 소프트웨어의 경우에는 최근에야 HdS개념이 등장했다. 기존의 OS API와 비교해서 HdS API는portability지원 면에서는 같은 개념이지만, 그 적용범위에서는 차이가 있다.
HdS 개념의 적용범위에 대해 설명하기 전에, SoC 설계에 있어 HdS API가 가지는 효과를 설계과정 측면에서 보면, HdS API는 하드웨어와 소프트웨어의 동시설계를 가능하게 한다. 즉, 소프트웨어 개발자는 하드웨어 구현이 끝나기 전에HdS API를 기반으로 소프트웨어 코드를 작성하고 테스트 할 수 있다. 이러한 동시설계는 SoC설계시간을 단축시킬 수 있으므로 서론에서 언급한 시장출시시간 문제를 해결하는데 실질적인 도움이 된다.
SoC설계를 위한 HdS의 범위
그림 6은 내장형 소프트웨어의 구성을 보여준다[6]. 상위소프트웨어에서부터 살펴보면 응용소프트웨어(application SW), 미들웨어, 테스트소프트웨어, OS, boot, 디바이스드라이버, hardware abstraction layer 또는 board support package로 구성된다. 그림에서 보는 것 처럼 넓게 보면HdS의 범위는 응용소프트웨어, 미들웨어 및 OS (OS에 의존하는 board support package 포함)를 제외한 나머지 소프트웨어 전부를 포함할 수 있다. 현재 HdS API 표준화를 준비중인 VSIA (Virtual Socket Interface Alliance)의 경우 이러한 넓은 의미의 HdS는 인정하되, 실질적으로 SoC 설계에 유요한 HdS API로는 그림에서 볼 수 있는 hardware abstraction layer와 board support package의 일부만을 포함하는 좁은 의미의HdS API를 표준화하려고 한다. 이는 넓은 의미의HdS API 경우 하드웨어 아키텍처의 추상화 면에서는 좋으나 모든 SoC설계에서 이러한 높은 수준의 추상화를 필요로 하지는 않으므로, 대부분의 SoC 하드웨어 아키텍처가 공통적으로 가지는 구조인 프로세서, 메모리 그리고 주변기기에 대한 추상, 즉 uniprocessor 아키텍처의 추상화만을 현재 목표로 한다. 물론, 멀티프로세서 아키텍처와 시스템응용분야에 따른 특별한 하드웨어블럭 들에 대한 추상화 역시 VSIA HdS Development Working Group의 계획에 포함되어 있다.
그림 6 내장형 소프트웨어의 구성
내장형 소프트웨어의 재사용을 위한 HdS 개념 역시 실제 설계기업에서 필요로 하는 기술이므로 기업주도의 HdS API 표준화가 여러 시스템응용분야에서 진행되고 있다. 무선단말기 분야에서는 Texas Instrument와 ST Microelectronics가 OMAP API를 개발했고, 최근에는 이를 업계표준으로 발전시키기 위해 Mobile Industry Processor Interface (MIPI) 컨소시엄을 만들어 표준화를 추진하고 있다. 범용 소프트웨어 분야에서도 Universal Device Interface (UDI) 프로젝트가 진행 중인데, 이는 최근 VSIA HdS 표준화 활동과 협력관계를 맺고 함께 표준화를 진행 중이다. 자동차 업계 및 네트워크 프로세서 업계에서도 내장형 소프트웨어 portability를 위해 각각 OSEK/VDX 와 NPF API를 표준화해서 실제 설계에 사용하고 있다.
앞으로의 전망
HdS 개념을 실제 설계에 적용하기 위해서 가장 중요한 것은 HdS API를 정의하는 것이다. 이는 업계 표준일 수도 있고, 한 기업 내에서만 사용하는 것일 수도 있다. 다음으로 필요한 일은HdS API를 기반으로 한 SoC 설계를 위한 새로운 설계 방법들을 개발하는 것이다. 예를 들어, 특정 HdS API 표준을 모두 만족시키는 HdS API의 경우 코드 크기가 아주 클 수 있다. 따라서, 정해진 HdS API를 모두 사용하지 않고 일부만 사용하는 응용소프트웨어만 가진 경우 HdS를 customization하여 HdS의 비용을 줄이는 방법에 대한 연구 등이 필요하다.
4. 결론
본고에서는 SoC설계의 최근 현황으로 공정기술발전에 의한 칩의 용량증가에 의한 멀티프로세서 SoC의 등장, 시장출시시간의 중요성, 설계능력 향상을 위한 플랫폼기반 설계에서의 소프트웨어 설계 복잡도 증가문제에 대해 설명하였다. 그리고, 최근 새로이 등장한 멀티프로세서 SoC 설계 및 소프트웨어 재 사용을 가능하게 하는 기술로, network-on-chip과 hardware-dependent software 기술에 대해 설명하였다. Network-on-chip기술은 기존의 컴퓨터 네트워크 및 병렬컴퓨터 분야에서 개발한 기술을 SoC에 효과적으로 응용하는 기술개발이 핵심이며, hardware-dependent software 기술은 표준 API 제정이 핵심사항이라 하겠다. 끝으로, 두 기술 모두 SoC 설계기업에서 현재 시급히 필요로 하는 기술이므로 기업주도의 연구개발활동이 다른 기술분야에 비해 활발하다는 점을 언급하면서 이 글을 마친다.
[1] http://public.itrs.net/
[2] http://www.arm.com/products/CPUs/ARM1136JF-S.html
[3] J. Borel, “Introduction: Moving to a global approach for EDA”, MEDEA+ Design Automation Conference, 2003.
[4] Nostrum, http://www.imit.kth.se/info/FOFU/NOC/node1.html
[5] E. Rijpkema, et al., « Trade Offs in the Design of a Router with both Guaranteed and Best-Effort Services for Networks On Chip », Design Automation and Test in Europe, 2003.
[6] Virtual Socket Interface Alliance HdS DWG, http://www.vsi.org/
그림 1 Gate length
최신 칩에서 gate length는 0.13m (130nm) ~ 0.090m (90nm)가 주로 사용된다. 길이의 단위로 예전부터 m를 사용했는데, gate length가 아주 작아진 최근의 기술을 표현할 때deep submicron (DSM)이라는 용어를 사용한다. Gate length는 앞으로 계속 줄어들 것으로 예상하는데 2013년 경에는 13nm 정도의 수준이 될 것으로 예상한다 [1]. 이 경우는 Si 원자의 크기가 0.1nm 수준이므로 대략 130개 정도의 Si 원자를 일렬로 배열한 것이 하나의 gate length에 해당하게 된다.
멀티프로세서 SoC 설계문제의 등장
SoC 설계에서 이러한 공정기술의 발전은 새로운 설계문제를 설계자들에게 주게 된다. 최근까지 대부분의 SoC 는 하나의 프로세서를 가지고 그 주위에 하드웨어 블록들이 특정한 기능을 수행하는 구조, 즉 uniprocessor 구조가 대부분이었다. 그러나 DSM 기술의 발전은 설계자들에게 멀티프로세서 구조 설계를 요구한다. 예를 들어 SoC 설계에서 많이 사용하는 내장형 프로세서로 ARM 프로세서가 있는데, ARM 프로세서의 최신버젼인 ARM11[2]을 130nm 공정기술로 구현할 경우 ARM11 하나가 7.75mm2 의 면적을 가지므로, 2cmx2cm 크기의 칩 상에 대략50여개의 ARM11 프로세서를 구현할 수 있다. 물론, 이들 프로세서들간의 통신을 위한 면적을 고려하면 실제로는 이보다 적은 숫자의 프로세서를 구현할 수 있겠지만, 여전히 몇십개 단위의 프로세서를 가진 SoC 즉 멀티프로세서 SoC 구현이 가능하게 된다. 이러한 멀티프로세서 SoC설계는 기존의 uniprocessor 설계와 상당히 다르고 더욱 복잡한 설계이다.
설계의 제한조건 시장출시시간
이러한 상황에서 설계자를 더욱 어렵게 만드는 것은 이러한 설계복잡도의 증가에 비해 제품출시시간은 늘어나지 않고, 때로는 줄어든다는 점이다. 설계의 복잡도 증가로 이러한 제품 출시시간을 맞추지 못하고 경쟁사에 비해 조금이라도 늦게 제품을 출시 할 경우는 기업이 원하는 매출을 올리기 어렵다는 다음과 같은 분석을 보면 제품출시시간의 중요성을 이해할 수 있다. 그림 2는 제품출시시간이 경쟁사에 비해 늦을 경우의 시장매출손실을 간단하게 계산하는 모델이다 [3]. 그림에서 두 경쟁사 A, B가 있을 때, A에 비해 B가 시간 D 만큼 제품출시를 늦게 했다고 가정하자. 시장기간(market window)를 2W이다. 이 경우 B 사가 겪을 매출손실액은, 예를 들어, 시장기간의 6개월이고, 300M$의 총 시장매출을 A가 올릴 경우, B는 1달 늦게 제품을 시장 출시할 경우 133M$의 매출을 손해 (그림에서는 두 삼각형의 면적차이) 보게 된다. 즉, 1달 지연출시로 40%이상의 매출을 손해 보게 된다.
그림 2 Time-to-market delay effects
Design productivity gap: 설계능력향상속도와 시스템복잡도증가속도의 차이
설계자를 더욱 더 어렵게 하는 상황은 더욱 복잡해신 시스템 설계를 주어진 시간조건 내에서 수행해야 한다면 설계능력의 향상이 필수적인데, 현재의 설계능력(design productivity) 향상속도는 시스템의 구현능력(즉 시스템의 복잡도, complexity) 증가속도에 비해 현저히 낮다는 점이다. ITRS roadmap에 의하면 시스템 복잡도의 증가속도(58%/년)와 시스템설계능력 향상속도(21%/년)는 큰 차이를 보인다 [1]. 설계능력을 향상시키기 위한 새로운 설계방법을 개발하지 않으면 이러한 설계복잡도와 설계능력 간의 격차는 시간이 갈수록 더욱 더 심화될 것으로 예상된다.
설계능력향상방안: 플랫폼 기반 설계
설계능력향상방안으로 최근 등장한 설계방법론은 플랫폼 기반 설계이다. 이는 하드웨어 아키텍처를 가능한 미리 고정시켜 놓고 그 위에 소프트웨어를 제품에 맞게 다르게 설계하는 방법이다. 즉, 하드웨어 아키텍처를 여러 다른 제품설계에서 재 사용하는 개념이다.
그림 3은 ST Microelectronics의 멀티미디어 SoC 플랫폼 Nomadik의 블록도를 보인다. 그림에서 보인 것처럼 가운데 위치한 ARM9 프로세서가 전체 아키텍처 동작을 제어하고, 멀티미디어 동작을 위한 비디오 및 오디오 프로세서(DSP와 하드웨어 가속기)가 설계에 따라 재사용 또는 새로이 설계되어 부착될 수 있다. 이러한 플랫폼을 재 사용해서 새로운 시스템을 구현할 경우 새로운 기능은 소프트웨어(Nomadik의 경우 ARM9과 비디오, 오디오 프로세서상에 동작하는 소프트웨어)로 주로 구현한다.
그림 3 Nomadik architecture
소프트웨어 설계 복잡도 증가
SoC에 구현되는 기능이 더욱 더 복잡해 짐에 따라 (예를 들어 무선휴대폰의 경우 3/4G, MPEG4 등의 사용으로 복잡도 증가), 플랫폼상에 구현되는 소프트웨어의 복잡도 역시 증가하게 된다. 최근의 조사에 의하면 소프트웨어 복잡도 증가의 속도는 10개월에 2배(소프트웨어 코드의 크기를 비교할 때) 증가한다고 한다. 코드 크기를 예로 들면 DVD player나 HDD 칩의 경우 이미 1백만 라인 이상의 소프트웨어 코드를 설계해야 한다. 따라서 소프트웨어 설계의 복잡도 문제가 심각하게 된다.
그림 4 Software cost dominates hardware cost.
그림 4는 소프트웨어 복잡도 문제의 단면을 보여준다. 그림은 공정기술이 130nm 에 이르르면 전체 SoC 설계비용에서 소프트웨어 관련비용이 하드웨어 관련비용보다 더 커지는 것을 보인다. 이는 소프트웨어 설계의 복잡도 증가로, 소프트웨어 IP의 구입, 소프트웨어 설계기간 증가로 인한 소프트웨어 개발팀의 관리비용 증가 등으로 인한 것이다.
이상과 같이 SoC 설계 현황을 살펴보면, 설계자가 직면한 큰 문제는 멀티프로세서 설계문제와 소프트웨어 재사용 문제이다. 이 문제들을 해결하기위해 최근의 연구개발방향은 멀티프로세서 설계문제 해결을 위한 network-on-chip (NoC), 소프트웨어 재사용문제 해결을 위한 hardware-dependent software (HdS) 이다.
2 Network-on-chip 설계기술
NoC 개념이 필요한 이유로는 크게 다음과 같은 두 가지 이유를 들 수 있다.
(1) 칩상의 구현능력 향상
(2) 물리적인 문제의 심화
칩상의 구현능력은 서론에서 설명한 바와 같이 하나의 칩 상에 수 십개의 프로세서를 구현할 수 있게 된 상황이다. 이 경우, 기존의 uniprocessor 기반 SoC 설계에서 사용하던 통신 아키텍처인 bus 구조의 확장이 필요하게 되는데, 이때 설계자의 문제는 “어떻게 수 십개의 프로세서를 지원할 수 있도록 통신 아키텍처를 확장할 것인가?”이다. 이를 위해서 네트워크개념을 칩상의 통신에 도입하게 되었다.
물리적인 면에서는 통신시간과 DSM 효과를 고려해야 한다. 통신속도의 물리적 한계는 진공에서의 빛의 속도(300mm/psec) 라고 볼 수 있다. 22mmx22mm 칩의 종단지연시간을 빛의 속도로 계산해 보면, 대각선길이가 대략30mm 이므로 100psec 즉 10GHz 클럭으로 한 클럭 싸이클에 통신이 가능할 것이다. 하지만 실제는 반도체 상에서의 빛의 속도의 감소, 칩을 가로 지르는 하나의 클럭 wire가 10GHz의 동작을 가지기는 어려우므로, 대략 5-10 clock cycles의 통신지연시간을 예상하게 된다. 즉, 기존의 bus 기반 통신에서 하나의 bus 클럭 싸이클에 통신을 하던 상황과는 통신지연시간 면에서 큰 차이를 볼 수 있다.
DSM 효과는 long wire 간의 capacitive coupling에 의한 상호간섭으로 인한 noise 및 signal integrity 문제와 soft errors (alpha particle, neutron scattering으로 인한 저장정보의 오류발생) 문제이다. 상호간섭 문제는 예를 들어 여러 개의 wire가 칩을 가로질러 아주 길게 배선되는 경우 이들 wire 간의 간격이 가까울 경우 상호간섭이 심해져 신호전달에 오류가 나는 것을 의미한다. 이를 해결하는 방법으로는 long wire를 사용하지 않는 것이 가장 효과적일 것이다. Soft error 문제는 DRAM에서는 이미 문제되어 왔었고, 최근에는 SRAM, register file로 그 영향범위가 확대되고 있다.
이러한 물리적 문제는 공정기술이 발달할수록 더욱 문제가 될 것이다. 따라서, 이들을 해결하기 위해서는 wire의 배선을 짧고 구조적으로 할 필요가 있다. 즉, 규칙적인, 정형화된 통신 아키텍처가 필요하다.
위의 두 가지 요구조건, 즉 네트워크 개념과 규칙적인 통신아키텍처의 필요성은 칩상에 통신을 위해 규칙적인 네트워크를 필요로 하게 되었다. 그림 5는 규칙적인 NoC를 예시한 것이다 [4]. 이 아키텍처 예제는 각각 가로 세로 10개의 행과 열을 가진 타일의 2차원 배열을 구조로 가진다. 각 타일은 시스템 자원(프로세서, 메모리, 하드웨어 가속기 등), 네트워크 인터페이스(Network Interface, NI)로 구성된다. 타일들은 라우터 (그림에서는 S로 표현됨)를 통해 다른 타일들과 통신을 수행한다. 그리고 라우터 간에는 링크로 연결된다. 이러한 네트워크는 플랫폼 기반 설계에서의 플랫폼으로 사용될 수 있다.
그림 5 A regular NoC example : 2D mesh
네트워크 기술은 컴퓨터네트워크 및 병렬컴퓨터 분야에서 지난 30여년간 많은 기술발전이 있었다. NoC 분야에서는 이러한 기존 기술들을 SoC 설계에 응용하는 것이다. 이러한 응용을 위해 기존의 컴퓨터네트워크 및 병렬컴퓨터설계에서 다루었던 다음과 같은 문제들을 SoC 설계의 관점에서 다시 다루게 된다. 괄호 안에는 관련주제의 대표적인 연구 내용들을 예시하였다.
- Topology (기존의 병렬컴퓨터의 네트워크 구조인 mesh, torus, cube, k-ary n-cube 등등의 구조들의 응용가능성에 대한 연구)
- Routing (deadlock free routing 등의 기존의 routing 알고리즘의 응용에 관한 연구)
- 라우터 구조 (SoC에 적합한 라우터 구조에 대한 연구)
- 네트워크 인터페이스 (기존의 bus 구조와 연동 가능한 네트워크 인터페이스 연구)
- 통신프로토콜 스택 (기존의 OSI 7 layer 모델 및 기타 모델의 NoC 적용의 적합성 연구)
- 병렬프로그램 모델 (message passing, shared memory 모델등의 기존의 모델를 SoC 설계에 응용하는 방법에 관한 연구)
기존의 컴퓨터네트워크와 병렬컴퓨터 설계에 비해 SoC 상의NoC설계에서 특별히 나타나는 문제들을 구현 및 동작비용 및 quality of service 측면에서 보면 다음과 같다.
비용면에서는 SoC설계가 칩면적 및 소모전력 제한조건을 가지므로, NoC가 칩상에서 차지하는 면적과 NoC가 소모하는 전력을 감소시키는 것이 아주 중요하다. 면적 면에서 보면, 칩 상에서는 메모리가 많은 면적을 차지할 수 있는데, 컴퓨터네트워크의 라우터 구조중 메모리를 많이 요구하는 경우 (예를 들어, output buffered 구조)는 NoC 상의 라우터로 적합하지 않게 된다. 또한, 전력 소모면에서도 저전력을 위해 topology, 라우터 구조, 패킷크기 등의 네트워크 설계의 가능성들을 검색해서 저전력 구현이 가능한 조합을 찾아 내야 한다.
컴퓨터 네트워크 상에서 통신의 quality of service (통신 대역폭, 지연시간, 지연시간 jitter 등)는 네트워크 설계자가 확정적으로(deterministically) 보장해 줄 수 없고, 대체로 통계적인 기준으로 보장이 가능하다. 이는 근본적으로 한 네트워크 사업자 또는 하나의 통신 프로토콜(예를 들어, ATM)이 네트워크의 모든 영역을 다 제어하지는 못하기 때문이다. 반면에 NoC의 경우 SoC 설계자가, 네트워크, 인터페이스, 프로세서 상의 소프트웨어/하드웨어 동작등 모든 관련 동작을 설계시에 결정할 수 있다. 따라서 NoC 상의 통신의 예측성 및 제어능력이 100%에 가깝다고 할 수 있다. 따라서, 통신의 quality of service 보장을 확정적으로(deterministically) 할 수 있다는 장점이 있다. 최근에 이러한 점을 이용하여, 통신의 quality of service 를 보장하는 네트워크 라우터 및 인터페이스에 관한 연구가 활발히 진행되고 있다 [5].
앞으로의 전망
NoC 설계문제는 SoC설계자들이 현재 실제 설계에서 만나고 있기 때문에, 대학연구소 뿐만 아니라 SoC설계기업에서도 NoC 설계기술에 대한 수요가 높은 상황이다. 앞으로 개발 및 응용될 NoC 설계기술은 앞에서 언급한 바와 같이 기존의 컴퓨터네트워크 및 병렬컴퓨터 분야의 연구결과를 SoC에 응용하는 기술일 것이다. 또한, NoC를 앞으로 설계에 사용한다고 해서 현재 사용중인 버스구조를 NoC로 완전히 대치할 수는 없을 것이다. 새로운 칩 설계에서 기존의 설계를 재사용하는 측면에서 볼 때, 앞으로 설계될 SoC는 재사용되는 버스구조를 가진sub-system 들, 새로이 개발되는sub-system 들 및 이들간의 통신을 수행하는 NoC 로 구성될 것으로 예상해 볼 수 있다.
3. Hardware-dependent Software 설계 기술
Hardware-dependent software (HdS)는 “하드웨어 아키텍처에 종속적인 소프트웨어 (all software that is directly dependent on the underlying HW)”이다. HdS 의 예를 들면, 부팅코드, 하드웨어 디바이스 테스트 코드, 하드웨어 디바이스 드라이버, (통신 시스템의 경우) 하드웨어에 의존하는 통신프로토콜 부분, DSP (digital signal processor)에 구현되는 소프트웨어 알고리즘 등이다. 이들 중, 부팅코드, 하드웨어 디바이스 테스트 코드, 하드웨어 디바이스 드라이버는 흔히 ‘시스템 소프트웨어’로 알려져 있다.
HdS API가 제공하는 내장형 소프트웨어의 Portability
이러한 HdS를 정의하는 이유는 HdS 보다 상위에 위치한 소프트웨어(예를 들어 응용소프트웨어)가 하드웨어와의 통신을 정해진 API (Application Programming Interface) 를 통해서만 할 수 있도록 하려는 것이다. 이 경우, HdS API는 상위에 위치한 소프트웨어에게 하위 하드웨어 아키텍처에 대한 일종의 추상(abstraction)을 제공한다. 따라서, 그 소프트웨어는 같은HdS API를 지원하는 서로 다른 하드웨어 아키텍처 상에 자유롭게 porting이 가능하다.
이러한 portability는 내장형 소프트웨어가 여러 다른 하드웨어 아키텍처, 즉 다른 SoC설계에 재사용될 수 있도록 한다. 이러한 재 사용은 서론에서 언급한 소프트웨어 설계의 복잡도문제를 설계자가 해결할 수 있는 방법이다. 범용 소프트웨어의 경우 이러한 portability 개념은POSIX API, Windows OS API 등의 OS API를 이용해 이미 널리 이용되어 왔다. 내장형 소프트웨어의 경우에는 최근에야 HdS개념이 등장했다. 기존의 OS API와 비교해서 HdS API는portability지원 면에서는 같은 개념이지만, 그 적용범위에서는 차이가 있다.
HdS 개념의 적용범위에 대해 설명하기 전에, SoC 설계에 있어 HdS API가 가지는 효과를 설계과정 측면에서 보면, HdS API는 하드웨어와 소프트웨어의 동시설계를 가능하게 한다. 즉, 소프트웨어 개발자는 하드웨어 구현이 끝나기 전에HdS API를 기반으로 소프트웨어 코드를 작성하고 테스트 할 수 있다. 이러한 동시설계는 SoC설계시간을 단축시킬 수 있으므로 서론에서 언급한 시장출시시간 문제를 해결하는데 실질적인 도움이 된다.
SoC설계를 위한 HdS의 범위
그림 6은 내장형 소프트웨어의 구성을 보여준다[6]. 상위소프트웨어에서부터 살펴보면 응용소프트웨어(application SW), 미들웨어, 테스트소프트웨어, OS, boot, 디바이스드라이버, hardware abstraction layer 또는 board support package로 구성된다. 그림에서 보는 것 처럼 넓게 보면HdS의 범위는 응용소프트웨어, 미들웨어 및 OS (OS에 의존하는 board support package 포함)를 제외한 나머지 소프트웨어 전부를 포함할 수 있다. 현재 HdS API 표준화를 준비중인 VSIA (Virtual Socket Interface Alliance)의 경우 이러한 넓은 의미의 HdS는 인정하되, 실질적으로 SoC 설계에 유요한 HdS API로는 그림에서 볼 수 있는 hardware abstraction layer와 board support package의 일부만을 포함하는 좁은 의미의HdS API를 표준화하려고 한다. 이는 넓은 의미의HdS API 경우 하드웨어 아키텍처의 추상화 면에서는 좋으나 모든 SoC설계에서 이러한 높은 수준의 추상화를 필요로 하지는 않으므로, 대부분의 SoC 하드웨어 아키텍처가 공통적으로 가지는 구조인 프로세서, 메모리 그리고 주변기기에 대한 추상, 즉 uniprocessor 아키텍처의 추상화만을 현재 목표로 한다. 물론, 멀티프로세서 아키텍처와 시스템응용분야에 따른 특별한 하드웨어블럭 들에 대한 추상화 역시 VSIA HdS Development Working Group의 계획에 포함되어 있다.
그림 6 내장형 소프트웨어의 구성
내장형 소프트웨어의 재사용을 위한 HdS 개념 역시 실제 설계기업에서 필요로 하는 기술이므로 기업주도의 HdS API 표준화가 여러 시스템응용분야에서 진행되고 있다. 무선단말기 분야에서는 Texas Instrument와 ST Microelectronics가 OMAP API를 개발했고, 최근에는 이를 업계표준으로 발전시키기 위해 Mobile Industry Processor Interface (MIPI) 컨소시엄을 만들어 표준화를 추진하고 있다. 범용 소프트웨어 분야에서도 Universal Device Interface (UDI) 프로젝트가 진행 중인데, 이는 최근 VSIA HdS 표준화 활동과 협력관계를 맺고 함께 표준화를 진행 중이다. 자동차 업계 및 네트워크 프로세서 업계에서도 내장형 소프트웨어 portability를 위해 각각 OSEK/VDX 와 NPF API를 표준화해서 실제 설계에 사용하고 있다.
앞으로의 전망
HdS 개념을 실제 설계에 적용하기 위해서 가장 중요한 것은 HdS API를 정의하는 것이다. 이는 업계 표준일 수도 있고, 한 기업 내에서만 사용하는 것일 수도 있다. 다음으로 필요한 일은HdS API를 기반으로 한 SoC 설계를 위한 새로운 설계 방법들을 개발하는 것이다. 예를 들어, 특정 HdS API 표준을 모두 만족시키는 HdS API의 경우 코드 크기가 아주 클 수 있다. 따라서, 정해진 HdS API를 모두 사용하지 않고 일부만 사용하는 응용소프트웨어만 가진 경우 HdS를 customization하여 HdS의 비용을 줄이는 방법에 대한 연구 등이 필요하다.
4. 결론
본고에서는 SoC설계의 최근 현황으로 공정기술발전에 의한 칩의 용량증가에 의한 멀티프로세서 SoC의 등장, 시장출시시간의 중요성, 설계능력 향상을 위한 플랫폼기반 설계에서의 소프트웨어 설계 복잡도 증가문제에 대해 설명하였다. 그리고, 최근 새로이 등장한 멀티프로세서 SoC 설계 및 소프트웨어 재 사용을 가능하게 하는 기술로, network-on-chip과 hardware-dependent software 기술에 대해 설명하였다. Network-on-chip기술은 기존의 컴퓨터 네트워크 및 병렬컴퓨터 분야에서 개발한 기술을 SoC에 효과적으로 응용하는 기술개발이 핵심이며, hardware-dependent software 기술은 표준 API 제정이 핵심사항이라 하겠다. 끝으로, 두 기술 모두 SoC 설계기업에서 현재 시급히 필요로 하는 기술이므로 기업주도의 연구개발활동이 다른 기술분야에 비해 활발하다는 점을 언급하면서 이 글을 마친다.
[1] http://public.itrs.net/
[2] http://www.arm.com/products/CPUs/ARM1136JF-S.html
[3] J. Borel, “Introduction: Moving to a global approach for EDA”, MEDEA+ Design Automation Conference, 2003.
[4] Nostrum, http://www.imit.kth.se/info/FOFU/NOC/node1.html
[5] E. Rijpkema, et al., « Trade Offs in the Design of a Router with both Guaranteed and Best-Effort Services for Networks On Chip », Design Automation and Test in Europe, 2003.
[6] Virtual Socket Interface Alliance HdS DWG, http://www.vsi.org/