KR102285084B1

KR102285084B1 - 이종의 멀티 cpu를 운용하는 시스템-온-칩 및 그 동작 방법

Info

Publication number: KR102285084B1
Application number: KR1020190174323A
Authority: KR
Inventors: 김문수; 오용석; 김호연지기; 정태훈
Original assignee: 주식회사 텔레칩스
Priority date: 2019-12-24
Filing date: 2019-12-24
Publication date: 2021-08-03
Also published as: WO2021132904A1; JP2023510131A; US20230020191A1; KR20210081909A; JP7444994B2; KR102285084B9; DE112020006305T5

Abstract

서로 다른 복수의 중앙 처리 장치를 운용하는 시스템-온-칩(System-On-Chip, SoC) 및 그 동작 방법이 제공된다. 시스템-온-칩(SoC)은 각각의 소프트웨어 프로그램을 서로 독립적으로 실행하는 복수의 중앙 처리 장치(Central Processing Unit, CPU), 상기 복수의 중앙 처리 장치를 연결하는 버스 인터커넥터, 그리고 상기 버스 인터커넥터에 연결되고, 상기 복수의 중앙 처리 장치가 상기 버스 인터커넥터를 통하여 공유하는 물리 자원에 대하여 중앙 처리 장치 별로 각각의 액세스를 제어하는 적어도 하나의 액세스 제어 장치를 포함한다.

Description

이종의 멀티 CPU를 운용하는 시스템-온-칩 및 그 동작 방법{SYSTEM-ON-CHIP FOR OPERATING HETEROGENEOUS MULTIPLE CPU AND METHOD THEREOF}

본 발명은 이종의 멀티 CPU를 운용하는 시스템-온-칩 및 그 동작 방법에 관한 것이다.

단일 시스템-온-칩(System-on-Chip, SoC)상에 다수의 중앙 처리 장치(Central Processing Unit, 이하, 'CPU'로 통칭함)를 지원하는 경우가 증가하고 있다. 이러한 시스템은 동일한 CPU가 여러개 존재하는 대칭형 다중 처리(Symmetric Multi-Processing, SMP)와 다수의 이기종(Heterogeneous) CPU로 구성된 비 대칭형 다중 처리(Asymmetric Multi-Processing, AMP)로 구분된다.

대칭형 다중 처리(SMP)의 경우, 주로 하나의 운영 체제(Operating System, OS)가 시스템-온-칩(SoC) 상의 모든 CPU를 점유하여 각 CPU에 작업을 분산시켜 처리하기 때문에 일반적인 작업에 대해 전반적인 처리 성능을 향상시킬 수 있다.

반면, 비 대칭형 다중 처리(AMP)의 경우, 각각의 CPU가 서로 다른 특정 작업을 전담하여 처리한다. 예를 들어, 특정 CPU에 그래픽 처리(graphic processing)나 디지털 신호 처리(digital signal processing)와 같은 작업을 전담시켜 범용 작업에 사용되는 CPU의 부하를 줄일 수 있다.

하나의 시스템-온-칩(SoC) 상의 다수의 이종 CPU가 서로 다른 특정 작업을 전담하기 위해서는, 각각의 CPU가 독립적으로 운영 체제를 운용할 수 있어야 한다. 이처럼, 하나의 시스템-온-칩(SoC) 상의 다수의 이종 CPU가 각기 독립적으로 운영 체제(OS)를 운용하는 경우, 각각의 운영 체제는 서로 다른 목적을 위해 독립적으로 동작한다. 따라서, 공유 물리 자원 접근에 대한 경쟁 상태(race condition)가 발생할 수 있다.

물리 자원을 공유하는 다중 운영 체제를 운용하는 상황에서 종래에는 가상화 기술을 이용하고 있다.

가상화 기술은 하나의 물리 자원을 다수의 가상의 논리 자원으로 추상화하는 기술로서, 이러한 가상화를 수행하는 소프트웨어를 하이퍼바이저(Hypervisor)라 한다. 하이퍼바이저는 운영 체제보다 높은 물리 자원 접근 권한을 기반으로, 운영체제의 물리 자원 접근을 통제하고 물리 자원을 추상화하여 관리한다. 이를 통해 다수의 운영 체제는 하나의 물리 자원을 경쟁 상태 없이 접근하고 이용할 수 있다.

그러나 운영 체제의 물리 자원 접근을 통제하고 가상의 논리 자원을 관리하기 위해 하이퍼바이저가 소모하는 시간이 발생하며, 하이퍼바이저가 동작하기 위한 메모리 영역 또한 추가로 할당이 필요할 수 있다.

이러한 추가적인 시간 소모는 시스템-온-칩(SoC) 상에 동작하는 다수의 운영체제가 처리하는 작업에 지연 시간으로 작용할 수 있다. 특히, 실시간성을 요구하는 작업의 경우 이러한 지연 시간은 큰 제약 사항으로 작용할 수 있다.

본 발명이 해결하고자 하는 한 과제는 서로 독립적인 소프트웨어 프로그램을 실행하는 이종의 멀티 CPU가 경쟁 상태 없이 물리 자원을 공유하고, 보호가 필요한 물리 자원에 대해서는 다른 CPU의 접근을 차단하는 이종의 멀티 CPU를 운용하는 시스템-온-칩(SoC) 및 그 동작 방법을 제공하는 것이다.

