첨단 운전자 지원 시스템(ADAS)과 인포테인먼트의 융합이 빠르게 진행되고 있다. 이와 함께 멀티코어 프로세서 하드웨어가 소비전력과 전자파의 증가를 억제하면서 ECU의 처리 성능을 향상시키기 위한 하나의 솔루션으로 주목받고 있다. 멀티코어의 경우, 애플리케이션 개발에 있어서 설계 툴이 중요한 이슈가 된다.

인포테인먼트 시스템은 지속적으로 증가하는 기능과 복잡성에 의해 전례 없는 연산 능력을 요구하고 있다. 이러한 기능을 지원하는 기존의 싱글코어(single-core) 프로세서는 높은 연산 능력은 물론, 자동차에서 발생하는 열, 전자파 간섭(EMI), 전력소비 등의 엄격한 제한을 극복하지 않으면 안 된다. 이 때문에 자동차 제조업체와 티어1 공급업체들은 엄격한 요구조건을 만족하면서도 필요한 성능을 높일 수 있는 멀티코어(multi-core) 프로세서에 주목하고 있다.
일반적으로 실리콘 설계의 물리적 제약을 극복하기 위해서는 동종 또는 이종의 프로세서를 여러 개 탑재하는 것이 바람직한 방법이다. 특히, 최근의 차량 인포테인먼트 시스템처럼 풍부한 미디어 그래픽, 상시 온(always-on) 기능, 멀티밴드 접속과 광범위한 프로세싱 요건을 제공하는 융합 기기의 경우 더욱 그렇다.
대부분의 경우, 서브시스템의 다양한 요구사항을 충족하기 위해서는 멀티코어 시스템에 이종의 운용체제(OS)가 공존하는 환경을 만들 필요가 있다. 예를 들면, 결정적 동작(deterministic)을 지원하는 통신 서브시스템에는 실시간 운용체제(Real-Time Operating System, RTOS)가, 사용자 애플리케이션을 실행하기 위해서는 임베디드 리눅스와 같은 범용 OS(General Purpose OS, GPOS)가 필요하다. 이러한 이종 OS 환경에서는 시스템 수준에서 애플리케이션을 설계할 필요가 있다. 낮은 지연(latency)과 실시간 동작 이외에도 프로세서 간 통신(InterProcessor Communication, IPC), 메모리 보호, 전력관리, 디바이스 관리 서브시스템 등의 기능도 필요하다.
또한 설계, 개발, 테스트, 복잡한 멀티코어 시스템의 도입을 효율적으로 수행하기 위해서는 통합 교차 개발(cross-development) 툴 슈트가 필요하다. 이러한 툴은 이해하기 쉽고 손에 익숙한 통합개발환경(IDE), 소위 개방형 업계 표준인 이클립스 프레임워크(Eclipse Framework) 기반이 바람직할 수 있으며, 멀티코어 플랫폼 특유의 복잡한 상태를 시각화하는 디버그 솔루션을 제공해야 한다. IDE에 완벽하게 통합되는 크로스 컴파일(cross compile) 툴과 다중 디버그 전송(JTAG, 에이전트 디버깅 등) 지원도 개발 사이클에서 대단히 중요하다.
멀티코어 시스템은 오래 전부터 존재해왔다. 현재 대부분의 멀티코어 시스템은 탁월한 성능과 전력 효율을 제공하는 임베디드 기기를 실현하며 차량 멀티미디어와 내비게이션, 모바일폰, 컨수머 기기 등 폭넓은 시장에서 소비자가 추구하는 다양한 기능을 지원하고 있다.
현재 멀티코어 프로세서로서 PowerPC 계열로는 프리스케일의 QorIQ P2020, MPC8315, MPC8377, ARM 계열로는 프리스케일의 i.MX51, Cortex A9, ARM 11 MPCore, 텍사스 인스트루먼트의 Davinci DM355와 OMAP 3530, OMAP L137, MIPS 계열로는 Raza XLS와 Cavium CN56xx, CN58xx, 인텔 계열로는 Intel Core i7 등이 있다.



