Eine Geschichte des Mikroprozessor-Debuggings, 1980–2016

Seit den Anfängen des Elektronikdesigns, wo es Designs gab, gab es Fehler. Aber wo es Fehler gab, gab es unweigerlich Debugging, in einem epischen Wrestling-Match mit Fehlern, Fehlern und Fehlern, um festzustellen, welche sich durchsetzen würden – und wie gründlich.

In vielerlei Hinsicht ist die Entwicklung der Debug-Technologie so faszinierend wie jeder Aspekt des Designs; aber es steht selten im Rampenlicht. Debug hat sich von einfachen Stimulus-Reaktion-Beobachtungs-Ansätzen zu ausgeklügelten Werkzeugen, Geräten und Methoden entwickelt, die für immer komplexere Designs konzipiert wurden. Jetzt, im Jahr 2017, stehen wir am Beginn einer neuen und aufregenden Ära mit der Einführung von Debugging über funktionale I/O.

Dies ist der Höhepunkt jahrzehntelanger harter Arbeit und Erfindungen aus der ganzen Welt. Ich beschäftige mich seit 1984 mit Debugging. Um den Paradigmenwechsel, den wir jetzt beim Debugging erleben, wirklich zu schätzen, ist es nützlich, einen Blick zurück auf die Innovationen zu werfen, die im Laufe der Jahre stattgefunden haben.

70er-1980er
Das Systemdesign war in dieser Zeit ganz anders als heute. Ein typisches System besteht aus einer CPU, (EP)ROM, RAM und einigen Peripheriegeräten (PIC, UART, DMA, TIMERs, IO…), die jeweils in einem eigenen IC implementiert sind.

Der typische Entwicklungsablauf bestand darin, Ihren Code in ASM oder C zu schreiben und ihn kompilieren, verknüpfen und lokalisieren zu lassen, sodass Sie am Ende eine HEX-Datei für das ROM-Image hatten. Sie würden dann das/die alte(n) EEPROM(s) aus den Sockeln auf der Zielplatine nehmen, in einen UV-EEPROM-Radierer legen und 20 Minuten lang mit UV-Licht bestrahlen.

Sie haben dann das/die EEPROM(s) in einen EEPROM-Programmierer platziert und die HEX-Datei von Ihrem Computer heruntergeladen (normalerweise über eine serielle oder parallele Schnittstelle), um sie zu programmieren.

Schließlich haben Sie das/die EPROM(s) wieder in die Zielplatine gesteckt und es eingeschaltet, um zu sehen, ob Ihr Programm funktioniert. Wenn Ihr Programm nicht wie erwartet funktionierte, standen Ihnen mehrere Optionen zum Debuggen Ihres Codes wie folgt zur Verfügung:

Codeinspektion: In diesem Fall würden Sie Ihren Code durchgehen und ihn lange und intensiv anstarren, um nach Fehlern zu suchen. Diese Technik wird auch heute noch von denen verwendet, die die Verwendung eines Debugging-Tools als Versagen der Programmierkenntnisse ansehen! Der andere Grund, warum Sie dies tun würden, ist, wenn Ihnen die folgenden Techniken aufgrund von Hardwarebeschränkungen oder aus Kostengründen nicht zur Verfügung stehen.

LEDs: Diese Technik wird auch heute noch verwendet. Wenn Sie auf dem Zielsystem LEDs oder eine andere Anzeige haben, können Sie den Pfad durch Ihren Code bestimmen, indem Sie den Code ändern, um einen Zustand an wichtigen Stellen im Code zu signalisieren. Sie können dann einfach auf die LEDs schauen, um den Fortschritt (oder oft auch den Mangel an Fortschritt) durch Ihren Code zu sehen und so zu bestimmen, worauf Sie Ihre Aufmerksamkeit richten sollten. (Siehe auch Wenn das Leben keine Debugging-Schnittstelle bietet, blinkt eine RGB-LED .) Wenn Sie mehrere freie digitale IOs hatten und das Glück hatten, Zugang zu einem Logikanalysator zu haben, könnten Sie Ihren Weg durch den Code in Echtzeit effektiv verfolgen, indem Sie die von Ihrem Programm ausgegebenen Zustände (Orte) verfolgen.