본 발명의 한 실시예에 따르면, 시스템-온-칩(System-On-Chip, SoC)으로서, 각각의 소프트웨어 프로그램을 서로 독립적으로 실행하는 복수의 중앙 처리 장치(Central Processing Unit, CPU), 상기 복수의 중앙 처리 장치를 연결하는 버스 인터커넥터, 그리고 상기 버스 인터커넥터에 연결되고, 상기 복수의 중앙 처리 장치가 상기 버스 인터커넥터를 통하여 공유하는 물리 자원에 대하여 중앙 처리 장치 별 액세스를 제어하는 적어도 하나의 액세스 제어 장치를 포함한다.

상기 적어도 하나의 액세스 제어 장치는, 물리 자원에 대한 공유 요청, 물리 자원에 대한 접근 요청, 중앙 처리 장치의 상태 정보 전달을 포함한 중앙 처리 장치 간 통신 중 적어도 하나를 위한 액세스를 제어할 수 있다.

상기 복수의 중앙 처리 장치는, 제1 버스 인터페이스를 통하여 메모리를 포함한 물리 자원을 공유하는 적어도 두개의 중앙 처리 장치를 포함하고, 상기 공유하는 물리 자원 중에서 상기 적어도 두개의 중앙 처리 장치 간에 배타적으로 사용하는 물리 자원에 대한 액세스를 제어하는 리소스 공유 제어 장치를 더 포함할 수 있다.

상기 적어도 두개의 중앙 처리 장치는, 제1 소프트웨어 프로그램을 실행하는 제1 중앙 처리 장치, 그리고 상기 제1 소프트웨어 프로그램과 다른 제2 소프트웨어 프로그램을 실행하는 제2 중앙 처리 장치를 포함하고, 상기 리소스 공유 제어 장치는, 상기 적어도 두개의 중앙 처리 장치 간에 배타적으로 사용하는 물리 자원 중에서 상기 제1 소프트웨어 프로그램이 로딩되는 메모리 영역을 물리적으로 분리하고, 분리된 메모리 영역에 대하여 상기 제2 중앙 처리 장치의 접근을 차단할 수 있다.

상기 리소스 공유 제어 장치는, 상기 제1 소프트웨어 프로그램 및 상기 제2 소프트웨어 프로그램보다 권한 레벨이 높은 펌웨어를 운용하고, 상기 펌웨어를 통하여 상기 배타적으로 사용하는 물리 자원에 대한 접근을 제어할 수 있다.

상기 복수의 중앙 처리 장치는, 제2 버스 인터페이스를 통하여 정적 램(RAM, Random Access Memory) 및 복수의 디바이스와 연결되고, 제3 소프트웨어 프로그램을 실행하는 제3 중앙 처리 장치를 포함하고, 상기 적어도 하나의 액세스 제어 장치는, 상기 제2 버스 인터페이스와 상기 버스 인터커넥터 사이에 위치하여, 상기 정적 램 및 상기 복수의 디바이스에 대한 다른 중앙 처리 장치들의 액세스를 제어하는 제1 액세스 제어 장치를 포함할 수 있다.

상기 복수의 중앙 처리 장치는, 부트 코드를 포함한 프로그램 코드들이 로딩되는 코드 램 및 유저 데이터가 로딩되는 데이터 램과 제3 버스 인터페이스를 통하여 연결되고, 제4 소프트웨어 프로그램을 실행하는 제4 중앙 처리 장치를 포함하고, 상기 적어도 하나의 액세스 제어 장치는, 상기 제3 버스 인터페이스와 상기 버스 인터커넥터 사이에 위치하여, 상기 코드 램 및 상기 데이터 램에 대한 다른 중앙 처리 장치들의 액세스를 제어하는 제2 액세스 제어 장치를 더 포함할 수 있다.

상기 제1 중앙 처리 장치는, 쿼드 코어를 포함하고, 상기 제2 중앙 처리 장치, 상기 제3 중앙 처리 장치 및 상기 제4 중앙 처리 장치는, 싱글 코어를 포함할 수 있다.

상기 복수의 중앙 처리 장치는, 상기 제3 중앙 처리 장치, 상기 제1 중앙 처리 장치, 상기 제4 중앙 처리 장치 및 상기 제2 중앙 처리 장치의 순서로 단계적으로 부팅된 후, 각각의 소프트웨어 프로그램을 독립적으로 실행할 수 있다.

본 발명의 다른 실시예에 따르면, 단일 시스템-온-칩(System-On-Chip, SoC)에 탑재된 복수의 중앙 처리 장치(Central Processing Unit, CPU)의 동작 방법으로서, 제1 중앙 처리 장치(Central Processing Unit, CPU)에서 상기 시스템-온-칩(SoC)의 부트코드를 실행하는 단계, 그리고 상기 제1 중앙 처리 장치에서 상기 부트코드에 의해 호출되는 1차 부트로더를 실행하는 단계를 포함하고, 상기 1차 부트로더는,상기 제1 중앙 처리 장치의 제1 소프트웨어 프로그램을 실행하고, 제2 중앙 처리 장치에서 실행하는 2차 부트로더를 호출하며, 상기 2차 부트로더는, 상기 제2 중앙 처리 장치의 제2 소프트웨어 프로그램을 실행하는 3차 부트로더를 호출하고, 제3 중앙 처리 장치의 제3 소프트웨어 프로그램을 실행하며, 상기 3차 부트로더는, 제4 중앙 처리 장치의 제4 소프트웨어 프로그램을 실행할 수 있다.

