마이크로프로세서 디버그의 역사, 1980–2016

마지막으로 EPROM을 대상 보드에 다시 연결하고 전원을 켜서 프로그램이 작동하는지 확인했습니다. 프로그램이 예상대로 작동하지 않으면 다음과 같이 코드를 디버깅하는 데 사용할 수 있는 몇 가지 옵션이 있습니다.

코드 검사: 이 경우 오류를 찾기 위해 길고 열심히 코드를 살펴보게 됩니다. 이 기술은 디버깅 도구의 사용을 프로그래밍 기술의 실패로 보는 사람들이 오늘날에도 여전히 사용하고 있습니다! 이렇게 하는 또 다른 이유는 하드웨어 제한이나 비용 때문에 다음 기술을 사용할 수 없는 경우입니다.

LED: 이 기술은 오늘날에도 여전히 사용됩니다. 대상 시스템에 LED 또는 기타 표시기가 있는 경우 코드의 중요한 위치에서 상태를 알리도록 코드를 수정하여 코드의 경로를 결정할 수 있습니다. 그런 다음 LED를 보고 코드를 통해 진행 상황(또는 종종 진행 부족)을 확인할 수 있으므로 주의를 집중할 위치를 결정하는 데 도움이 됩니다. (인생이 디버깅 인터페이스를 제공하지 못하면 RGB LED를 깜박임도 참조하십시오. .) 여분의 디지털 IO가 여러 개 있고 운 좋게도 논리 분석기에 액세스할 수 있는 경우 프로그램에서 출력한 상태(위치)를 추적하여 실시간으로 코드를 통한 경로를 효과적으로 추적할 수 있습니다.

대상 모니터: 직렬 포트(RS232)와 모니터 프로그램을 포함하기에 충분한 여유 EPROM/RAM이 있는 대상 보드의 경우 어셈블리 수준에서 코드를 단계별로 실행하고 레지스터 및 메모리 위치의 내용을 표시할 수 있습니다. 모니터 프로그램은 실제로 자신의 코드에 포함된 저수준 디버거였습니다. 프로그램의 특정 위치에서 모니터 프로그램으로 이동하여 디버깅을 시작합니다. 직렬 포트는 모니터 프로그램과 상호 작용하는 데 사용되었으며 사용자는 "s"와 같은 명령을 실행하여 명령을 실행하고 "m 83C4,16"과 같은 명령을 실행하여 16개 위치의 내용을 표시합니다. 예를 들어 주소 0x83C4에서 시작하는 메모리입니다. 코드가 예상대로 작동하면 일반적으로 최종 프로그램은 모니터 없이 빌드됩니다.

회로 내 에뮬레이터: 여유가 있는 사람들에게는 ICE(In-Circuit Emulator)가 최고의 디버그 도구였습니다. 어떤 면에서 이 도구는 최신 디버그 도구가 오늘날 개발자에게 제공하는 것보다 더 많은 기능을 제공했습니다! ICE는 대상 시스템의 CPU를 CPU를 에뮬레이트하는 전자 장치로 교체합니다. 이 ICE 도구는 크고(데스크톱 PC보다 훨씬 큼) 매우 비쌌습니다. 수천 달러에 해당합니다. 이 시대에 ICE는 일반적으로 CPU 제조업체 또는 당시의 주요 도구 회사 중 하나(Tektronix, HP/Agilent, Microtek 등)에 의해 설계되었으며 에뮬레이션 중인 CPU의 '본드아웃' 버전을 포함합니다. . 본드아웃 CPU는 말 그대로 에뮬레이터가 CPU를 제어하고 내부 작동에 대한 추가 가시성을 얻을 수 있도록 장치의 핀에 추가 내부 신호를 가져왔습니다. 에뮬레이터는 CPU가 수행하는 작업을 감시할 수 있으며 오늘날 많은 개발자가 부러워할 복잡한 중단점 및 추적 기능을 제공합니다. 타겟 메모리(일반적으로 EPROM) 영역을 ICE에 포함된 에뮬레이션 RAM으로 교체하는 것도 가능했습니다. 이렇게 하면 에뮬레이션 RAM에 코드를 다운로드할 수 있습니다. 더 이상 개발 중에 EPROM을 지우거나 날려버릴 필요가 없습니다. 행복합니다!

