Die enge Kopplung der On-Chip-Trace-Hardware an die eigentlichen Chipkomponenten und der damit verbundene direkte und schnelle Zugriff auf die relevanten Daten erlaubt eine Trace-Datenerfassung zu jedem Prozessortakt, also in Echtzeit. Doch wie zeichnet man solch große Mengen an Tracedaten möglichst einfach auf? Theoretisch wäre es natürlich am einfachsten, die Daten direkt vom Chip herunter auf den Debug-Host zu übertragen. Um die erforderlichen Datenraten zur ermöglichen, wäre dafür aber ein zusätzlicher, breitbandiger Debug-Zugang (Trace-Kanal) nötig. Das für Debug-Zwecke vorhandene JTAG-Interface ist hierfür technisch keinesfalls geeignet.
Eine weitere denkbare Alternative wäre die Implementierung eines On-Chip-Tracespeichers direkt auf dem Die. Die Bandbreite für die Aufzeichnung würde sich dadurch verzehnfachen. Zudem wäre für die Übertragung der Tracedaten zum Debug-Host prinzipiell auch ein Debug-Kanal mit geringerer Bandbreite (z.B. JTAGInterface) ausreichend, da mit dem Transfer bis zur Beendigung der Trace-Aufzeichnung gewartet werden könnte. Wie gesagt: prinzipiell. Voraussetzung dafür wäre nämlich ein On-Chip-Tracespeicher ausreichender Größe, Speicherkapazitäten über 1 MByte dürften aber wohl zumindest in naher Zukunft aus Kostengründen reines Wunschdenken bleiben. Bleibt als Ausweg faktisch also nur die Reduzierung der Tracedaten noch vor der Übertragung bzw. On-Chip-Speicherung. Nur so ist es möglich, die Kosten für einen schnellen Trace-Kanal bzw. großen Trace-Speicher in einem vertretbaren Rahmen zu halten.
Für den Programm-Trace ist so eine Reduktion relativ leicht: Um den Programmablauf auf dem Debug-Host zu rekonstruieren, müssen lediglich Sprünge bzw. Unterbrechungen in der sequentiellen Verarbeitung des Befehlsstromes (Interrupts, Traps) aufgezeichnet werden. Die restlichen Informationen kann der Debugger aus dem geladenen Programm selbst ermitteln. Schwieriger gestaltet sich das Ganze beim Datentrace. Hier ist meistens die Aufzeichnung des kompletten gelesenen oder geschriebenen Datenwortes und dessen Adresse auf dem Adressbus erforderlich. Viele, zeitlich dicht aufeinander folgende Datenzugriffe verursachen indes eine so große Menge an Trace-Informationen, dass diese nicht mehr über den in seiner Bandbreite doch recht beschränkten Debugkanal übertragen werden können. Der On-Chip-Tracespeicher wäre in so einem Fall schon nach wenigen Millisekunden gefüllt, ein typischer »Overrun « träte ein. Zudem würde eine anschließende Auswertung – unabhängig davon, ob diese manuell oder mittels automatischer Werkzeuge erfolgt – massiv erschwert, wenn nicht gar unmöglich. Es ist daher sinnvoll, nur die Daten aufzuzeichnen, die auch später zur Analyse wirklich benötigt werden.