Auf dem Zielmonitor: Bei Target-Boards, die über einen seriellen Port (RS232) und genügend freien EPROM/RAM für ein Monitorprogramm verfügen, können Sie Ihren Code auf Assembly-Ebene schrittweise durchgehen und den Inhalt von Registern und Speicherplätzen anzeigen. Das Monitorprogramm war praktisch ein Low-Level-Debugger, den Sie in Ihren eigenen Code integriert haben. An einer Stelle in Ihrem Programm würden Sie in das Monitorprogramm springen und mit dem Debuggen beginnen. Der serielle Port wurde verwendet, um mit dem Monitorprogramm zu interagieren, und der Benutzer gab Befehle wie „s“ aus, um eine Anweisung zu durchlaufen, und „m 83C4,16“, um den Inhalt von 16 Speicherorten anzuzeigen, beispielsweise ab Adresse 0x83C4. Sobald der Code wie erwartet funktionierte, wurde das endgültige Programm normalerweise ohne den Monitor erstellt.

In-Circuit-Emulator: Für diejenigen, die es sich leisten konnten, war der In-Circuit Emulator (ICE) das ultimative Debug-Tool. In gewisser Weise bot dieses Tool mehr Funktionalität als die modernen Debug-Tools Entwicklern heute bieten! Der ICE würde die CPU im Zielsystem durch eine Elektronik ersetzen, die die CPU emuliert. Diese ICE-Tools waren groß (viel größer als ein Desktop-PC) und sehr teuer – wir sprechen von vielen Tausend Dollar. In dieser Ära wurde der ICE normalerweise vom CPU-Hersteller oder einem der größten Werkzeughersteller der Zeit (Tektronix, HP/Agilent, Microtek usw.) entwickelt und enthielt eine „Bond-out“-Version der CPU unter Emulation . Die Bond-Out-CPU hatte buchstäblich zusätzliche interne Signale, die an Pins des Geräts ausgegeben wurden, damit der Emulator sowohl die CPU steuern als auch zusätzliche Einblicke in ihren internen Betrieb gewinnen konnte. Der Emulator könnte die von der CPU ausgeführten Operationen überwachen und würde komplexe Breakpoints und Tracing-Funktionen bereitstellen, um die heute viele Entwickler beneiden würden. Es war auch möglich, einen Bereich des On-Target-Speichers (typischerweise das EPROM) durch im ICE enthaltenes Emulations-RAM zu ersetzen. Auf diese Weise können Sie Ihren Code in den Emulations-RAM herunterladen – kein Löschen und Durchbrennen von EPROMs mehr während der Entwicklung – Glück!

1982-1990
Während der 1980er Jahre haben sich für den Embedded-Entwickler drei wesentliche Änderungen ergeben. Der erste war, dass mehr integrierte ICs auftauchten, die Kombinationen aus CPU, PIC, UART, DMA enthielten – alle in einem Gerät enthalten. Beispiele wären der Intel 80186/80188, eine Weiterentwicklung der 8086/8088-CPUs (ursprünglicher IBM PC), der Zilog Z180, der eine Weiterentwicklung des Z80 (Sinclair Spectrum) war, und die Motorola CPU32-Familie (z 68302), die eine Weiterentwicklung des 68000 (Apple Lisa) war.

Der zweite war, dass der ICE für Entwickler viel zugänglicher wurde. Mehrere Unternehmen hatten mit der Herstellung von ICE-Tools zu viel niedrigeren Kosten begonnen als die Systeme der CPU-Hersteller. Viele dieser Unternehmen verwendeten keine Bond-Out-Chips. Dies führte zwar zu einer geringfügigen Verringerung der verfügbaren Funktionalität, trug jedoch erheblich zur erhöhten Verfügbarkeit von kostengünstigeren ICE-Produkten bei. Ein ICE für einen 80186 konnte jetzt für weniger als 10.000 US-Dollar abgeholt werden.