자원을 공유하는 동종 코어에 부하를 분산시키기 위해서는 대칭형 멀티프로세싱(Symmetric Multi-Processing, SMP)을 사용한다. SMP에서 고려해야 할 사항에는 스케줄링 메커니즘의 호환성, 어피니티(affinity: 친화력)와 스핀락(spinlocks), 가상화 등이 포함된다. SMP와 달리, 비대칭형 멀티프로세싱(Asymmetric Multi-Processing, AMP) 시스템은 동종 또는 이종의 코어 상에서 실행하는 부하의 분할(partitioning)에, 같거나 또는 다른 OS의 여러 인스턴스(instance)를 사용하는 것이 일반적이다. AMP는 최적화된 프로세서 간 통신(IPC) 프레임워크를 통해 결정적 실시간 컴포넌트와 다른 시스템 부분을 분리하는 한편, 공통의 미들웨어와 그래픽 유저 인터페이스(GUI) 서비스를 구현할 수 있다. 또 한 가지 중요한 차이는 제어 플레인과 데이터 플레인 간 서비스의 분산이다.
일반적으로 AMP 접근법은 이종의 하드웨어 설계에 적용된다. 이러한 접근법의 주요 목적은 전용 칩에서 실행되는 전용 OS를 사용하는 데 있다. 예를 들면, 휴대용 기기나 또는 차량 인포테인먼트를 겨냥한 SoC는 RTOS나 펌웨어 코드를 실행하는 각각의 DSP 또는 GPS 칩을 구성할 수 있다.
AMP 시스템은 전통적으로 동종의 하드웨어를 상정하고 있는 OS에 대해 전례 없는 도전 과제를 안겨 주고 있다. 일반적으로 낮은 지연 성능, 결정성(determinism), 최소 풋프린트 등 AMP 시스템의 실시간 기능을 제공하는 것은 RTOS이다. 그러나 다양한 파라미터 세트 내에서 동작하고 많은 유저 애플리케이션을 관리하는 범용 OS와 공존시킬 필요도 있다.

AMP 하드웨어 아키텍처
최근의 동종 멀티코어 SoC는 기존의 멀티 코어 설계에 비해 복잡하고 더 많은 기능을 제공한다. 과거에 많은 멀티코어 시스템은 싱글코어 환경에 적합한 IP(반도체 설계 자산)을 사용해 맞춤형 ASIC이나 FPGA로 구현했다.
이러한 IP는 멀티코어 환경 전용의 기능이 그다지 없었다. 그래서 ASIC이나 FPGA 개발자가 멀티코어 환경을 지원하는 로직을 추가해 설계마다 맞춤형 하드웨어 솔루션을 제공했다.
ARM Cortex-A9 MPCore와 같은 새로운 멀티 코어 IP는 대칭형 환경과 비대칭형 환경을 모두 지원하는 전용 로직과 기능을 갖추었으며 효율성을 대폭 개선했다. 이러한 최신 설계에는 하드웨어 캐시 컨트롤러를 통해 통합 가능한 여러 수준의 캐시, 여러 실행 유닛에 걸쳐 소비전력과 성능을 최대화하는 첨단 전력관리 기능, 여러 코어에 인터럽트 라우팅을 중시한 인터럽트 컨트롤러, AMP 환경과 SMP 환경을 모두 지원하는 전용 컨피규레이션 설정 등이 갖춰져 있다.
이러한 설계의 복잡성은 코어 자체에 그치지 않으며 주변 환경 역시 진화를 거듭하고 있다. 메시 패브릭(mesh fabrics)과 인터커넥트가 표준 버스 토폴로지를 대체하고 영상, 음성 등을 오프로딩(off-loading) 하는 하드웨어 가속 장치가 추가되고, 온칩 주변장치 개수도 계속해서 늘어나고 있다. 여러 개의 코어를 탑재한 단일 칩에 네트워킹, USB, 암호화/복호화, 다수의 버스(SPI, I2C, PCI-e), LCD/터치 패널, SD/MMC, UART, 타이머 등을 지원하는 IP 블록을 탑재한 SoC 설계도 드물지 않다.
이러한 모든 개선은 복합적인 효과를 제공한다. 아키텍처 상의 개선을 추가한(ARMv7 아키텍처) 새로운 멀티코어 IP, 여기에 지속적인 SoC의 진보가 AMP 환경이나 SMP 환경에도 적합한 완전 멀티코어 하드웨어 설계를 만들어내고 있다.

AMP 소프트웨어 아키텍처
앞서 언급한 바와 같이, AMP 설계를 이용한 임베디드 장치에 관해서는 잘 알려져 있지만, 그런 시스템에는 논의할만한 가치가 있는 일반적인 설계 패턴이 있다. 그림 1은 AMP 시스템의 전형적인 하이-레벨 소프트웨어 아키텍처다.
이런 설계는 핸드셋, 소비자 기기, 의료기기, 산업제어 기기 등 다수의 수직 시장을 아우르는 많은 종류의 임베디드 장치에서 발견할 수 있다. 설계에는 명백히 서로 다른 목적을 지원하는 GPOS와 RTOS가 있다. 시스템이 수행해야 할 작업은 분할되어 GPOS가 제어 플레인 처리(유저 인터페이스, 애플리케이션 관리, 복잡한 프로토콜 등)를, RTOS가 데이터 플레인 처리(모터 제어, 센서 입력, 데이터 처리, 시간이 중시되는  처리, 암호화/복호화 등)를 담당한다. GPOS에는 Linux와 그 진화형인 Android, MeeGO 등이 많이 사용된다. 시간에 민감하고 결정성이 중시되는 동작이나 계산 처리가 많은 작업에는 QNX Neutrino, 멘토 그래픽스 Nucleus, 윈드리버 VxWorks와 같은 RTOS가 주로 사용된다. 현재 이러한 RTOS는 멀티코어, 멀티 OS 설계 기반으로 개발을 하는 개발자들을 위해 SMP와 AMP 멀티프로세싱 모델을 모두 지원한다.



