DE69613979T2

DE69613979T2 - Vorrichtung und verfahren zur verarbeitung ablaufverfolgbarer information

Info

Publication number: DE69613979T2
Application number: DE69613979T
Authority: DE
Inventors: P. Mann
Original assignee: Advanced Micro Devices Inc
Current assignee: Advanced Micro Devices Inc
Priority date: 1995-06-01
Filing date: 1996-05-31
Publication date: 2002-04-04
Anticipated expiration: 2016-06-01
Also published as: US6023561A; WO1996038791A1; EP0829050A1; DE69613979D1; EP0829050B1

Description

Hintergrund der Erfindung

Die vorliegende Erfindung bezieht sich auf Mikroprozessoren und insbesondere auf Ablaufverfolgungsinformationen von einem von einem Mikroprozessor bereitgestellten verfolgbaren Cache-Speichers.
Es ist bekannt, einen Mikroprozessor mit dem Merkmal eines verfolgbaren Cache-Speichers auszustatten. Z.B. ist unter der Handelsbezeichnung Am29040 ein Prozessor erhältlich, der von Advanced Micro Devices mit Sitz in Sunnyvale, Kalifornien, angeboten wird, welcher das Merkmal eines verfolgbaren Cache-Speichers aufweist. Das Merkmal eines verfolgbaren Cache-Speichers erlaubt es einem Hardware-Entwicklungssystem die Ausführung des Prozessor zu verfolgen, während der Prozessor aus dem Cache- Speicher heraus arbeitet.
Die Ablaufverfolgung eines Cache-Speichers wird erzielt, indem zwei Prozessoren in Tandemanordnung benutzt werden; ein Hauptprozessor und ein Ablaufverfolgungsprozessor. Der Hauptprozessor führt alle erforderlichen Operationen aus und der Ablaufverfolgungsprozessor dupliziert die Operation des Hauptprozessors mit der Ausnahme, dass der Ablaufprozessor bestimmte Ausgänge benutzt, welche als Slave- oder Ablaufverfolgungsausgänge bezeichnet werden, um die Ablaufverfolgung der Instruktion anzuzeigen. Die Slave-Ausgänge umfassen die Adressleitungen des Ablaufverfolgungsprozessors und auch die REQ#-, die R/W#- und I/D#-Leitungen des Ablaufverfolgungsprozessors. Der Ablaufverfolgungsprozessor ist mit dem Hauptprozessor parallel geschaltet; jedoch sind alle der s-Ausgänge des Ablaufverfolgungsprozessors gesperrt. Diese Anordnung ist ähnlich zu einer Master/Slave-Beziehung mit der Ausnahme, dass die Slave-Ausgänge des Ablaufverfolgungsprozessors nicht mit dem Hauptprozessor verbunden sind. Da der Ablaufverfolgungsprozessor die Slave-Ausgänge zum Anzeigen der Ablaufverfolgung der Instruktion benutzt, verlässt sich der Ablaufverfolgungsprozessor auf den Hauptprozessor bei der Ausführung aller Zugriffe für den Ablaufverfolgungsprozessor. Der Ablaufverfolgungsprozessor sammelt die Ergebnisse der Zugriffe des Hauptprozessors, Alle Ausgänge des Prozessor zu dem System werden von dem Hauptprozessor gesteuert. Der Adressbus des Ablaufverfolgungsprozessors zeigt gemeinsam mit dem Signal REQ#, R/W# und I/D# den internen s-Zugriff des Prozessors auf die Instruktions- und Daten-Cache-Speicher an.
Da der Hauptprozessor mehr als einen Cache-Speicherzugriff pro Takt ausführen kann (einen Zugriff auf einen Instruktions-Cache-Speicher und einen Zugriff auf einen Daten-Cache-Speicher), betrachtet der Ablaufverfolgungsprozessor nicht alle Instruktionszugriffe sondern lediglich jene Zugriffe, welche mit Verzweigungszielen zusammenhängen. Weit Verzweigungen, Laden und Speichern von separaten Instruktionen veranlasst werden, kann der Prozessor nicht mehr als ein Verzweigungsziel oder einen Datenzugriff per Takt ausführen. Entsprechend kann ein Hardware-Entwicklungssystem die Sequenz der Instruktionsausführung aus der Sequenz der Adressen der Verzweigungsziele rekonstruieren.
Wenn der Hauptprozessor eine Abzweigung nimmt, deren Zieladresse den Cache-Speicher trifft, erscheint die physikalische Adresse der Verzweigungszielinstruktion auf dem Adressbus des ablaufverfolgten Cache-Speichers. Wenn der Hauptprozessor eine Verzweigung nimmt, betrachtet der Ablaufverfolgungsprozessor das Verzweigungsziel.
Wenn ein Laden oder Speichern in den Daten-Cache-Speicher trifft, treibt der Ablaufverfolgungsprozessor die entsprechende physikalische Adresse auf den Adressbus. Die Speicher-Adresse wird betrachtet, wenn das Speichern unter Beibehaltung der ordentlichen Abfolge mit Laden in den Schreibpuffer angeordnet wird. Die Speicher-Daten werden nicht betrachtet. Sobald das Speichern in dem Schreibpuffer angeordnet ist, führt der Ablaufverfolgungsprozessor keine weiteren Aktionen, welche mit dem Speichern zusammenhängen, aus, mit der Ausnahme des Schreibens der Daten in den Cache-Speicher, wenn der entsprechende Block in dem Cache-Speicher ist. Alle anderen notwendigen Aktionen, wie etwa Write-Through, werden von dem Hauptprozessor ausgeführt und erscheinen daher auf dem Bus des Hauptprozessors.
Es ist ebenso bekannt, einen Prozessor vorzusehen mit Status-Ausgangssignalen, welche Informationen über Prozessormodi anzeigen zusammen mit anderen Informationen über die Prozessoroperation. Z.B. können die Status-Ausgangssignale anzeigen, wann der Prozessor sich in einem Haltemodus befindet, wenn der Prozessor in einem Pipeline-Haltemodus ist, wenn der Prozessor in einem Lade-Test-Instruktionsmodus ist, wenn ein Prozessor im Wartemodus ist, wenn eine Interrupt-Rückkehr erzeugt ist, wenn ein Prozessor einen Interrupt oder eine Falle bearbeitet, wenn ein Prozessor ein nicht sequentielles Holen einer Instruktion bearbeitet oder wenn ein Prozessor in einem Ausführungsmodus ist.
US 5,694,420 (Fig. 5) und US S 321 828 (Fig. 10) zeigen einen Satz von Assembler-Sprache-Kürzeln, welche von einem inversen Assemblierungsprozess stammen.

