DE102008060790B4

DE102008060790B4 - Debugging-System

Info

Publication number: DE102008060790B4
Application number: DE102008060790.8A
Authority: DE
Inventors: Dr. Mayer Albrecht
Original assignee: Infineon Technologies AG
Current assignee: Infineon Technologies AG
Priority date: 2007-12-12
Filing date: 2008-12-05
Publication date: 2015-10-22
Anticipated expiration: 2028-12-06
Also published as: US8234531B2; US20110041010A1; US8347158B2; US20090158107A1; USRE46021E1; DE102008060790A1; US20120260131A1; US7870455B2

Abstract

Debugging-System für eine mit einem Einchipsystem (SOC) versehene integrierte Schaltung (IC), das Folgendes umfasst: eine Vielzahl von SOC ICs (102, 104, 106), die mit einem gemeinsam genutzten Debug-Bus (108) verbunden sind, wobei wenigstens eine der Vielzahl von SOC ICs (102, 104, 106) als Master SOC IC (102) betreibbar ist und eine Master/Slave-Debug-Schnittstelle (120) und eine Benutzerschnittstelle (116) umfasst, wobei die Master/Slave-Debug-Schnittstelle (120) eine bidirektionale Debug-Schnittstelle ist, die so betriebsfähig ist, dass sie in einem Mastermodus Debug-Daten-Signale von den anderen SOC ICs (104, 106) empfängt, und die zudem in einem Slavemodus betriebsfähig ist, in dem die Signalrichtungen gegenüber dem Mastermodus umgedreht sind, wobei ein Hostsystem (110) direkt oder über mehrere Netzwerk- oder Buskomponenten mit der wenigstens einen Master SOC IC (102) durch die Benutzerschnittstelle verbindbar ist.

Description