대부분의 OS는 일부 IPC 메소드를 통해 통신한다. 과거에는 IPC가 대개 설계마다 다양했다. 현재 그 수는 적지만 IPC 메커니즘을 위한 개방형 표준이 존재한다. 그 중에서도 일반적인 것이 TIPC (Transparent IPC)와 멀티코어 통신 API(MCAPI)이다. TIPC는 Linux 및 다른 OS를 지원하는 완전히 트랜스페어런트 하고 대규모인 IPC 프로토콜이다. MCAPI는 TIPC보다 더 새롭고 메시지를 주고받는 가벼운 API로 친밀 분산형 시스템(SoC)에 적합하다. AMP 시스템의 확장성을 유지하고, 레거시 소프트웨어의 이식을 쉽게 하기 위해서는 이러한 개방형 표준을 준수하는 것이 필수적이다. GPOS와 RTOS 사이에 최적화된 IPC 메커니즘을 갖는 것도 AMP 시스템의 존속에 중요한 요소다. 따라서 AMP 설계는 개방형 표준을 기반으로 고도로 최적화된 IPC 메커니즘이 매우 중요하다.



앞서 설명한 AMP 소프트웨어 설계 패턴은 몇 년 전부터 존재해왔으며 가까운 장래에도 AMP 설계에 사용될 것이다. 이런 설계에서 주로 바뀌는 점이라면, 시스템의 GPOS 상이나 RTOS 상에서도 실행되는 애플리케이션과 미들웨어가 발전하고 작업이 복잡해지고 있다는 것이다. 복잡한 소프트웨어의 증가는 새로운 SoC의 복잡성과 임베디드 기기에서 지원하는 기능 증가와 직접적인 관계가 있다.

AMP 개발 툴
1개의 코어에서 1개의 OS를 실행하는   복잡한 소프트웨어 설계라도 뛰어난 개발 툴이 없기 때문에, 일정에 맞추지 못하는   경우가 종종 있다. 복잡한 시스템 수준 문제를 해결하기 위해서는 통합개발환경이 대단히 중요하다. 그리고 그런 현실은 멀티코어   시스템에서 더욱 심각하다.
앞서 언급했지만, AMP 설계 문제는 표준화된 툴의 가용성이 시스템의 GPOS 부분과 RTOS 부분에서 종종 다를 수 있다.
따라서 일관성 없는 환경을 만들어 사용하는 데 문제가 되고 시스템 수준의 문제해결이 상당히 어렵게 된다. 다른 툴에서는 다른 OS 간에 데이터를 상호 연관시킬 수 없으며 하이 레벨 시스템의 문제해결을 위한 통합 데이터 세트를 표시할 수도 없다. 결과적으로, 많은 개발자들은 “printf”를 사용하거나 수작업으로 데이터 로그를 검색하는 등 최적화가 덜 된 디버깅 기법으로 복귀하지 않을 수 없다. 기기가 계속해서 정교해지면서 AMP 설계에 사용하는 모든 OS에 대해 툴 솔루션을 통일하고, 그 툴을 효율적으로 사용할 수 있는 엔지니어링 팀을 확보하는 일이 더욱 더 중요해지고 있다.