Zusammenfassung der Erfindung

Die vorliegende Erfindung betrifft ein System zum Anwenden von Ablaufverfolgungsinformation eines Cache-Speichers. Das System greift auf Ablaufverfolgungsdaten zu und rekonstruiert einen Ausführungspfad und Datenzugriffe, die von dem ablaufverfolgten Programm ausgeführt werden.
Genauer gesagt bezieht sich die Erfindung in einem bevorzugten Ausführungsbeispiel auf ein Verfahren zur Ablaufverfolgung der Operation eines Prozessors zwecks Bereitstellung einer Ablaufverfolgungs-Ausgabe entsprechend Operationszyklen des Prozessors. Das Verfahren umfasst das Erfassen einer Ablaufverfolgung der Prozessoroperation, das Bereitstellen der Ablaufverfolgung in Form selektierter Testdaten, das Verarbeiten von Datenzugriffen auf die selektierten Testdaten und das Verarbeiten von Befehlen der selektierten Testdaten basierend auf der Detektion eines nicht sequentiellen Befehls mit einer Zieladresse. Der Schritt des Verarbeitens von Befehlen verwendet die Zieladresse des nicht sequentiellen Befehls zum Bestimmen eines Befehlsflusses entsprechend der Zieladresse.
Des weiteren bezieht sich die Erfindung in einer alternativen Ausführungsform auf eine Ablaufverfolgungs-Analysevorrichtung zur Ablaufverfolgung der Operation von selektierten Testdaten eines Prozessors. Die Vorrichtung enthält eine Einrichtung zum Erfassen einer Ablaufverfolgung der Prozessoroperation, ein Prozessdatenmodul und ein Prozessbefehlsmodul. Das Prozessdatenmodul verarbeitet Datenzugriffe auf die selektierten Testdaten. Das Prozessbefehlsmodul verarbeitet die Befehlsausführung der selektierten Testdaten basierend auf der Detektion eines eine Zieladresse aufweisenden nicht sequentiellen Befehls. Das Prozessorbefehlsmodul benutzt die Zieladresse des nicht sequentiellen Befehls zum Bestimmen eines Befehlsflusses entsprechend der Zieladresse.

Kurzbeschreibung der Zeichnungen

Fig. 1 zeigt ein Blockdiagramm eines Computersystems, welches ein Ablaufverfolgungs-Analysesystem umfasst.
Fig. 2A bis 2C zeigen Bildschirmdarstellungen des Bildschirms des Ablaufverfolgungs-Analysesystems aus Fig. 1.
Fig. 3 zeigt ein Flussdiagramm der Operation des Ablaufverfolgungs- Analysesystems aus Fig. 1.
Fig. 4 zeigt ein Flussdiagramm des Erzeuge-entsprechende Instruktion- Schrittes aus dem Flussdiagramm von Fig. 3.
Fig. 5 ist ein diagrammartiges Blockdiagramm einer beispielhaften Instruktionsverarbeitungssequenz.
Fig. 6 zeigt ein Flussdiagramm des Prozessdatenmoduls aus dem Flussdiagramm von Fig. 4.
Fig. 7 ist ein Flussdiagramm eines Bearbeite-Daten-Cache-Speichertreffers-Schrittes des Prozessdatenmoduls aus Fig. 6.
Fig. 8 ist ein Flussdiagramm eines Bearbeite-externen Datenzugriff- Schrittes des Prozessdatenmoduls aus Fig. 6.
Fig. 9 ist ein Flussdiagramm eines Bearbeite-Datenbündelzugriff-Schrittes des Prozessdatenmoduls aus Fig. 6.
Fig. 10 ist ein Flussdiagramm des Bearbeite-Vektorabruf-Schrittes des Prozessdatenmoduls aus Fig. 6.
Fig. 11 zeigt ein Flussdiagramm des Bearbeite-Instruktions-Schrittes des Flussdiagramms aus Fig. 6.
Fig. 12 zeigt ein Flussdiagramm des Berechne-Adress-Schrittes des Flussdiagramms aus Fig. 11.
Fig. 13 zeigt ein Flussdiagramm des Berechne-Instruktions-Schrittes des Flussdiagramms aus Fig. 12.

Detaillierte Beschreibung

