고속 클록 속도의 자동차용 임베디드 프로세서를 위한 디버그 및 보정 아키텍처 - Technology

고속 클록 속도의 자동차용
임베디드 프로세서를 위한 디버그 및 보정 아키텍처

클록 속도의 증가는 고도로 통합된 시스템 온 칩 마이크로컨트롤러의 디버깅과 보정을 더욱 어렵게 만들 뿐이다. 임베디드 에뮬레이션 디바이스는 소프트웨어 엔지니어에게 마이크로컨트롤러의 내부 작동에 대한 진정한 가시성을 제공하므로, 따라서 시스템 소프트웨어 견고성과 모든 실제 조건에서도 기능이 정확히 작동하도록 보장한다.

글│시몬 브레베톤(Simon Brewerton), 인피니언 자동차 시스템 수석 엔지니어

그래픽 모델 기반 설계에서 C 코드를 생성하는 자동 코드 생성 툴의 이용이 증가하면서 소프트웨어 엔지니어링은 많은 시간의 노력을 절약할 수 있게 되었지만, 동시에 소프트웨어 엔지니어링 문화에 변화가 발생하고 있다.

일반 모듈러 소프트웨어 재사용

소프트웨어 엔지니어는 시스템 요구조건에 맞추어 커스텀 모듈을 작성하는 것보다 기존 모듈을 한데 합쳐 시스템 위에서 구축하고 설계하는 것이 더 효율적이다. 이러한 일반 모듈러 소프트웨어를 재사용할 경우 개발 효율과 소프트웨어 품질이 증대된다. 그러나 이 방법은 저품질 구조, 메모리 비효율, 긴 대기시간으로 이어질 수 있으며, 하드웨어로부터 설계 공정을 추출할 수 있다.
이와 같은 시스템 성능은 기본 소프트웨어를 변경하지 않고도 여러 가지 다른 버전의 기계적 하드웨어에 맞출 수 있다. 일반적으로 이러한 과정은 실시간으로 기능을 인에이블 또는 디스에이블하고, 즉시 이득을 조정하고 룩업 테이블을 변경할 수 있도록 많은 보정 변수를 포함시킴으로써 수행된다.

에뮬레이션 기법

소프트웨어 엔지니어는 에뮬레이션 기법에 의존하여 실제 시스템의 프로그램 흐름을 추적하고 갱신되는 데이터를 감시하며 지연 시간을 측정하고 논리적 문제를 디버깅한다. 그러나, 고속에서 여러 개의 코어를 시스템 온 칩으로 통합하여 구현하는 경우 이러한 시스템을 디버깅할 때 일부 문제를 발생시킨다.
임베디드 비휘발성 메모리 크기가 증가하고 실리콘 공정이 소형화됨에 따라, 캐시가 있는 파이프라인 구조의 프로세서 코어와 코프로세서에 데이터를 전송하는 폭이 넓은 고속 내부 버스가 탑재된 수퍼스칼라 시스템 온 칩 마이크로컨트롤러가 탄생할 수 있었다. 또한 마이크로컨트롤러 서브 시스템을 애플리케이션 환경에 더 깊게 통합할 수 있었다. 이와 같은 깊게 임베디드된 디바이스의 외부 버스 상에 분석 장치를 후킹(Hooking)하는 것은 물리적 연결 문제(외부 버스가 아예 존재하지 않을 가능성도 있다), 빠른 클록 속도, 케이블 길이, 주위 온도 등의 이유로 인해 어려운 문제가 될 수 있다.
많은 경우 외부 버스에서 볼 수 있는 외부 데이터 페치(Fetch)는 내부 캐시와 파이프라인 인출 예측으로 인해 완전한 프로그램 흐름을 나타내지 않는다. 또한 버스트 모드 플래시는 순차적 주소 증분이 예상되기 때문에 인출 디코딩을 더 복잡하게 한다.
에뮬레이션 시스템을 연결할 경우 주요 문제는 높은 시스템 클록 속도로 인해 연결 길이가 제한된다는 점이다. 예를 들어 150MHz 마이크로컨트롤러를 사용하면 50cm 연결에서 전파 지연은 약 2.0ns가 된다. 그러나 클록 주기(Clock Period)는 단지 6.67ns이므로, 2.0ns의 단방향 지연은 매우 큰 의미를 가지며, 이러한 높은 주파수에서는 연결이 전송 라인으로 작동하기 때문에 터미네이션을 보장할 수 없으므로 실제로 타겟 디바이스에서 제어 기능을 원격으로 수행하는 것이 불가능하다. 이 예에서 전송 라인 효과를 무시할 수 있는 최대 길이는 불과 16cm이므로 인 서킷 에뮬레이터는 테스트 하의 ECU와 동일한 환경 요구조건을 갖는다.

