본문으로 건너뛰기
Embedded Performance Engineering · 45/57

ARM DS·Lauterbach 분석 — Hardware Trace 전문 도구

· Hawk · 8분 읽기
arm-ds lauterbach trace32 etm ptm streamline

#한 줄 요약

“ARM DS와 Lauterbach는 ETM·PTM hardware trace로 모든 명령 실행을 무손실로 기록하는, 임베디드 전용 측정의 표준입니다.”

#어떤 문제를 푸는가

Linux 위 perf와 ftrace는 software sampling 기반이라 짧은 spike를 놓치거나 측정 자체가 시스템 동작을 바꿉니다. Cortex-M 같은 RTOS·bare-metal 환경에서는 perf가 아예 없습니다.

ARM 코어는 ETM(Embedded Trace Macrocell) 또는 PTM(Program Trace Macrocell)이라는 hardware trace unit을 코어 옆에 두고, 매 명령 실행을 압축된 stream으로 외부로 내보냅니다. 외부에는 DSTREAM, ULINKpro, Lauterbach TRACE32 같은 debug probe가 이 stream을 수신해 PC와 메모리에 기록합니다.

소프트웨어 overhead가 0이며, 모든 분기와 함수 호출이 ns 단위로 보존됩니다. 자동차, 항공, 산업 인증이 필요한 분야에서 사실상 표준 도구입니다.

#ARM Development Studio와 Streamline

ARM이 직접 제공하는 IDE는 ARM Development Studio(DS)이며, 그 안에 Streamline Performance Analyzer가 포함됩니다.

ARM Development Studio 구성

Streamline의 capture 흐름은 다음과 같습니다.

  1. Target에 gator daemon 설치 (Linux) 또는 ETM unit 활성화 (bare-metal).
  2. 호스트에서 Streamline 실행, target 연결.
  3. Capture 시작 → 코어 PMU, ETM trace, OS 정보 동시 수집.
  4. Timeline view에 코어별 hotspot, 함수 호출, OS 이벤트 표시.

Streamline의 강점은 Linux 시스템과 bare-metal을 같은 UI로 처리하는 점입니다. RTOS task switch와 인터럽트도 자동으로 인식합니다.

#DSTREAM·DSTREAM-PT Debug Probe

  • DSTREAM — JTAG/SWD 디버그, 4 GB trace buffer
  • DSTREAM-PT — PCIe 기반 고속, 32 GB trace buffer, 100 Gbit/s 수신
  • DSTREAM-ST — 휴대형, 16 GB trace buffer

JTAG/SWD는 디버그 제어용, ETM/PTM trace는 별도의 trace port로 출력됩니다. 멀티코어 Cortex-A의 ETM은 코어당 수 Gbps의 trace 데이터를 생성하므로, probe의 buffer 크기와 수신 대역폭이 측정 깊이를 결정합니다.

#Lauterbach TRACE32

산업계에서 가장 폭넓게 쓰이는 임베디드 디버거가 Lauterbach TRACE32입니다. 자동차 ECU 개발에서는 사실상 기본 도구입니다.

  • TRACE32 PowerView — GUI
  • TRACE32 PowerDebug — JTAG/SWD/cJTAG probe
  • TRACE32 PowerTrace — ETM/PTM/Nexus trace probe (8-32 GB buffer)

PRACTICE 스크립트(.cmm)로 자동화가 가능합니다.

SYStem.RESet
SYStem.CPU CortexA72
SYStem.Up


Break.Set main /Onchip
Go
WAIT !STATE.RUN()


Trace.Init
Trace.METHOD Onchip
Trace.Mode FlowTrace
Trace.Arm
Go

수집된 trace는 statistics, branch coverage, function timing 분석에 사용됩니다.

#ETM과 PTM — 무엇을 trace하는가

ETM vs PTM — Hardware Trace Unit 비교