상기 제1 소프트웨어 프로그램은, 운영 체제(Operating System, OS)를 포함하고, 상기 제2 소프트웨어 프로그램은, 리눅스 커널을 포함하며, 상기 제3 소프트웨어 프로그램은, 실시간 운영 체제(RTOS, real-time operating system)를 포함하고, 상기 제4 소프트웨어 프로그램은, 펌웨어를 포함할 수 있다.

상기 2차 부트로더의 제3 소프트웨어 프로그램의 실행은, 상기 제2 중앙 처리 장치와 상기 제3 중앙 처리 장치를 연결하는 버스 인터커넥터에 연결된 제1 액세스 제어 장치가 상기 제2 중앙 처리 장치의 상기 제3 중앙 처리 장치에 대한 접근을 허용한 경우 수행될 수 있다.

상기 3차 부트로더의 제4 운영 체제의 실행은, 상기 제2 중앙 처리 장치와 상기 제4 중앙 처리 장치를 연결하는 버스 인터커넥터에 연결된 제2 액세스 제어 장치가 상기 제2 중앙 처리 장치의 상기 제4 중앙 처리 장치에 대한 접근을 허용한 경우 수행될 수 있다.

본 발명의 실시예에 따르면, 이종의 멀티 CPU를 운용하는 시스템-온-칩(SoC)에서 종래와 같은 가상화 기술을 사용하지 않고도, 각 CPU 간에 경쟁 상태 없이 물리 자원을 공유할 수 있고, 일부 공유 자원에 대한 CPU 접근을 통제할 수 있다. 따라서, 가상화 기술 사용에 따른 추가 지연 시간의 발생이 없을 뿐만 아니라 오버헤드로 인한 성능 저하 문제를 해결할 수 있다.

또한, 실시간 작업 처리를 요구하는 응용에 있어 실시간성을 만족할 수 있는 환경을 제공할 수 있다.

도 1은 본 발명의 실시예에 따른 시스템-온-칩(SoC)의 구성도이다.
도 2는 도 1의 시스템-온-칩(SoC) 상에 두가지 타입의 콘트롤 도메인을 설명하는 도면이다.
도 3은 본 발명의 실시 예에 따른 부팅 순서를 메모리 관점에서 도시한 도면이다.
도 4는 본 발명의 실시 예에 따른 시스템-온-칩(SoC)의 부팅 동작을 설명하는 도면이다.

아래에서는 첨부한 도면을 참고로 하여 본 발명의 실시 예에 대하여 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 발명은 여러가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시 예에 한정되지 않는다. 그리고 도면에서 본 발명을 명확하게 설명하기 위해서 설명과 관계없는 부분은 생략하였으며, 명세서 전체를 통하여 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.

명세서 전체에서, 어떤 부분이 어떤 구성요소를 "포함" 한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다.

또한, 명세서에 기재된 "…부", "…기", "…모듈" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어나 소프트웨어 또는 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다.

본 명세서에서 "전송 또는 제공" 은 직접적인 전송 또는 제공하는 것뿐만 아니라 다른 장치를 통해 또는 우회 경로를 이용하여 간접적으로 전송 또는 제공도 포함할 수 있다.

본 명세서에서 단수로 기재된 표현은 "하나" 또는 "단일" 등의 명시적인 표현을 사용하지 않은 이상, 단수 또는 복수로 해석될 수 있다.

본 명세서에서 도면에 관계없이 동일한 도면 번호는 동일한 구성요소를 지칭하며, "및/또는" 은 언급된 구성 요소들의 각각 및 하나 이상의 모든 조합을 포함한다.

본 명세서에서, 제1, 제2 등과 같이 서수를 포함하는 용어들은 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되지는 않는다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 개시의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다.

본 명세서에서, '부트로더(Bootloader)'는 전자 장치를 부팅하거나 시동 시킬 때 사용자가 전자 장치를 사용할 수 있도록 소프트웨어 프로그램을 특정 저장 매체(예컨대, 외부 기억 장치)로부터 읽어와 주기억장치(예컨대, RAM)에 설치해 주는 프로그램을 말한다.

도 1은 본 발명의 실시 예에 따른 시스템-온-칩(System-On-Chip, SoC)의 구성도이고, 도 2는 도 1의 시스템-온-칩(SoC) 상에 두가지 타입의 콘트롤 도메인을 설명하는 도면이다.

도 1을 참조하면, 단일 시스템-온-칩(SoC)(100)은 4개의 중앙 처리 장치(Central Processing Unit, 이하, 'CPU'로 통칭함)(101, 103, 105, 107)를 포함한다.