인피니언의 TC1796

이와 같은 진정한 "시스템 온 칩" 구현의 예로는 인피니언 TC1796을 들 수 있다. 32비트 TriCore CPU는 코드와 데이터에 대해 별도의 개별 버스를 갖고 있으며, LFI를 통해 시스템 버스에 브리징되므로 주변기기 서브시스템에 데이터 액세스를 할 수 있다. DMA를 통한 추가 브리지는 원격 주변기기 버스에 액세스할 수 있도록 한다. PCP2 (Peripheral Control Processor)는 개별적인 데이터와 프로그램 버스를 갖는 흔히 볼 수 없는 또 다른 32비트 CPU이다. 이 프로세서는 프로세서 서브시스템에 대해 최대 150MHz에서 실행하고, 주변기기 서브시스템에 대해서는 75MHz에서 실행하는 2클록 도메인이 존재한다.
제품은 416핀 볼 그리드 어레이 패키지로 공급되며 디버거 지원을 위한 표준 JTAG 디버그 인터페이스를 제공한다. 그러나, 이와 같은 마이크로컨트롤러에 대해 완벽한 에뮬레이션을 수행하려면 외부 핀과 연결되지 않은 다른 많은 내부 버스 상에서 트랜잭션을 검사할 수 있어야 한다. 대형 임베디드 메모리(2MB 플래시)는 폭이 넓은 내부 인출 경로(128비트)와 로컬 캐시를 가지므로 내부 메모리에서 실행하는 것이 외부 메모리(32비트 액세스)에서 실행하는 것보다 훨씬 빠르다(그림 1).

다중 버스와 다중 코어의 이러한 복잡성은 본드아웃 디바이스(Bondout Device)만 시스템을 완벽하게 디버그하는데 필요한 가시성 수준을 제공할 수 있다는 것을 의미한다. 그러나 앞에서도 설명한 바와 같이 150MHz에서 버스 주기 시간은 불과 6.67ns이므로, 이는 외부 본드아웃 컨트롤러(FPGA)가 버스 정보를 수신하고 디코딩하고, 트리거할 브레이크 타임을 결정하고, 프로세서를 일시 정지(Halt)시키기에는 너무 짧은 시간이다. 이러한 경우를 위해 채택된 솔루션은 본드아웃 디바이스 내부에 에뮬레이터를 임베드하는 방법으로, 따라서 "에뮬레이션 디바이스"(ED)라고 한다(그림 2).

에뮬레이션 디바이스는 모든 일반 기능, 주변기기와 포트가 완전하게 갖추어진 원래 생산 장치의 매크로를 사용하고, 그런 다음 에지 주위에 512Kbyte SRAM, 많은 BOB(Bus Observation Blocks), 에뮬레이터 제어를 위한 일부 로컬 메모리를 탑재한 로컬 CPU(이 경우 또 하나의 PCP2)를 추가한다. 외부 연결은 USB, JTAG, Micro-Link 인터페이스 포트를 포함하여 여러 고속 직렬 인터페이스에 의해 제공된다. 이러한 추가 회로는 EEC(Emulation Extension Chip)라고 하며, 양산 디바이스(Mass Production Device)를 변경할 때 인터커넥션 포인트를 변경하지 않아도 되므로 에뮬레이션 디바이스를 손쉽게 재설계할 수 있도록 한다.
전통적인 본드아웃 디바이스의 또 다른 공통적인 문제는 패키지 크기이다. 이러한 에뮬레이션 디바이스는 생산 장치의 표준 풋프린트에 맞도록 특별히 설계되었으며 추가 신호를 제공하기 위해 별도의 핀 그룹만 추가된다. 또한 패키지 위에 직접 상단 연결(Top Connection)이 추가되므로 착탈식 커넥터에서 동일한 신호를 액세스할 수 있다(그림 3).

에뮬레이션 디바이스는 다음을 포함하여 기존 ICE 시스템에 비해 더 많은 기능을 제공한다.

추적:
- TriCore 프로그램, 데이터 및 상태 추적
- PCP 프로그램, 데이터 및 채널 추적
- 모든 다중 마스터 버스에 대한 완전한 가시성
- 버퍼링된 추적 데이터의 최적화 압축
- 완벽하게 시간 정렬되는 모든 추적
- 중앙 시간 소인 장치(Time Stamp Unit)
- 사전 & 사후 이벤트 추적 버퍼링("로직 분석기")