Die dritte war, dass die ständig steigenden CPU-Taktraten Probleme für die ICE-Technologie verursachten. Dies stellte die von ICEs verwendeten Verkabelungssysteme vor erhebliche Herausforderungen und verursachte Probleme mit der Emulationssteuerungstechnologie, die bei diesen hohen Geschwindigkeiten einfach nicht arbeiten konnte, ohne (wieder) ernsthaft teuer zu werden. CPU-Hersteller zögerten auch, Bond-Out-Versionen der CPUs herzustellen, da die zusätzlichen On-Chip-Verbindungen den Chipbetrieb störten. Die Lösung für diese Probleme bestand darin, die CPU-Fehlerbeseitigungssteuerschaltung auf dem Chip zu bauen. Dies ermöglichte den Einzelschritt-, Speicher- und Registerzugriff sowie die Breakpoint-Technologie, um mit voller CPU-Geschwindigkeit zu arbeiten, ermöglichte jedoch zu diesem Zeitpunkt keine Rückverfolgung, die noch Zugriff auf die externen Busschnittstellenpins des Geräts benötigte.

Dieser Trace war auch weniger funktional, da für viele interne Peripheriezugriffe der externe Bus nicht verwendet wurde. Somit waren nur externe Zugriffe vollständig sichtbar und die internen peripheren Zugriffe waren dunkel. Der Zugriff auf die On-Chip-Debug (OCD)-Technologie erfolgte entweder über eine proprietäre Schnittstellentechnologie – typischerweise als BDM (Background Debug Mode) bezeichnet – oder über die Standard-JTAG-Schnittstelle, die traditionell eher für Produktionstests als für Debugs verwendet wurde. Diese Schnittstellen ermöglichten es Unternehmen, kostengünstige Debug-Tools zur Steuerung der CPU-Ausführung ohne Taktbeschränkungen zu entwickeln. Die Funktionen variierten leicht zwischen den Implementierungen; zum Beispiel erlaubten einige dem Debug-Tool, auf den Speicher zuzugreifen, während die CPU ausgeführt wurde, während andere dies nicht taten.

1990-2000
Externe Spuren sind so gut wie ausgestorben. Die Erhöhung der CPU-Taktraten in Verbindung mit der Einführung des internen CPU-Cache machte externe Traces ziemlich nutzlos. Um komplexere Programmfehler zu diagnostizieren, bestand jedoch weiterhin die Anforderung, den Ausführungspfad der CPU aufzeichnen zu können. Die Herausforderung bestand darin, dies unter Verwendung von On-Chip-Logik zu erreichen (damit sie mit voller CPU-Geschwindigkeit arbeiten kann), aber die Trace-Daten mit einer praktikablen Taktrate und mit so wenigen Pins wie möglich außerhalb des Chips zu transportieren. Die Lösung bestand darin, den Ausführungspfad der CPU in einen komprimierten Datensatz umzuwandeln, der außerhalb des Chips transportiert und von einem Debug-Tool erfasst werden konnte. Das Tool kann dann den Datensatz verwenden, um den Ausführungspfad zu rekonstruieren. Es wurde erkannt, dass die Komprimierung verlustbehaftet sein könnte, wenn das Debug-Tool Zugriff auf das ausgeführte Programm hätte. Wenn beispielsweise nur die nicht sequentiellen Programmzähleränderungen ausgegeben würden, könnte das Debug-Tool mit Kenntnis des ausgeführten Programms „die Lücken füllen“. IBMs PowerPC, Motorolas ColdFire-CPUs, ARMs 7TDMI-basierte Kerne und andere implementierten alle Trace-Systeme, die auf diesem Konzept basieren.