시스템-온-칩(SoC)(100)은 CPU_1(101), CPU_2(103), CPU_3(105) 및 CPU_4(107)를 포함한다. 이때, CPU_1(101), CPU_2(103), CPU_3(105) 및 CPU_4(107)은 이종의 CPU들로서, 독립된 작업을 수행하는 각각의 소프트웨어 프로그램을 실행한다.

이때, CPU_1(101)은 시스템 운영 체제(Operating System, OS)를 실행할 수 있다. 시스템 운영 체제는 사용자와의 상호 작용을 포함한 범용 작업을 실행하며, 예를 들어, 안드로이드(Android) 운영체제일 수 있다.

CPU_2(103)는 사용자의 상호 작용 없이 빠른 처리가 필요한 특수 작업을 처리하는 소프트웨어 프로그램을 실행할 수 있다. 예를 들어, CPU_2(103)는 리눅스 커널을 실행할 수 있다.

CPU_3(105)은 실시간 처리가 필요한 작업을 처리하는 소프트웨어 프로그램을 실행할 수 있다. 예를 들어, CPU_3(105)은 실시간 운영 체제(Real Time Operating System, RTOS)를 실행할 수 있다.

CPU_4(107)는 다른 CPU들(101, 103, 105)에 비하여 저 사양 프로세서를 포함할 수 있다. CPU_4(107)는 무결성 검사 등과 같은 암/복호화 작업을 처리하는 보안 펌웨어(Security Firmware)를 실행할 수 있다.

CPU_1(101)은 쿼드(Quard) 코어 프로세서를 포함할 수 있다. CPU_2(103), CPU_3(105) 및 CPU_4(107)는 싱글(Single) 코어 프로세서를 포함할 수 있다.

이처럼, CPU_1(101), CPU_2(103), CPU_3(105) 및 CPU_4(107)가 서로 독립된 소프트웨어 프로그램을 실행함으로써, 예컨대 CPU_1(101)의 소프트웨어 프로그램은 4개의 코어 프로세서를 모두 사용할 수 있게 된다. 특히, CPU_1(101)의 소프트웨어 프로그램이 시스템 운영 체제일 경우, 4개의 코어 프로세서를 모두 점유할 수 있게 되므로, 시스템-온-칩(SoC)(100) 전체의 성능이 향상될 수 있다.