Die vorliegende Erfindung betrifft ein Debugging-System, insbesondere ein Debugging-System für eine mit einem Einchipsystem (SOC; System an Chip) versehene integrierte Schaltung.
Die Technologie des Einchipsystems (SOC) betreibt und steuert verschiedene Arten von Systemen. Im Allgemeinen ist die SOC-Technologie die Zusammenfassung bzw. Montage all der für ein System (wie etwa ein Mobiltelefon oder eine Digitalkamera) notwendigen elektronischen Schaltkreise und Teile auf einer einzigen integrierten Schaltung (IC; integrated circuit), was allgemein als ein Mikrochip bekannt ist. SOC-Vorrichtungen verringern in großem Maße die Größe, die Kosten und den Energieverbrauch des Systems.
Während einer SOC-Entwicklung werden Debugger mit den Debug-Schnittstellen (z. B. einem JTAG-Port) der SOCs verbunden. Um ein synchrones Debugging zu erlauben und Anschlussstifte zu sparen, benutzen alle SOCs des Systems typischerweise gemeinsam einen einzigen Debug-Bus (z. B. CJTAG) und einen einzigen Verbindungsstecker zu der Debug Tool Hardware für Debugging- und Testprozeduren. Unter Verwendung des Debug-Busses kann das System durch einen einzigen Verbindungsstecker einem Debugging (Steuerung, Status und Ablaufverfolgung) unterzogen werden.
Auf Grund des sehr hohen Grades an Integration auf einer einzigen IC ist in vielen Fällen die Anzahl an Eingangs-/Ausgangs-(EA)-Signalen weg von der SOC-Vorrichtung reduziert. Des Weiteren steigt, da die Chipgrößen immer weiter anwachsen, die Anzahl an Transistoren auf einem Chip viel schneller als die mögliche Anzahl von EA-Signalen, die von dem Chip weg geleitet werden können. Deshalb heißt es bei vielen modernen Chipdesigns, dass der Chip bezüglich der Lötaugen (Pads) begrenzt (pad limited) oder bezüglich der Eingänge/Ausgänge begrenzt (IO limited) ist, was bedeutet, dass bedingt durch die Größe des Chips nicht genügend Platz für alle diejenigen EA-Signale ist, die die Designer gerne von dem Chip weggeleitet haben würden oder die von den Designern von dem Chip eigentlich weg geleitet werden müssten. In solchen Umgebungen können, um die Kosten herabzusetzen, Platz zu sparen und eine verbesserte Sicherheit bereitzustellen, SOCs und Systems in Packages (SiPs) ohne Debug-Schnittstellen konfiguriert werden, was aber Test- und Debuggingoperationen problematisch macht. In solchen Fällen ist eine Analyse entweder nicht durchführbar oder es ist ein beträchtlicher Aufwand erforderlich, um einen Debug-Verbindungsstecker an der Leiterplatte zu einem Zeitpunkt anzulöten, wenn eine Analyse benötigt wird.
In der Druckschrift US 2003/0217306 A1 ist ein Microcomputer gezeigt, der einen sog. ”Hilfs-”Microcontroller mit JTAG-Port und weiteren Schnittstellen zum Test von FPGA Fabric Domains/CPUs aufweist. Die DE 10 2006 016 303 A1 offenbart einen Schaltkreis mit einer Testschnittstelle, welche Daten in einen Datenspeicher schreiben und aus diesem lesen kann, wobei die Testschnittstelle zum Senden und Empfangen von Daten verschiedener Inhaltskategorien für jede Inhaltskategorie jeweils eine separate Signalleitung aufweist. In der Druckschrift US 2006 01 49958 A1 ist ein Code-Download-Verfahren für ein System mit mehreren integrierten Schaltkreisen offenbart. Die US 6 779 145 B1 zeigt ein Verfahren, das ermöglicht, dass ein integrierter Schaltkreis Debugging-Informationen und System-Bus-Transaktions-Informationen an ein externes System kommuniziert. In der US 2006/0161815 A1 ist ein System offenbart, das einen Adapter aufweist, und einen Test-Zugriffs-Port, der in mehreren, verschiedenen, von einer State-Maschine definierten Zuständen betrieben werden kann.
Die Erfindung hat zur Aufgabe, ein neuartiges Debugging-System zur Verfügung zu stellen, insbesondere ein Debugging-System, bei dem ein integrierter Schaltkreis – auf einfache Weise – statt als Master auch als Slave betrieben werden kann.
Die Erfindung erreicht dieses bzw. weitere Ziele durch den Gegenstand des Anspruchs 1. Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.
Vorteilhaft umfasst ein Debugging-System für eine mit einem Einchipsystem (SOC) versehene integrierte Schaltung (IC) (im Folgenden kurz SOC IC Debugging System genannt) eine Vielzahl von SOC ICs (mit einem SOC versehene ICs), die mit einem gemeinsam genutzten Debug-Bus verbunden sind. Eine der Vielzahl von SOC ICs ist eine Master SOC IC, die eine Master/Slave-Debug-Schnittstelle und eine Benutzerschnittstelle aufweist. Die Master/Slave-Debug-Schnittstelle auf der Master SOC IC ist eine bidirektionale Debug-Schnittstelle, die dahingehend betriebsfähig ist, dass sie Debug-Daten zwischen den SOC ICs und einem externen Hostsystem sendet und empfängt. Das Hostsystem ist mit der wenigstens einen der Vielzahl von SOC ICs über die Benutzerschnittstelle verbunden.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 veranschaulicht ein beispielhaftes SOC IC Debugging System in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung; und
2 ist ein Ablaufdiagramm, das ein Verfahren für das Debuggen von mehreren SOC ICs durch eine Benutzerschnittstelle einer Master SOC IC in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
AUSFÜHRLICHE BESCHREIBUNG EINES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS DER ERFINDUNG
1 und 2, die unten erörtert werden, sowie das Ausführungsbeispiel, das verwendet wird, um die Prinzipien der vorliegenden Erfindung zu beschreiben, dienen lediglich Illustrationszwecken und sollen nicht in irgendeiner den Schutzumfang der Erfindung begrenzenden Art und Weise ausgelegt werden. Obwohl diese hier im Hinblick auf SOCs beschrieben werden, wird es den Fachleuten auf diesem Gebiet klar sein, dass die Prinzipien der vorliegenden Erfindung in jeder auf geeignete Weise angeordneten IC- oder System-in-Package-Vorrichtung implementiert werden können.
Allgemein bekannte Schaltungen sind in Blockdiagrammform gezeigt, um die vorliegende Erfindung nicht in unnötigen Einzelheiten schwer verständlich zu machen. Gewisse Einzelheiten in Bezug auf Komponenten der hier beschriebenen SOCs sind hier weggelassen worden, soweit diese Einzelheiten nicht notwendig sind, um ein vollständiges Verständnis der vorliegenden Erfindung zu erhalten, und soweit diese in dem Bereich des Könnens eines Durchschnittsfachmanns auf dem relevanten Fachgebiet liegen.
1 zeigt ein System 100 einer gedruckten Leiterplatte (PCB; printed circuit board) für das Debugging, das Testen und das Überwachen der Leistungsinformationen von mehreren SOCs 102, 104, 106. Obwohl dies in den Figuren nicht explizit gezeigt ist, kann das SOC 102 einen Prozessorkern, eine Busschnittstelle und einen Systembus für die Kommunikation von Informationen umfassen. Das SOC 102 kann des Weiteren eine Maschine zur Verarbeitung digitaler Signale, einen Mehrzweck-Mikroprozessor zur Bereitstellung einer Steuerfunktionalität, einen chipinternen Speicher 126 und eine Speicherkontrolleinheit (nicht gezeigt) für den Zugriff auf den Speicher 126 beinhalten. Die SOCs 104 und 106 können ebenfalls jedes der oben im Hinblick auf das SOC 102 diskutierten Elemente umfassen.
Die SOCs 102, 104 und 106 sind mit einem gemeinsam genutzten Debug-Bus 108 verbunden. Das PCB-System 100 ist mit einem Hostsystem 110 direkt über das SOC 102 verbunden. Obwohl das Hostsystem 110 unabhängig von dem System 100 gezeigt ist, kann für die Zwecke des Debugging und des Testens einer Vielzahl von SOCs eine Verbindung mit dem Hostsystem 110 als ein integraler Teil des Debug-Systems 100 betrachtet werden. Das Hostsystem 110 kann jede Art von Computer sein (z. B. ein Personal Computer, eine Großrechenanlage, ein Minicomputer, ein Netzcomputer, ein Arbeitsstationscomputer, etc.), der eine Hostsoftware laufen lässt, die es einem Benutzer erlaubt, auf eine oder mehrere Komponenten auf den SOCs 102, 104, 106 für das Debugging abzuzielen und Auslöseparameter für die Ablaufverfolgung ihrer Verarbeitungskerne zu spezifizieren.
Das SOC 102 umfasst eine Benutzerschnittstelle 116 für das Verbinden und das Kommunizieren mit dem Hostsystem 110. Die Benutzerschnittstelle 116 kann jede Art von Benutzerschnittstelle sein (z. B. eine SPI-Schnittstelle, eine USB-Schnittstelle, etc.). Das Hostsystem 110 kommuniziert mit dem SOC 102 durch die Benutzerschnittstelle 116 und mit den SOCs 104 und 106 durch den Debug-Bus 108.
Das SOC 102 übermittelt Debug-Daten, wie zum Beispiel Ablaufverfolgungsdaten, Debug-Steuersignale und Statusdaten, zu dem Hostsystem 110 durch die Benutzerschnittstelle 116. Die SOCs 104 und 106, die von dem Hostsystem 110 einem Debugging unterzogen werden sollen, übermitteln ihre Debug-Daten durch die Master/Slave-Debug-Schnittstelle 120 des SOC 102. Folglich übernimmt das SOC 102 die Rolle eines „Master” SOC und wird im Folgenden als Master SOC 102 bezeichnet werden. In ähnlicher Weise fungieren die SOCs 104 und 106 als Slaves für das Master SOC 102. Die Master/Slave-Debug-Schnittstelle 120 ist so konfiguriert, dass sie Transaktionen auf dem Debug-Bus 108 initiiert. Diese Transaktionen können Anweisungen zur Speicherung von Daten in einem Speicher, zum Lesen von Daten aus einem Speicher und zum Übertragen von Daten zu und von einem Hostsystem 110 umfassen, sind aber nicht darauf beschränkt.
Die Master/Slave-Debug-Schnittstelle 120 ist zum Beispiel eine bidirektionale Debug-Schnittstelle mit zwei Pins (CJTAG), wie sie in IEEE 1149.7 definiert ist, die aus einem bidirektionalen Debug-Daten-Pin und einem Debug-Takt-Pin besteht. Eine solche Schnittstelle erlaubt die Übertragung von Befehlen zu der Vorrichtung zur Steuerung des in dem Chip integrierten Debug-Systems und zum Lesen und Schreiben von Daten.
Wie oben kurz erwähnt worden ist, können die Debug-Daten, die durch das Überwachen von einem oder mehreren der SOCs 102, 104 und 106 gesammelt werden, Ablaufverfolgungsdaten enthalten. Eine Ablaufverfolgung ist nützlich, wenn das Verhalten oder Fehlverhalten eines SOC oder seines Verarbeitungskerns oder seiner Verarbeitungskerne analysiert werden soll. Die Ablaufverfolgung kann Probleme in der Programmierung eines SOC-Verarbeitungskerns aufzeigen und auf Fehler in der SOC-Hardware hinweisen. Die Ablaufverfolgung kann man sich als eine externe Aufzeichnung der Aktivität des SOC vorstellen, die ein Benutzer mit Software Tools auf dem Hostsystem 110 abspielen kann, um spezifische interne Operationen verstehen zu können, die das SOC vorgenommen hat, und um zu verstehen, warum es diese unternommen hat.
Die Ablaufverfolgung von externen EA-Signalen eines SOC kann mit anderen Daten erweitert werden, um dem Benutzer eine zusätzliche Sicht in die internen Operationen der SOCs 102, 104 und 106 zu geben. Diese Erweiterung wird erreicht, indem ausgewählte interne Signale der SOCs 102, 104 und 106 als zusätzliche Ausgangssignale an die Außenseite des Systems 100 gebracht werden.
Das System 100 umfasst eine willkürliche Anzahl an SOCs, wobei sich alle SOCs einen einzigen Debug-Bus 108 (z. B. CJTAG) teilen. Wenn die SOCs 102, 104 und 106 mit einem einzigen gemeinsam genutzten Debug-Bus 108 verbunden sind, dann kann ein einzelnes SOC (z. B. das SOC 102) die Rolle eines Tool Hardware Front-End für den Debug-Bus 108 übernehmen. Unter Bezugnahme auf 1 spielt das SOC 102 diese Rolle und kann folglich als „Master SOC 102” bezeichnet werden. Auf der physikalischen Ebene ist die Richtung aller Signale für das Master SOC 102 im Vergleich zu einer herkömmlichen Einstellung umgekehrt, wobei auf alle SOCs einschließlich des Master SOC von dem Debug-Tool her über den auf dem Chip integrierten Debug-Verbindungsstecker zugegriffen wird. In Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung ist die Debug-Schnittstelle des Master SOC 102 in zwei unterschiedlichen Modi betreibbar: In einem Standardmodus (z. B. Rückstellwert) ist sie ein Slave und arbeitet wie die Debug-Schnittstelle jedes anderen SOC, die von dem Debug-Tool über eine Hardware-Schnittstelle, einen Leiterplatten-Steckverbinder und einen Debug-Bus gesteuert wird; in dem zweiten Modus ist sie ein Master, was intern aktiviert wird, die Signalrichtungen sind umgedreht (z. B. Taktausgang anstatt eines Eingangs), und dieser Master steuert die Slave-Debug-Schnittstellen aller anderen SOCs. In dem letztgenannten Modus braucht kein Debug-Tool an dem Debug-Verbindungsstecker auf der Leiterplatte angebracht zu werden.
Das Master SOC 102 wirkt als eine Busbrücke zwischen dem Hostsystem 110, das über die Benutzerschnittstelle 116 angeschlossen ist, und dem Debug-Bus 108. Auf diese Weise greift das Hostsystem 110 auf die SOCs 104 und 106 indirekt durch das Master SOC 102 zu, wobei die Richtung seiner Debug-Schnittstelle umgekehrt ist. Das Master SOC 102 ersetzt effektiv die Notwendigkeit, eine herkömmliche Debug Tool Hardware an der PCB anschließen zu müssen, um Test- und Debugging-Prozeduren durchführen zu können. Statt dessen ist das Master SOC 102 mit einem Debug-Monitor (nicht gezeigt) ausgestattet. Der Debug-Monitor ist vorzugsweise eine Software, die auf dem Master SOC 102 abläuft.
Dieser Debug-Monitor ist zum Beispiel ein Prozess, der in dem Prozessor des Master SOC 102 abläuft. Er wird von dem Betriebssystem aktiviert. Wenn Debug-Anforderungen an der Benutzerschnittstelle 116 ankommen, analysiert der Debug-Monitor diese Anforderungen, plant zeitlich Transfers über den Debug-Bus 108 und sendet die Ergebnisse über die Benutzerschnittstelle 116 zurück. Um die Auswirkungen auf das Echtzeitverhalten des Systems zu begrenzen, können diese Aufgaben über verschiedene Unterbrechungsroutinen (Interrupt Service Routines) und Echtzeitprozesse verteilt sein. Die Fachleute auf diesem Fachgebiet werden erkennen, dass andere Implementierungen mit weniger Softwareteilen und mehr Hardwareteilen der Busbrückenfunktionalität ebenfalls möglich sind.
Das System 100 funktioniert ohne Einschränkungen für den Debug-Steuer- und Statusdatenaustausch, der niedrige bis mittlere Latenzzeit- und Bandbreitenerfordernisse aufweist. Ablaufverfolgungsdaten benötigen eine viel höhere Bandbreite. Wenn die zur Verfügung stehende Bandbreite der Benutzerschnittstelle 116 im Durchschnitt niedriger als diejenige ist, die für die Ablaufverfolgungsdaten benötigt wird, kann ein chipinterner Ablaufverfolgungspufferspeicher (Trace Buffer) (nicht gezeigt) in dem Master SOC 102 verwendet werden, um solche Ablaufverfolgungen von den anderen SOCs 104 und 106 für eine kurze Zeitdauer zu erfassen und abzuspeichern. Wenn die zur Verfügung stehende Bandbreite der Benutzerschnittstelle 116 im Durchschnitt höher als diejenige ist, die für die Ablaufverfolgungsdaten benötigt wird, dann kann die gesamte Ablaufverfolgung über die Benutzerschnittstelle 116 ausgegeben werden.
2 zeigt ein Verfahren des Debuggingsystems 100 von 1. Das Verfahren beginnt mit dem Anschließen eines Hostsystems 110 an der Benutzerschnittstelle 116 des Master SOC 102 (Schritt 210). Dann werden Debug-Daten, die die Aktivität eines oder mehrerer SOCs 104, 106 repräsentieren, von dem Master SOC 102 über den Debug-Bus 108 empfangen (Schritt 220). Diese Daten können vorübergehend von dem Master SOC 102 gespeichert werden (Schritt 230). Das Master SOC 102 überträgt die Debug-Daten für die Analyse über seine Benutzerschnittstelle 116 zu dem Hostsystem 110 (Schritt 240). Schließlich werden die Daten von dem Hostsystem 110 empfangen, bei dem sie von dem Endbenutzer analysiert werden können (Schritt 250).
Einem Fachmann auf dem Fachgebiet wird klar sein, dass zusätzliche Variationen bei dem oben beschriebenen Ausführungsbeispiel durchgeführt werden können, ohne dass von dem Erfindungsgedanken und dem Schutzumfang der Erfindung abgewichen wird, die von den nachfolgenden Ansprüchen definiert wird.