2000-2010
Mit der Einführung komprimierter Core-Trace-Datensätze wurde es möglich, zwischen dem Transport des Datensatzes außerhalb des Chips und/oder der Verwendung eines relativ kleinen On-Chip-Trace-Puffers zum Speichern der Daten zu wählen. In den frühen 2000er Jahren bemühten sich verschiedene Anbieter, die Traceleistung zu verbessern; ARM hat beispielsweise den Embedded Trace Buffer (ETB) entwickelt, der über JTAG zugänglich und in der Größe konfigurierbar war, um die Trace-Daten zu speichern. Dadurch wurde das Problem gelöst, einen relativ schnellen Off-Chip-Trace-Port (wenn auch immer noch nicht annähernd die Kerntaktgeschwindigkeit) auf Kosten der Siliziumfläche im SoC bereitstellen zu müssen.

Mitte der 2000er Jahre begannen Embedded-CPU-Designer mit der Implementierung von Multi-Core-Systemen. Die Designs mit ARM IP nutzten die JTAG-Technologie, wobei jeder Kern in der seriellen JTAG-Scan-Kette erscheint. Dies war kein Problem, bis die Kernenergieverwaltung implementiert wurde, was dazu führte, dass die Kerne beim Herunterfahren ihre Präsenz in der seriellen JTAG-Scan-Kette verloren. JTAG unterstützt das Erscheinen und Verschwinden von Geräten in der seriellen Scan-Kette nicht, sodass dies sowohl für Debug-Tools als auch für SoC-Designer zu Komplikationen führte. Um dies zu überwinden, hat ARM eine neue Debug-Architektur namens CoreSight entwickelt. Dadurch konnte ein einzelner JTAG-basierter Debug-Zugriffsport (ein Gerät in der JTAG-Scankette) den Zugriff auf viele speicherabgebildete CoreSight-Komponenten, einschließlich aller ARM-Kerne im System, ermöglichen. CoreSight-kompatible Geräte konnten jetzt ohne Beeinträchtigung der JTAG-Scankette ausgeschaltet werden (in diesem neuen Whitepaper erfahren Sie mehr über die CoreSight-Technologie). Diese Technologie wird immer noch in moderneren – und viel komplizierteren – ARM IP-basierten Systemen verwendet, die heute entwickelt werden.

2010-
Mit zunehmender Leistungsfähigkeit eingebetteter Prozessoren – insbesondere mit dem Aufkommen von 64-Bit-Kernen – wurde es möglich, Geräte-Debugging zu unterstützen. Zuvor verwendete das typische Debug-System Debug-Tools auf einer Hochleistungs-Workstation, die eine JTAG/BDM-Verbindung zum Zielsystem nutzte, um die Ausführung/das Trace zu steuern. Als Linux/Android weit verbreitet wurde, wurde der Kernel mit Gerätetreibern erweitert, um auf die CoreSight-Komponenten auf dem Chip zuzugreifen. Durch die Verwendung des Perf-Subsystems ist jetzt eine zielgenaue Trace-Erfassung und -Analyse möglich.

Mit der Einführung des ARM Embedded Logic Analyzer (ELA) ist es jetzt möglich, in die Tage des ICE zurückzukehren und Zugriff auf komplexe On-Chip-Breakpoints, Trigger und Trace mit Zugriff auf interne SoC-Signale zu haben – genau wie die alten Bond-Out-Chips, die in den frühen 1980er Jahren verwendet wurden.

Heute, nach 40 Jahren Innovation, stehen wir an der Schwelle zu einer neuen Ära des Debuggings, in der Ingenieure Debugging und Trace über funktionale E/A durchführen können und dadurch Zeit und Geld sparen. Der Vorstoß zur Durchführung von Debugging über vorhandene Geräteschnittstellen wird nicht nur eine schlankere Lösung bieten, sondern auch dazu beitragen, die Debug- und Trace-Fähigkeiten auf die nächste Stufe zu heben. Damit beginnt ein neues Kapitel in unserer faszinierenden und langen Geschichte im Kampf gegen Insekten.