Das Hinzufügen eines Echtzeit-Trace-Bus zum Prozessor ermöglicht es, die Verzweigungsaktivitäten in Echtzeit zu sammeln, ohne dabei die Zielhardware anzuhalten. Dafür werden jedoch zusätzliche Pins benötigt, die das Endprodukt verteuern. Ein Kompromiss wäre, eine spezielle Gehäuseoption mit herausgeführten Anschlüssen zu verwenden, um den Entwicklern Zugriff auf einen Baustein zu gewähren. Das endgültige Produkt kann mit den deaktivierten Pins ausgeliefert werden.
Eine weitere Möglichkeit ist es, einen Multiplexer zu verwenden, um die Trace-Pins mit denen, die für andere Peripherie benutzt werden, zu mischen. Dies ist jedoch keine Option, wenn alle SoC-Pins für Input/Output im Zielsystem benötigt werden.
Obwohl JTAG eine Standard-Infrastruktur für den Zugriff auf Debugging-Engines innerhalb eines SoCs ist, ist sie nur rudimentär. Jeder Prozessor-Hersteller hat seinen eigenen Satz an Befehlen, Funktionen und zusätzlichen Trace-Pins, die er benutzt, um das Debugging zu steuern und die nötigen Daten zu sammeln.
Die Probleme, die durch das Fehlen eines wirklich standardisierten Debuggings auftreten, wurden bereits in den 90ern erkannt. Die IEEE-Nexus-Arbeitsgruppe versuchte einen allgemeinen Standard zu definieren, der von allen Herstellern eingebetteter Systeme eingehalten würde. Obwohl einige Firmen das Kernkonzept von Nexus begrüßten, resultierten Änderungen im Markt in einem Abblocken der gemeinsamen Standardisierung. Stattdessen kamen De-facto-Standards auf, wie z.B. CoreSight von ARM.
Der ARM-Prozessor wurde zur bevorzugten Wahl für die Entwickler eingebetteter Systeme und damit wurde CoreSight selbst die bevorzugte Verbindung zwischen dem Software-Debugger und dem Prozessor innerhalb der meisten SoCs. Ein Debugging-Protokoll, das für eine einzige Familie von Prozessor-Kernen entwickelt wurde, kann aber nicht mehr mit den Problemen fertig werden, denen sich die SoC-Anbieter und ihre Kunden heutzutage gegenüber sehen. Inzwischen dominieren Multicore-SoCs den Markt in allen, selbst in den einfachsten Anwendungen.
SoCs mit mehreren Rechenkernen verkomplizieren das Debugging-Problem, denn es gibt nur wenig Spielraum um weitere Debugging-Ports hinzuzufügen. Der JTAG-Zugangs-Port kann nicht länger mit dem Debugging-Monitor eines einzigen Prozessors verbunden werden. Es wird ein spezieller Bus benötigt, um die Aktivitäten von mehreren Prozessoren auf einem Chip zu koordinieren. Dieser Bus muss wiederum Zugriff auf komplexere Triggermöglichkeiten bieten. Diese können von Cross-Trigger-Engines geliefert werden, die bestimmen, wie jeder Rechenkern auf einen Breakpoint reagieren soll.
Einige Situationen erfordern, alle Rechenkerne gemeinsam anzuhalten. In anderen Fällen, in denen eine präzise Synchronisation zwischen Tasks, die auf unterschiedlichen Kernen laufen, notwendig ist, kann die Debugging-Software Start- und Stopp-Befehle unabhängig für jeden Kern ausgeben.
Die Debugging-Logik auf dem Chip muss auch Daten von jedem der Rechenkerne auf einen gemeinsamen Bus multiplexen können, damit sie an den Debugger übermittelt werden. Das Nachverfolgen aller Rechenkerne benötigte eine große Bandbreite, die nicht in jedem Fall gegeben ist, aber auch nicht in jedem Fall notwendig ist. Was die eingebettete Trace-Engine können muss, ist einen Trace zwischenzuspeichern, während ein anderer Kern-Buffer ausgelesen wird. So können Ereignisse auf einem Kern nachverfolgt und auch zu einem späteren Zeitpunkt ausgelesen und untersucht werden.
Solche Trace-Möglichkeiten für Mehrkern-Prozessoren sind kommerziell verfügbar, aber meistens noch auf das Prozessorangebot eines bestimmten IP-Lieferanten fokussiert. Um mit einem allgemeinen Debugging-Interface zu arbeiten, muss das SoC-Designteam entweder Prozessoren exklusiv von diesem Hersteller einsetzen oder Prozessoren von Fremdherstellern in das primäre Debugging-Protokoll integrieren. Besonders die zweite Möglichkeit ist mit einem signifikanten Aufwand verbunden. In vielen Fällen haben nur CPUs und GPUs mehr als eine Basis-Debugging-Unterstützung.