트리거 로직:
- 트리거는 브레이크(Break), 추적 검증 및 추적 시작/중지를 위해 사용할 수 있다.
- 명령 포인터와 데이터 주소를 위한 범위 비교기
- 데이터를 위한 마스크 품질/범위 비교기
- 추가 외부 이벤트 입력(2) 및 출력(4)
- 이벤트 카운팅과 시간 측정을 위한 카운터와 이를 기초로 한 이벤트 생성
- 모든 코어를 동시에 그리고 선택적으로 시작하고 중지시킬 수 있는 중앙 메커니즘

에뮬레이션 디바이스는 또한 모든 종류의 리셋(파워 온 리셋 제외)을 통해 디버그 또는 보정할 수 있는 특수한 리셋 모드를 제공한다(그림 4). EEC에는 512Kbyte SRAM이 제공되는데, 이는 여러 가지 다른 작업에 자유롭게 할당할 수 있는 다수의 구성 가능한 타일로부터 구축된다. 따라서 단일 장치에서 다양한 애플리케이션 용도를 처리할 수 있다.

- 로직 분석기 모드: SRAM은(압축 알고리즘과 함께) 프로그램과 모든 내부 버스와 두 코어 모두에서 데이터 흐름을 추적하는데 사용된다.
- 소프트웨어 개발 모드: SRAM은 변경을 수행할 때마다 플래시 버닝을 방지하고 무제한의 소프트웨어 기반 정지점을 허용하기 위해 프로그램 코드를 저장하는데 사용된다.
- 보정 오버레이: SRAM은 원하는 보정 상수를 임시로 복사해 저장하는데 사용된다. 액세스가 발생하면 오버레이 하드웨어는 내부 플래시에서 EEC SRAM으로 인출을 리다이렉트한다. 외부 보정 툴은 USB 또는 JATG 인터페이스를 통해 이러한 SRAM 타일을 읽고 쓸 수 있으므로, 빠르고 유연한 접근이 가능하다.
- 신속한 프로토타이핑: SRAM은 외부의 신속한 프로토타이핑 하드웨어와 마이크로컨트롤러 사이의 메시지 버퍼로 사용된다. 대기시간 요건(3ms 미만)으로 인하여 USB는 이러한 작업에 적합하지 않으므로, Micro Link 인터페이스 또는 JTAG를 대신 사용할 수 있다(대기시간~2μs, 대역폭~3MByte/s).
- 비행 기록장치: SRAM은 시스템의 사용 데이터를 기록하는데 사용되거나 또는 특정한 오류가 발생할 경우 이를 중심으로 시스템 상태를 추적하기 위해 설치할 수 있다.

에뮬레이션 디바이스는 호스트 PC에 의해 실시간으로 구성되고, 다양한 소프트웨어 툴이 공통 표준을 기반으로 상호운용성을 갖도록 이러한 인터페이스가 정의된다. NEXUS 병렬 버스 기반 추적 포트는 여기에 직접 적용할 수 없으므로, 대신 이로부터 소프트웨어 API를 재사용해 왔다. 에뮬레이션 개념에 대한 소프트웨어 지원은 DAS(De-vice Access Server)를 제공한다. 이러한 인터페이스를 통해 여러 개의 툴 인스턴스를 PC에 호스트 할 수 있으므로 임베디드 호스트(USB, JTAG)에 대한 단일 통신 경로를 공유할 수 있다.
또한 DAS는 임베디드 호스트 내부에서 여러 개의 프로세서 인스턴스를 연결할 수 있도록 하므로, 향후에 대형 시스템 온 칩 디바이스도 액세스할 수 있다. 이 밖에도, DAS는 XCP 프로토콜 표준을 지원하므로 실제 물리적 연결 매체(CAN, FlexRay, USB, JTAG)와 상관 없이 보정과 로깅 툴을 연결할 수 있다.
클록 속도의 증가는 고도로 통합된 시스템 온 칩 마이크로컨트롤러의 디버깅과 보정을 더욱 어렵게 만들 뿐이다. 임베디드 에뮬레이션 디바이스는 소프트웨어 엔지니어에게 마이크로컨트롤러의 내부 작동에 대한 진정한 가시성을 제공하므로, 따라서 시스템 소프트웨어 견고성과 모든 실제 조건에서도 기능이 정확히 작동하도록 보장한다.

<자료제공: 월간 반도체네트워크 2006년 09월호>