Cortex-A에서는 ETMv4가 표준이며 Cortex-M에서는 ETM-M0, ETM-M4가 있습니다. Cortex-M0+의 MTB(Micro Trace Buffer)는 SRAM 일부를 trace buffer로 쓰는 간이형입니다.

ETM stream은 압축되어 있어 disassembly와 합쳐야 사람이 읽을 수 있습니다. Lauterbach나 ARM DS가 이 reconstruct를 자동으로 합니다.

#RTOS Awareness

지원 RTOS — FreeRTOS, ThreadX, Zephyr, AUTOSAR OS, QNX, INTEGRITY.

TRACE32와 ARM DS는 위 RTOS의 task 구조를 인식해 task switch를 timeline에 표시합니다. Task별 CPU 점유율, mutex 대기 시간, ISR 진입 횟수 같은 metric을 hardware trace에서 직접 계산합니다.

Task A   ████████░░░░░░██████░░░░
Task B   ░░░░░░░░██████░░░░░░░░██
ISR1     ░░█░░░░░░░░░░░░░░░░█░░░░
Idle     ░░░░░░░░░░░░░░░░░░░░░░░░

소프트웨어 trace point를 심을 필요 없이 RTOS의 task control block을 ETM 데이터에서 읽어 재구성하므로 production 코드가 그대로 측정됩니다.

#Code Coverage와 인증

표준도메인요구
DO-178C항공Modified Condition/Decision Coverage
ISO 26262자동차Branch Coverage
IEC 62304의료Statement Coverage

위 인증은 모든 분기가 실제로 실행되었음을 증명해야 합니다. ETM trace는 코드 instrumentation 없이 분기 전부를 기록하므로, 코드 수정 없이 인증을 통과할 수 있는 거의 유일한 방법입니다.

TRACE32 → Coverage.List

FunctionStatementBranchMC/DC
process_input100%95%80%
handle_error80%60%50%

#가격대와 라이센스

제품가격
ARM Development Studio Ultimate Edition (ARM Streamline 포함)연 $3,000-5,000
DSTREAM probe$5,000-8,000
DSTREAM-PT (고속)$15,000+
Lauterbach PowerDebug USB 3$4,000-6,000
Lauterbach PowerTrace II$10,000-20,000
Lauterbach PowerTrace III$30,000+

가격이 높아 보이지만, 자동차나 항공 ECU 개발에서는 개발팀 한 사람의 1-2개월 인건비 수준입니다. 인증 통과에 드는 시간이 줄어드는 가치가 훨씬 크다는 판단입니다.

#시나리오 — 자동차 ECU의 ISR 지연 측정

요구사항 — CAN 수신 ISR이 50 us 안에 완료.

측정 절차

  1. TRACE32로 PowerTrace 연결
  2. CAN_RX_ISR 진입과 이탈을 break point로 등록
  3. 100만 번의 trace 수집
  4. Statistic.Func로 평균, 최대, 분포 확인

결과

  • 평균 12 µs
  • 최대 78 µs ← 요구사항 위반
  • 분포 95% < 20µs, 99% < 40µs, 0.01% > 70µs

이 0.01%의 spike가 무엇 때문인지 ETM trace로 그 시점의 instruction stream을 거꾸로 재생해 원인을 찾습니다. Software profiler로는 불가능한 분석입니다.

#자주 보는 함정과 안티패턴

⚠️ Trace port 핀이 출력되지 않은 보드

PCB 설계 시 ETM trace 핀(TRACEDATA, TRACECLK)을 연결하지 않으면 hardware trace를 사용할 수 없습니다. 양산 보드에서 제거하더라도 개발 보드에는 반드시 빼두어야 합니다.

⚠️ Trace buffer overflow

ETM이 초당 10 Gbit를 출력하는데 probe buffer가 1 GB면 0.8초만 기록 가능합니다.

긴 시나리오는 cycle accurate를 끄거나 filter로 특정 함수만 trace합니다.

