멀티코어를 활용한 개발은 여러 가지 SW의 기능을 각각의 코어에 분산 처리해 시스템 성능을 향상시킬 수 있다. 멀티코어 아키텍처의 종류와 개발 시 고려사항에 대해 알아보고, 멀티코어 환경에서 CPU 로드를 측정하기 위해 HW와 SW를 이용하는 두 가지 방법을 제시한다.

최근 자동차 개발 방식은 기계식으로 작동하던 기능이나 새로운 기능을 전자식으로 바꾸는 이른바 ‘전장화’로 빠르게 전환되고 있다. 이로 인해 차량 제어를 위한 ECU 수가 증가하고 SW의 비중이 커지면서 복잡도 역시 증가하고 있다. 그 결과 성능이나 안정성 이슈가 많아져 이러한 요구사항들을 만족시키기 위해 자동차 기능안전성 국제표준인 ISO 26262가 도입됐다.

ISO 26262 Part 6에서는 제품 안정성을 향상시키기 위한 SW 개발 프로세스를 제안한다. 특히 6.4.1 항목에서는 SW 안전 요구사항에 Time Critical Operation에 대해 관리하도록 하고 있는데, 이러한 요구사항을 만족시키려면 싱글코어의 연산처리 속도로는 부족할 수 있다. 따라서 최근 출시된 Infineon 사의 오릭스(AURIX)나 Freescale 사의 MPC57xx 계열의 CPU들은 많게는 7~9개의 코어를 제공하고 있다. 또한 AUTOSAR Release 4.0부터는 멀티코어에 대한 내용이 추가됐다.

멀티코어 아키텍처 종류

멀티코어는 동일 코어로 구성된 대칭형 멀티프로세싱(SMP)과 서로 다른 코어로 구성된 비대칭형 멀티프로세싱(AMP)으로 구분된다. 하지만 차량용 시스템에서는 위 개념보다는 주로 LSM(Lock Step Mode)과 DPM(Decoupled Parallel Mode)으로 구분한다.

LSM 아키텍처는 두 개 이상의 코어가 동일한 SW를 실행해 각각의 결과를 비교한다. 만약 동일한 결과가 나오지 않을 경우, 미리 정의돼 있는 에러 처리를 해 안정성에 대한 검증이 가능하다. DPM 아키텍처는 각 코어가 독립적으로 다른 SW를 실행해 요구되는 성능들을 만족시킨다.

멀티코어 개발 시 고려사항

멀티코어 코드를 작성하기 위해서는 단일 코어와는 다른 접근방법이 필요하다. 예를 들면, 코어별로 독립된 전역 변수나 프로그램 스택과 같은 메모리를 갖기 때문에 Startup 코드와 메인 함수가 따로 존재한다. 그러나 메모리 초기화와 같은 시스템 초기화는 메인 코어에서 진행되고 코드는 기능에 따라 코어별로 분리돼 작성된다. 기능에 대한 분리는 주로 서브 코어(sub core)에 어떤 작업을 할당할 것인가의 문제인데 다양한 방법으로 접근이 가능하다. 예를 들면, 연산 중심의 기능을 제공하거나 기능 자체를 분리하고 수행해 메인 코어의 로드(load)를 분산시킬 수 있다.

하지만 멀티코어를 사용한다고 해서 무조건적으로 SW의 성능이나 속도를 향상시킬 수 있는 것은 아니다. 예를 들어, 서브 코어의 부하가 심할 경우에는 메인 코어에 연산 결과를 전달하는데 시간이 더 오래 걸릴 수 있다. 즉 SW의 성능이나 속도를 향상시키기 위해서는 각 코어에 처리해야 하는 작업들을 적절히 잘 분배하는 것이 중요하다.

MPU의 TRACE 기능을 이용한 측정

CPU 로드를 측정하기 위한 하드웨어적인 방법으로는 MCU가 제공하는 TRACE Logic과 인터페이스를 이용하면 된다. 이는 MCU 계열마다 다른 이름(NEXUS, OCDS, HSSTP, ETM 등)을 가지고 있지만 동일한 TRACE 기능을 제공한다. 이러한 인터페이스를 활용하면 타깃의 정지 없이 코드의 흐름을 관찰할 수 있다. 이는 샘플링(sampling) 방식이 아니라 수행된 결과가 모두 저장되기 때문에 정확한 CPU 로드를 측정할 수 있다.

그렇다면 실제로 멀티코어가 적용된 환경에서 CPU 로드를 측정하는 방법을 알아보자. 타깃을 동작시키면 TRACE Logic을 통해 수행된 정보가 Trace Buffer에 실시간으로 저장된다. 이 때 OS에서 수행되고 있는 TASK가 없을 경우 Idle TASK가 수행된다. 각 코어의 Idle TASK가 수행된 시간을 측정해 보면 코어의 사용량을 분석할 수 있다. 예를 들어, 메인 코어의 Idle Task 수행 시간이 서브 코어보다 적을 경우 메인 코어의 사용량이 더 많다는 것을 파악할 수 있다.




그림 3은 GliwOS를 이용한 멀티코어 환경에서 Lauterbach 사의 PowerTrace 툴을 이용해 측정한 결과이다. GliwOS에서는 OS의 idle 상태를 위한 코어별 idle Task를 제공한다. 메인 코어의 경우 ‘core0BackgroundTask’라는 이름을 갖고 있으며, 서브 코어는 ‘core1Back groundTask’라는 이름을 갖고 있다. 각 Task는 TBM_RunNextBenchmark와 T1_AppBg Handler를 참조하고 있어서, 총 Idle 시간은 “core0BackgroundTask의 수행 시간 + TBM_RunNextBenchmark 수행 시간 + T1_AppBgHandler의 수행시간”이 된다.