1982-1990
1980년대에 임베디드 개발자에게는 세 가지 주요 변화가 있었습니다. 첫 번째는 하나의 장치에 모두 포함된 CPU, PIC, UART, DMA의 조합을 포함하는 더 많은 집적 IC가 등장하기 시작했다는 것입니다. 예는 8086/8088 CPU(원래 IBM PC)의 진화인 Intel 80186/80188, Z80(Sinclair Spectrum)의 진화인 Zilog Z180, Motorola CPU32 제품군(예:68302), 68000(Apple Lisa)의 진화입니다.

두 번째는 ICE가 개발자에게 훨씬 더 쉽게 접근할 수 있게 되었다는 것입니다. 여러 회사에서 CPU 제조업체의 시스템보다 훨씬 저렴한 비용으로 ICE 도구를 제조하기 시작했습니다. 이들 회사 중 다수는 본드아웃 칩을 사용하지 않았습니다. 이로 인해 사용 가능한 기능이 약간 감소했지만 더 저렴한 ICE 제품의 가용성이 증가하는 데 크게 기여했습니다. 80186의 ICE는 이제 $10,000 미만으로 구입할 수 있습니다.

세 번째는 계속 증가하는 CPU 클럭 속도가 ICE 기술에 문제를 일으키기 시작했다는 것입니다. 이것은 ICE가 사용하는 케이블링 시스템에 중대한 문제를 일으켰고 에뮬레이션 제어 기술에 문제를 일으키기 시작했습니다. 이 기술은 (다시) 심각하게 비싸지 않으면 이러한 고속에서 작동할 수 없습니다. 추가 온칩 연결이 칩 작동을 방해하기 때문에 CPU 제조업체는 CPU의 본드아웃 버전을 만드는 것을 더욱 꺼리게 되었습니다. 이러한 문제에 대한 해결책은 CPU 디버그 제어 회로를 온칩으로 구축하는 것이었습니다. 이를 통해 단일 단계, 메모리 및 레지스터 액세스, 중단점 기술이 전체 CPU 속도로 작동할 수 있었지만 현재로서는 장치 외부 버스 인터페이스 핀에 대한 액세스가 필요한 추적을 제공하지 않았습니다.

이 트레이스는 또한 많은 내부 주변기기 액세스에 대해 외부 버스가 사용되지 않았기 때문에 기능이 떨어졌습니다. 따라서 외부 액세스 만 완전히 볼 수 있었고 내부 주변 장치 액세스는 어둡습니다. 온칩 디버그(OCD) 기술에 대한 액세스는 일반적으로 BDM(백그라운드 디버그 모드)이라고 하는 독점 인터페이스 기술을 통하거나 디버그보다는 프로덕션 테스트에 더 전통적으로 사용되었던 표준 JTAG 인터페이스를 통해 이루어졌습니다. 이러한 인터페이스를 통해 기업은 클럭 속도 제한 없이 CPU 실행을 제어하기 위한 저렴한 디버그 도구를 만들 수 있었습니다. 기능은 구현마다 약간씩 다릅니다. 예를 들어 일부는 CPU가 실행되는 동안 디버그 도구가 메모리에 액세스할 수 있도록 허용했지만 다른 일부는 그렇지 않았습니다.

1990-2000년
외부 추적이 거의 사라졌습니다. 내부 CPU 캐시의 도입과 함께 CPU 클록 속도의 증가는 외부 추적을 거의 쓸모 없게 만들었습니다. 그러나 더 복잡한 프로그램 결함을 진단하기 위해서는 여전히 CPU의 실행 경로를 기록할 수 있어야 한다는 요구 사항이 있었습니다. 문제는 온칩 로직(최대 CPU 속도로 작동할 수 있도록)을 사용하여 이 작업을 수행하면서 가능한 한 적은 수의 핀을 사용하여 실현 가능한 클록 속도로 칩에서 트레이스 데이터를 전송하는 방법이었습니다. 해결책은 CPU의 실행 경로를 압축된 데이터 세트로 변환하는 것이었습니다. 이 데이터 세트는 오프칩으로 전송되고 디버그 도구로 캡처될 수 있습니다. 그런 다음 도구는 데이터 세트를 사용하여 실행 경로를 재구성할 수 있습니다. 디버그 도구가 실행된 프로그램에 액세스할 수 있는 경우 압축이 손실될 수 있음을 깨달았습니다. 예를 들어, 비순차적 프로그램 카운터 변경 사항만 출력된 경우 디버그 도구는 실행 중인 프로그램에 대한 지식을 사용하여 "갭을 채울" 수 있습니다. IBM의 PowerPC, Motorola의 ColdFire CPU, ARM의 7TDMI 기반 코어 등 모두 이 개념을 기반으로 추적 시스템을 구현했습니다.