⚠️ Cortex-M0에서 ETM 기대

Cortex-M0에는 ETM이 없습니다. Cortex-M0+는 MTB가 있지만 SRAM 일부를 사용하므로 buffer가 매우 작습니다(KB 단위). Cortex-M3 이상부터 ETM-M3가 본격적입니다.

⚠️ Streamline gator daemon overhead 무시

gator daemon은 sampling 기반이며 1-3% CPU를 사용합니다.

Bare-metal과 달리 Linux Streamline은 software 측정이 일부 섞여 있으므로 ETM 만큼 완전 zero overhead는 아닙니다.

#정리

  • ETM과 PTM은 ARM 코어 옆에 붙은 hardware trace unit으로 zero overhead 명령 추적을 제공합니다.
  • ARM Development Studio의 Streamline은 Linux와 bare-metal을 같은 UI로 분석합니다.
  • Lauterbach TRACE32는 자동차 ECU 개발의 사실상 표준이며 PRACTICE 스크립트로 자동화 가능합니다.
  • RTOS awareness로 task switch와 ISR이 자동 timeline에 표시됩니다.
  • DO-178C, ISO 26262 인증의 coverage 증명에 ETM trace가 핵심입니다.
  • PCB 설계 시 trace 핀을 빼두어야 하며 buffer 크기가 측정 깊이를 결정합니다.

다음 편은 Bare-metal 프로파일링 — 더 작은 시스템의 GPIO와 DWT.

#관련 항목