아래의 예를 들면, 메인 코어의 코어 사용률은 총 성능(100%) - Idle의 점유율(3.463% + 6.915% + 12.672%) = 76.95%가 된다. 서브 코어의 사용률은 총 성능(100%) - Idle의 점유율(7.595% + 11.712% + 22.110%) = 58.583%가 된다. 따라서 현재 SW는 메인 코어에 더 많은 작업을 수행하고 있다.

SW 방식을 이용한 측정

TRACE Logic을 활용하는 경우의 장점은 SW 변경 없이 정확한 성능을 측정할 수 있는 점이다. 하지만, 물리적인 Trace Interface가 필요하다. 일반적으로 JTAG 인터페이스에 비해서 적게는 10 pin 많게는 40~50 pin이 추가로 필요하다. 이미 제작된 또는 양산된 ECU의 경우, MCU로부터 이 인터페이스를 확보하기란 매우 어려운 문제이다. 그리고 실차 테스트의 경우에는 이 인터페이스가 제공되더라도 활용하기 어려운 것이 사실이다.

이에 반해 SW 성능 측정은 Code Instrumentation 방법을 이용하는 것이다. 일반적으로 GPIO 토글을 통해 오실로스코프로 측정하는 방법과 유사하다. 이 방법은 각 함수/Task별 수행 시간을 모두 측정할 수 있는 장점을 제공하지만, 코드 크기만큼 코드 사이즈도 증가하는 단점이 있다. 또한 각 코어별로 Code Instrumentation이 독립적으로 이뤄져야 하며, 만일 공용으로 사용하는 함수/Task의 경우, 추가되는 코드가 이를 구분할 수 있도록 작성돼야 한다.


이는 성능 측정을 하기 위해 추가된 코드가 오히려 코드를 복잡하게 만들고, 심지어 CPU 점유율이 굉장히 높아지는 문제를 유발한다. 경우에 따라서는 실행 코드가 15%~20%정도 커지고 CPU 점유율도 동일한 크기로 증가하는 현상이 발생한다. 그래서 최근 유럽 차량용 SW 개발업체들은 Scheduler에 Code Instrumentation하는 방법을 그 대안으로 적용하고 있다.

이 방법을 활용하면 SW에 추가되는 코드양을 최소화 할 수 있다. 실제 적용 사례로 CPU 점유율을 0.2% 이내의 최소 로드로 원하는 성능을 측정할 수 있다. 그리고 다중 코어의 경우, 중복 사용되는 함수/Task의 구분 문제도 Scheduler 내부에서 정보를 습득해 출력하기 때문에 매우 정확한 정보 수집이 가능할 뿐만 아니라 코드 변경도 최소화할 수 있다. 그림 4는 이 방법을 적용한 GLIWA T1을 활용해 측정된 결과다.

정확한 수행 정보를 통한 측정

TRACELogic을 이용하는 툴은 디버깅에 특화된 제품이다. 그러나 CPU 로드의 다양한 분석 기능이나 문서화 기능은 제공하지 않는다. 이 기능을 위해서는 별도의 리포트 기능을 제공하는 타이밍 분석 툴과 연동해야 한다. 예를 들어, 타깃이 수행한 정보는 Trace Buffer에 저장되고, 그 내용은 코드 흐름과 시간 정보가 포함돼 있어 여러 가지 형태로 변환할 수 있다.

보통 CSV(Comma Separated Value) 포맷을 가장 많이 활용하는데, CSV 포맷의 파일을 Export 하면 타이밍 분석 툴에 Import 하는 것이 가능하다. 이를 통해 정확한 CPU 로드 분석과 문서화가 가능하다.

다양한 연산을 위해 계속 증가하고 있는 데이터량을 싱글에서만 처리하기에는 분명 한계가 존재한다. 그 해결방안으로 멀티코어를 사용해 데이터를 각 코어에 분산해 연산 효율을 높일 수 있다. 하지만 암달의 법칙(Amdahl's Law)에서 말하는 바와 같이 프로세서 수가 늘어나는 만큼 성능이 비례해 향상되지는 않는다. 즉 멀티코어를 사용하더라도 반드시 각각의 코어에 일을 잘 분산시키는 것이 매우 중요하다. 앞으로 멀티코어 개발은 신뢰성과 성능 향상을 위해 거의 필수가 될 것이다. 이 경우 SW의 최적화 과정에서 타이밍 측정은 필수 작업이 된다.

타이밍 측정 방법은 앞서 언급한 바와 같이 환경에 따라 다양한 방법을 구성할 수 있다. SW를 이용한 측정은 실차 테스트에 용이하며, 현재 사용중인 하드웨어를 변경 없이 바로 적용할 수 있다. MCU의 TRACE Logic을 이용하면 SW 변경 없이 원하는 성능을 바로 측정할 수 있을 뿐만 아니라, CPU에 전혀 로드가 발생하지 않는 장점이 있다.

어떤 방법이 더 효과적이라고 단언할 수는 없다. 각 적용 방법은 개발 환경과 목적에 따라 장점이 발휘되기 때문이다. 즉 개발환경을 정확히 파악한 후 각각의 장점이 충분히 발휘될 수 있는 적용 방법을 선택하는 것이 중요하다. 

AEM_Automotive Electronics Magazine