CPU_1(101) 및 CPU_2(103)는 버스(109)를 통해 SDRAM(Synchronous Dynamic Random Access Memory(111), 전용 디바이스(113) 및 복수의 공유 디바이스(115)에 연결된다. 여기서, 전용 디바이스(113) 및 복수의 공유 디바이스(115)는 UART(Universal asynchronous receiver/transmitter), I2C(Inter-Integrated Circuit), GPSB, eMMC(embedded Multi-Media Card) 등을 포함할 수 있다.

이때, CPU_1(101) 및 CPU_2(103)와 버스(109) 사이에는 리소스 공유 제어 장치(117)가 위치한다.

리소스 공유 제어 장치(117)는 CPU_1(101) 및 CPU_2(103)가 공유하는 물리 자원 중에서 배타적으로 사용하는 물리 자원에 대한 액세스를 제어한다.

CPU_3(105)는 버스(119)를 통해 SRAM(Static Random-Access Memory)(121), 전용 디바이스(123) 및 복수의 공유 디바이스(125)에 연결된다. 여기서, 전용 디바이스(123) 및 복수의 공유 디바이스(125)는 UART, ICTC(Input Capture Timer Counter), 직렬 플래시 메모리(Serial Flash Memory), GPSB 등을 포함할 수 있다.

이때, UART, GPSB 등은 공유되지 않는 CPU 전용 자원일 수 있다.

CPU_4(107)는 버스(127)를 통해 코드 램(CODE RAM)(129) 및 데이터 램(DATA RAM)(131)에 연결된다. 코드 램(129) 및 데이터 램(131)은 CPU_4(107)의 소프트웨어 프로그램(ex. 보안 펌웨어)을 로딩한다. 이때, 데이터 램(131)은 공유되지 않고 CPU_4(107)에 의해서만 점유되는 전용 물리 자원일 수 있다. 따라서, 데이터 램(131)으로의 접근은 액세스 제어 장치_2(137)에 의해 차단될 수 있다.

버스들(109, 119, 127)은 버스-인터커넥터(133)를 통해 연결되어 각 버스(109, 119, 127)에 연결된 물리 자원들(111, 115, 121, 125, 129, 131)에 연결된다. 따라서, CPU_1(101), CPU_2(103), CPU_3(105) 및 CPU_4(107)는 물리 자원들(111, 115, 121, 125, 129, 131)을 공유할 수 있다. 예를 들어, CPU_1(101)은 CPU_3(105)의 버스(119)에 연결된 물리 자원(121, 125)에 접근할 수 있다. 여기서, 데이터 램(131)은 액세스 제어 장치_2(137)에 의해 선택적으로 공유될 수 있다.

이때, CPU_1(101) 및 CPU_2(103)는 프로세서를 제외한 모든 물리 자원(111, 113, 115)을 공유한다.

그런데, 이렇게 모든 물리 자원들(111, 115, 121, 125, 129, 131)이 모든 CPU들(101, 103, 105, 107)에 의해 공유되는 경우, 물리 자원들(111, 115, 121, 125, 129, 131)에 대한 접근에 있어 경쟁 상태가 발생할 수 있다. 이러한 경쟁 상태없이 각각의 모든 CPU들(101, 103, 105, 107)이 물리 자원들(111, 115, 121, 125, 129, 131)을 공유하기 위하여 본 발명의 실시 예는 두가지 타입의 콘트롤 도메인(P1, P3)을 정의한다.

도 2를 참조하면, 트러스트존 콘트롤 도메인(Trustzone Contro Domain)(P1)은 리소스 공유 제어 장치(117)에 의해 제어된다.

CPU_1(101) 및 CPU_2(103)는 버스-인터커넥터(133)를 통하지 않고, 메모리를 포함한 모든 물리 자원(111, 113, 115)을 공유한다. 이때, 리소스 공유 제어 장치(117)는 공유되는 물리 자원 중에서 배타적으로 사용해야 하는 물리 자원에 대해서는 물리적으로 구분하여 접근을 차단한다.

리소스 공유 제어 장치(117)는 ARM Trustzone Technology를 이용하여 물리 자원의 사용을 분리한다. 구체적으로 리소스 공유 제어 장치(117)는 ARM Trustzone Techonolgy를 이용하여 운영 체제보다 높은 권한을 가진 펌웨어(firmware)를 리소스 공유 제어 장치(117)를 통해 운용할 수 있다.

리소스 공유 제어 장치(117)는 CPU_1(101) 및 CPU_2(103)가 서로 공유하는 물리 자원 중에서 일부 물리 자원을 CPU_1(101)에게만 배타적인 접근 권한을 설정할 수 있다. CPU_2(103)는 CPU_1(101)에게만 배타적인 접근 권한이 설정된 물리 자원에 대해서는 리소스 공유 제어 장치(117)에 의해 접근이 차단된다.

액세스 컨트롤 도메인(P3)은 버스-인터커넥터(133)에 연결된 액세스 제어 장치_1(135) 및 액세스 제어 장치_2(137)에 의해 제어된다.

액세스 제어 장치_1(135)는 버스(119)와 버스-인터커넥터(133) 사이에 연결된다.

액세스 제어 장치_1(135)는 버스(119)를 통해 연결된 물리 자원(121, 123, 125)에 대한 별도의 접근 권한을 설정한다. 이 접근 권한은 CPU_3(105) 또는 물리 자원(121, 123, 125)에 대한 다른 CPU들(101, 103, 107)의 접근 차단 설정을 포함할 수 있다. 액세스 제어 장치_1(135)는 버스-인터커넥터(133)를 통해 버스(119)로 향하는 트래픽을 차단할 수 있다.

액세스 제어 장치_2(137)는 버스(127)와 버스-인터커넥터(133) 사이에 연결된다.

액세스 제어 장치_2(137)는 버스(127)를 통해 연결된 물리 자원(129, 131)에 대한 별도의 접근 권한을 설정한다. 이 접근 권한은 CPU_4(107) 또는 물리 자원(129, 131)에 대한 다른 CPU들(101, 103, 105)의 접근 차단 설정을 포함할 수 있다.

액세스 제어 장치_2(137)는 버스-인터커넥터(133)를 통해 버스(127)로 향하는 트래픽을 차단할 수 있다.

여기서, 액세스 제어 장치_1(135), 액세스 제어 장치_2(137)에 의해 차단되는 트래픽은 물리 자원의 공유 요청, 물리 자원에 대한 접근 요청, CPU 간 통신 요청 등을 포함할 수 있다.

CPU 간 통신 요청에는 각 CPU들(101, 103, 105, 107)의 비정상 상태 정보들의 전달 요청이 포함될 수 있다. 여기서, 비정상 상태 정보는 리셋(reset), 재시작(restart), 재부팅(reboot), 크래시(crash) 중 적어도 하나를 포함할 수 있다.

이와 같이, 액세스 제어 장치들(135, 137)을 이용하여 CPU_3(105) 또는 CPU_4(107)에 연결된 물리 자원을 공유하거나 보호할 수 있다.

도 1 및 도 2에서 설명한 바와 같이, 본 발명의 실시 예에 따르면, 각각의 CPU(101, 103, 105, 107)가 독립적으로 소프트웨어 프로그램을 실행하며 경쟁 상태 없이 물리 자원을 공유할 수 있다.

이때, 각 CPU(101, 103, 105, 107)를 동작 가능한 상태로 전환하기 위한 부팅 방법에 대해 설명한다. 부팅 순서는 각 CPU(101, 103, 105, 107) 간의 동작 환경과 소프트웨어 프로그램을 운용하는 과정을 포함한다

단일 시스템-온-칩(SoC)(100) 상의 4개의 이종 CPU(101, 103, 105, 107)는 독립적인 소프트웨어 프로그램을 운용하며 각각 다른 목적의 작업을 수행한다. 각 CPU들(101, 103, 105, 107)은 앞서 설명한 바와 같이 자체적인 물리 자원을 소유함과 동시에 이들을 다른 CPU들(101, 103, 105, 107)과 공유하여 사용한다. 따라서, 물리 자원의 초기화가 이루어지는 부팅 단계를 단일화하여 경쟁 상태의 발생 없이 자원을 초기화한다.

도 3은 본 발명의 실시 예에 따른 부팅 순서를 메모리 관점에서 도시한 도면이다.

도 3을 참조하면, 경쟁 상태의 발생 없는 자원 초기화를 하는 부팅 순서를 메모리 사용 관점에서 나타내었다.

시스템-온-칩(SoC)(100)상의 전원이 인가되면, CPU_3(도 1의 105)는 ROM에 저장되어 있는 칩 부트코드(Chipboot ROM Code)를 SRAM(도 1, 2의 121)에 로딩하여 실행한다. 칩 부트코드는 1차 부트로더를 호출하고 CPU_3(105)는 호출된 1차 부트로더를 SRAM(도 1, 2의 121)에 로딩하여 실행한다.

1차 부트로더는 CPU_1(도 1, 2의 101)의 2차 부트로더를 호출한다. CPU_1(101)은 호출된 2차 부트로더를 SRAM(121)에 로딩하여 실행한다. 2차 부트로더는 3차 부트로더를 호출한다.

CPU_1(101)은 호출된 3차 부트로더를 SDRAM(도 1, 2의 111)에 로딩하여 실행한다.

1차 부트로더는 CPU_3(105)의 실시간 운영 체제(RTOS)를 호출하고, 호출된 실시간 운영 체제(RTOS)는 CPU_3(105)의 SNOR(Serial NOR Flash Memory)에 XIP(eXecution In Place)를 이용하여 실행될 수 있다. 여기서, SNOR은 비휘발성 메모리로서, 물리적 특성으로 인해서 SRAM(121), SDRAM(111)과 달리 비휘발성 메모리이다. SNOR은 다른 휘발성 메모리와는 다르게 Byte Access가 가능하므로, 실시간 운영 체제(RTOS)를 SDRAM(111)과 같은 메모리에 로딩하지 않고, 직접 SNOR 상에서 실행할 수 있다.

2차 부트로더는 CPU_4(도 1, 2의 107)의 펌웨어를 호출하고, 호출된 펌웨어는 CPU_4(107)의 코드 램(도 1, 2의 129)에 로딩된다.

3차 부트로더는 CPU_1(101)의 안드로이드 OS와 CPU_2(도 1, 2의 103)의 리눅스 커널을 호출하고, 호출된 안드로이드 OS와 리눅스 커널은 SDRAM(111)에 로딩된다.

이와 같이, 4개의 이종 CPU들(101, 103, 105, 107)은 전원이 인가된 시점에 병렬적으로 동작한다. 이종 CPU들(101, 103, 105, 107)은 CPU_3(105) → CPU_1(101) → CPU_2(103) → CPU_4(107)의 순서로 단계적으로 구동된 후, 각각의 소프트웨어 프로그램을 독립적으로 실행한다.

도 4는 본 발명의 실시예에 따른 시스템-온-칩(SoC)의 부팅 동작을 설명하는 도면이다.

도 4를 참조하면, 시스템-온-칩(SoC)(100)상의 이종 CPU들(101, 103, 105, 107)에 전원이 온(S101)되면, 최초 동작하는 CPU는 CPU_3(도 1, 2의 105)이다.

CPU_3(105)은 초기화(또는 리셋)(S103)후, 롬(ROM)에 미리 탑재된 칩 부트코드(Chipboot ROM Code)를 실행하여 부팅을 위한 기본 작업을 수행한다(S105).

CPU_3(105)은 칩 부트코드에 의해 스토리지 디바이스(115 또는 123 또는 125)로부터 호출된 1차 부트로더를 실행(S107)한다. CPU_3(105)은 1차 부트로더의 실행으로 CPU_3(105)의 소프트웨어 프로그램을 동작시키기 위한 기본 작업을 수행하고, CPU_1(도 1, 2의 101)을 동작시키기 위한 준비를 진행한다. 이러한 준비는 2차 부트로더의 호출 및 CPU_1(101)을 구동시키는 작업을 포함한다.

CPU_3(105)은 CPU_1(101)에게 2차 부트로더의 호출을 전달한다(S109).

CPU_3(105)은 독립적인 운영 체제인 RTOS를 실행한다(S111).

CPU_1(101)은 CPU_3(105)에 의해 호출된 2차 부트로더를 실행한다(S113). 여기서, 2차 부트로더는 ARM Trusted Firmware일 수 있다.

2차 부트로더는 CPU_4(도 1, 2의 107)를 동작시키기 위한 준비를 하고, 3차 부트로더를 호출한다. 즉, CPU_1(101)은 2차 부트로더를 실행하여 CPU_4(107)의 펌웨어 실행을 요청한다(S115).

CPU_1(101)은 2차 부트로더에 의해 호출된 3차 부트로더를 실행(S117)한다.

이와 같이, 2차 부트로더는 부트로더로서의 역할 뿐 아니라, 물리 자원을 여러 독립적인 소프트웨어 프로그램이 안전하게 공유할 수 있도록 보안 펌웨어(secure firmware)로서의 역할도 함께 수행한다. 이를 위해 2차 부트로더는 부팅 단계 이후에도 보안 펌웨어로 수행될 일부 코드를 SDRAM(도 1, 2의 111)에 유지한다.

보안 펌웨어로서의 2차 부트로더는 CPU_1(101) 및 CPU_2(도 1, 2의 103)가 공유하는 물리 자원을 상호 배타적으로 사용할 수 있게 한다. 구체적으로, 2차 부트로더는 CPU_1(101)에서 가장 높은 권한의 실행 모드로 동작된다. 2차 부트로더는 CPU_1(101) 및 CPU_2(103) 각각에서 실행될 소프트웨어 프로그램들의 물리 자원 접근을 제한하여 CPU_1(101) 및 CPU_2(103) 간에 발생할 수 있는 경쟁 상태를 제거한다.

2차 부트로더의 실행으로 CPU_1(101)은 CPU_3(105)과의 종속 관계에서 독립한다. 이로써, CPU_3(105)은 자신을 제외한 나머지 CPU들(101, 103, 107)에 대한 시동과 종료에 대한 권한을 상실한다.

CPU_1(101)의 3차 부트로더는 CPU_2(도 1, 2의 103)의 리눅스 커널을 호출하여 CPU_2(103)를 구동한다(S119). 이어서, CPU_1(101)의 3차 부트로더는 안드로이드 OS를 실행한다(S121).

모든 부팅 절차를 마치면 최종적으로 4개의 이종 CPU들(101, 103, 105, 107)은 각각 다른 목적의 작업을 수행하는 독립된 소프트웨어 프로그램을 운용하게 된다. 따라서, 가상화 기술을 사용하는 종래 기술과 달리 어느 하나의 소프트웨어 프로그램이 전체 CPU를 점유하지 않는다. 따라서, 소프트웨어 프로그램 또는 CPU 상의 비정상이 발생하더라도 가상화 기술을 사용하는 경우와 달리 전체 시스템(100)의 구동없이 일부 문제가 되는 소프트웨어 프로그램 또는 CPU만 재구동하도록 설계할 수 있다.

또한, 디바이스 공유 관점에서, 가상화 기술을 사용하는 경우, 중앙의 제어 프로그램이 디바이스 접근을 제어하므로, 모든 CPU가 이 제어 프로그램을 거쳐야 함에 따른 오버헤드가 발생한다. 따라서, 실시간 작업(Time critical)의 경우, 가상화 기술을 사용할 수 없다. 그러나, 본 발명의 실시예에 따르면, RTOS와 같은 실시간 작업을 수행하는 CPU_3(105)가 전용 디바이스(123)를 독점하여 사용하므로, 별도의 오버헤드 문제가 없다.

이상에서 설명한 본 발명의 실시예는 장치 및 방법을 통해서만 구현이 되는 것은 아니며, 본 발명의 실시예의 구성에 대응하는 기능을 실현하는 프로그램 또는 그 프로그램이 기록된 기록 매체를 통해 구현될 수도 있다.

이상에서 본 발명의 실시예에 대하여 상세하게 설명하였지만 본 발명의 권리범위는 이에 한정되는 것은 아니고 다음의 청구범위에서 정의하고 있는 본 발명의 기본 개념을 이용한 당업자의 여러 변형 및 개량 형태 또한 본 발명의 권리범위에 속하는 것이다.

Claims

시스템-온-칩(System-On-Chip, SoC)으로서,
제1 소프트웨어 프로그램을 독립적으로 실행하는 제1 중앙 처리 장치(Central Processing Unit, CPU),
제2 소프트웨어 프로그램을 독립적으로 실행하는 제2 중앙 처리 장치,
상기 제1 중앙 처리 장치 및 상기 제2 중앙 처리 장치와 연결되는 제1 버스 인터페이스,
제3 소프트웨어 프로그램을 독립적으로 실행하는 제3 중앙 처리 장치,
상기 제3 중앙 처리 장치와 연결되는 제2 버스 인터페이스,
상기 제1 버스 인터페이스 및 상기 제2 버스 인터페이스와 연결되는 버스 인터커넥터, 그리고
상기 제2 버스 인터페이스 및 상기 버스 인터커넥터 사이에 위치하여 상기 제2 버스 인터페이스 및 상기 버스 인터커넥터와 연결되는 제1 액세스 제어 장치를 포함하고,
상기 제1 중앙 처리 장치와 상기 제2 중앙 처리 장치는,
상기 제1 버스 인터페이스를 통해 연결된 물리 자원을 공유하고,
상기 제3 중앙 처리 장치는,
상기 제2 버스 인터페이스를 통하여 메모리 또는 복수의 디바이스와 연결되고,
상기 제1 버스 인터페이스 및 상기 제2 버스 인터페이스는,
물리적으로 서로 분리되어 있고,
상기 제1 액세스 제어 장치는,
상기 제1 중앙 처리 장치 또는 상기 제2 중앙 처리 장치의 상기 메모리 또는 상기 복수의 디바이스에 대한 공유 요청 또는 접근 요청, 그리고 상기 제3 중앙 처리 장치에 대한 상기 제1 중앙 처리 장치 또는 상기 제2 중앙 처리 장치의 통신 요청 중 적어도 하나를 포함하는 액세스 제어를 수행하는, 시스템-온-칩(SoC).
삭제
제1항에서,
상기 제1 중앙 처리 장치, 상기 제2 중앙 처리 장치 및 상기 제1 버스와 연결되어, 상기 제1 중앙 처리 장치 및 상기 제2 중앙 처리 장치 간에 배타적으로 사용하는 물리 자원에 대한 액세스를 제어하는 리소스 공유 제어 장치
를 더 포함하는, 시스템-온-칩(SoC).
제3항에서,
상기 리소스 공유 제어 장치는,
상기 제1 중앙 처리 장치 및 상기 제2 중앙 처리 장치 간에 배타적으로 사용하는 물리 자원 중에서 상기 제1 소프트웨어 프로그램이 로딩되는 메모리 영역을 물리적으로 분리하고, 분리된 메모리 영역에 대하여 상기 제2 중앙 처리 장치의 접근을 차단하는, 시스템-온-칩(SoC).
제4항에서,
상기 리소스 공유 제어 장치는,
상기 제1 소프트웨어 프로그램 및 상기 제2 소프트웨어 프로그램보다 권한 레벨이 높은 펌웨어를 운용하고, 상기 펌웨어를 통하여 상기 배타적으로 사용하는 물리 자원에 대한 접근을 제어하는, 시스템-온-칩(SoC).
삭제
제1항에서,
제4 소프트웨어 프로그램을 실행하는 제4 중앙 처리 장치,
상기 제4 중앙 처리 장치와 연결되는 제3 버스 인터페이스, 그리고
상기 제3 버스 인터페이스 및 및 상기 버스 인터커넥터 사이에 위치하여 상기 제3 버스 인터페이스 및 상기 버스 인터커넥터와 연결되는 제2 액세스 제어 장치를 더 포함하고,
상기 제4 중앙 처리 장치는,
상기 제3 버스 인터페이스를 통하여 부트 코드를 포함한 프로그램 코드들이 로딩되는 코드 램 및 유저 데이터가 로딩되는 데이터 램과 연결되고,
상기 제2 액세스 제어 장치는,
상기 코드 램 및 상기 데이터 램에 대한 다른 중앙 처리 장치들의 공유 요청 또는 접근 요청, 그리고 상기 제4 중앙 처리 장치에 대한 다른 중앙 처리 장치들의 통신 요청 중 적어도 하나를 포함하는 액세스 제어를 수행하는 제2 액세스 제어 장치를 더 포함하고,
상기 다른 중앙 처리 장치들은,
상기 제1 중앙 처리 장치, 상기 제2 중앙 처리 장치 및 상기 제3 중앙 처리 장치 중 적어도 하나를 포함하는, 시스템-온-칩(SoC).
제7항에서,
상기 제1 중앙 처리 장치는, 쿼드 코어를 포함하고,
상기 제2 중앙 처리 장치, 상기 제3 중앙 처리 장치 및 상기 제4 중앙 처리 장치는, 싱글 코어를 포함하는, 시스템-온-칩(SoC).
제7항에서,
상기 복수의 중앙 처리 장치는,
상기 제3 중앙 처리 장치, 상기 제1 중앙 처리 장치, 상기 제4 중앙 처리 장치 및 상기 제2 중앙 처리 장치의 순서로 단계적으로 부팅된 후, 각각의 소프트웨어 프로그램을 독립적으로 실행하는, 시스템-온-칩(SoC).
제7항에서,
상기 제1 중앙 처리 장치는,
상기 시스템-온-칩(SoC)의 부트코드와, 상기 부트코드에 의해 호출되는 1차 부트로더를 실행하고,
상기 1차 부트로더는,
상기 제1 중앙 처리 장치의 제1 소프트웨어 프로그램을 실행하고, 상기 제2 중앙 처리 장치에서 실행하는 2차 부트로더를 호출하며,
상기 2차 부트로더는,
상기 제2 중앙 처리 장치의 제2 소프트웨어 프로그램을 실행하는 3차 부트로더를 호출하고, 상기 제3 중앙 처리 장치의 제3 소프트웨어 프로그램을 실행하며,
상기 3차 부트로더는,
상기 제4 중앙 처리 장치의 제4 소프트웨어 프로그램을 실행하는, 시스템-온-칩(SoC).
제10항에서,
상기 제1 소프트웨어 프로그램은, 운영 체제(Operating System, OS)를 포함하고,
상기 제2 소프트웨어 프로그램은, 리눅스 커널을 포함하며,
상기 제3 소프트웨어 프로그램은, 실시간 운영 체제(RTOS, real-time operating system)를 포함하고,
상기 제4 소프트웨어 프로그램은, 펌웨어를 포함하는, 시스템-온-칩(SoC).
제10항에서,
상기 2차 부트로더의 제3 소프트웨어 프로그램의 실행은,
상기 제1 액세스 제어 장치가 상기 제2 중앙 처리 장치의 상기 제3 중앙 처리 장치에 대한 접근을 허용한 경우 수행되는, 시스템-온-칩(SoC).
제10항에서,
상기 3차 부트로더의 제4 소프트웨어 프로그램의 실행은,
상기 제2 액세스 제어 장치가 상기 제2 중앙 처리 장치의 상기 제4 중앙 처리 장치에 대한 접근을 허용한 경우 수행되는, 시스템-온-칩(SoC).