Embedded Performance Engineering · 46 of 57

  1. 1Embedded Performance Engineering — 임베디드 성능 엔지니어링 시리즈 소개
  2. 2임베디드 성능 분석 방법론 — Measure → Analyze → Optimize 사이클
  3. 3성능 지표 정의 — Latency·Throughput·Utilization 분석
  4. 4성능 측정의 기본 — Wall-Clock·CPU Cycle·Instruction Count
  5. 5성능 데이터 통계적 분석 — Percentile·Histogram·평균의 함정
  6. 6실시간 성능 분석 — WCET·Jitter·Deadline Miss 측정
  7. 7임베디드 벤치마킹 기초 — 재현성·Warmup·노이즈 제거
  8. 8성능 모델링 — Amdahl·Gustafson·Roofline Model 적용
  9. 9프로파일링 기법 개요 — Sampling vs Instrumentation·PGO·LTO
  10. 10CPU 파이프라인 분석 — 5-stage·Cortex-M·Cortex-A 비교
  11. 11Pipeline Stall 분석 — Data·Structural·Control Hazard·Forwarding
  12. 12Branch Prediction 분석 — Static·2-bit·BTB·BHT·Mispredict 비용
  13. 13Speculative Execution 분석 — OoO·Reorder Buffer·Register Renaming
  14. 14CPU Cache 기초 — L1·L2·L3·Set Associative·Replacement Policy
  15. 15Cache Miss 3C Model 분석 — Compulsory·Capacity·Conflict
  16. 16Cache Line 최적화 — Alignment·Prefetch·False Sharing 처리
  17. 17메모리 대역폭 분석 — STREAM·Roofline·Bus Saturation 측정
  18. 18SIMD·NEON 활용 — 128-bit Vector·Auto-Vectorization·SVE/SVE2
  19. 19PMU·HPM 하드웨어 카운터 분석 — 정밀 성능 진단
  20. 20임베디드 Bus Architecture — AHB·AXI·CHI 진화와 5-Channel
  21. 21Bus Contention 진단 — Arbitration·QoS·Starvation 측정
  22. 22DMA 성능 최적화 — Burst·Scatter-Gather·Chain·Cache 일관성
  23. 23DMA vs CPU Copy 성능 비교 — Break-even·Setup Overhead 실측
  24. 24Interrupt Latency 분석 — 진입·종료·Tail-Chaining·Late Arrival
  25. 25Interrupt Storm 처리 — NAPI·Rate-Limit·Polling 전환
  26. 26MMIO 접근 성능 — Cache Policy·Write-Combining·Volatile·Barrier
  27. 27Peripheral Clock 분석 — PLL·Divider·Gating·DVFS
  28. 28Power vs Performance 트레이드오프 — DVFS·Race-to-Idle·Big.LITTLE
  29. 29Thermal Throttling 분석 — Junction Temp·Trip Point·냉각
  30. 30CXL Interconnect 분석 — AI 시대 메모리 대역폭 확장
  31. 31Concurrency 기초 — Concurrency vs Parallelism·Race·Memory Model
  32. 32False Sharing 진단 — Cache Line Ping-Pong·Padding·측정
  33. 33Lock Contention 분석 — Wait·Hold·Convoy·측정 기법
  34. 34Spinlock 성능 분석 — Spin-Wait vs Context Switch·Ticket·MCS
  35. 35Mutex 성능 분석 — Futex·Adaptive·Priority Inheritance
  36. 36Reader-Writer Lock 성능 — Reader/Writer Priority·RCU·Seqlock
  37. 37Lock-Free 자료구조 성능 — CAS·ABA·Hazard Pointer·Epoch Reclamation
  38. 38Memory Ordering 분석 — Acquire·Release·Seq-Cst·ARM Relaxed Model
  39. 39Cache Coherency 프로토콜 — MESI·MOESI·Snoop·Directory
  40. 40SMP 성능 분석 — Per-Core·Affinity·Load Balance·Scalability
  41. 41Linux perf 기초 — stat·record·report 활용
  42. 42Linux perf 고급 — Raw Event·Tracepoint·perf script
  43. 43ftrace 활용 — function·function_graph·latency tracer
  44. 44eBPF·bpftrace 동적 트레이싱 — 커널 무수정 관측
  45. 45Flamegraph 분석 — On-CPU·Off-CPU·Differential
  46. 46ARM DS·Lauterbach 분석 — Hardware Trace 전문 도구
  47. 47Bare-metal 프로파일링 — GPIO·DWT·SysTick·ITM 활용
  48. 48NVIDIA Nsight Systems — GPU·NPU 포함 시스템 분석
  49. 49모던 프로파일러 비교 — Tracy·Hotspot·uftrace·Coz
  50. 50연속 프로파일링 — Parca·Pixie·Pyroscope·Tetragon
  51. 51실전 사례 — ISR Latency 100µs Deadline Miss 추적
  52. 52실전 사례 — Matrix Multiply가 예상의 10배 느린 이유
  53. 53실전 사례 — 8-core가 4-core를 넘으면 throughput이 떨어지는 이유
  54. 54실전 사례 — 카메라 1080p 60fps가 30fps로 떨어지는 이유
  55. 55CXL.mem 지연·대역폭 실측 — Direct·Switch·Pooled 토폴로지 비교
  56. 56CXL 성능 프로파일링 도구 — cxl-cli·DAMON·perf-mem 활용
  57. 57실전 사례 — CXL.mem 추가로 LLM inference KV cache 처리량 회복

관련 글

실전 사례 — CXL.mem 추가로 LLM inference KV cache 처리량 회복

70B 모델 KV cache가 HBM 한계를 넘어 throughput이 무너졌을 때, CXL.mem 256 GB pool 추가로 회복한 실전 케이스.

·cxl

CXL 성능 프로파일링 도구 — cxl-cli·DAMON·perf-mem 활용

CXL.mem 환경 성능 도구 — cxl-cli 토폴로지·DAMON page activity·perf-mem로 보는 CXL 트래픽·numastat 통계.

·cxl

CXL.mem 지연·대역폭 실측 — Direct·Switch·Pooled 토폴로지 비교

CXL.mem 토폴로지별 실측 — Direct attach·Single switch·Multi-host pool의 지연·대역폭 비용 측정.

·cxl

이 글을 참조하는 글 (3)