AHB-AP (Advanced High-performance Bus Access Port)는 ARM의 CoreSight 디버깅 아키텍처에서 중요한 구성 요소로, AHB(Advanced High-performance Bus) 버스에 대한 액세스를 제공하는 디버그 포트입니다. AHB-AP는 디버거가 타겟 시스템의 AHB 버스를 통해 메모리 및 주변 장치에 접근할 수 있도록 해줍니다.
### 주요 기능
1. **메모리 접근**: - 디버거가 AHB 버스에 연결된 메모리와 주변 장치에 직접 읽기/쓰기 접근을 할 수 있게 합니다. - 메모리 덤프, 설정 레지스터 변경, 펌웨어 업로드 등의 작업을 지원합니다.
2. **디버깅 제어**: - AHB-AP를 통해 CPU 레지스터와 상태를 읽고 쓸 수 있습니다. - 브레이크포인트 설정, 단일 스텝 실행 등 디버깅 작업을 제어할 수 있습니다.
3. **멀티 레이어 버스 지원**: - AHB 버스가 멀티 레이어 구조일 경우, 디버거가 여러 마스터와 슬레이브 장치에 접근할 수 있게 해줍니다.
### AHB-AP 구성
AHB-AP는 다음과 같은 레지스터 집합을 포함합니다: - **Control/Status 레지스터**: AHB-AP의 상태와 제어를 위한 레지스터. - **Transfer Address 레지스터**: AHB 버스에서 읽기/쓰기 작업을 수행할 주소를 지정하는 레지스터. - **Data Read/Write 레지스터**: AHB 버스를 통해 데이터를 읽고 쓰기 위한 레지스터.
### 예제 사용 시나리오
1. **펌웨어 업로드**: - 디버거가 AHB-AP를 통해 타겟 MCU의 플래시 메모리에 새로운 펌웨어를 업로드합니다.
2. **레지스터 접근**: - 디버거가 AHB-AP를 사용하여 타겟 MCU의 특정 주변 장치 레지스터를 읽거나 설정합니다.
3. **메모리 덤프**: - 디버거가 AHB-AP를 통해 전체 메모리 공간을 덤프하여 분석합니다.
### 요약
AHB-AP는 ARM CoreSight 디버깅 아키텍처에서 중요한 역할을 하며, 디버거가 AHB 버스를 통해 타겟 시스템의 메모리와 주변 장치에 접근할 수 있도록 해줍니다. 이를 통해 개발자는 효율적으로 시스템을 디버깅하고 제어할 수 있습니다.
장점 : 기존 Debug logic의 경우 debugger가 메모리에 접근하기 위해서는 반드시 프로세서와 디버그 인터페이스가 형성된 상황에서 debug logic을 통해 프로세서가 바라보고 있는 메모리만을 바라볼 수 있었지만 CoreSight가 채용된 SoC의 경우 Debugger는AHP-AP를 거쳐 AHB bus를 통해 바로 메모리 접근이 가능하다.
사례1 : Debugger interface가 불가능한 문제 발생시 기존의 방식으로는 아무것도 못했으나 CoreSight 환경의 debugger는 DAP와 인터페이스하고 AHP-AP 거쳐 실시간 메모리 값 Access 가능 --> 이를 통해 문제의 원인이 logic 자체 설정으로 인한 것인지 어떤 원인으로 인해 debug bus가 잡혀 있기 때문에 debugger에서 접근할 수 없는 것인지 등을 유추할 수 있다.
사례2: 보안성 등의 이유로 특정 비트 값에 따라 디버그 권한을 설정하는 경우가 있는데 (JTAG Secure Write) 먼저 AHB-AP를 통하여 Memory Write 하여 Debugger 사용 할수 있게 한다. AHB-AP 를 통한 Memory Access자체를 막은 경우에는 불가능하다.
사례3: Cache data의 반영 여부를 확인하는것. cache flush 했으나 memory 반영이 되지 않은거 같은 상황에서 cache 동작확인이 필요할 때 AHB-AP를 통해 접근한 덤프창과 일반적인 덤프 창을 비교해 보면 Cache flush가 정상적으로 이루어졌는지 알 수 있다. (덤프는 MMU나 cache를 거치는것) AHP-AP는 시스템버스를 이용해 Memory Access 하기 떄문에 MMU나 cache를 거치지 않은 순수한 물리 메모리 값을 볼 수 있기 때문이다.
TRACE32의 경우 덤프 창을 열 때 메모리 클래스를 지정해주는 것으로 메모리 접근 경로를 지정할 수 있으며 아래 화면을 참고(AZSD, ASD 에 대해서는 TRACE32 Memory Access 참고) ASD 통한 메모리 접근과 AHB-AP를 통한 메모리 접근
*참고 : 경우에 따라 OS 부팅 중 AHB Bus 통한 접근을 막는 경우가 있는데, 이때 AHP-AP 통한 접근시 에러발생
단점 : AHP-AP를 통해 직접 Memory Access 하는 경우 프로세서와 Debug logic을 통하여 Memory를 보는게 아니기 떄문에 breakpoint 등 디버그 기능은 사용할 수 없다.
APB-AP APB-AP 내용은 TRACE32 Memory Access를 모르면 이해하기가 어렵다. "APB를 접근하는 포트다"라고만 알고 다른 포스팅을 한번 보고 다시 와서 보면 이해가 갈거 같다. (아직 포스팅을 안함)
APB를 통해 프로세서, 코프로세서 및 기타 페리에 접근하는 것으로 설계 시 보통 포트번호는 1번을 할당
일반적인 Debug interface 및 debugging을 위한 동작은 APB-AP를 거치게 되며 Debugger가 메모리를 바라보는 시점은 프로세서와 동일하기 때문에 특별한 메모리 클래스 지정 없이 Data.list 나 Data.dump 창등을 열어보면 MMU 및 Cache data가 반영된 값을 보게 된다.
일반적인 debug interface가 이루어지고 debug 기능을 한다는 면에서는 특이점이 없지만, 메모리 주소 지정 시 한가지 특이점이 있다. -->APB-AP를 통해 CoreSight의 각 로직에 접근하는 경우 마치 MMU의 가상메모리 주소와 같이 별도의 주소가 할당되어 있다는 것이다.
많이 사용되는 0x800X_XXXX번지 대에 CoreSight 각 logic 들의 base address가 할당되어 있는데, 이는 APB-AP를 통하는 경우의 주소대이며, 실제 CPU가 인식하는 주소로는 0x108X_XXXX번지대가 할당되어 있다.
때문에 Base Address를 지정해 줄 때에는 정확한 메모리 클래스를 지정해 주어야 하며, (-->???)일반적인 debug 동작은 APB-AP를 통해 접근하는 주소대와 실제 CPU가 인식하는 주소인 AHP-AP를 통한 덤프창을 확인해보자 아래는 TPIU의 베이스 어드레스 부분을 확인한 것이다. APB-AP를 통한 디버그 리소스 접근과 AHB-AP를 통한 디버그 리소스 접근
이와 같이 메모리 클래스를 지정하여 Data.List 창이나 Data.dump 창을 열어볼 때에는 메모리 클래스 지정에 주의해야 한다. 같은 주소를 준다 해도 같이 지정되는 메모리클래스에 따라 완전 다른 값과 의도와 다른 값을 보여줄 수 있고, MMU페이지 설정에 따라 해당 영역에 접근할 수 없기 때문에 물음표로 가득한 창을 볼 수도 있기 때문이다. TRACE32의 경우 흔히 사용되는 메모리 클래스와 의미는 다음과 같다.
SD: MMU가 활성화되어 있을 때, 가상메모리 기준으로 메모리를 볼 때. ASD: SD와 동일하지만 지정되는 주소는 물리메모리 기준. ANC: 물리메모리 기준 주소를 지정하고 캐쉬값이 반영되지 않은 순수한 물리메모리값을 보고자 할 때 사용. SR: 램으로 바이너리 다운로드 시, 데이터캐쉬를 통과하지 않고 값을 쓰고자 할 때. AHB: AHB버스를 통해 직접 메모리에 접근하고자 할 때 사용. 보통 ANC와 같은 결과값을 볼 수 있다. E: Run-time으로 메모리 접근을 하고자 할 때 사용. JTAG을 이용한 디버깅은 보통 반드시 타깃을 세워야 메모리/레지스터 값을 볼 수 있지만 Core Sight가 적용된 프로세서인 경우, AHB-AP혹은 APB-AP를 통해 메모리에 직접 접근할 수 있기 때문에 프로세서 동작 시에도 메모리 값의 변화를 볼 수 있다. DMA 등을 통해 메모리 변화가 있는지 확인하고자 할 때 유용하며, 다만 이 때에는 디버그 로직을 거치지 않고 바로 버스를 경유해 메모리를 보는 것이기 때문에 브레이크포인트 등의 디버그 기능은 이용할 수 없다. 이 부분도 다른 포스팅에서 연계해서 다시 정리해야겠다.
JTAG-AP : SoC 내부의 다른 디버깅 포트에 액세스하는 역할을 함. 다른 JTAG 장치와의 연결을 통해 디버깅 인터페이스 확장 가능
JTAG-AP는 ARM9/11 등 기존의 ARM 코어를 사용할 때 이를 APB-AP 뒤에 놓지 않고?? 그대로 TAP 컨트롤러만 연결하고자 할 때 사용되는 액세스 포인트이며 설계 시 주로 포트 번호는 2번을 할당한다. 역시 CoreSight의 기본 개념과 같이 병렬로 연결하게 되어 있으며 일반적인 경우 포트번호 0번부터 7번까지 8개의 구형 ARM 코어의 연결을 지원한다. 이를 제외한 다른 특이점은 없으며, 로직의 구성 측면에서 보았을 때 일반적인 데이지 연결과 비교해보면 일장일단이 존재한다. JTAG-AP
JTAG-AP 구성 시 CoreSight DAP를 통한 연결 시의 장점 그대로 병렬 연결이기 때문에 JTAG-AP 뒤에 연결된 각 코어의 전원/클럭 차단에 의한 디버그 인터페이스 끊김이 다른 코어의 디버그 인터페이스에 영향을 주지 않는다는 것이다. 하지만 디버거와 코어 사이에 DAP와 JTAG-AP라는 과정을 더 거쳐야 하고 디버그 신호의 변환이 필요하기 때문에 데이지 체인과 비교해 6배에서 10배 가량 느린 속도를 보인다. ARM9/11은 비교적 느린 클럭으로 동작하기 때문에 별 다른 문제는 되지 않겠으나 좀 더 빠른 동기 제어가 필요한 경우라면 로직 디자인 시 각 코어들을 JTAG-AP와 연결하지 않고 DAP와의 데이지 체인 형식으로 구성하는 것이 좋을 수 있다.
지금까지 CoreSight의 여러 로직 중 디버거와 직접 인터페이스를 하는 DAP와 DAP 내부 로직에 대해 알아보았다.
JTAG-AP (JTAG Access Port)는 Arm® Cortex® 코어에 내장된 디버깅 기능으로,JTAG 인터페이스를 통해 코어 레지스터, 메모리 및 디버깅 이벤트에 접근하고 제어할 수 있도록 합니다.
JTAG-AP는 ARM Debug Interface v5 아키텍처를 기반으로 하며, 다음과 같은 주요 기능을 제공합니다.
코어 레지스터 읽기/쓰기: JTAG-AP를 사용하여 코어 레지스터의 값을 읽거나 쓰고, 코어의 작동 상태를 제어할 수 있습니다.
메모리 읽기/쓰기: JTAG-AP를 사용하여 메모리에 데이터를 읽거나 쓰고, 디버깅 과정에서 메모리 내용을 검사할 수 있습니다.
디버깅 이벤트 트리거 및 제어: JTAG-AP를 사용하여 브레이크포인트를 설정하고, 단계별 실행, 하드웨어 트리거 등 다양한 디버깅 기능을 제어할 수 있습니다.
JTAG-AP는 다음과 같은 장점을 제공합니다.
비침투성 디버깅: JTAG-AP를 사용하면 코어를 물리적으로 수정하지 않고도 디버깅할 수 있습니다.
강력한 디버깅 기능: JTAG-AP는 코어 레지스터, 메모리 및 디버깅 이벤트에 대한 광범위한 제어 기능을 제공합니다.
표준화된 인터페이스: JTAG-AP는 ARM Debug Interface v5 아키텍처를 기반으로 하며, 다양한 디버깅 도구와 호환됩니다.
JTAG-AP는 다음과 같은 단점도 가지고 있습니다.
복잡성: JTAG-AP는 다른 디버깅 방법에 비해 복잡할 수 있으며, JTAG 인터페이스 및 ARM Debug Interface v5 아키텍처에 대한 이해가 필요합니다.
성능 저하: JTAG-AP를 사용하면 디버깅 과정에서 성능 저하가 발생할 수 있습니다.
JTAG-AP는 다양한 디버깅 도구에서 지원됩니다. 대표적인 도구로는 다음과 같은 것들이 있습니다.
** Lauterbach TRACE32**
** Segger J-Link**
** STMicroelectronics ST-Link**
JTAG-AP는 Arm® Cortex® 코어를 디버깅하는 데 사용되는 강력하고 유용한 기능입니다. JTAG-AP를 사용하면 코어 레지스터, 메모리 및 디버깅 이벤트에 대한 광범위한 제어 기능을 제공하며, 비침투성 디버깅을 가능하게 합니다. 하지만 JTAG-AP는 복잡할 수 있으며, 성능 저하가 발생할 수 있다는 단점도 가지고 있습니다.
4. CTI / CTM : Cross Trigger Interface / Matrix
CoreSight 는 멀티코어 환경에서의 Real-time debugging을 내세우고 있다.
CTI/CTM 은 멀티코어의 동기제어를 담당한다.
CTI : 멀티코어 SoC를 구성하는 각 코어는 CTI와 연결되어 있고, 자신이 연결된 코어에서 발생한 디버그 이벤트를 CTM으로 전달하는 역할을 한다.
CTM : CTI에서 발생한 디버그 이벤트를 시스템 전체의 코어에 전달하는 다리 역할을 한다. 이를 통해 go/break/step 등으로 인해 하나의 코어 상태가 변할 때 시스템의 모든 코어가 같은 동작을 할 수 있다.
디버거 사용시 CTI를 통해 동기 제어 기능을 이용하려면 여차 CoreSight 로직과 마찬가지로 CTI의 베이스 어드레스를 지정해 줘야 한다.
실제 이벤트는 CTI에서 발생하고 CTM은 연결고리 역할만을 하기 때문에 디버거 설정 시 CTM은 고려하지 않아도 된다.
CoreSight 설정 화면으로 CTM에 관한 사항은 없는걸 볼 수 있다.
CTI 를 통한 동기 제어의 장점 (데이지 체인 방식에 비해)은 속도이다. 데이지 체인 구성시 각 코어간의 동기제어는 HW가 아닌 TRACE32 SW에 의해 이루어진다. e.g.) CORE0 에서 디버그 이벤트 발생 -> CORE0에 연결된 TRACE32 SW에서 이를 감지 -> CORE1에 연결된 SW에 이를 전달-> CORE1에 이벤트가 전달되고 CORE0과 같은 상태로 진입
전체적인 흐름은 CTI를 사용할 떄와 동일하지만 이 과정이 SoC 내부에서 이루어지느냐 외부에서 이루어지느냐의 차이이며 이 차이는 코어 간의 상태 동기화에 상당한 시간차를 발생시킨다.
5. ETM : Embedded Trace Macrocell
CoreSight에서 프로세서가 수행하는 명령어에 대한 트레이스 정보를 출력하는 역할을 한다.
CTI와 마찬가지로 각 코어에 바로 연결되어 프로그램의 수행 정보를 트레이스 버스(ATB)를 거쳐 외부로 출력 한다.
프로세서가 정지해야 정보를 볼 수 있는 JTAG과는 달리 ETM은 프로세서의 모든 동작을 담아내는 형태이기 때문에 실시간성이 보장되어야 하는 환경에서 디버깅 및 성능분석을 위한 정보를 제공해 줄 수 있다.
이를 통해 특정 변수가 변경되거나 특정 메모리 주소에 접근할 때 이를 감지할 수 있습니다.
데이터 트레이스 (Data Trace):
메모리 접근 이벤트를 실시간으로 기록하고, 이를 트레이스 데이터로 전송합니다.
읽기 또는 쓰기 접근 시 데이터를 캡처하여 후속 분석을 위해 저장할 수 있습니다.
사이클 카운터 (Cycle Counting):
CPU 사이클을 카운트하여 성능 분석을 지원합니다.
코드의 실행 시간을 측정하거나 특정 이벤트 간의 사이클 수를 계산할 수 있습니다.
이벤트 카운터 (Event Counters):
특정 이벤트(예: 명령어 실행, 분기 발생, CPU 예외 등)를 카운트하여 성능 분석에 활용합니다.
다양한 이벤트를 실시간으로 모니터링하고, 이를 기반으로 시스템의 성능을 평가할 수 있습니다.
DWT의 주요 레지스터
COMPn:
워치포인트 비교 레지스터로, 모니터링할 메모리 주소를 설정합니다.
DWT_COMPn은 n번째 비교기 레지스터를 의미합니다.
MASKn:
워치포인트 비교 시 사용되는 마스크 레지스터로, 특정 비트 범위만을 비교할 수 있습니다.
DWT_MASKn은 n번째 마스크 레지스터를 의미합니다.
FUNCTIONn:
비교기가 활성화될 조건과 행동을 설정합니다.
DWT_FUNCTIONn은 n번째 기능 레지스터로, 특정 조건에 따라 워치포인트 또는 트레이스를 설정할 수 있습니다.
CYCCNT:
사이클 카운터 레지스터로, CPU 사이클을 카운트합니다.
CTRL:
DWT의 전체 설정을 제어하는 레지스터로, 워치포인트와 트레이스 기능을 활성화하거나 비활성화할 수 있습니다.
DWT와 ETM의 관계
DWT는 독립적으로 동작할 수 있지만, ETM(Embedded Trace Macrocell)과 결합하여 더 강력한 트레이스 기능을 제공합니다. DWT는 데이터 이벤트를 감지하고, ETM은 이러한 이벤트를 포함한 전체 실행 흐름을 기록합니다. 이를 통해 개발자는 프로그램의 실행 경로와 데이터 접근 패턴을 동시에 분석할 수 있습니다.
요약
DWT(Data Watchpoint and Trace): 데이터 접근 이벤트를 모니터링하고 기록하는 모듈입니다.
주요 기능: 데이터 워치포인트 설정, 데이터 트레이스 기록, 사이클 카운터 및 이벤트 카운터를 통한 성능 분석.
주요 레지스터: COMPn, MASKn, FUNCTIONn, CYCCNT, CTRL.
ETM과의 결합: DWT는 ETM과 함께 사용되어 프로그램 실행 흐름과 데이터 접근 패턴을 종합적으로 분석할 수 있습니다.
DWT는 특히 데이터 중심의 디버깅과 성능 분석을 지원하는 중요한 도구로, ARM Cortex-M 프로세서의 강력한 디버깅 기능을 제공합니다.
Cortex 계열만 보아도 ETMv3.3부터 4.0까지의 다양한 ETM 이 적용된걸 볼 수 있다. 데이터 트레이스를 보면 ARM7 부터 CortexA5 까지의 ETM은 전체, 혹은 부분적으로나마 데이터 트레이스를 지원하고 있지만 CortexA9에서는 아예 데이터 트레이스를 뺀 것으로 이유는 역시 생성되는 트레이스 데이터의 폭증을 들 수 있다.
ETM 사용 시 프로그램 트레이스만 받는 것과 데이터 트레이스를 함께 받는 것은 단순히 총 데이터가 두배가 늘어나는 것이 아니다. 실제로 PowerTrace를 이용해 트레이스 데이터를 확인해보면 데이터 트레이스의 사용 여부에 따라 트레이스 데이터가 유실되는 FIFO overflow의 빈도가 상당히 높아진다.
더욱이 CortexA 시리즈의 경우 대부분 멀티코어로 구성된다. 이는 생성되는 트레이스 자체가 코어의 개수만큼 늘어나는 것을 의미하며, CoreSight는 각 ETM에서 생성된 트레이스 데이터를 하나의 스트림으로 합치는 과정이 있기 떄문에 데이터 트레이스를 제외하고서라도 이미 상당한 양의 트레이스 데이터를 처리해야 한다.
트레이스 데이터가 늘어나는 것은 곧 FIFO 오버플로우의 가능성을 높이는 것이기 때문에 ARM은 부득이하게 데이터 트레이스를 제외하고 명칭을 PTM - Program Trace Macrocell이라 한 것이다.
하지만 이를 보완하기 위해 ITM과 HTM을 구현했고 이는 제한적으로나마 데이터 트레이스를 이용할 수 있는 방법을 제공해 준다.
트레이스 내용: 주로 분기(branch)와 같은 이벤트를 기록하여 프로그램이 실행된 경로를 추적합니다.
데이터 트레이스 (Data Trace)
목적: 데이터 접근을 추적합니다.
기능: 특정 메모리 주소에 대한 읽기/쓰기 접근을 기록합니다.
용도: 데이터 흐름 분석, 변수 추적, 메모리 접근 패턴 분석 등에 유용합니다.
트레이스 내용: 메모리 주소와 해당 주소에 접근한 데이터 값을 기록합니다.
트레이스 핀과 시간 분할
ETM 트레이스 데이터는 일반적으로 별도의 트레이스 핀(TRACECLK, TRACEDATA[3:0] 등)을 통해 전송됩니다. 프로그램 트레이스와 데이터 트레이스는 같은 트레이스 핀을 사용하여 시간 분할(Time Division Multiplexing, TDM) 방식으로 전송될 수 있습니다.
시간 분할(Time Division Multiplexing, TDM)
원리: 같은 트레이스 핀을 사용하여 시간에 따라 프로그램 트레이스와 데이터 트레이스를 번갈아 전송합니다.
효율성: 트레이스 데이터의 양이 많을 경우, TDM을 사용하여 한정된 트레이스 핀을 효율적으로 활용할 수 있습니다.
동작 방식: 트레이스 데이터는 작은 패킷으로 나누어 시간 간격에 따라 전송됩니다. 이 패킷들은 프로그램 트레이스와 데이터 트레이스를 포함할 수 있으며, 수신 측에서는 이를 조합하여 전체 트레이스 데이터를 복원합니다.
요약
프로그램 트레이스: 프로그램 실행 흐름을 추적하며, 주로 프로그램 카운터(PC) 값을 기록합니다.
데이터 트레이스: 데이터 접근을 추적하며, 메모리 주소와 해당 데이터 값을 기록합니다.
트레이스 핀: 프로그램 트레이스와 데이터 트레이스는 같은 트레이스 핀을 사용하여 시간 분할 방식으로 전송됩니다.
6. ITM : Instrumentation Trace Macrocell
특정 변수 값이나 메모리 값을 보기 위해 보고자 하는 값을 ITM에 할당된 특정 레지스터에 전달하고 이 값이 출력되는 것이다. ITM Trace
ITM, printf 차이는 데이터 출력과정 처리해 주는 주체이다.
프로세서가 data를 ITM으로 던지는 것은 어셈으로 3~4라인에 불과, 다른 함수로 점프하지 않아도 되기 때문에 프로세서의 성능 저하가 거의 없는 상황에서 개발자가 보고 싶은 특정 데이터의 로깅 이라는 목적을 달성할 수 있다. 예를 들어, CortexA9의 경우 data trace를 지원하지 않기 때문에 이전 버전의 ETM에서 유용하게 사용 할 수 있었던 태스크의 컨텍스트 스위칭에 대한 트레이스에는 약간의 어려움이 있었다. 하지만 ITM이 구현된 SoC를 사용한다면 ITM을 이용해 스케쥴러에서 처리되는 태스크 정보를 ITM으로 출력받아 태스크 트레이스에 적용할 수 있다.
CoreSight는 ETM, ITM, HTM 등 다양한 트레이스 소스에서 생성되는 데이터를 트레이스 버스 - ATB - 통해 하나의 트레이스 스트림을 생성하는 Funnel로 전달한다. 때문에 ITM 데이터는 두 가지 경로를 통해 외부로 출력 될 수 있다. ITM과 ITM 데이터의 출력 경로
ITM 데이터는 위 그림에서 볼 수 있듯이 Replicator를 통해 다시 트레이스 버스에 전달되어 TPIU 또는 ETB를 통해 ETM 등 다른 트레이스 소스로 부터 생성되는 트레이스 데이터와 ITM을 조합해서 디버깅에 활용할 수 있다. JTAG 디버깅 방식을 이용한다면 JTAG 또는 SWDP를 통해 ETB에 저장된 ITM을 조합해서 디버깅에 활용할 수 있다. JTAG 디버깅 방식을 이용한다면 JTAG 또는 SWDP를 통해 ETB에 담긴 작은 크기만큼의(Cortex의 경우 주로 8KB) 데이터만 읽을 수 있다.
HTM은 시스템 버스인 AHB 버스를 통해 오고 가는 값을 출력한다. ETB은 프로세서가 실행하는 프로그램 코드 또는 읽고 쓰는 데이터에 관한 정보를 출력하기 때문에 DMA와 같이 프로세서의 영역을 벗어나는 부분에 대해서는 아무것도 알 수 없다. 하지만 HTM은 시스템 버스의 데이터를 출력하고 이를 볼 수 있는 것이기 때문에 시스템 분석과 문제 해결에 좀 더 풍부한 정보를 제공해 준다.
또한 사용자는 HTM을 통해 시스템 버스가 어떻게 활용되고 있는지, 버스의 부하 정도는 어떤지 확인(또는 추정)할 수 있는 데이터를 얻을 수 있다. 프로그램 동작 중 락업이나 기타 문제가 발생했을 때 AHB 버스에 데이터가 들어갔는데 그 상태에서 스톨되어 멈춘 것인지, 프로그램 수행 후 읽고 쓰는 데이터가 버스에 들어오기는 했는지 등을 살펴보는 등 프로그램의 수행 여부 수준으로만 디버깅을 하던 차원에서 시스템 상태를 확인하며 디버깅을 위한 정보를 얻을 수 있는 것이다.
다른 트레이스 데이터와 마찬가지로 HTM에서 출력되는 데이터 역시 Funnel - AMBA Trace Bus(ATB) - Tra ce Port Interface Unit(TPIU)를 통해 바로 출력되거나 다른 트레이스 데이터와 하나의 트레이스 스트림을 만들어 출력될 수 있다.
이러한 데이터는 PowerTrace 또는 Co mbiProbe를 통해 받아볼 수 있으며, 트레이스 장비가 없을 때에는 JTAG 또는 SWDP를 통해 ETB에 저장된 데이터에 접근할 수 있다. 물론 ETB에 담긴 작은 크기만큼의(Cortex의 경우 주로 8/kB) 데이터만 읽을 수 있다. CortexA7/A15의 경우 주 시스템 버스로 AXI를 사용하는데, 이를 트레이싱 할 수 있는 트레이스 매크로셀은 아직 발표되지 않았다.
ㅇㄹㅇㄹ
8. TPIU / Funnel : 그동안 이게 개인적으로 가장 이해가 안갔던 내용
Funnel과 TPIU는 디버깅에 활용할 수 있는 직접적인 정보를 생성하는 것은 아니지만 멀티코어 환경의 디버깅 방법론을 제공하기 위한 중요한 역할을 한다. 가령 CoreSight가 적용되지 않은 멀티코어의 경우, 각 코어에서 ETM을 통해 생성되는 트레이스 데이터를 받으려면 각 ETM에 연결되는 트레이스 포트를 따로 뽑아주어야 했다. 하나의 트레이스 포트는 총 38핀으로 구성되는데 JTAG과 GND들이 포함된 것이지만 보드 한장에 여러 트레이스 포트를 뽑는 것은 현실적으로 불가능하다. 하지만 Coresight는 ETM, ITM, HTM 등 여러 트레이스 소스에서 생성된 트레이스 데이터들이 ATB를 통해 Funnel로 전달되고 하나의 트레이스 스트림으로 합성된다. 때문에 하나의 트레이스 포트로도 여러 트레이스 소스의 데이터를 받을 수 있게 되는 것이다.
마지막으로 Coresight Block 을 다시 한번 봐보자 CoreSight Block Diagram