Das folgende setzt eine detaillierte Beschreibung des besten angenommenen Modus zum Ausführen der Erfindung fort. Die Beschreibung soll die Erfindung erläutern und nicht als limitierend angesehen werden.
Fig. 1 zeigt ein System 10 mit einem Zielsystem 12 und einem Testsystem 14. Das Zielsystem 12 umfasst einen Verbindungsanschluss 22, an welchen ein Prozessor gekoppelt werden kann. Das Zielsystem 12 umfasst des weiteren einen Testbereich 24 mit einem Hauptprozessor 26 und einem Ablaufverfolgungsprozessor 28, welche parallel an den Verbindungsanschluss 22 angeschlossen sind. Der Testbereich 24 ist angeschlossen, um den Stiftanschlüssen des Verbindungsanschlusses 22 zu entsprechen, als ob ein Prozessor an den Verbindungsanschluss 22 angeschlossen wäre. D.h. die Verbindung des Testbereichs 24 an den Verbindungsanschluss 22 ist stiftkompatibel mit den Stiften des Prozessors 26. Der Testbereich 24 umfasst auch eine Joint Test Action Group (JTAG)-Treiberschaltung 29, welche den Ablaufverfolgungsprozessor 28 veranlasst, in einem Slave-Operationsmodus zu arbeiten. Der Hauptprozessor 26 und der Ablaufverfolgungsprozessor 28 des Testbereichs 24 ist ebenso an das Testsystem 14 angeschlossen.
Genauer gesagt sind alle Signalpfade, welche von dem Hauptprozessor 26 bereitgestellt werden, an das Testsystem 14 angeschlossen. Zusätzlich sind der Adresssignalpfad (S ADDR), als auch der s-Anfrage (S REQ# )-Signalpfad des Ablaufverfolgungsprozessors, der s Lese/Schreib (S R/W# )-Signalpfad des Ablaufverfolgungsprozessors und der s Instruktions- oder Datenzugriff (S I/D#)-Signalpfad des Ablaufverfolgungsprozessors separat mit dem Testsystem 14 verbunden.
Das Testsystem 14 umfasst einen Logikanalysator 30 und auch ein Testcomputersystem 32. Das Testcomputersystem 32 enthält einen mit einem Speicher 42 verbundenen Prozessor 40. Der Speicher 42 umfasst ein Ablaufverfolgungs-Analysesystem 44, welches von dem Prozessor 40 ausgeführt wird. Das Testcomputersystem 32 kann auch einen Bildschirm 46 umfassen, über den Ergebnisse von Tests angezeigt werden können.
Fig. 2A zeigt eine Bildschirmdarstellung, welche von dem Prozessor 40 erzeugt ist und auf dem Bildschirm 46 des Testcomputersystems 32 dargestellt ist. Genauer gesagt umfasst die Bildschirmdarstellung 50 ein Fenster 52 mit Original-Ablaufvertolgungsdaten, ein Fenster 54 mit Assembliersprache und ein Fenster 56 mit Quellcode. Das Fenster 52 mit den Original- Ablaufverfolgungsdaten umfasst Spalten, welche den verschiedenen Verbindungen zwischen dem Logikanalysator 30 und dem Testbereich 24 entsprechen. Genauer gesagt enthält das Fenster 52 mit den Original-Ablaufverfolgungsdaten eine Zeilennummer-Spalte (Label), eine Adressen-Spalte (ADDR), eine Daten-Spalte (DATA), eine Status-Spalte (*STAT_), eine Bereitsignal-Spalte (_RDY), eine Slave-Instruktions/Daten-Cache-Speicher- Treffersignal-Spalte (S I/D#), eine Bündel-Spalte (BURST) und eine Slave- Adress-Spalte (S ADDR). Das Fenster 54 mit Assembliersprache umfasst Spalten entsprechend einer Zeilennummer, einer symbolischen Anzeige einer äquivalenten Adresse (SYMADDR), einer Anzeige für disassemblierte Daten (ASMDATA), einer Anzeige für Lesen/Schreiben (R/W#) und einer Statusanzeige (*STAT). Das Fenster 56 mit Quellcode umfasst eine Zeilennummer-Spalte und einen Code-Bereich.
Die Fig. 2B und 2C zeigen weitere Beispiele eines Fensters 52 mit Original- Ablaufverfolgungsdaten und eines Fensters 54 mit Assembliersprache.
Fig. 3 ist ein Flussdiagramm der Operation des Testsystems 14. Wenn eine Ablaufverfolgungsanalyse gestartet wird, wird der Logikanalysator 30 konfiguriert, um Testdaten von dem Testbereich 24 im Datenmischer-Schritt 60 zu beschaffen. D.h., der Logikanalysator 30 bildet eine Ablaufverfolgung der Operation des Hauptprozessors 26 ab. Diese Testdaten umfassen Daten für jeden Taktzyklus des Testbereichs 24. Die Testdaten umfassen das Adresssignal (ADDR), das Lese/Schreib-Signal (R/W#), das Bereit-Signal (RDY#), das Instruktions- oder Datenzugriffs-Signal (I/D#) und das Status-Signal (STAT) von dem Hauptprozessor 26. Die Testdaten umfassen auch das Slave-Adress-Signal (S ADDR), das Slave-Bündel-Signal (S BURST), das Slave-Anfrage-Signal (S REQ#), das Slave-Lese/Schreib-Signal (S R/W#) und das Slave-Instruktions- oder Datenzugriffs-Signal (S I/D#).
Als nächstes geht die Steuerung an den Datentransfer-Schritt 62 über, während welchem ein Bereich der Daten, der von dem Logikanalysator beschafft wurde (d. h. ein Bereich der abgebildeten Ablaufverfolgung), selektiv von dem Logikanalysator 30 an den Speicher 42 des Testcomputersystems 32 übertragen wird. Der Teil der Daten, welcher selektiv übertragen wird, fängt mit einer Verzweigungsinstruktion an und läuft dann weiter, so dass der Bereich der interessierenden Ablaufverfolgungsdaten, d.h. der Bereich der debugged werden soll, in den selektierten Testdaten enthalten ist. Dieser Transfer platziert die transferierten Daten in eine Form, auf die effizienter zugegriffen werden kann. Auf die Daten kann effizienter zugegriffen werden, weil sie in dem Speicher 42 des Testcomputersystems 32 enthalten sind und daher auf sie von dem Prozessor 40 des Testcomputersystems 32 besser zugegriffen werden kann. Darüber hinaus sind die selektierten Testdaten wesentlich kleiner, d.h. sie umfassen weniger Zeilen als die tatsächlich abgebildete Testanordnung; daher muss der Prozessor 40 nicht auf so viele Zeilen zugreifen, wenn er das Ablaufverfolgungs-Analysesystem 44 ausführt.
Die Steuerung schreitet dann weiter voran zu dem Erzeugen von Assembliercode-Schritt 44, wobei während dieses Schrittes Assembliercode erzeugt wird, welcher den Daten entspricht, welche von dem Logikanalysator 30 beschafft worden sind und im Speicher 44 gespeichert worden sind. Der Assembliercode wird von dem Prozessor 40 erzeugt, der das Ablaufverfolgungs-Analysesystem 44 ausführt und auf die selektierten Testdaten zugreift, welche von dem Logikanalysator 30 beschafft worden sind und im Speicher 44 gespeichert worden sind. Der Assembliercode wird dann während eines Anzeigen des Assembliercode-Schrittes 65 in dem Fenster 54 für Assembliercode dargestellt in einem Format, welches eine Fehlersuche der Operation des Hauptprozessors 26 ermöglicht.
Nachdem der Assembliercode erzeugt wurde, wird der entsprechende Quellcode im Erzeugen-Quellcode-Schritt 66 hergestellt. Genauer gesagt benutzt das Ablaufverfolgungs-Analysesystem 44 eine Datei mit einem allgemeinen Objekt-Dateiformat (COFF), welche den selektierten Testdaten entspricht, um einen zu dem hergestellten Assembliercode entsprechenden Quellcode zu erzeugen. Der Quellcode wird dann während eines Anzeige-des Quellcodes-Schrittes 67 in dem Fenster 56 für den Quellcode präsentiert, und zwar in einem Format, welches die Fehlersuche des Betriebs des Hauptprozessors 26 erlaubt. In diesem Fenster wird eine Zeile des Codes hervorgehoben, welche der aktuellen Ablaufverfolgungsposition entspricht.
Nachdem der gesamte Testcode verarbeitet worden ist, schließt das Ablaufverfolgungs-Analysesystem seinen Betrieb ab.
Fig. 4 ist ein Blockdiagramm des Betriebs des Erzeugens von Assembliercode-Schrittes 64 des Ablaufverfolgungs-Analysesystems 44. Der Erzeuge- Assembliercode-Schritt 64 umfasst das Prozessdatenmodul 70 und das Prozessbefehlsmodul 72. Das Verarbeiten der selektierten Testdaten verläuft sequentiell durch die selektierten Testdaten zuerst für das Prozessdatenmodul und dann für das Prozessbefehlsmodul. Nach dem Bearbeiten einer selektierten Testdaten endete der Erzeuge-Assembliercode-Schritt 64.
Während der Operation des Prozessdatenmoduls 70 werden Datenzugriffe untersucht, um festzustellen, ob irgendwelche wiederholten Zugriffe infolge von skalierter Taktung aufgetreten sind. Bei skalierter Taktung ist die interne Taktgeschwindigkeit des Prozessors schneller als die Taktgeschwindigkeit der externen Speicherzugriffe und daher werden die erkannten Zugriffe verdoppelt. Weil die Ablaufverfolgungsinformation mit der internen Taktgeschwindigkeit des Prozessors abgebildet wird, werden Zugriffe auf den Speicher entsprechend mehrere Male in benachbarten Ablaufverfolgungszyklen abgebildet. Lediglich die letzte abgebildete Ablaufverfolgung wird als gültig angesehen.
Der Datentransfer, hervorgerufen durch einen Lade- oder Speicher-Befehl, kann während des gleichen Taktes auftreten, indem ein weiterer Befehl ausgeführt wird. Wenn dies auftritt, bewegt das Ablaufverfolgungs-Analysesystem 44 die Benachrichtigung des Datenzugriffes zu einem zukünftigen Ablaufverfolgungszyklus, welcher keine gültige Ablaufverfolgungsinformation enthält. Wenn ein weiterer Datentransfer auftritt, bevor der vorherige gemeldet worden ist, dann wird der vorherige Datenwert nicht gemeldet. Die R/W#- und I/D#-Information wird, wo es notwendig und möglich ist, umpositioniert, um aufgetretene Datenzugriffe zu melden. Jedoch werden Datenbündel-Zugriffe, wie die Lademehrfach (LOADM)- und Speichermehrfach (STOREM)-Datenzugriffe, gemeldet, bevor die Ausführung eines Befehls gemeldet wird.
Unter Benutzung der von dem Ablaufverfolgungsprozessor 28 bereitgestellten Daten werden Datenzugriffe, welche einen Cache-Speichertreffen erzeugen, auf die gleiche Weise wie externe im Speicher befindliche Datenzugriffe gemeldet. Wenn ein Datentransfer auftritt, wird dies in dem nächsten verfügbaren Takt (welches der aktuelle Takt sein kann), welcher nicht benutzt wird, zur Meldung einer Ausführung einer Instruktion oder anderen gültigen Datenzugriffen, gemeldet. Wenn der Daten-Cache-Speicher angeschaltet wird, ist es nicht immer möglich, den Wert der transferierten Daten zu melden. Der Ablaufverfolgungsprozessor 28 stellt nicht die zwischengespeicherten Datenwerte bereit sondern nur die Adresse. Bei Vektorabrufen werden der Vektorabruf und die Adresse der ersten Instruktion als auch der Status des Vektorabrufs im derzeitigen Takt gemeldet.
Nachdem die Daten bearbeitet worden sind, wird die Steuerung an das Prozessinstruktionsmodul 72 übergeben. Das Prozessinstruktionsmodul 72 produziert einen vollständigen Adressfluss für den auszuführenden Code. Das Prozessinstruktionsmodul 72 enthält ein rekursives Adresserzeugungsmodul, welches basierend auf dem Vorhandensein von nicht sequentiellen wie beispielsweise Sprung-Instruktionen aufeinanderfolgende Instruktionsausführungssequenzen bestimmt.
Beispielsweise zeigt Fig. 5 ein Beispiel des Betriebs des Prozessinstruktionsmoduls 72. Das Adresserzeugungsmodul beginnt mit einer Verzweigungsinstruktion und stoppt, wenn es eine Verzögerungsslot-Instruktion erreicht. Verzweigungsinstruktionen initiieren neue Instruktionssequenzen zum rekursiven Bearbeiten durch das Prozessinstruktionsmodul 72. Da das Testcomputersystem 32 leicht diejenige Adresse detektieren kann, welche dem Verzweigungsziel entspricht, stellen Verzweigungsinstruktionen einen wünschenswerten Startpunkt zum Rekonstruieren des Ausführungspfades von einem ablaufverfolgten Programm dar.
Sobald der Adressfluss bestimmt ist, bestimmt ein ebenfalls rekursives Instruktionskalkulationsmodul die Instruktion, welche dem Adressfluss entspricht. Oftmals werden diese Instruktionen aus dem Speicher abgerufen und können in dem Datenfeld eines vorherigen Ablaufverfolgungszyklus gefunden werden. Wenn die Instruktion jedoch von dem Instruktions-Cache- Speicher bereitgestellt wird, dann wird während des Datentransfer-Schrittes 62 ein Wert von XXXXXXXX in das Datenfeld eingetragen. Wenn ein Adresswert in einem Textbereich des ablaufverfolgten Programms liegt, d.h. in einer Region, welche ausführbaren Code umfasst, und der Datenwert DATA, welcher während des Transferdaten-Schritts 62 erzeugt wurde, als XXXXXXXX markiert ist, dann wird der mit der Instruktion korrespondierende Source-Code aus der COFF-Datei gewonnen, welche dem Ablaufverfolgungsprogramm entspricht. Dieser Quellcode wird während des Erzeuge- Quellcode-Schrittes 66 (Fig. 3) in dem Datenfeld platziert.
Fig. 6 ist ein Blockdiagramm des Betriebs des Prozessdatenmoduls 70. Das Prozessdatenmodul 70 startet durch das Auffinden von Datenzugriffen im Datenzugriffs-Schritt 90. Während des Datenzugriffs-Schrittes 90 werden Wiederholungen von Daten entfernt, die erzeugt werden können, da ein interner Takt schneller ist als ein externer Takt. Diese Wiederholungen von Daten werden detektiert durch das Auffinden von sich wiederholenden Adressen. Die Steuerung führt dann weiter zu einem Cache-Speichertreffer- Schritt 92, wo eine ausgewählte Reihe der selektierten Testdaten bearbeitet wird, um einen Daten-Cache-Speichertreffer zu detektieren. Während des Cache-Speichertreffer-Schrittes 92 wird die Reihe der ausgewählten Testdaten bearbeitet und ein Daten-Cache-Speicher, so er entdeckt wird, wird gemeldet. Nachdem eine ausgewählte Reihe der selektierten Testdaten für einen externen Datenzugriff bearbeitet wurde, geht die Steuerung weiter zu Schritt 98 zum Verarbeiten von Zugriffen auf Datenbündel. Während des Verarbeitens von Zugriffen auf Datenbündel-Schrittes 98 wird die Reihe der selektierten Testdaten bearbeitet, um zu bestimmen, ob ein Datenbündelzugriff aufgetreten ist. Wenn ein Bündelzugriff vorhanden ist, wird dieser Zugriff gemeldet. Die Bearbeitung schreitet dann fort, indem bestimmt wird, ob die gesamte ausgewählte Testdatenprobe bearbeitet wurde für Daten- Cache-Speichertreffer, externe Datenzugriffe und Datenbündelzugriffe, was im Probevollständig-Schritt 99 geschieht. Wenn die Bearbeitung der Probe nicht vollständig ist, geht die Steuerung an Bearbeite-Daten-Cache- Speichertreffer-Schritt 92 über, um die nächste Reihe der selektierten Testdaten auf Daten-Cache-Speichertreffer, externe Datenzugriffe und Datenbündelzugriffe zu untersuchen. Nachdem die Bearbeitung der Probe auf Daten-Cache-Speichertreffer, externe Datenzugriffe und Datenbündelzugriffe vollständig ist, geht die Steuerung auf den Verarbeite-Vektorabruf- Schritt 100 über. Während des Verarbeite-Vektorabruf-Schrittes 100 werden alle Zeilen der zugegriffenen Daten bearbeitet, um zu bestimmen, ob ein irgendein Vektorabruf aufgetreten ist. Wenn beliebige Vektorabrufe aufgetreten sind, werden diese Vektorabrufe gemeldet. Nachdem alle Vektorabrufe bearbeitet worden sind, dann ist Operation des Prozessormoduls 70 vollständig und die Steuerung geht über an das Prozessinstruktionsmodul 72.
Fig. 7 ist ein Flussdiagramm, dass die Operation des Bearbeite-Daten- Cache-Speichertreffer-Schrittes 92 darstellt. Der Bearbeite-Daten-Cache- Speichertreffer-Schritt 92 startet durch das Detektieren von Daten-Cache- Speichertreffern bei dem Detektiere-Daten-Cache-Speichertreffer-Schritt 110. Ein Daten-Cache-Speichertreffer wird detektiert durch das Betrachten des S I/D-Signals, um zu bestimmen, wann ein Cache-Speichertreffer auftritt, gemeinsam mit der Betrachtung des S REQ-Signals, um zu bestimmen, ob ein Cache-Speichertreffer gültig ist. Nachdem ein gültiger Cache- Speichertreffer detektiert wurde, wird dieser Cache-Speichertreffer in dem Melden-Daten-Cache-Speichertreffer-Schritt 112 gemeldet.
Während des Melden-Daten-Cache-Speichertreffer-Schrittes 110 sucht der Prozessor 40 nach einem verfügbaren Takt, um einen Daten-Cache- Speichertreffer zu melden, Da eine Instruktion in dem gleichen Takt wie der Daten-Cache-Speichertreffer ausgeführt worden sein kann, findet das Ablaufverfolgungs-Analysesystem 44 einen verfügbaren Takt, um den Daten- Cache-Speichertreffer zu melden. Wenn in dem Prozess des Findens eines verfügbaren Taktes ein weiterer Daten-Cache-Speichertreffer auftritt, dann wird der erste Daten-Cache-Zugriff fallengelassen und der Prozessor 40 setzt das Suchen für einen verfügbaren Takt zu melden dieses darauffolgenden detektierten Daten-Cache-Speichertreffers fort. Dieser Prozess kann sich wiederholen, wenn ein weiterer Daten-Cache-Speichertreffer detektiert wird. Im Endeffekt meldet das System 44 den zuletzt detektierten Daten- Cache-Speichertreffer. Nachdem ein Takt gefunden worden ist, um den zuletzt detektierten Daten-Cache-Speichertreffer zu melden, werden die selektierten Testdaten durchgesehen, um zu bestimmen, ob das Verarbeiten für Cache-Speichertreffer vollständig ist, was im Schritt 114 geschieht. Wenn das Bearbeiten der selektierten Testdaten für Daten-Cache-Speichertreffer vollständig ist dann transferiert die Steuerung auf den Verarbeiteexterne Datenzugriffe-Schritt 96.
Fig. 8 ist ein Flussdiagramm, das die Operation des Bearbeite-externe Datenzugriffe-Schrittes 96 zeigt. Der Bearbeite-externe Datenzugriffe- Schritt 96 startet durch das Detektieren von externen Datenzugriffen im Detektiere-externe Datenzugriffe-Schritt 120. Ein externer Datenzugriff wird detektiert, indem bestimmt wird, wann das RDY-Signal niedrig ist und das I/D#-Signal niedrig ist. Nachdem ein externer Datenzugriff detektiert ist, wird dieser externe Datenzugriff im Melde-externen Datenzugriff-Schritt 122 gemeldet.
Während des Melde-externen Datenzugriff-Schrittes 122 sucht der Prozessor 40 für einen verfügbaren Takt um den externen Datenzugriff zu melden. Da eine Instruktion im gleichen Takt wie der externe Datenzugriff ausgeführt worden sein kann, findet das Ablaufverfolgungs-Analysesystem einen verfügbaren Takt, um den Daten-Cache-Speichertreffer zu melden. Wenn in dem Prozess des Findens eines verfügbaren Taktes ein weiterer externer Datenzugriff auftritt, dann wird der erste externe Zugriff fallengelassen und der Prozessor 40 setzt die Suche nach einem verfügbaren Takt zu melden dieses darauffolgenden detektierten externen Datenzugriffes fort. Dieser Prozess kann sich wiederholen, wenn ein weiterer externer Datenzugriff detektiert wird. Auf jeden Fall meldet das System 44 den als letzten detektierten externen Datenzugriff. Nachdem ein Takt gefunden wurde, um den als letzten detektierten externen Datenzugriff zu melden, werden die selektierten Testdaten durchgesehen, um zu bestimmen, ob die Bearbeitung für die externen Datenzugriffe vollständig ist, was in Schritt 124 geschieht. Wenn die Verarbeitung der selektierten Testdaten für externe Datenzugriffe vollständig ist, dann geht die Steuerung über auf den Verarbeite-Datenbündelzugriffs-Schritt 98.
Fig. 9 ist ein Flussdiagramm, das die Operation des Verarbeite-Datenbündelzugriffs-Schrittes 98 zeigt. Der Verarbeite-Datenbündelzugriffs-Schritt 98 startet durch das Detektieren von Zugriffen auf Datenbündel im Detektieren von Zugriff auf Datenbündel-Schritt 130. Ein Zugriff auf Datenbündel wird detektiert, indem festgestellt wird, wann das BURST-Signal niedrig ist. Nachdem ein Zugriff auf ein Datenbündel detektiert ist, wird dieser Zugriff auf ein Datenbündel im Melden eines Zugriffes auf ein Datenbündel-Schritt 132 gemeldet.
Während des Meldens eines Zugriffes auf einen Datenbündel-Schritt 132 meldet der Prozessor 40 den Zugriff auf ein Datenbündel in dem gleichen Takt, in dem der Zugriff auf ein Datenbündel aufgetreten ist. Es besteht keine Möglichkeit für das Ausführen einer Instruktion während eines Taktes, in dem ein Zugriff auf ein Datenbündel auftritt. Wenn das Verarbeiten der selektierten Testdaten für Datenbündelzugriffe vollständig ist, dann geht die Steuerung an den Probevollständig-Schritt 99 über.
Fig. 10 ist ein Flussdiagramm, das die Operation des Verarbeite-Vektorabruf-Schrittes 100 zeigt. Der Verarbeite-Vektorabruf-Schritt 100 startet durch das Detektieren von Vektorabrufen im Detektiere-Vektorabruf-Schritt 140. Ein Vektorabruf wird detektiert durch das Betrachten des Status-Signals STAT, um festzustellen, wann ein Vektorabruf auftritt, was durch einen Wert angezeigt wird, welcher anzeigt, dass der Hauptprozessor 26 einen Interrupt oder eine Falle nimmt. Nachdem ein Vektorabruf detektiert ist, wird dieser Vektorabruf im Meide-Vektorabruf-Schritt 142 gemeldet.
Während des Melde-Vektorabruf-Schrittes 142 meldet der Prozessor 40 den Vektorabruf in dem gleichen Takt, in dem der Vektorabruf aufgetreten ist. Es besteht keine Möglichkeit für das Auftreten einer Ausführung einer Instruktion während eines Taktes, in dem eine Vektorabrufoperation auftritt. Wenn die Verarbeitung der selektierten Testdaten für Vektorabrufe vollständig ist, dann ist das Prozessdatenmodul 70 vollständig und die Steuerung geht auf das Prozessinstruktionsmodul 72 über.
Fig. 11 ist ein Flussdiagramm, das die Operation des Prozessinstruktionsmoduls 72 zeigt. Wie zuvor unter Bezugnahme auf Fig. 5 diskutiert wurde, beginnt das Verarbeiten von Instruktionen durch das Durchsuchen der selektierten Testdaten auf Verzweigungsinstruktionen im Suche nach Verzweigung-Schritt 150. Wenn eine Verzweigungsinstruktion gefunden wird, geht die Steuerung an den Berechne-Adresse-Schritt 152 über, während welchem die Adresse für die Verzweigung berechnet wird. Da Verzweigungsinstruktionen immer von einer Verzögerungsslot-Instruktion gefolgt werden, welche immer ausgeführt werden, kann die aktuelle Instruktionssequenz verfolgt werden.
Nachdem der Berechne-Adresse-Schritt 152 beendet ist, geht die Steuerung auf Schritt 154 über, während welchem die selektierten Testdaten nochmals betrachtet werden, um festzustellen, ob das Verarbeiten der selektierten Testdaten vollständig ist. Ist dies der Fall, dann ist das Verarbeiten der selektierten Testdaten abgeschlossen. Ist dies nicht der Fall, dann geht die Steuerung zurück zum Suche nach Verzweigungen-Schritt 150, um für die nächste Verzweigung in der Instruktionssequenz der selektierten Testdaten zu suchen. Wenn keine Verzweigung gefunden wurde, nachdem alle der selektierten Testdaten durchsucht worden sind, dann ist das Prozessinstruktionsmodul 72 vollständig abgeschlossen.
Fig. 12 zeigt die Operation des Berechne-Adresse-Schrittes 152. Dem Berechne-Adresse-Schritt 152 werden die Parameter STAT, ADDR, S ADDR, RDX und I/D# als auch der Parameter b, welcher anzeigt, dass eine Instruktion eine Verzweigungsinstruktion ist, zugeführt. Der Berechne- Adresse-Schritt 152 startet, indem die Adresse für das Ziel der Verzweigungsinstruktion im Schritt 170 bestimmt wird. Diese Adresse wird bestimmt durch das Durchsehen der Adressdaten in dem Zyklus, welcher dem Zeitpunkt entspricht, wenn die Verzweigungsinstruktion ausgegeben wird. Diese Daten werden von der Information abgeleitet, welche durch den Hauptprozessor 26 und den Ablaufverfolgungsprozessor 28 bereitgestellt wird.
Nachdem die Verzweigungszieladresse bestimmt ist, wird die selektierte Dateninstruktionssequenz bearbeitet, um die nächste gültige Instruktion zu finden, was im Schritt 174 geschieht. Dieses ist die Verzögerungsslot- Instruktion. Da die Verzögerungsslot-Instruktion immer ausgeführt wird, wird die Ausführung der Verzweigungszielinstruktion verschoben bis nach der Ausführung der Verzögerungsslot-Instruktion. Der Schritt 174 des Auffinden des nächsten Befehls bestimmt, dass eine gültige Instruktion jegliche Instruktion außer einer Pipeline-Halteinstruktion ist. Wenn diese nächste Instruktion eine Vektorinstruktion ist, dann ruft der Berechne-Adresse- Schritt 152 sich rekursiv selbst auf und die Steuerung geht wiederum über auf den Bestimme-Adresse des Verzweigungsziels-Schritt 170. Unter der Annahme, dass die Verzögerungsslot-Instruktion kein Vektor ist, geht die Steuerung dann auf den Rücke-um eine Instruktion vor-Schritt 178 über.
Der Vorrücken-um eine Instruktion-Schritt 178 bringt die Analyse der selektierten Dateninstruktionssequenz zu der Instruktion, auf die die Verzweigungsinstruktion zielt. Diese Instruktion ist die Verzweigungszielinstruktion.
Nachdem die Adresse der Verzweigungszielinstruktion detektiert worden ist, geht die Steuerung an den Instruktionsberechnungs-Schritt 179 über, welcher die Instruktion findet, welche der Verzweigungszieladresse entspricht. Der Instruktionsberechnungs-Schritt 179 bestimmt und verarbeitet auch die sequentiellen Instruktionen, welche der Verzweigungszielinstruktion folgen. Nachdem die der Sprungzielinstruktion folgenden sequentiellen Instruktionen bearbeitet sind, geht die Steuerung auf den Vektorbestimmungs-Schritt 180 über.
Im Vektorbestimmungs-Schritt 180 wird die derzeit verarbeitete Instruktion, genauer gesagt die dieser Instruktion entsprechenden Statusdaten, durchgesehen, um zu bestimmen, ob die Instruktion eine Vektorinstruktion ist. Falls die Instruktion eine Vektorinstruktion ist, dann ruft sich der Berechne- Adresse-Schritt 152 rekursiv selbst auf und die Steuerung geht wiederum auf den Bestimme-Adresse des Verzweigungsziels-Schritt 170 über.
Wenn die nächste Instruktion kein Vektor ist, was anzeigt, dass die Instruktionssequenz oder die verbundene Gruppe von Instruktionssequenzen verarbeitet worden ist, dann geht die Steuerung auf den Vervollständige-Restschritte-Schritt 182 über.
Der Vervollständige-Restschritte-Schritt 182 hat die Funktion, Verzögerungsslot-Instruktionen zurückzugeben und zu detektieren, weiche zuvor nicht detektiert wurden, weil Vektorinstruktionen den Instruktionsfluss veranlasst haben, von der Verzögerungsslot-Instruktion abzuzweigen. Nachdem die Bearbeitung der Restschritte vollständig ist, beendet der Adressberechnungs-Schritt 152 und die Steuerung geht auf Schritt 154 über.
Während eine Vektorausnahme hier beschrieben ist, beeinflussen andere Vorfälle, welche zu einem nicht sequentiellen Instruktionsfluss führen, die Operation des Adressberechnungs-Schritts 152. Wie auch bei der Vektorausnahme haben diese anderen Vorfälle, welche zu einem nicht sequentiellen Instruktionsfluss führen, nicht das Verzögerungsslot-Verhalten einer Verzweigungsinstruktion. Z.B. können andere Typen von nicht sequentiellen Instruktionen, wie z.B. eine Interrupt-Rückkehr, die Detektion einer Verzweigung im Schritt 150 veranlassen. Die Bearbeitung einer Interrupt-Rückkehr variiert, da Interrupt-Rückkehren nicht von Verzögerungsslot-Instruktionen gefolgt werden. Bei der Verarbeitung einer Rückkehr ist es daher nicht notwendig, die Instruktionssequenz um einen Extraschritt vorzurücken. Eine weitere Ausnahme kann auftreten, wenn Rücken-zu-Rücken- Verzweigungen detektiert werden, d.h. wenn die Verzögerungsslot-Instruktion selbst eine Verzweigungsinstruktion ist. In diesem Fall ruft sich der Adressberechnungs-Schritt 152 wiederum rekursiv selbst auf.
Fig. 13 zeigt die Operation des Instruktionsberechnungs-Schrittes 179. Dem Instruktionsberechnungs-Schritt 179 werden die Parameter STAT, ADDR, S ADDR, RDY und I/D# als auch die Parameter depth, der anzeigt, wie lange eine Instruktionssequenz bearbeitet werden, um die Verzweigungszielinstruktion zu finden, und temporary address, welcher die Startadresse von möglichen Adressen auf dem Adressbus anzeigt, welche die Instruktion enthalten können, zugeführt. Der Instruktionsberechnungs-Schritt 179 startet mit dem Suchen nach einer gültigen Adressübereinstimmung zwischen der Verzweigungszieladresse und einer Adresse in dem Adressfeld. Wenn eine Adressübereinstimmung gefunden ist, dann ist die dieser Adresse entsprechende Instruktion die Verzweigungszieladresse. Das Bearbeiten der Sequenz geht dann weiter, indem der Wert der temporären Adressen weitergesetzt wird und dann rekursiv sich selbst aufruft. Diese Sequenz geht weiter, bis eine nicht sequentielle Instruktion detektiert wird, was das Ende der aktuellen Sequenz von Instruktionen anzeigt.

Andere Ausführungsbeispiele

Weitere Ausführungsbeispiele sind in den folgenden Ansprüchen enthalten.
Beispielsweise kann das Ablaufverfolgungs-Analysesystem 44 verbessert werden, um die Meldung von Mehrfachinstruktionsausführungen oder Datenzugriffen zu ermöglichen, welche auf verschiedenen verarbeiteten Ablaufverfolgungszeilen auftreten, welche demselben abgebildeten Ablaufverfolgungstakt entsprechen. Dies eliminiert den Zwang, die Meldungen von Datenzugriffen umzuordnen oder fallenzulassen. Diese Erweiterung erlaubt es dem Ablaufverfolgungs-Analysesystem 44 mit superskalaren Prozessoren zu arbeiten.

Claims

1. Verfahren zur Ablaufverfolgung der Operation eines Prozessors zwecks Bereitstellung einer Ablaufverfolgungs-Ausgabe entsprechend Operationszyklen des Prozessors, mit folgenden Schritten:

- Erfassen einer Ablaufverfolgung der Prozessoroperation;

- Bereitstellen der Ablaufverfolgung in Form selektierter Testdaten,

- Verarbeiten von Datenzugriffen auf die selektierten Testdaten, und

- Verarbeiten von Befehlen der selektierten Testdaten basierend auf der Detektion eines nichtsequentiellen Befehls mit einer Targetadresse, wobei die Targetadresse des nichtsequentiellen Befehls zum Bestimmen eines Befehlsflusses entsprechend der Targetadresse verwendet wird.

2. Verfahren nach Anspruch 1, ferner mit folgenden Schritten:

- Prüfen der selektierten Testdaten zwecks Bestimmung, ob Wiederholungszugriffe vorhanden sind, und

- Entfernen sämtlicher Wiederholungszugriffe, mit Ausnahme eines Wiederholungszugriffs.

3. Verfahren nach Anspruch 1 oder 2, bei dem

- der Schritt des Verarbeitens von Datenzugriffen folgende Schritte umfasst:

- Bestimmen, ob ein Datenzugriff ein Daten-Cache-Speicher- Treffer ist, und

- Meiden des Daten-Cache-Speicher-Treffers in einem als nächstes verfügbaren Zyklus der Ablaufverfolgungsausgabe.

4. Verfahren nach Anspruch 1, 2, oder 3, bei dem

- der Schritt des Verarbeitens von Datenzugriffen folgende Schritte umfasst:

- Bestimmen, ob ein Datenzugriff ein Zugriff auf einen externen Speicher ist, und

- Melden des Zugriffs auf den externen Speicher in einem als nächstes verfügbaren Zyklus der Ablaufverfolgungsausgabe.

5. Verfahren nach einem der Ansprüche 1 bis 4, bei dem

- der Schritt des Verarbeitens von Datenzugriffen folgende Schritte umfasst:

- Bestimmen, ob ein Datenzugriff ein Zugriff auf Datenbündel ist, und

- Melden des Zugriffs auf das Datenbündel in einem Zyklus entsprechend dem Zugriff auf das Datenbündel.

6. Verfahren nach einem der Ansprüche 1 bis 5, bei dem

- der Schritt des Verarbeitens von Datenzugriffen folgende Schritte umfasst:

- Bestimmen, ob ein Datenzugriff ein Vektorabruf ist, und

- Melden des Vektorabrufs in einem Zyklus entsprechend dem Vektorabruf.

7. Verfahren nach einem der Ansprüche 1 bis 6, bei dem

- der Schritt der Befehlsverarbeitung folgenden Schritt umfasst:

- Detektieren der Targetadresse nach dem Detektieren des nichtsequentiellen Befehls.

8. Verfahren nach Anspruch 7, bei dem

- der Schritt der Befehlsverarbeitung folgende Schritte umfasst:

- Verarbeiten der selektierten Ablaufverfolgungsdaten zwecks Auffindung des nächstgültigen Befehls, und

- Interpretieren dieses Befehls als Verzögerungs-Slot-Befehl.

9. Verfahren nach Anspruch 8, bei dem

- der Schritt der Befehlsverarbeitung ferner folgende Schritte umfasst:

- Vorrücken um einen weiteren Zyklus in den selektierten Ablaufverfolgungsdaten, und

- Interpretieren des einen Befehls entsprechend dem einen weiteren Zyklus als Adresse eines Verzweigungs-Targetbefehls.

10. Verfahren nach Anspruch 9, bei dem

- der Schritt der Befehlsverarbeitung ferner folgenden Schritt umfasst:

- rekursives Aufrufen des Befehlsverarbeitungsschritts, wenn der Verzweigungs-Targetbefehl ein nichtsequentieller Befehl ist.

11. Verfahren nach Anspruch 9, bei dem

- der Schritt der Befehlsverarbeitung ferner folgenden Schritt umfasst:

- Berechnen des Verzweigungs-Targetbefehls basierend auf der Adresse der Verzweigungs-Targetbefehlsadresse.

12. Verfahren nach Anspruch 11, bei dem

- der Schritt der Befehlsverarbeitung ferner folgenden Schritt umfasst:

- Berechnen einer Befehlssequenz im Anschluss an den Verzweigungs-Targetbefehl.

13. Verfahren zum Erstellen einer Assemblierkoderepräsentation der Operation eines Prozessors, mit dem Verfahren nach einem der Ansprüche 1 bis 12 und ferner mit dem Schritt des Erstellens einer Assemblierkoderepräsentation der selektierten Testdaten basierend auf den selektierten Testdaten, wobei der Schritt des Erstellens des Assemblierkodes den Schritt des Verarbeitens von Datenzugriffen und den Schritt der Befehlsverarbeitung umfasst.

14. Ablaufverfolgungs-Analysevorrichtung zur Ablaufverfolgung der Operation von selektierten Testdaten eines Prozessors, mit:

- einer Einrichtung (30) zum Erfassen einer Ablaufverfolgung der Prozessoroperation,

- einem Prozessdatenmodul (70), das die Datenzugriffe auf die selektierten Testdaten verarbeitet, und

- einem Prozessbefehlsmodul (72), das die Befehlsausführung der selektierten Testdaten und die auf der Detektion eines eine Targetadresse aufweisenden nichtsequentiellen Befehls basierenden Befehle verarbeitet und die Targetadresse des nichtsequentiellen Befehls zum Bestimmen eines Befehlsflusses entsprechend der Targetadresse verwendet.