AMP 시스템의 통합 문제
AMP 설계는 오랫동안 존재했지만, 새로운 SoC 및 플랫폼에 여러 OS를 통합하는 어려움은 여전히 부담이 되고 있다. 그림 2는 GPOS와 RTOS를 시스템에 통합할 때 결정해야 할 것들을 몇 가지 제시하고 있다. 그림 2는 GPOS와 RTOS 사이의 하이 레벨 리소스 파티션만 보여주고 있지만, 통합에는 이외에도 고려해야 할 다른 분야가 많이 있다.
예를 들면, 장치의 부팅 방법이 결정되어야 한다. GPOS와 RTOS 중 어느 쪽을 먼저 부팅해야할지, 부트 로더는 사용해야할지(비사용, u-boot 등), 다른 OS 간에 메모리를 어떻게 분할하고 보호해야할지, 특정 플랫폼에 맞게 시스템을 어떻게 최적화하고 조정할 수 있을지, 이렇게 복수의 OS를 한 개의 AMP SoC에 통합하기 위해서는 답하지 않으면 안 되는 난제가 많다.
불행한 것은, 이러한 환경을 통합하고 최적화하는데 시간이 필요하기 때문에 본래의 문제에서 벗어날 수 있다. 다시 말해, 본래의 문제는 개발하는 기기의 기능을 실현하기 위해서 GPOS와 RTOS에서 실행되는 애플리케이션의 개발이다. 지금까지 언급한 많은 논점 이외에도 통합에 소요되는 노력도 설계 대상의 기능이 늘어나고 실행하는 SoC의 기능이 급속히 발전함에 따라 크게 증가할 수 있다.
긴밀하게 통합된 GPOS, RTOS 솔루션과 그 솔루션을 지원하고 최적화할 수 있는 개발 서비스를 구입할 수 있는지 여부가 중요해지고 있다. 이들 솔루션과 서비스에 액세스하는 것이 허용된 새로운 임베디드 기기를 개발하는 개발팀은 기기가 대응해야 할 문제에 신경을 집중할 수 있다. 이 문제는 애플리케이션 수준에서 해결해야 할 것이며, 따라서 OS와 통신방식은 애플리케이션 개발 작업의 부담이 되지 않을 것이다.

AMP 유스 케이스
스트리밍 멀티미디어, 와이어리스 통신, 매력적인 유저 인터페이스 기술들이 전자기기에 보급됨에 따라, 이러한 기능을 지원하는 시스템 소프트웨어의 수요가 높아지고 있다. AMP 환경에서 효율적인 시스템 설계는 설계 엔지니어가 RTOS와 GPOS에 시스템 자원을 분할하고 하드웨어 컴포넌트에 매핑을 최적화할 수 있느냐에 달려 있다. 그러나, 시스템 요구사항과 자원의 분할 및 매핑은 일반적으로 주변장치, 서브시스템, 그리고 이것들의 타이밍 요구사항, 접속 I/O의 필요성 등 다양한 변수에 따라 시스템마다 다르다.
모바일폰은 AMP가 임베디드 개발자에게 높을 가치를 제공하는 예에 해당한다. 멀티미디어 스트리밍, 게임, 음성 통화의 발신과 수신까지 다수의 애플리케이션을 탑재한 다기능 기기인 스마트폰을 생각해 보자. 유저 애플리케이션의 대부분은 GPOS를 실행하는 범용 프로세서(GPP)에 할당할 수 있다. 무선 베이스밴드 서브시스템은 “상시 접속(always-on)” 에어 링크를 유지하면서 소비전력을 최적화해 QoS를 제공하는 멀티밴드 프로토콜 스택과 통합한 낮은 오버헤드의 RTOS를 필요로 한다.



멀티미디어 처리를 요구하는 애플리케이션은 대부분의 경우, 데이터 압축/해제, 이미지 처리, 이미지 안정화, 조작(manipul-ation), 해상도 향상 등 계산 집중적인 알고리즘을 수반한다. 앞서 언급했듯이, 현재 AMP SoC의 대부분은 이러한 집중적인 데이터 처리 작업을 수행하기 위해 컴패니언 가속기(companionaccelerator)를 탑재하고, 그것을 RTOS에서 관리 또는 제어하고 있다. 멀티코어 프로세서 아키텍처의 사용은 배터리 전원의 휴대용 기기에 전력을 최적화한 설계로, 다양한 시스템 요구를 분리하는 하나의 방법이 될 수 있다(그림 3 참조).
멀티코어 도입이 빠른 속도로 늘어남에 따라, SMP 및 AMP 설계와 적용도 빠르게 확대되고 있다. 처음엔 이종 OS에 시스템 자원을 분할, 분산하는 데 따른 설계와 통합의 복잡성과 기기의 개발 및 도입에 의해 제기되는 과제를 해결하는 데 비용 부담이 있을 수 있지만, 많은 경우에 비용을 상회하는 장점이 있다.
어떤 AMP의 유스 케이스에도 최적의 솔루션을 만들어낼 수 있는 설계 방법은 없다. 하지만, 개발자는 AMP 시스템이 근본적으로 싱글코어 환경과 다르다는 것을 인식하고 상업적으로 제공되는 솔루션과 서비스를 이용함으로써 AMP 환경을 최대한 활용하도록 애플리케이션을 최적화하는 것이 중요하다. 많은 경우에 개발자들이 부가가치가 높은 디자인 서비스를 통해 시스템 전문지식을 갖춘 외부 자원을 활용하면 복잡한 설계에 대응하고 제품화 기간을 단축할 수 있다. ES