2000-2010년
압축 코어 트레이스 데이터 세트의 도입으로 데이터 세트를 오프 칩으로 전송하거나 비교적 작은 온칩 트레이스 버퍼를 사용하여 데이터를 보관하는 것 중에서 선택하는 것이 가능해졌습니다. 2000년대 초반에 다양한 공급업체가 추적 성능을 개선하기 위해 노력했습니다. 예를 들어 ARM은 JTAG를 통해 액세스할 수 있고 추적 데이터를 보유하도록 크기를 구성할 수 있는 ETB(Embedded Trace Buffer)를 설계했습니다. 이것은 SoC에서 실리콘 영역을 사용하는 대신 비교적 고속의 오프칩 트레이스 포트를 제공해야 하는 문제를 해결했습니다.

2000년대 중반에 임베디드 CPU 설계자들은 멀티 코어 시스템을 구현하기 시작했습니다. ARM IP를 사용하는 설계는 JTAG 기술을 사용했으며 각 코어는 직렬 JTAG 스캔 체인에 나타납니다. 이것은 코어 전원 관리가 구현될 때까지 문제가 되지 않았으며, 이로 인해 전원이 꺼졌을 때 JTAG 직렬 스캔 체인에서 코어의 존재가 손실되었습니다. JTAG는 직렬 스캔 체인에서 나타나고 사라지는 장치를 지원하지 않으므로 디버그 도구와 SoC 설계자 모두에게 문제가 발생했습니다. 이를 극복하기 위해 ARM은 CoreSight라는 새로운 디버그 아키텍처를 만들었습니다. 이를 통해 단일 JTAG 기반 디버그 액세스 포트(JTAG 스캔 체인의 하나의 장치)가 시스템의 모든 ARM 코어를 포함하여 많은 메모리 매핑된 CoreSight 구성 요소에 대한 액세스를 제공할 수 있었습니다. 이제 CoreSight 호환 장치는 JTAG 스캔 체인에 영향을 주지 않고 자유롭게 전원을 끌 수 있습니다(이 새로운 백서에서 CoreSight 기술에 대한 자세한 내용을 읽을 수 있음). 이 기술은 오늘날 설계되고 있는 보다 현대적이고 훨씬 더 복잡한 ARM IP 기반 시스템에서 여전히 사용되고 있습니다.

2010-
임베디드 프로세서의 기능이 향상됨에 따라(특히 64비트 코어의 등장으로) 장치 디버그 지원이 더욱 가능해졌습니다. 이전에 일반적인 디버그 시스템은 실행/추적을 제어하기 위해 대상 시스템에 대한 JTAG/BDM 연결을 활용하는 고성능 워크스테이션에서 디버그 도구를 사용했습니다. Linux/Android가 널리 사용되면서 커널은 온칩 CoreSight 구성 요소에 액세스하기 위한 장치 드라이버로 보강되었습니다. perf 하위 시스템을 활용하여 이제 대상 추적 캡처 및 분석이 가능합니다.

ARM ELA(Embedded Logic Analyzer)의 도입으로 이제 ICE 시대로 돌아가 내부 SoC 신호에 대한 액세스를 통해 복잡한 온칩 중단점, 트리거 및 추적에 액세스할 수 있습니다. 1980년대 초에 제공하는 데 사용된 본드아웃 칩입니다.

40년의 혁신 끝에 오늘날 우리는 엔지니어가 기능적 I/O에 대해 디버그 및 추적을 수행하여 시간과 비용을 모두 절약할 수 있는 디버그의 새로운 시대의 정점에 서 있습니다. 기존 장치 인터페이스를 통해 디버그를 수행하기 위한 푸시는 더 간결한 솔루션을 제공할 뿐만 아니라 디버그 및 추적 기능을 다음 수준으로 높이는 데 도움이 됩니다. 이로써 벌레와의 전쟁에서 우리의 흥미롭고 긴 역사의 새로운 장이 시작됩니다.