Claims

Debugging-System für eine mit einem Einchipsystem (SOC) versehene integrierte Schaltung (IC), das Folgendes umfasst: eine Vielzahl von SOC ICs (102, 104, 106), die mit einem gemeinsam genutzten Debug-Bus (108) verbunden sind, wobei wenigstens eine der Vielzahl von SOC ICs (102, 104, 106) als Master SOC IC (102) betreibbar ist und eine Master/Slave-Debug-Schnittstelle (120) und eine Benutzerschnittstelle (116) umfasst, wobei die Master/Slave-Debug-Schnittstelle (120) eine bidirektionale Debug-Schnittstelle ist, die so betriebsfähig ist, dass sie in einem Mastermodus Debug-Daten-Signale von den anderen SOC ICs (104, 106) empfängt, und die zudem in einem Slavemodus betriebsfähig ist, in dem die Signalrichtungen gegenüber dem Mastermodus umgedreht sind, wobei ein Hostsystem (110) direkt oder über mehrere Netzwerk- oder Buskomponenten mit der wenigstens einen Master SOC IC (102) durch die Benutzerschnittstelle verbindbar ist.
SOC IC Debugging System nach Anspruch 1, wobei die Benutzerschnittstelle (116) eine USB-Schnittstelle, eine Netzwerkschnittstelle oder eine drahtlose Schnittstelle ist.
SOC IC Debugging-System nach Anspruch 1, wobei das Hostsystem (110) ein Computer ist, der eine Software laufen lässt, die es einem Benutzer erlaubt, auf eine oder mehrere Komponenten der Vielzahl von SOC ICs für das Debugging abzuzielen, wobei die Software so konfiguriert ist, dass sie Ausläseparameter für die Ablaufverfolgung von Verarbeitungskernen der Vielzahl von SOC ICs spezifiziert.
SOC IC Debugging System nach Anspruch 1, wobei die Master/Slave-Debug-Schnittstelle (120) so konfiguriert ist, dass sie Transaktionen auf dem gemeinsam genutzten Bus initiiert, wobei die Transaktionen Anweisungen zum Speichern von Daten in einem Speicher, zum Lesen von Daten aus einem Speicher und zum Übertragen von Daten zu und von dem Hostsystem über die Benutzerschnittstelle umfassen,
SOC IC Debugging System nach Anspruch 1, wobei die Master/Slave-Debug-Schnittstelle (120) eine Debug-Schnittstelle mit zwei Pins ist, die einen Pin für ein Taktsignal und einen zweiten Pin für bidirektionale Daten umfasst.
SOC IC-Debugging System nach Anspruch 1, wobei die wenigstens eine Master SOC IC so konfiguriert sein kann, dass sie als ein Tool Hardware Front-End für den gemeinsam genutzten Debug-Bus funktioniert.
SOC IC Debugging System nach Anspruch 1, wobei die wenigstens eine Master SOC IC als eine Busbrücke zwischen dem Hostsystem und dem gemeinsam genutzten Debug-Bus funktioniert.
SOC IC Debugging System nach Anspruch 1, wobei das Hostsystem mit der wenigstens einen Master SOC IC durch die Benutzerschnittstelle verbunden ist und auf die Nicht-Master SOC ICs indirekt durch die wenigstens eine Master SOC IC zugreift.
SOC IC Debugging System nach Anspruch 1, wobei die wenigstens eine Master SOC IC eine Software umfasst, die als ein Debug-Monitor funktioniert.
SOC IC Debugging System nach Anspruch 1, wobei die wenigstens eine Master SOC IC einen Ablaufverfolgungspufferspeicher (Trace Buffer) zum Erfassen und Speichern von Ablaufverfolgungen von den anderen SOC ICs umfasst.