DE69706271T2

DE69706271T2 - Integrierter Rechner mit Befehlsverfolgung

Info

Publication number: DE69706271T2
Application number: DE69706271T
Authority: DE
Inventors: Robert Warren
Original assignee: STMicroelectronics Ltd Great Britain; SGS Thomson Microelectronics Inc
Current assignee: STMicroelectronics Ltd Great Britain; STMicroelectronics lnc USA
Priority date: 1996-12-19
Filing date: 1997-12-12
Publication date: 2002-05-23
Anticipated expiration: 2017-12-13
Also published as: DE69706271D1; GB9626367D0; EP0849670B1; JPH10240572A; US6279103B1; EP0849670A1

Description

Die vorliegende Erfindung betrifft ein Bereitstellen einer Befehlsüberwachung. Insbesondere betrifft sie ein integriertes Einchip-Schaltungselement, auf welchem eine Befehlsüberwachung erfaßt wird, und ein Verfahren zum Bereitstellen einer Befehlsüberwachung.
CPUs enthalten zusätzlich zu ihrer Abruf- und Ausführungsschaltung zum Abrufen und Ausführen von Befehlen aus einem Speicher, ein Befehlszeigerregister, welches die Adresse eines Befehls im Speicher hält, welcher von der CPU auszuführen ist. Die Kenntnis der in dem Befehlszeigerregister gehaltenen Adresse ist von besonderer Bedeutung, wenn Diagnosefunktionen auf einer Software durchgeführt werden, welche auf einer CPU läuft. In einigen, einfachen Fällen kann die als der Befehlszeiger gehaltene Adresse durch Überwachung des Speicheradressenwertes auf einem externen Speicherbus abgeleitet werden. In vielen Fällen ist der Befehlszeiger jedoch innerhalb der Tiefen der CPU verborgen und ist außerhalb der CPU nicht leicht zugänglich.
Insbesondere wurden CPUs in der Vergangenheit als ein Einchip hergestellt, was einen chipexternen Zugriff auf alle ihre Hilfsschaltungen, wie dem Speicher, erforderlich machte. Als Folge hatten sie eine Mehrzahl von Zugriffspins, so daß Information über die CPU, insbesondere Speicheradresseninformation, in jedem Fall extern von diesen Zugriffspins verfügbar war.
Heutzutage sind Chips komplexer und enthalten nicht nur einen chipintegrierten Prozessor, sondern auch seinen zugehörigen Speicher und andere Hilfsschaltungen. Es ist nicht mehr länger eine einfache Sache, den Betrieb des Prozessors zu überwachen, weil die Signale, welche normalerweise chipextern verfügbar sind, nicht mehr länger einen direkten Hinweis bezüglich des internen Betriebs der CPU liefern.
Mit der größer werdenden Komplexität von Software, welche für den Ablauf auf integrierten CPUs entworfen wird, ist es in größer werdendem Maße wichtig, die Software angemessen zu testen. Dies erfordert Techniken zum Überwachen des Betriebs der CPU, während sie die Software ausführt. Eine besonders schwere Anforderung ist, daß die Software nicht-beeinflussend überwacht werden soll, während sie in Echtzeit arbeitet.
Sogenannte Diagnose- oder Fehlersuchtechniken (diagnostic or debugging techniques) sind in einem Versuch entwickelt worden, dies zu erreichen. Eine dieser Techniken besteht darin, einen Logikanalysator (logic state analyser = LSA) zu verwenden. Dies ist ein Element, welches an die Pins der integrierten Schaltung angeschlossen ist, welche den Zustand von allen chipexternen Datenübertragungen kontinuierlich überwacht. Jeder sequentiell erzeugte Satz von Zuständen wird gespeichert und kann dann analysiert werden. Ein LSA ist nicht nur teuer, sondern erfordert eine große Menge an Ableitung und Analyse, um irgendeine nützliche Information von der riesigen Anzahl von sequentiell erzeugten Zustandssätzen, welche gespeichert werden, abzuleiten. Da es nur möglich ist, die Statussignale zu analysieren, welche chipextern übertragen werden, ist es unvermeidbarer Weise notwendig, etwas Ableitung oder Hypothese betreffend der chipinternen Situation zu betreiben. Manchmal ist es durch diese Technik möglich, Befehlszeiger abzuleiten. Auf die Sequenz von Adressen, gespeichert in dem Befehlszeigerregister, welche durch den LSA erfaßt wird, wird als eine Befehlsüberwachung Bezug genommen.
Manchmal ist es auch möglich, eine Befehlsüberwachung in einer äquivalenten, virtuellen Umgebung durch Softwaresimulation, Hardwaresimulation, Hardwareemulation oder andere Mittel herzustellen. Keine dieser Techniken gibt jedoch die Situation der realen Welt oder die Echtzeitsequenz von Ereignissen wieder. Eine solche Überwachung ist oft nützlich zum Vergleichen mit einer Echtzeitbefehlsüberwachung, aber ist ansonsten in Diagnoseprozeduren von beschränktem Wert.
Keine dieser Techniken kann jedenfalls dazu verwendet werden, um Information betreffend den Befehlszeiger herauszufinden, außer wenn diese durch Überwachen von externen Anschlußpins abgeleitet werden kann. Wenn es keine existierenden externen Anschlußpins gibt, können externe Anschlußpins manchmal speziell hinzugefügt werden, um den Befehlszeiger von dem Befehlszeigerregister wieder aufzufinden. Dies ist ein zusätzlicher Platzbedarf für den Chip und zwar nur für den Zweck der Fehlersuche. Darüber hinaus ist unter gewissen Umständen nicht einmal dies möglich. Aus der Druckschrift EP-A-0636976 ist jedoch schon ein System zum Überwachen von Befehlen bekannt, welches auf dem CPU-Chip integriert ist.
Gemäß der vorliegenden Erfindung wird ein integriertes Einchip-Schaltungselement bereitgestellt, mit:
einer chipintegrierten (on-chip) CPU mit einer Abruf- und Ausführungsschaltung zum Abrufen und Ausführen von Befehlen aus einem Speicher, und einem Befehlszeigerregister zum sequentiellen Halten von Adressen von Befehlen im Speicher, die von der CPU auszuführen sind; dadurch gekennzeichnet, daß vorhanden sind:
eine Befehlsüberwachungssteuerung, welche die Adressen überwachen kann und welche verbunden ist, um Speicherplätze zu überwachen, um zu bewirken, daß ausgewählte Adressen an den Überwachungsspeicherplätzen gespeichert werden, abhängig von der Feststellung, daß eine der Speicheradressen nicht die nächste sequentielle Adresse im Speicher nach der vorhergehenden Adresse ist.
Somit ermöglicht eine chipintegrierte Befehlsüberwachungssteuerung eine Befehlsüberwachung zu erfassen, und zwar in Echtzeit, ohne die Notwendigkeit von zusätzlichen externen Anschlußpins. Dadurch, daß lediglich der Wert des Befehlszeigers bei Diskontinuitäten (nicht- sequentiellen Adressen) gespeichert wird, wird die Informationsmenge, welche über eine gegebene Zeitperiode gespeichert werden muß, beträchtlich verringert.
Die Befehlsüberwachungssteuerung kann an das Befehlszeigerregister angeschlossen werden, um die Adressen zu überwachen. Alternativ hierzu kann sie an einen Speicherbus angeschlossen werden, entlang welchem Befehle an die CPU abgerufen werden, um die Adressen zu überwachen.
Die Überwachungsspeicherplätze können in einem anwendungsspezifischen Speicher, welcher an die Überwachungssteuerung durch einen anwendungsspezifischen Bus angeschlossen ist, in einem anwendungsspezifischen Speicher, welcher an einen Speicherbus angeschlossen ist, welcher auch Zugriffe von der CPU ermöglicht, oder in dem gleichen Speicher, wie derjenige, welcher durch die CPU zugänglich ist, und zwar entweder chipintegriert oder chipextern, bereitgestellt werden. Wo der Speicher chipextern ist, kann er durch eine externe Speicherinterfacesteuerung an den chipintegrierten Bus angeschlossen werden. Alternativ hierzu kann er mit einer Host-CPU verbunden werden, welche durch eine chipexterne serielle Datenübertragungsverbindung an den Chip angeschlossen ist.
Die nicht-sequentiellen Adressen oder Diskontinuitäten können entweder durch die Befehlsüberwachungssteuerung selbst festgestellt werden oder können identifiziert werden, wenn der Befehlszeiger von der CPU zu der Befehlsüberwachungssteuerung gesendet wird.
Wo der Zugriff zum Speicher langsam ist, um das Speichern der Überwachungsadressen zuzulassen, kann die Befehlsüberwachungssteuerung den Normalbetrieb der CPU blockieren, um zu ermöglichen, daß die Adressen in den Überwachungsspeicherplätzen gespeichert werden können.
Die Befehlsüberwachungssteuerung kann eines oder mehrere der folgenden Register aufweisen:
ein Zieladressenregister, welches die Adresse des nächsten Überwachungsspeicherplatzes hält, in welchem die nächste ausgewählte Adresse zu speichern ist;
ein erstes Register zum Speichern von einer der Adressen unmittelbar vor der Feststellung einer Diskontinuität;
ein zweites Register zum Speichern von einer der Adressen unmittelbar nach Feststellung einer Diskontinuität;
ein Größenregister (size register) zum Einstellen der Größe eines anwendungsspezifischen Speichers oder Überwachungspuffers für die Befehlsüberwachungssteuerung; und
ein Optionssteuerungsbitregister zum Auswählen von einer oder mehreren Optionen, welche durch die Befehlsüberwachungssteuerung zu implementieren sind.
Das Optionssteuerungsbitsregister kann steuern, ob oder ob nicht das erste Register verwendet wird oder das zweite Register verwendet wird oder beide verwendet werden. Das Optionssteuerungsregister kann auch bestimmen, ob oder ob nicht ein Blockierungs-CPU-Signal zu senden ist, wenn die Überwachungsspeicherplätze nicht leicht verfügbar sind. Das Optionssteuerungsbitsregister kann auch die CPU unterbrechen, wenn die Überwachungsspeicherplätze voll werden (d. h., wenn die Überwachungsspeicherplätze ihr Größenlimit erreichen) oder die Überwachungsspeicherplätze ansteuern überzulaufen (roll over), wenn sie voll werden, oder andere auswählbare Optionen anzusteuern.
Gemäß einem weiteren Gesichtspunkt der vorliegenden Erfindung wird bereitgestellt: Ein Verfahren zum Bereitstellen einer Befehlsüberwachung von einer chipintegrierten CPU in einem integrierten Einchip-Schaltungselement, bei welchem Adressen im Speicher von durch die CPU auszuführenden Befehlen sequentiell in einem Befehlszeigerregister der CPU gehalten werden, dadurch gekennzeichnet, daß die Adressen durch eine Befehlsüberwachungssteuerung auf dem integrierten Einchip-Schaltungselement überwacht werden, wobei die Befehlsüberwachungssteuerung bewirken kann, daß ausgewählte Adressen an vorbestimmten Überwachungsspeicherplätzen abhängig von der Feststellung gespeichert werden, daß eine der Adressen nicht die nächste sequentielle Adresse im Speicher nach einer vorhergehenden Adresse ist.
Für ein besseres Verständnis der vorliegenden Erfindung und um zu zeigen, wie diese verwirklicht werden kann, wird nun beispielhaft auf die beigefügte Zeichnung Bezug genommen, bei welcher:
Fig. 1 eine integrierte Schaltung mit einer Testzugriffsportsteuerung darstellt, welche Verbindungen gemäß dem beschriebenen Ausführungsbeispiel aufweist;
Fig. 2 die Testzugriffsportsteuerung von Fig. 1 darstellt;
Fig. 3 einen Datenadapter gemäß dem beschriebenen Ausführungsbeispiel zur Verbindung mit der Testzugriffsportsteuerung von Fig. 2 darstellt;
Fig. 4 das Datenformat für Daten darstellt, welche chipextern über die Testzugriffsportsteuerung von Fig. 2 in einem Diagnosemodus übertragen werden;
Fig. 5 eine Implementierung des Datenadapters von Fig. 3 in Form eines hierarchischen Blockdiagramms darstellt;
Fig. 6 das Format von Kopfbytes von Nachrichten gemäß dem beschriebenen Ausführungsbeispiel darstellt;
Fig. 7 das Format von Nachrichten gemäß dem beschriebenen Ausführungsbeispiel darstellt;
Fig. 8 schematisch den Nachrichtenwandler des beschriebenen Ausführungsbeispiels darstellt;
Fig. 9 das Format von Bussen darstellt, welche mit dem Nachrichtenwandler in dem beschriebenen Ausführungsbeispiel verbunden sind;
Fig. 10 eine Implementierung des Nachrichtenwandlers des beschriebenen Ausführungsbeispiels darstellt;
Fig. 11 eine Implementierung des Nachrichtenwandlers des beschriebenen Ausführungsbeispiels in Form eines hierarchischen Blockdiagramms darstellt;
Fig. 12 ein Blockdiagramm ist, welches eine Anwendung einer Befehlsüberwachungssteuerung darstellt;
Fig. 13 ein Blockdiagramm ist, welches eine andere Anwendung einer Befehlsüberwachungssteuerung darstellt; und
Fig. 14 ein Blockdiagramm ist, welches die Bauelemente einer Befehlsüberwachungssteuerung zeigt.
Fig. 1 stellt schematisch eine integrierte Schaltung 2 mit einer Testzugriffsport (TAP)-Steuerung 4 und eine Chipgrenzenabtastkette 10 dar. Die TAP-Steuerung 4 empfängt vom Chipexternen ein Testtaktsignal TCK auf Leitung 14, ein Testmodusauswahlsignal TMS auf Leitung 16, ein Testdateneingangssignal TDI auf Leitung 18, und ein Testrücksetzeingangssignal TRST* auf Leitung 22. Die TAP- Steuerung 4 gibt chipextern ein Testdatenausgangssignal TDO auf Leitung 20 aus. Die TAP-Steuerung 4 empfängt auch ein Bauelementidentifizierungssignal DEVICEID auf Leitung 12. In Fig. 1 wird das Signal DEVICEID als eine Signalleitung 12 gezeigt, welche innerhalb der integrierten Schaltung geerdet ist. Die Signalleitung 12 kann eine Multi-Bitleitung sein und das Signal DEVICEID kann seinen Ursprung entweder auf der integrierten Schaltung oder chipextern haben. Wenn die Leitung 12 eine Multi- Bitleitung ist, dann kann jedes Bit entweder mit einem niedrigen Logikpegel oder einem hohen Logikpegel auf dem Chip verbunden sein. Die TAP-Steuerung 4 gibt auf die chipintegrierte Schaltung ein Abtastdateneingangssignal SCANIN auf Leitung 28, ein Testtaktsignal TESTCLK auf Leitung 38, ein die Auswahl eines Abtasttestmodus anzeigendes Signal SCANMODE auf Leitung 24, und ein die Auswahl eines Diagnosemodus anzeigendes Signal DIAGMODE auf Leitung 26 aus. Die Chipgrenzenabtastkette 10 empfängt als Eingangssignale das Abtastdateneingangssignal SCANIN auf Leitung 28 und das Signal SCANMODE auf Leitung 24, und gibt ein Abtastdatenausgangssignal SCANOUT auf Leitung 34 an die TAP-Steuerung 4 aus. Das Signal SCANIN auf Leitung 28 wird auch der chipintegrierten Quellen- /Ziellogik für Diagnosezwecke gemäß der vorliegenden Erfindung zugeführt und wird nachfolgend beschrieben werden. Die Quellen-/Ziellogik liefert ein Eingangssignal DIAGSCANOUT an die TAP-Steuerung 4 auf Leitung 36 gemäß der vorliegenden Erfindung.
Fig. 5, welche untenstehend im Detail beschrieben ist, stellt die Bauelemente dar, aus welchen die Quellen- /Ziellogik aufgebaut sein kann. Die Quellen-/Ziellogik kann zumindest ein Prozessor sein, welcher an ein chipintegriertes Bussystem angeschlossen ist, mit einem daran angeschlossenen chipintegrierten Speicher. Chipexterne Speicher können auch direkt an ein solches Bussystem angeschlossen. Eine chipintegrierte Ziel-/Quellenlogik kann auch eine andere Funktionsschaltung mit einem DMA-Antrieb oder EMI-Interface umfassen.
Die TAP-Steuerung 4 ist schematisch in Fig. 2 dargestellt, mit denjenigen Schaltungsblöcken, welche für ihren Standardbetrieb wesentlich und wie sie für die vorliegende Erfindung erforderlich sind. Bezugnehmend auf Fig. 2 umfaßt die TAP-Steuerung 4, in Grundform, eine Ablaufsteuereinheit 50, ein ID-Register 42, ein Befehlsregister 44, einen Befehlsdekoder 46, einen Überbrückungsspeicher 48, einen Datenmultiplexer 52, einen Befehls- /Datenmultiplexer 54, einen Zwischenspeicher 56, und einen Inverter 60. Das Befehlsregister empfängt das Testdateneingangssignal TDI auf Leitung 18, erzeugt einen parallelen Befehl auf Bus 62 und ein serielles Ausgangssignal auf Leitung 76, und empfängt ein Befehlssteuerungseingangssignal auf Leitung 82. Der Befehlsdekoder 46 empfängt den Parallelbefehl auf Bus 62 und ein Dekodersteuerungseingangssignal auf Leitung 84 und erzeugt die Signale SCANMODE und DIAGMODE auf Leitung 24 bzw. 26, und ein paralleles Datenmultiplexer-Auswahlsignal auf. Leitung 70. Der Überbrückungsspeicher 48 empfängt das Testdateneingangssignal TDI auf Leitung 18 und erzeugt ein Ausgangssignal auf Leitung 72. Das ID-Register 42 empfängt das parallele Signal DEVICEID auf Leitung 12 und erzeugt ein serielles Bauelementidentifizierungs-Ausgangssignal auf Leitung 68. Der Datenmultiplexer 52 empfängt das Ausgangssignal des ID-Registers 42 auf Leitung 68, das Ausgangssignal des Überbrückungsspeichers 48 auf Leitung 72, das SCANOUT-Signal auf Leitung 34, das DIAGSCANOUT-Signal auf Leitung 36 und das Datenmultiplexer-Auswahlsignal auf Leitung 70. Der Datenmultiplexer 52 erzeugt ein Ausgangssignal auf Leitung 74. Der Befehls-/Datenmultiplexer 54 empfängt das serielle Ausgangssignal auf Leitung 76, das Ausgangssignal des Datenmultiplexers auf Leitung 74, und ein Befehls-/Datenmultiplexer-Auswahlsignal auf Leitung 78. Der Befehls-/Datenmultiplexer erzeugt ein Ausgangssignal auf Leitung 80. Der Zwischenspeicher 56 empfängt das Ausgangssignal des Befehls-/Datenmultiplexers 54 auf Leitung 80 und erzeugt das Testdatenausgangssignal TDO auf Leitung 20. Die Ablaufsteuereinheit 50 empfängt das Signal TMS auf Leitung 16 und das Signal TRST* auf Leitung 22. Die Ablaufsteuereinheit erzeugt das Befehls- /Datenmultiplexer-Auswahlsignal auf Leitung 78, das Befehlssteuerungseingangssignal auf Leitung 82, und das Dekodersteuerungseingangssignal auf Leitung 84. Das ID- Register 42, das Befehlsregister 44, der Befehlsdekoder 46, der Überbrückungsspeicher 48, die Ablaufsteuereinheit 50, und der Datenwandler 57 empfangen jeweils das Testtaktsignal TCK auf Leitung 14. Der Zwischenspeicher 56 empfängt das Testtaktsignal TCK invertiert über den Inverter 60 auf Leitung 64. Das Testtaktsignal TCK und das Testdateneingangssignal TDI werden direkt als Ausgangssignale TESTCLK der Leitung 38 bzw. SCANIN der Leitung 28 zugeführt.
Der Betrieb der TAP-Steuerung 4 beim Durchführen von Tests der integrierten Schaltung 2 sind vollständig in IEEE 1149.1-1990 erklärt. Im wesentlichen werden endliche Längenabtastketten auf der integrierten Schaltung gebildet, wie diejenigen, welche durch die Chipgrenzenabtastkette 10 gebildet werden.
Die TAP-Steuerung 4 ist eine synchrone endliche Ablaufsteuereinheit, welche durch IEEE Standard 1149.1-1990 definiert ist. IEEE Standard 1149.1-1990 definiert eine Testlogik, welche in einer integrierten Schaltung umfaßt sein kann, um standardisierte Methoden bereitzustellen, um die Zwischenverbindungen zwischen integrierten Schaltungen zu testen, die integrierten Schaltungen selbst zu testen, und Schaltungsaktivität während des Normalbetriebes der integrierten Schaltung zu überwachen oder zu verändern.
Während des Normalbetriebes der integrierten Schaltung 2 ist die TAP-Steuerung 4 in einem zurückgesetzten Zustand und alle ihre Eingänge und Ausgänge sind inaktiv. Wenn ein Test durchgeführt werden soll, welcher den Testzugriffsport gemäß des IEEE Standards 1149.1-1990 verwendet, arbeitet die Testzugriffsportsteuerung gemäß den Definitionen dieses Standards. In einem solchen Testmodus muß die Testzugriffsportsteuerung zumindest einen Testbetriebsmodus auswählen können. Ein möglicher Testmodus ist ein Abtasttestmodus, welcher durch Setzen des Signals SCANMODE auf Leitung 24 ausgewählt werden würde. In dem Abtasttestmodus wird eine Abtastkette auf der integrierten Schaltung 2 zum Testen ausgewählt. In diesem Beispiel wird die Chipgrenzenabtastkette 10 durch das Signal SCANMODE ausgewählt. Ein solcher Abtasttest kann einfach das Eingeben von Daten an einem Ende der Abtastkette und das Überprüfen, daß die gleichen Daten am anderen Ende der Abtastkette ausgegeben werden, beinhalten. Alternativ hierzu können komplexere Abtastoperationen durchgeführt werden, so etwa das Abtasten von Daten, welche der chipintegrierten Funktionslogik eingegeben werden, den Chip für einen oder mehrere Taktzyklen funktionell zu takten und dann die Ausgangssignale der Funktionslogik abzutasten. Jegliche Verbindungspunkte oder chipintegrierte Schaltung kann für Testzwecke verbunden werden, um eine Abtastkette zu bilden. Die Chipgrenzenabtastkette 10 kann eine Reihe von Flipflopschaltungen sein, welche im Testmodus gesteuert werden, um alle Eingangs-/Ausgangsports der integrierten Schaltung 2 zu verbinden. Ein volles Verständnis eines solchen Abtasttests kann durch Bezugnahme auf den IEEE Standard 1149.1-1990 gewonnen werden. Für spezielle Beispiele wie Abtasttests durchgeführt werden können, sollte Bezug auf die Veröffentlichungen der europäischen Patentanmeldungen Nr. 0698890, 0702239, 0702240, 0702241, 0702242, 0702243, 0709688 genommen werden.
Eine Charakteristik von bekannten Testmodi, welchen den Testzugriffsport des IEEE Standards 1149.1-1990 benutzen, ist, daß die Abtastkette von endlicher Länge oder eine geschlossene Schleife ist und daß das Testdatenausgangssignal TDO vom Testdateneingangssignal TDI abhängt und eine Zeitbeziehung damit aufweist.
In dem beschriebenen Ausführungsbeispiel wird der Diagnosearbeitsmodus bereitgestellt, um Diagnoseprozeduren von einer chipintegrierten Quellen-/Ziellogik auszuführen, welche kompatibel mit dem IEEE Standard 1149.1-1990 ist. In einem solchen Diagnosetestmodus ist das Testdatenausgangssignal TDO nicht abhängig von dem Testdateneingangssignal und weist keine Zeitbeziehung damit auf. Die Kette zwischen dem Testdateneingangssignal TDI und dem Testdatenausgangssignal TDO wird als von unendlicher Länge oder als offene Schleife angesehen. Im Diagnosemodus agiert die TAP-Steuerung, während sie damit fortfährt, alle Normalfunktionen bereitzustellen, zusätzlich als Transportmittel zum Übertragen von vollduplexen, ablaufgesteuerten, unbegrenzten, seriellen Daten, obwohl der TAP- Steuerung unbewußt ist, daß dies das Datenformat ist. Umgekehrt handhabt die TAP-Steuerung normalerweise einen einzelnen Datenstrom ohne jede Ablaufsteuerung, welcher durch eine ausgewählte Abtastkette fließt.
Unter Bezugnahme auf die Fig. 1 und 2 wird nun ein Überblick über die Arbeitsweise der TAP-Steuerung 4 in einem Testmodus gegeben. Es soll betont werden, daß obwohl in Fig. 2 gezeigt ist, daß das Signal SCANIN direkt dem Testdateneingangssignal TDI zugeführt wird, SCANIN unter bestimmten Umständen eine abgeänderte Variante von TDI sein kann. Gleichermaßen kann es erforderlich sein, daß das Signal TESTCLK, obwohl das Testtaktsignal TESTCLK direkt dem Testtaktsignal TCK zugeführt wird, unter bestimmten Umständen eine abgeänderte Variante des Signals TCK ist.
In einem Testbetriebsmodus werden das Testdateneingangssignal TDI und das Testmodusauswahlsignal TMS in serieller Form der TAP-Steuerung 4 unter Steuerung des Testtaktsignals TCK zugeführt. Die Ablaufsteuereinheit 50 wirkt auf den Wert des Testmodusauswahlsignals TMS auf jeder aktiven Flanke des Testtaktsignals TCK ein, um seine, gemäß IEEE Standard 1149.1-1990 definierten Zustände zu durchlaufen. Das Testrücksetzsignal TRST* sorgt für asynchrone Initialisierung der TAP-Steuerung 4, wenn in einem niedrigen Logikzustand gemäß dem IEEE Standard 1149.1-1990 befindlich.
Das Befehlsregister 44 wird durch das Testtaktsignal TCK getaktet, um einen Befehl in serieller Form von dem Testdateneingangssignal TDI unter der Steuerung des Befehlssteuerungseingangssignal auf Leitung 82 von der Ablaufsteuereinheit 50 zu laden. Wenn der Befehl seriell in das Befehlsregister 44 geladen worden ist, wird es parallel auf den Befehlsbus 62 an den Befehlsdekoder 46 unter Steuerung des Dekodersteuerungseingangssignals auf Leitung 84 von der Ablaufsteuereinheit 50 übertragen. Gemäß dem darin gespeicherten Befehl wird der Befehlsdekoder entweder das SCANMODE-Signal oder das DIADMODE-Signal setzen, und zwar je nachdem, ob es ein Abtasttest oder ein Diagnosetest ist, welcher durchgeführt werden soll. Das Laden des Befehlsregister 44 und der Befehlsdekoder 46 werden durch die Ablaufsteuereinheit 50 gemäß des IEEE Standards 1149.1-1990 gesteuert. Gemäß des durch den Befehlsdekoder 46 dekodierten Befehls, und wie nachfolgend weiter beschrieben wird, steuert das parallele Ausgangssignal auf Leitung 70 des Befehlsdekoders 46 den Datenmultiplexer 52, um einen seiner Eingänge an die Ausgangsleitung 74- anzuschließen. Gleichermaßen steuert das Ausgangssignal auf Leitung 78 der Ablaufsteuereinheit 50 den Befehls-/Datenmultiplexer, um einen seiner Eingänge an den Ausgang auf Leitung 80 anzuschließen.
Das ID-Register 42 empfängt das DEVICEID-Signal parallel auf Leitungen 12. Das ID-Register 42 speichert einen Chipidentifikator, welcher aus dem ID-Register 42 über Leitung 68 zu dem Testdatenausgangssignal TDO ausgetastet werden kann. Der Chipidentifikator identifiziert die integrierte Schaltung 2.
In einem Betriebsmodus kann der durch den Befehlsdekoder 46 dekodierte Befehl einfach die Identität des Bauelements ausgeben, wobei in diesem Fall der Multiplexer 52 so gesteuert wird, daß er seinen Eingang auf Leitung 68 an seinen Ausgang auf Leitung 74 anschließt, und der Befehls-/Datenmultiplexer 54 so gesteuert wird, daß er seinen Eingang auf Leitung 74 an seinen Ausgang auf Leitung 80 anschließt. Die Identität des Bauelements wird dann seriell als das Signal TDO ausgegeben.
In einem anderen Betriebsmodus kann es erforderlich sein, den aktuellen Befehl auf dem Testdatenausgangssignal TDO auszugeben, wobei in diesem Fall der serielle Ausgang auf Leitung 76 durch den Befehls-/Datenmultiplexer 54 an die Leitung 80 angeschlossen wird.
In einem Testbetriebsmodus kann es erforderlich sein, daß die TAP-Steuerung 4 einer bestimmten integrierten Schaltung 2 lediglich das Testdateneingangssignal TDI dem Testdatenausgangssignal TDO zuführt. In diesem Betriebsmodus wird der Datenmultiplexer so gesteuert, daß er den Ausgang der Überbrückungsflipflopschaltung auf Leitung 72 an den Ausgang auf Leitung 74 anschließt, und der Befehls-/Datenmultiplexer wird so gesteuert, daß er die Leitung 74 an die Ausgangsleitung 80 anschließt. Auf diese Art wird das Testdateneingangssignal TDI dem Testdatenausgangssignal TDO über die Flipflopschaltung 56 zugeführt.
Der Zwischenspeicher 56 ist lediglich eine Flipflopschaltung, welche nur dazu bereitgestellt wird, um eine Zeit- Steuerung des Testdatenausgangssignals TDO zu gestatten, so daß ein solches Signal zu der negativen Flanke des Testtaktsignals TCK synchronisiert werden kann.
Wenn der auszuführende Testmodus ein Abtasttestmodus ist, dann setzt der Befehlsdekoder 46 das Signal SCANMODE. Der Datenmultiplexer 52 wird so durch den Befehlsdekoder 46 gesteuert, daß er das Signal SCANOUT der Ausgangsleitung 74 zuführt. Der Befehls-/Datenmultiplexer 54 wird auch so gesteuert, daß er die Leitung 74 an die Leitung 80 anschließt, um das Signal SCANOUT als das Testdatenausgangssignal TDO auszugeben. Während eines solchen Abtasttestmodus werden Testdaten in die ausgewählte Abtastkette beim SCANIN-Signal eingelesen, welches direkt dem Testdateneingangssignal TDI zugeführt wird. Abtasttesten, insbesondere Grenzenabtasttesten, ist vollständig im IEEE Standard 1149.1-1990 beschrieben. Man wird verstehen, daß zusätzliche Steuerungssignale, gemäß dem durchzuführenden Test, der ausgewählten Abtastkette zugeführt werden müssen, um den erforderlichen Testbetrieb zu erreichen.
In dem beschriebenen Ausführungsbeispiel kann ein Diagnosemodus auch eingegeben werden, wobei in diesem Fall der Befehlsdekoder 46 das Signal DIAGMODE auf der Ausgangsleitung 26 setzt. Ferner wird der Datenmultiplexer 52 so gesteuert werden, daß er das Signal DIAGSCANOUT auf Leitung 36 dem Ausgang auf Leitung 74 zuführt, welcher umgekehrt durch den Befehls-/Datenmultiplexer 54 mit der Leitung 80 und über die Flipflopschaltung 56 mit dem Testdatenausgangssignal TDO verbunden ist.
Im Diagnosemodus kann der serielle Datenfluß zwischen dem Testdateneingangssignal TDI und dem Testdatenausgangssignal TDO als durch ein Schieberegister von unendlicher Länge durchlaufend betrachtet werden, gegenüber dem Abtasttestmodus, in dessen Modus der serielle Datenfluß durch ein Schieberegister (Schieberegisterkette) von endlicher Länge stattfindet. Im Diagnosemodus wird eine Sequenz von Bitmustern, welche in dem Testzugriffsport als das Testdateneingangssignal TDI hineingeschoben (shifted in) sind, niemals in der Sequenz von Bitmustern reflektiert, welche aus dem Testzugriffsport als das Testdatenausgangssignal hinausgeschoben (shifted out) werden. Die Übertragung von Diagnosedaten kann Speicherzugriffsanfragen von der Art "host to target" und "target to host" (Lese- und Schreiboperationen); Statusinformation von CPU-Registern; Datenlesung vom Host-Speicher oder Target- Speicher als Antwort auf eine Speicherzugriffsanfrage; Statusdaten zum Laden in CPU-Register; und Information über Speicheradressen, auf welche durch die Target-CPU. zugegriffen wird, beinhalten. Auf diese Art kann der Diagnosemodus nicht-beeinflußende Datenüberwachung umfassen oder beeinflußendes Laden von Daten.
Im Diagnosemodus sind die seriellen Daten, welche in den Testzugriffsport hineingeschoben werden, ein gleichgerichteter serieller Datenstrom, welcher in jedes gewünschte Mittel kodiert werden kann, zum Beispiel mit Start- und Stop-Bits zum Strukturieren von Datenklumpen. Gleichermaßen sind Daten, welche über den Testzugriffsport hinausgeschoben werden, ein gleichgerichteter serieller Datenstrom, welcher in jedes gewünschte Mittel kodiert werden kann, zum Beispiel mit Start- und Stop- Bits zum Strukturieren von Datenklumpen. Normalerweise werden die hineingeschobenen Daten und die hinausgeschobenen Daten in der gleichen Weise kodiert werden. Die gleichgerichteten Eingangs- und Ausgangs-Datenströme können simultan benutzt werden, um vollduplexe, bidirektionale, serielle Übertragungen zu erlauben. Die Sequenz von seriellen Datenbits kann ein Informationsbyte bilden.
In dem beschriebenen Ausführungsbeispiel, wenn dieses mit einem Diagnosebetriebsmodus zusätzlich zu einem normalen Testmodus ausgestattet ist, ist die integrierte Schaltung 2 vorzugsweise, wie in Fig. 3 gezeigt, mit einem Datenadapter 90 ausgestattet, um zwischen der TAP-Steuerung 4 und der chipintegrierten Quellen-/Ziellogik als Interface zu dienen. Der Datenadapter 90 empfängt als Eingangssignale von der TAP-Steuerung 4 das Abtastdateneingangssignal SCANIN auf Leitung 28, das Testtaktsignal TESTCLK auf Leitung 38 und das Signal, welches die Auswahl des Diagnosemodus anzeigt, DIAGMODE auf Leitung 26. Der Datenadapter 90 gibt an die TAP-Steuerung 4 das Signal DIAGSCANOUT auf Leitung 36 aus. Der Datenadapter empfängt Daten von einer chipintegrierten Quellen- /Ziellogik auf einem Übertragungsdatenbus TXDATA auf Leitung 92 und gibt Daten an eine chipintegrierte Quellen- /Ziellogik auf einem Empfangsdatenbus RXDATA auf Leitung 94 aus. Der Datenadapter 90 empfängt als Eingang ein Sendegültigkeitssignal TXVALID auf Leitung 96 und gibt ein Sendebestätigungssignal TXACK auf Leitung 98 aus, wobei beide dieser Signale Steuerungssignale sind, welche mit dem Sendedatenbus TXDATA in Verbindung stehen. Der Datenadapter 90 gibt ein Empfangsgültigkeitssignal RXVALID auf Leitung 100 aus und empfängt als Eingang ein Empfangsbestätigungssignal RXACK auf Leitung 102, wobei beide Signale Steuerungssignale sind, welche mit dem Empfangsdatenbus RXDATA in Verbindung stehen.
Der Datenadapter 90 umfaßt ein Empfangsschieberegister 114, einen Empfangspuffer 116, eine Empfangssteuerungslogik 110, eine Empfangsablaufsteuerungsstatus-Flipflopschaltung 120, eine Sendeablaufsteuerungsstatus-Flipflopschaltung 124, ein Sendeschieberegister 118 und eine Sendesteuerungslogik 112. Das Empfangsschieberegister 114 empfängt das Signal SCANIN auf Leitung 28 und ein Steuerungssignal von der Empfangssteuerungslogik auf Leitung 126 und gibt parallel Daten an den Bus 130 aus, um einen Eingang an dem Empfangspuffer 116 zu bilden. Der Empfangspuffer empfängt zusätzlich ein Steuerungssignal von der Empfangssteuerungslogik auf Leitung 128 und erzeugt das Empfangsdatenbus-Signal RXDATA auf Leitung 94. Die Empfangssteuerungslogik erzeugt zusätzlich das Signal RXVALID auf Leitung 100, empfängt das Signal RXACK auf Leitung 102, empfängt das Signal DIAGMODE auf Leitung 26 und erzeugt die Signale STARTDATA und ACKRX auf den Leitungen 134 bzw. 132. Die Empfangsablaufsteuerungsstatus- Flipflopschaltung 120 empfängt das Signal STARTDATA und ein Signal TXSENDACK auf Leitung 136 und gibt ein Signal RXSENDACK an die Sendesteuerungslogik auf Leitung 142 aus. Die Sendeablaufsteuerungsstatus-Flipflopschaltung 124 empfängt das Signal ACKRX und ein Signal TXSENDBYTE auf Leitung 138 und gibt ein Signal TXWAITACK an die Sendesteuerungslogik auf Leitung 140 aus. Die Sendesteuerungslogik 112 empfängt zusätzlich das Signal DIAGMODE auf Leitung 26 und das Signal TXVALID auf Leitung 96 und gibt das Signal TXACK auf Leitung 98, ein Steuerungssignal an das Sendeschieberegister 118 auf Leitung 144 und ein paralleles Signal SERCONT an das Sendeschieberegister 118 aus. Das Sendeschieberegister 118 empfängt zusätzlich den parallelen Datenbus TXDATA auf Leitungen 92 und gibt das Signal DIAGSCANOUT auf Leitung 36 aus.
Der Datenadapter kann wahlweise mit einem Eingang von dem chipintegrierten System-Taktgerät ausgestattet sein, obwohl diese Verbindung in keiner der Figuren gezeigt ist. Das System-Taktgerät kann für synchrone Implementierungen verwendet werden, bei welchen die Daten- und Steuerungssignale zwischen dem Datenadapter und der chipintegrierten Ziel-/Quellenlogik synchron mit dem Takt der chipintegrierten Ziel-/Quellenlogik sein müssen. Der Datenadapter 90 vollführt eine Synchronisation von seriellen Daten von der TAP-Steuerung, getaktet durch das Signal TESTCLK. (abgeleitet von dem Signal TCK), zu der Taktumgebung von der internen Funktionalität der Ziel-/Quellenlogik, und zu der TAP-Steuerung, getaktet durch das Signal TESTCLK von der Taktumgebung der internen Ziel-/Quellenlogik. Die TAP-Steuerung 4 kann wahlweise ein Abtast-Freigabesignal an den Datenadapter 90 liefern, wobei das Signal auch nicht in den Figuren gezeigt wird. Ein solches Abtast- Freigabesignal zeigt an, daß die TAP-Steuerung diesen Abtastpfad für die Datenausgabe an das Testdaten-Ausgangssignal TDO ausgewählt hat.
Der Datenadapter wandelt die gleichgerichteten seriellen Daten vom Chipexternen durch die TAP-Steuerung 2 in ein Format um, welches geeigneter für die Benutzung durch die chipintegrierte Ziel-/Quellenlogik ist. Umgekehrt muß der Datenadapter das Datenformat, welches durch die chipintegrierte Ziel-/Quellenlogik zugeführt wird, in gleichgerichtete serielle Daten umwandeln. In einem bevorzugten Ausführungsbeispiel ist es gewünscht, Daten an die chipintegrierte Ziel-/Quellenlogik in Form von acht parallelen Datenbits oder einem Datenbyte, zu liefern. Im Extremfall können jedoch der Empfangsdatenbus RXDATA und der Sendedatenbus TXBUS nur ein Bit, anstatt einem Byte, breit sein. Es wird auch ins Auge gefaßt, daß die Empfangs- und Sendedatenbusse RXBUS und TXBUS mehrfachbytebreite Busse sein können.
Der Datenadapter 90 muß die Funktion "Ablaufsteuerung" sowohl für den Empfang als auch das Senden von Daten durchführen. Serielle Daten können nur durch die TAP- Steuerung 4 geführt werden (in beiden Richtungen), wenn das empfangende Ende Kapazität zum Empfangen dieser Daten verfügbar hat, um Datenverluste oder -zerstörung zu verhindern. Die Übertragung des Faktums, daß das empfangende Ende bereit ist, mehr Daten zu empfangen, wird dadurch erreicht, daß eine solche Information in der umgekehrten Richtung gesendet wird. Dies bildet das Ablaufsteuerungsprotokoll. Der Datenadapter 90 gemäß dem beschriebenen Ausführungsbeispiel sorgt dafür, daß die gleichgerichteten seriellen Daten in ein paralleles Format zum Datenaustausch mit der chipintegrierten Ziel-/Quellenlogik umgewandelt werden. Somit ist auch zwischen dem Datenadapter 90 und der chipintegrierten Ziel-/Quellenlogik ein Ablaufsteuerungsprotokoll notwendig.
Diese Ablaufsteuerung muß somit über zwei Grenzen hinweg durchgeführt werden: Die Grenze zwischen der TAP- Steuerung 4 und dem Datenadapter 90; und die Grenze zwischen dem Datenadapter 90 und der chipintegrierten Ziel- /Quellenlogik, welcher der Datenadapter 90 als Interface dient.
Um eine Ablaufsteuerung zwischen der TAP-Steuerung 4 und dem Datenadapter 90 bereitzustellen, werden die gleichgerichteten Daten auf der Testdaten-Eingangssignal TDI Leitung und der Testdaten-Ausgangssignalleitung mit Start- und Stop-Bits kodiert, wie in Fig. 4(a) gezeigt. Das Bitablaufsteuerungsprotokoll signalisiert Rückkehr zur Null (RPZ) mit zwei Startbits S1 und S2 und einem Stoppbit E1. Zwischen den Startbits und dem Stoppbit ist ein Datenbyte enthalten. Serielle Daten in diesem Format werden von dem Testdateneingang TDI der TAP-Steuerung an das SCANIN Signal auf Leitung 28 geführt und dem Datenadapter 90 eingegeben. Die Empfangssteuerungslogik 110 des Datenadapters empfängt das serielle Datensignal SCANIN. Wenn das Empfangssteuerungssignal zwei aufeinanderfolgende serielle Bits als Startbits S1 und S2 erkennt, wird das Empfangsschieberegister 114 so auf der Leitung 126 gesteuert, daß es die nächsten acht aufeinander folgenden Bits, welche ein Datenbyte bilden, darin seriell lädt.
In Antwort auf die zwei aufeinander folgenden Startbits S1 und S2, setzt die Empfangssteuerungslogik 110 auch das Signal STARTDATA auf Leitung 134, welches die Empfangsablaufsteuerungsstatus-Flipflopschaltung 120 einstellt. Wenn eingestellt, setzt die Empfangsablaufsteuerungsstatus-Flipflopschaltung 120 dann wieder das Signal RXSENDACK auf Leitung 142, wobei das Signal verursacht, daß die Sendesteuerungslogik 112 ein Bestätigungssignal beim Testdatenausgangssignal TDO in der in Fig. 4(b) gezeigten Form sendet, welches nur ein Startbestätigungsbit ACK und ein Stoppbit E1 umfaßt. Diese Bits werden direkt in das Sendeschieberegister parallel als das Signal SERCONT auf Leitung 150 unter der Steuerung des Signals auf Leitung 144 geladen und von dem Sendeschieberegister in serieller Weise in Form von Fig. 4(b) als das Signal DIAGSCANOUT ausgegeben. Sobald das Bestätigungssignal gesendet worden ist, setzt die Sendesteuerungslogik 112 das Signal TXSENDACK auf Leitung 136, um die Empfangsablaufsteuerungsstatus-Flipflopschaltung zurückzusetzen und dadurch das Signal RXSENDACK zurückzusetzen.
Das Signal SERCONT, gemäß dem in diesem Ausführungsbeispiel verwendeten Ablaufsteuerungsprotokoll, ist ein 3- Bit-Signal, welches den Startbits S1, S2 und dem Stoppbit E1 gestattet, direkt in das Sendeschieberregister 118 geladen zu werden. Wenn ein Datenbyte, welches durch die chipintegrierte Ziellogik dargestellt wird, um durch die TAP-Steuerung 4 ausgegeben zu werden, auf dem Sendebus TXDATA dargestellt ist, wird es parallel unter der Steuerung der Sendesteuerungslogik 112 in das Sendeschieberegister 118 geladen und die Sendesteuerungslogik 112 lädt direkt die Startbits S1, S2 und das Stoppbit E1, welche das Signal SERCONT bilden, in die geeigneten Bitpositionen in dem Sendeschieberegister und zwar vor dem seriellen Schieben eines Signals in dem in Fig. 4(a) gezeigten Format. Wenn ein Bestätigungssignal gesendet wird, lädt die Sendesteuerungslogik 118 ein einzelnes Startbit und ein Stoppbit direkt in das Sendeschieberegister und schiebt sie dann seriell hinaus.
Wenn die Empfangssteuerungslogik 110 das Stoppbit E1 auf dem Signal SCANIN empfängt, ist das Datenbyte in das Empfangsschieberegister 114 geladen worden und das Datenbyte wurde unter der Steuerung der Empfangssteuerungslogik 110 auf dem Bus 120 von dem Empfangsschieberegister 114 an den Empfangspuffer 116 übertragen. Wenn ein Datenbyte in den Empfangspuffer 116 geladen worden ist, wird es auf dem Bus RXDATA unter Steuerung der Empfangslogik 110 ausgegeben, welche auch das Signal RXVALID auf Leitung 100 setzt. Die chipintegrierte Ziel-/Quellenlogik, welche auf das Signal RXVALID anspricht, nimmt das Datenbyte auf dem RXBUS an und zeigt diese Annahme durch Setzen des Signals RXACK auf Leitung 102 an. In Antwort auf das Signal RXACK setzt die Empfangssteuerungslogik 110 erneut das Signal RXVALID und, falls sich ein weiteres Datenbyte in dem Empfangsschieberegister 114 befindet, überträgt sie dieses an den Empfangspuffer 116, bevor sie wieder das Signal RXVALID setzt.
Der Empfangspuffer 116 wird in dem bevorzugten Ausführungsbeispiel bereitgestellt. Dies ermöglicht es, Bestätigungstoken, welche den Empfang von Daten überlappen, zu übertragen, sobald die zwei Startbits empfangen worden sind, und dies unterstützt auch rationelle Datenübertragungsraten, indem aufeinander folgenden Bytes erlaubt wird, ohne jegliche Lücke zwischen jedem Byte übertragen zu werden. Datenpufferung kann auch auf der Sendeseite bereitgestellt werden.
Die chipintegrierte Ziel-/Quellenlogik überträgt Datenbytes parallel an den Datenadapter 90 auf dem TXDATA-Bus 92. Wenn die chipintegrierte Ziel-/Quellenlogik ein zu sendendes Datenbyte aufweist, wird das Signal TXVALID auf Leitung 96 gesetzt. In Antwort auf das gesetzte Signal TXVALID steuert die Sendesteuerungslogik das Sendeschieberegister 118 über Leitung 144, um das Datenbyte auf dem TXDATA Bus parallel zu laden. Zusätzlich lädt die Sendesteuerungslogik unter Benutzung der Leitungen 150 die geeigneten Startbits S1 und S2 und das Stoppbit E1 in das Sendeschieberegister 118. Dann wird, wieder unter der Steuerung des Signals 144, das Datenbyte einschließlich von zwei Startbits und einem Stoppbit seriell aus dem Sendeschieberegister als Signal DIAGSCANOUT hinausgeschoben, welches durch die TAP-Steuerung dem Signal TDO zugeführt wird. Wenn das Datenbyte auf dem Bus TXDATA in das Schieberegister geladen wird, setzt die Sendesteuerungslogik das Signal TXACK auf Leitung 98, um der chipintegrierten Ziellogik den Empfang der Datenbytes zu bestätigen. Die chipintegrierte Ziellogik kann dann ein weiteres Datenbyte senden. Datenpufferung kann in Verbindung mit dem Sendeschieberegister bereitgestellt werden, wenn dies gewünscht ist.
Wenn das Sendeschieberegister 118 durch die Sendesteuerungslogik 112 gesteuert wird, um serielle Daten in der in Fig. 4(a) gezeigten Form auszugeben, setzt die Sendesteuerungslogik 112 auch das Signal TXSENDBYTE auf Leitung 138, welches die Sendeablaufsteuerungsstatus- Flipflopschaltung 124 einstellt. In Antwort auf dieses Signal setzt die Sendeablaufsteuerungsstatus- Flipflopschaltung 124 das Signal TXWAITACK auf Leitung 140. Während das TXWAITACK Signal gesetzt ist, wartet die Sendesteuerungslogik auf eine Bestätigung von der chipexternen Ziel-/Quellenlogik, daß der Datenbytesatz empfangen worden ist. Wenn die chipexterne Ziel-/Quellenlogik das gesendete Datenbyte erfolgreich empfängt, dann sendet sie auf dem Testdaten-Eingangssignal TDI ein Bestätigungssignal des Typs wie in Fig. 4(b) gezeigt. Auf den Empfang eines solchen Bestätigungssignals als das SCANIN Signal auf Leitung 28 hin, wird die Empfangssteuerungslogik 110 das Signal ACKRX auf Leitung 132 setzen, wodurch die Sendeablaufsteuerungsstatus-Flipflopschaltung 124 und folglich das Signal TXWAITACK zurückgesetzt wird. Die Sendesteuerungslogik 112 ist dann bereit, das nächste parallele Datenbyte von der chipintegrierten Quellen- /Ziellogik zu empfangen und zu senden.
Fig. 5 stellt in schematischer Form dar, wie der Datenadapter 90 verwendet werden kann, um eine Verbindung zwischen einem Host-Speicher und einem Target-Speicher herzustellen. Die integrierte Schaltung 2 umfaßt die TAP- Steuerung 4 und den Datenadapter 90, welche untereinander Daten austauschen, und zwar chipextern, und mit einer chipintegrierten Schaltung unter Verwendung der oben beschriebenen Signale. Die gleichen Bezugszeichen sind in Fig. 5 verwendet, um Signale zu bezeichnen, welche denjenigen entsprechen, welche bereits beschrieben wurden. Wie in Fig. 5 gesehen werden kann, umfaßt die integrierte Schaltung 2 auch einen Speicherbus-Adapter 160, eine Target-CPU 162 und einen chipintegrierten Speicher 164. Die integrierte Schaltung 2 ist mit einem Speicherbus 166 ausgestattet, welcher als Interface mit der Target-CPU 162 und dem chipintegrierten Speicher 164 in Verbindung steht. Der Speicherbus 166 ist auch an den chipexternen Speicher 174 angeschlossen. Chipextern werden die Testzugriffsportsignale TCK, TMS, TDI, TDO und TRST* einem TAP- Steuerungsinitialisierer 176 zugeführt, welcher selbst ein serielles Dateneingangssignal SERIN auf Leitung 178 von einem weiteren Datenadapter 180 empfängt und ein serielles Datenausgangssignal SEROUT auf Leitung 179 an den weiteren Datenadapter 180 ausgibt. Der weitere Datenadapter 180 gibt Signale EXTRXDATA, EXTRXVALID und EXTTXACK auf Leitungen 190, 188 bzw. 186 an einen weiteren Speicherbusadapter 194 aus und empfängt Signale EXTTXDATA, EXTTXVALID und EXTRXACK auf Leitungen 184, 182 bzw. 192 von dem weiteren Speicherbusadapter 194. Der Speicherbusadapter 194 ist an den externen Speicherbus 198 angeschlossen. Eine Host-CPU 200 ist an den externen Speicherbus 198 angeschlossen und ein weiterer chipexterner Speicher 202 ist an den externen Speicherbus 198 angeschlossen.
Der TAP-Steuerungsinitialisierer 176 bildet die TAP- Steuerung 4 für den Betrieb entweder im Testmodus oder Diagnosemodus. Die Speicherbusadapter 160 und 194 passen die parallelen Daten auf dem Bus RXDATA an ein Nachrichtenformat an, welches geeigneter für Datenübertragung mit der chipintegrierten Ziel-/Quellenlogik ist. Die Speicherbusadapter sind hierfür Nachrichtenwandler und können Nachrichtenwandler des Typs sein, wie in der parallel anhängigen Anmeldung Page White & Farrer Ref. Nr. 82116 beschrieben. Die Speicherbusadapter müssen auch das Nachrichtenformat der chipintegrierten Ziel-/Quellenlogik in parallele Datenbytes zur Übertragung des Busses TXDATA umwandeln.
Die Struktur von Fig. 5 kann dazu verwendet werden, verschiedene Diagnoseprozeduren zu implementieren. Die chipintegrierten und chipexternen seriellen Verbindungen können die Datenübertragung von mehreren verschiedenen Diagnosedatentypen zwischen der integrierten Schaltung 2 und der Host-CPU 200 erlauben.
Die Host-CPU kann auf dem chipintegrierten Speicher 164 oder dem chipexternen Speicher 174 zugreifen, wobei sie das chipintegrierte Bussystem 166 benutzt, aber ohne die Target-CPU 162 einzubeziehen. Um dies zu tun, kann eine von der Host-CPU erstellte Speicherzugriffsanfrage über die als Interface dienende Schaltung, welche die chipexternen Speicherbusadapter 194, Datenadapter 180 und TAP- Steuerungsinitialisierer 176 und die chipintegrierte TAP- Steuerung 4, Datenadapter 90 und Speicherbusadapter 160 umfaßt, übertragen werden, wobei sie verschiedenen, hier diskutierten Umwandlungen unterzogen wird. Gleichmaßen können Daten, welche von dem chipintegrierten Speicher 164 oder chipexternen Speicher 174 gelesen werden, über das chipintegrierte Bussystem 166 und die als Interface dienende Schaltung an die Host-CPU zurückgesendet werden. Umgekehrt kann die Target-CPU auf den chipexternen Speicher 202 zugreifen, welcher mit der Host-CPU in Verbindung steht. Daten, welche von dem chipexternen Speicher 202, welcher mit der Host-CPU 200 in Verbindung steht, gelesen werden, können in gleicher Weise über die als Interface dienende Schaltung zurückgesendet werden.
Zusätzlich kann die Target-CPU für Diagnosezwecke überwacht werden. Zum Beispiel können ihre Zugriffe auf ihren eigenen Speicher durch chipintegrierte Schaltung überwacht werden und Informationen über die Speicheradressen, auf welche zugegriffen worden ist, unter Benutzung der als Interface dienenden Schaltung an die Host-CPU übertragen werden. Darüber hinaus enthält die Target-CPU Konfigurationsregister, welche ihren Status darstellen, oder hat Zugriff zu solchen. Informationen über den Inhalt dieser Register können chipextern an die Host-CPU unter Benutzung der als Interface dienenden Schaltung übertragen werden. Umgekehrt können bestimmte Statusinformationen in diese Register geladen werden, um diesen Zustand der Target-CPU unter dem Befehl der Host-CPU zu beeinflussen.
Somit erlaubt die hier diskutierte integrierte Schaltung die Übertragung von Diagnosedaten einschließlich Speicherzugriffsanfragen von der Art "host to target" und "target to hast" (Lese- und Schreiboperationen); Statusinformationen von CPU Registern; Datenlesung vom Host- Speicher oder Target-Speicher als Antwort auf eine Speicherzugriffsanfrage; Statusdaten zum Laden in CPU- Register; und Information über Speicheradressen, auf welche durch die Target-CPU zugegriffen wird.
Somit erlaubt die Interface-Schaltung das Bereitstellen folgender Diagnosemerkmale in der Schaltung:
Die Einrichtung Realzeit-Diagnoseprozeduren zu implementieren, d. h. während die Target-CPU in Echtzeit arbeitet und ohne ihre Operationen zu beeinflussen, während die Diagnoseprozeduren stattfinden. Insbesondere können die Überwachung des Speicherbusses und Zugriffe auf den Target-Speicher durch die Host-CPU vorgenommen werden, ohne die Target-CPU einzubeziehen;
Zugriff zum Target-Speicher und den Konfigurationsregistern vom Host;
Zugriff zum Host-Speicher vom Target;
Steuerung der Target-CPU und von Subsystemen, einschließlich der Einrichtung, Ladeoperationen der CPU vom Hostprozessor zu bewirken.
In dem beschriebenen Ausführungsbeispiel ist der gleichgerichtete serielle Datenstrom, welcher in den Testzugriffsport hinein und aus diesem hinaus geschoben wird und zwar im Diagnosebetriebsmodus beim Testdateneingangssignal TDI bzw. Testdatenausgangssignal TDO, Information in Form von Nachrichten. Solche Nachrichten können durch die Host-CPU oder durch die Target-CPU eingeleitet werden. In einer Fehlersuchumgebung kann die Host-CPU beeinflußende oder nicht-beeinflußende Diagnosen der chipintegrierten Ziel-/Quellenlogik durchführen. Alternativ hierzu können solche Nachrichten im Diagnosemodus durch die Target-CPU eingeleitet werden.
Der Speicherbusadapter 160 von Fig. 5 wandelt in den Chip eingehende Nachrichten in Steuerungsinformation, Adressen und Daten zur Benutzung durch die chipintegrierte Ziel- /Quellenlogik um. In dem beschriebenen Ausführungsbeispiel ist jede Nachricht ein Paket, welches eine Mehrzahl von Bytes aufweist. Wie oben beschrieben, wandelt der Datenadapter 90 eingehende serielle Daten in parallele Bytes um und wandelt ausgehende parallele Bytes in serielle Daten um. Der Speicherbusadapter 160 dekodiert die eingehenden Nachrichten und stellt der chipintegrierten Ziel-/Quellenlogik entsprechend Steuerungs-, Adress- und Dateninformation zur Verfügung. Gleichermaßen kodiert der Speicherbusadapter 160 Steuerungs-, Adress- und Dateninformation von der chipintegrierten Ziel-/Quellenlogik in Nachrichten, welche parallel an den Datenadapter übertragen werden.
In dem beschriebenen Ausführungsbeispiel gibt es zwei Typen von Nachrichten, welche ausgelöst werden können, und zwei Typen von Nachrichten, welche als Antworten erzeugt werden können. Die zwei Typen von Nachrichten, welche ausgelöst werden können, sind eine Speicherschreibanfrage zum Schreiben von bestimmten Daten an einem bestimmten Speicherort, welche als "Poke" bezeichnet wird, und eine Speicherleseanfrage zum Lesen von Daten von einem bestimmten Speicherort, welche als "Peek" bezeichnet wird. Die zwei Typen von Nachrichten, welche als Antworten erzeugt werden können, sind eine peek-enthaltende ("peeked") Nachricht, welche auf eine Speicherleseanfrage antwortet, um die gelesenen Daten zurückzusenden und eine getriggerte ("triggered") Nachricht, welche später beschrieben wird. Das erste Byte von jeder Nachricht ist ein Kopfbyte, dessen Struktur für jede der vier Nachrichten in Fig. 6 dargestellt ist. Das Kopfbyte bildet einen Paketindentifizierer, um die Beschaffenheit des Pakets zu identifizieren.
Die ersten zwei Bits eines Kopfbytes bilden einen Typenidentifizierer, um den Nachrichtentyp zu identifizieren, d. h. ob die Nachricht ein Poke, ein Peek, eine peekenthaltende Nachricht oder eine getriggerte Nachricht ist. Die folgenden sechs Bits des Kopfbytes wirken als ein Längenindikator, um die Anzahl Wörter, welche dem Kopfbyte folgen und mit dieser Nachricht in Verbindung stehen, zu identifizieren und somit die Länge des Pakets anzuzeigen. Alternativ hierzu, wie nachstehend im Detail diskutiert wird, können diese sechs Bits als ein Ursachenindikator wirken. Fig. 7 stellt die Struktur von jedem der vier Typen von Nachrichten gemäß dem beschriebenen Ausführungsbeispiel dar. Fig. 7a zeigt eine Poke- Nachricht umfassend ein Poke-Kopfbyte 00 + WORDCOUNT, gefolgt von einem Adresswort und gefolgt von mindestens einem Datenwort. Fig. 7b zeigt eine Peek-Message umfassend einen Peek-Kopfbyte 01 + WORDCOUNT gefolgt von einem Adresswort. Fig. 7c zeigt eine peek-enthaltende Nachricht umfassend ein peekenthaltendes Kopfbyte 10 + WORDCOUNT gefolgt von mindestens einem Datenwort. Fig. 7d zeigt eine getriggerte Nachricht umfassend nur ein getriggertes Kopfbyte 11 + REASON. Die Betriebsweise von jeder der vier Typen von Nachrichten wird nachfolgend im Detail beschrieben.
Wie oben erwähnt, wirkt der Speicherbusadapter 160 als ein Nachrichtenwandler und als solchen wird nachfolgend auf ihn Bezug genommen. Fig. 8 stellt ein Blockdiagramm eines Nachrichtenwandlers 160 gemäß dem beschriebenen Ausführungsbeispiel dar. Der Nachrichtenwandler 160 empfängt Informationsbytes auf dem Empfangsdatenbus RXDATA auf Leitungen 94 von dem Datenadapter 90 und überträgt Informationsbytes auf den Empfangsdatenbus TXDATA auf Leitungen 92 an den Datenadapter 90, wie oben im Detail beschrieben. Ferner, wie oben beschrieben, empfängt der Nachrichtenwandler die Signale RXVALID und TXACK auf Leitungen 100 bzw. 98 von dem Datenadapter und erzeugt Signale RXACK und TXVALID auf Leitungen 102 bzw. 96 an den Datenadapter. Der Nachrichtenwandler 160 steht zusätzlich als Interface mit der chipintegrierten Ziel-/Quellenlogik über drei Speicherbusports in Verbindung: Einem Speicher- Slave-Bus 220, einem Speicher-Master-Bus 222 und einem Speicher-Überwachungs-Bus 226. Der Nachrichtenwandler 160 steht als Interface ferner mit der chipintegrierten Ziel- Quellenlogik über den Diagnosebus 234 in Verbindung. Der Nachrichtenwandler 160 empfängt ferner Systemsignale SYSTEM auf Leitungen 236.
Der Speicher-Slave-Bus 220, der Speicher-Master-Bus 222, der Speicher-Überwachungs-Bus 226 und der Diagnose-Bus 234 sind jeweils in Fig. 8 als Einwegbusse dargestellt. Jeder dieser Busse wird jedoch Signale enthalten, deren Richtung entgegengesetzt zu derjenigen ist, welche durch die Pfeile in Fig. 8 gezeigt wird. Die Konvention, welche in der Zeichnung von Fig. 8 verwendet wird, ist, daß die Richtung der Pfeile des Busses die Richtung wiedergibt, in welche eine Anfrage gemacht wird. Fig. 9 zeigt mehr im Einzelnen die Signale, welche in jedem Bus enthalten sind.
Bezugnehmend auf Fig. 9 enthält jeder Bus eine Mehrzahl von ADDRESS-Signalen 350, eine Mehrzahl von WRITE DATA- Signalen 352, eine Mehrzahl von READ DATA-Signalen 354, ein REQUEST-Signal 356, ein GRANT-Signal 358 und ein VA- LID-Signal 360. Jeder der Busse hat andere damit in Verbindung stehende Steuerungssignale, welche nicht gezeigt werden, zum Beispiel Lese- und Schreibsteuerungssignale. Wie in Fig. 9 gesehen werden kann, werden die ADDRESS- Signale 350, die WRITE DATA-Signale 352 und das REQUEST- Signal 356 alle in eine Richtung übertragen, wobei die READ DATA-Signale 354, die das GRANT-Signal 358 und das VALID-Signal 360 in entgegengesetzter Richtung übertragen werden. Es soll jedoch angemerkt werden, daß in dem Speicher-Überwachungsbus 226, die READ DATA-Signale 354 und das GRANT-Signal 358 auch in der gleichen Richtung wie die ADDRESS-Signale 350, die WRITE DATA-Signale 352 und das REQUEST-Signal 356 übertragen werden. Das VALID- Signal 360 ist nicht in dem Speicher-Überwachungsbus 226 angeschlossen.
Der Speicher-Master-Bus 222 wird durch die chipexterne Host-CPU angetrieben, um Speicherzugriffsanfragen an den Speicherbereich der Target-CPU zu richten, und kann auch durch Diagnoseeinrichtungen angetrieben werden. Der Speicher-Slave-Bus 220 wird durch die Target-CPU angetrieben, um Speicherzugriffsanfragen an den chipexternen Speicher oder an die Diagnoseeinrichtungen zu richten. Der Speicher-Überwachungsbus 226 ist ein Festpfadbus, welcher an die gleichen chipintegrierten Signale wie der Speicher- Slave-Bus 220 angeschlossen sein kann und welcher durch Diagnoseeinrichtungen benutzt wird, um (nicht- beeinflußend) festzustellen, für was die Target-CPU den Slave-Bus benutzt. Der Diagnosebus 234 ist eher ein Registeradressierbus als ein Speicherbus, welcher auszuführendes Lesen und Schreiben von und auf chipintegrierte Diagnoseeinrichtungen, als auch das Übertragen von getriggerten Ereignissen, welche durch die Diagnoseeinrichtungen erzeugt werden, ermöglicht. Der Diagnosebus wird auch verwendet, um Speicherzugriffe (entweder zu einem lokalen chipintegrierten/chipexternen Speicher über den Speicher-Master-Bus oder zu einem entfernten Host- Speicher über den Datenadapter) von Diagnoseeinrichtungen auszulösen.
Statussignale werden dem Nachrichtenwandler von der Target-CPU über die Diagnoseeinrichtungen zugeführt. Diese können Target-CPU-Ablaufinformation enthalten, wie etwa den Befehlszeiger mit Kontrollsignalen, welche anzeigen, wenn der Befehlszeiger gültig ist. Die Host-CPU kann den Befehlszeiger überwachen, um zu bestimmen, was die Target-CPU macht. Die Statussignale können auch andere Target-CPU-Statussignale enthalten, einschließlich verschiedener einzelner Steuerungssignale, welche zusätzliche Information über den Betriebsstatus der CPU liefern. Auf den Status wird durch eine "Register"-Leseoperation auf dem Diagnosebus zugegriffen. Auf den Befehlszeiger wird auch durch eine "Registert"-Leseoperation zugegriffen, aber von einer verschiedenen Registeradresse.
Andere Information, welche mit dem Status der chipintegrierten Ziel-/Quellenlogik in Verbindung stehen, kann als das Statussignal eingeschlossen sein, wie etwa Information, die mit den chipintegrierten Registern in Verbindung stehen, aber eine solche Information würde typischerweise nur von Registern abgeleitet werden, welche eine Abstraktion der chipintegrierten Funktionalität für Diagnosezwecke enthalten. Die Funktionssignale können jeder nicht-beeinflußenden chipintegrierten Diagnoseeinrichtung zugeführt werden, zum Beispiel jeden Registern, welche die Abstraktion von Diagnoseinformation und -steuerung erleichtern.
Der Speicher-Master-Bus ist an den chipintegrierten Adressenbus, Schreib-Datenbus und Lese-Datenbus und damit verbundene Steuerungssignale angeschlossen. Der Speicher- Master-Bus wird verwendet, um der Host-CPU und den Diagnoseinrichtungen Zugriff auf den Adressenbereich innerhalb des Target-Speicherraums zu erlauben, einschließlich dem chipintegrierten Speicher 164, dem chipexternen Speicher 174 und anderen Bauelementen, welche über den Speicherbus zugänglich sind, wie etwa Konfigurationsregister.
Anstatt mehrere getrennte Busports zu haben, um die verschiedenen Verbindungen mit der chipintegrierten Ziel- /Quellenlogik bereitzustellen, wäre es möglich, einige Busse "zusammenzuschmelzen", unter Benutzung von geeigneten Steuerungssignalen, um zwischen ihnen zu unterscheiden. Zum Beispiel können die Speicherbus-Schreibdaten und -Lesedaten auf einem gemeinsamen Speicherdatenbus verschmolzen werden. Speicheradressen können mit Speicherdaten verschmolzen werden. Der Speicher-Slave-Bus kann mit dem Speicher-Master-Bus verschmolzen werden. Solche Alternativen stellen Implementierungsabwägungen zwischen Leistung, Bereich und anderen Faktoren dar.
Die Systemsignale auf Leitung 236 stellen eine Verbindung mit Systemdiensten bereit. Solche Systemdienste können zum Beispiel Taktung, Stromversorgung, Rücksetzung, Test sein.
Der Nachrichtenwandler empfängt aufeinanderfolgende Informationsbytes, welche in ein serielles Byteformat von einem seriellen Bitformat durch den Datenadapter umgewandelt worden sind und liest das Kopfbyte, um die darin übertragene Nachricht zu bestimmen. Der Nachrichtenwandler 106 interpretiert somit die eingehenden Nachrichten und führt die entsprechend notwendige Aktion aus. Eine solche notwendige Aktion beinhaltet das Auswählen der Information, welche an den Host zurückgesendet werden soll, oder das Auslösen eines Speicherzugriffs über einen der Busse, welcher geeignet ist und welcher mit dem Nachrichtenwandler verbunden ist, um Daten zu lesen oder zu schreiben. Der Nachrichtenwandler 160 kompilliert auch parallele Daten, welche von den chipintegrierten Bussen empfangen werden, in Nachrichten zur chipexternen Übertragung gemäß dem Nachrichtenprotokoll. Dies beinhaltet Zuordnen eines Kopfbytes zu den parallelen Daten- und Adressbytes, um die Beschaffenheit der Nachricht zu definieren, abhängig von den eingehenden Daten-, Adress- und Steuerungssignalen. Die Betriebsweise des Nachrichtenwandlers 160 von Fig. 8 und das Nachrichtenprotokoll von Fig. 6 und 7 wird nun detailliert unter Bezugnahme auf Fig. 10 beschrieben.
Fig. 10 stellt den Nachrichtenwandler 160 gemäß des beschriebenen Ausführungsbeispiel dar. Der Nachrichtenwandler umfaßt ein Kopfregister 240, ein Adressenregister 242, ein Datenregister 244, eine Dekrementierungssteuerung 246, eine Inkrementierungssteuerung 248, eine Schiebesteuerung 250, eine Ablaufsteuereinheit 252 und eine Busauswahls- und Routing-Logik 254. Der Nachrichtenwandler 160 ist mit einem internen Steuerungsbus 258 zur Übertragung aller Steuerungssignale und einem internen Informationsbus 256 ausgestattet. Der Steuerungsbus 258 ist an die Ablaufsteuereinheit 252 angeschlossen und überträgt die Ablaufsteuersignale RXVALID, RXACK, TXVALID und TXACK zur und von der Ablaufsteuereinheit 252. Der Steuerungsbus 258 überträgt ferner ein Dekrementierungssteuerungssignal auf Leitung 260 zu der Dekrementierungssteuerung 246, ein Inkrementierungssteuerungssignal auf Leitung 262 zu der Inkrementierungssteuerung 248, ein Schiebesteuerungssignal auf Leitung 264 zu der Schiebesteuerung 250, ein Kopfsteuerungssignal auf Leitung 266 an das Kopfregister 240, ein Adresssteuerungssignal auf Leitung 268 an das Adressenregister 242, ein Datensteuerungssignal auf Leitung 270 an das Datenregister 244, und ein Auswahls- und Routing-Steuerungssignal auf Leitung 272 an die Busauswahls- und Routing-Logik 254. Das Kopfregister 240 empfängt ein Steuerungssignal auf Leitung 241 von der Dekrementierungssteuerung 246, das Adressenregister 242 empfängt ein Steuerungssignal auf Leitung 243 von der Inkrementierungsteuerung 248 und das Datenregister 244 empfängt ein Steuerungssignal auf Leitung 245 von der Schiebesteuerung 250. Der Informationsbus 256 trägt die empfangenen Datenbytes RXDATA zu dem Kopfregister 240, dem Adressenregister 242, dem Datenregister 244 und der Busauswahls- und Routing-Logik 254. Zusätzlich trägt der Informationsbus 256 die Ausgangssignale von der Busauswahls- und Routing-Logik 254, dem Datenregister 244, dem Adressenregister 242 und dem Kopfregister 240 zu dem Sendedatensignal TXDATA. Die Busauswahls- und Routing-Logik 254 leitet die Information auf den Informationsbus 256, welcher in dem beschriebenen Ausführungsbeispiel einen Byte breit ist, zu und von entweder dem Speicher-Slave-Bus 220, dem Speicher-Master-Bus 222, dem Speicher-Überwachungsbus 226 oder dem Diagnosebus 234.
In dem Ausführungsbeispiel von Fig. 10 liefern die Systemsignale 236 lediglich das Taktsignal auf Leitung 280, welches benutzt wird, um das Kopfregister 240, das Adressenregister 242, das Datenregister 244 und die Ablaufsteuereinheit 252 zu takten. Die Betriebsweise des Nachrichtenwandlers 160 wird nun für die verschiedenen möglichen Nachrichtentypen beschrieben.
Wenn die Host-CPU einen Poke auslöst, wird eine serielle Nachricht in der in Fig. 7a gezeigten Form an dem Testzugriffsport der integrierten Schaltung 2 empfangen und nachfolgend in Form von parallelen Informationsbytes durch den Datenadapter 90 auf den Empfangs-Datenbus RXDATA ausgegeben. Bei Ausgabe jedes parallelen Informationsbytes auf den Empfangs-Datenbus RXDATA setzt der Datenadapter 90 das Signal RXVALID auf Leitung 100. Als Antwort auf Signal RXVALID auf Leitung 100, lädt die Ablaufsteuereinheit 252 des Nachrichtenwandlers 160 das Informationsbyte auf den Empfangs-Datenbus RXDATA in den Nachrichtenwandler 160 und setzt das Signal RXACK auf Leitung 102, um den Empfang des Informationsbytes zu bestätigen. Als Antwort an den Datenadapter 90, welcher das Signal RXVALID setzt, um ein erstes Informationsbyte einer Nachricht anzuzeigen, steuert die Ablaufsteuereinheit 252 das Kopfregister 240 über die Leitung 266, um das Informationsbyte auf den Empfangs-Datenbus RXDATA in das Kopfregister 240 über den Informationsbus 256 zu laden. Die Ablaufsteuereinheit 252 schaut dann auf die zwei niedrigstwertigen Bits des in dem Kopfregister 240 geladenen Bytes, um zu bestimmen, welcher Nachrichtentyp gerade eingeht. In diesem Moment identifiziert die Ablaufsteuereinheit 252 die zwei niedrigstwertigen Bits des empfangenen Bytes als 00 und identifiziert die eingehende Nachricht als einer Poke-Nachricht entsprechend. Eine Poke-Nachricht, welche durch die Host-CPU ausgelöst wurde, enthält Daten, welche die Host-CPU in eine bestimmte Adresse innerhalb des Target-CPU-Speicherbereichs einzufügen wünscht. Die Wortzählung, welche mit dem in dem Kopfregister 240 gespeicherten Kopfbyte in Verbindung steht, ist die Zählung der Anzahl von Datenwörtern in der Nachricht. Die Ablaufsteuereinheit 252 steuert das Adressenregister 242 über Leitungen 268, um die nächsten vier Bytes zu laden, welche auf den Empfangs-Datenbus RXDATA in das Adressenregister 242 über den Informationsbus 256 empfangen wurden, wobei die vier Bytes das Adresswort bilden. Sobald das Adresswort in das Adressenregister 242 geladen worden ist, werden die nächsten vier Bytes, welche auf dem Empfangs-Datenbus RXDATA empfangen werden und das erste Datenwort bilden, in das Datenregister 244 unter der Steuerung der Ablaufsteuereinheit 252 über die Steuerungsleitung 270 geladen. Die Ablaufsteuereinheit 252 steuert dann die Busauswahls- und Routing-Logik 254 über Leitung 272, um den Inhalt des Adressenregisters 242 und des Datenregisters 244 auf den Speicher-Master-Bus 222 auszugeben.
Beim Ausgeben des Inhalts des Adressen- und Datenregisters an den Speicher-Master-Bus 222 setzt die Ablaufsteuereinheit 252 das Schreibsteuerungssignal, welches mit diesem Bus in Verbindung steht, und das Anfragesignal auf Leitung 356, welches mit dem Speicher-Master-Bus in Verbindung steht. Wenn eine Speicherprioritätsentscheidungseinheit, welche mit dem Speicherbereich der Target- CPU, auf welche zugegriffen wird, in Verbindung steht, bestimmt, daß der angefragte Speicherzugriff fortgeführt werden kann, sendet sie das Gewährungssignal (grant signal) auf Leitung 358, welches mit dem Speicher-Master- Bus in Verbindung steht. Der Nachrichtenwandler 160 kann eine niedrige Priorität haben, wobei er in diesem Falle nur zugelassen wird, wenn Anfrager mit einer höheren Priorität (zum Beispiel die CPU) nicht anfragen und die vorangegangenen Zugriffe abgeschlossen haben. Eine Anfrage und ein Gewährungs-Setzen von Signalen ist für jedes übertragene Datenwort erforderlich.
Wenn die Wortzählung, welche in dem Kopfregister 240 enthalten ist, nach dem Speicherzugriff nicht eins ist (eins zeigt in diesem Ausführungsbeispiel einen Wortzählstand von Null an), dann wird das Adressenregister 242 durch die Inkrementierungssteuerung 248 über Steuerungsleitung 243 inkrementiert und ein weiteres Informationswort in das Datenregister 244 geladen. Nach dem Laden des Datenworts in das Register 244 wird wieder die Adresse, welche in dem Adressenregister 242 gespeichert ist, und die Daten, welche in dem Datenregister 244 gespeichert sind, an den Speicher-Master-Bus ausgegeben, wobei das Schreibsteuerungssignal und das Anfragesignal gesetzt werden, und das Datenwort, welches in dem Datenregister 244 enthalten ist, wird zu der Adresse, welche in dem Adressenregister 242 enthalten ist, geschrieben, wobei die Bestätigung hierüber durch die Speicherprioritätsentscheidungseinheit bestätigt wird, welche das Gewährungssignal auf dem Speicherbus setzt. Eine solche Sequenz von Inkrementierungen des Adressenregisters 242 und Laden von vier Informationsbytes in das Datenregister 244 wird fortgeführt, bis die Wortzählung, welche in dem Kopfregister 240 enthalten ist, gleich eins ist, d. h. keine Datenwörter mehr übrig sind.
Wenn die Host-CPU ein Peek auslöst, wird eine serielle Nachricht in der in Fig. 7b gezeigten Form am Testzugriffsport der integrierten Schaltung 2 empfangen und nachfolgend in Form eines parallelen Informationsbytes durch den Datenadapter 90 auf dem Empfangs-Datenbus RXDATA ausgegeben. Als Antwort an den Datenadapter 90, welcher das Signal RXVALID setzt, um ein erstes Informationsbyte anzuzeigen, steuert die Ablaufsteuereinheit 252 das Kopfregister 240 so, das Informationsbyte darin zu laden. Die Ablaufsteuereinheit 252 schaut dann auf die zwei niedrigstwertigen Bits des darin geladenen Bytes, um zu bestimmen, welche Nachricht eingeht und identifiziert in diesem Moment die zwei niedrigstwertigen Bits des empfangenen Bytes als 01 und identifiziert die eingehende Nachricht als einer Peek-Nachricht entsprechend. Eine Peek-Nachricht, welche durch die Host-CPU ausgelöst wurde, enthält eine Adresse innerhalb des Target-CPU- Speicherbereichs, dessen Inhalt die Host-CPU sich anzusehen wünscht.
Wenn die Ablaufsteuereinheit 252 eine Peek-Nachricht identifiziert, welche in das Kopfregister 240 geladen wird, indem sie die ersten beiden Bits des darin enthaltenen Kopfbytes als 01 identifiziert, dann verändert die Ablaufsteuereinheit 252 die ersten zwei Bits des Kopfbytes so, daß sie den geeigneten Bits für einen peekenthaltenden Kopf entsprechen, d. h. zu 01, und überträgt ein solches verändertes Kopfbyte auf den Sendedatenbus zurück zu der Host-CPU, einschließlich der in dem Kopfregister gespeicherten Wortzählung und zwar unversehrt, um das Kopfbyte der zurückgesendeten peek-enthaltenden Nachricht in der in Fig. 7c gezeigten Form zu bilden. Mit an deren Worten wird das Peek-Kopfbyte als ein peekenthaltendes Kopfbyte zurückgesendet, wobei die Wortzählung unversehrt ist und die zwei niedrigstwertigen Bits von 01 auf 10 geändert sind. Die nächsten vier Informationsbytes, welche auf dem Empfangsdatenbus RXDATA empfangen werden, werden in das Adressenregister 242 geladen und bilden das Adresswort. Die Ablaufsteuereinheit 252 steuert dann die Auswahls- und Routing-Logik 254 über Leitung 272, um das in dem Adressenregister 242 enthaltene Adresswort auf dem Speicher-Master-Bus 222 auszugeben, wobei in Verbindung das Lese-Steuerungssignal, welches mit diesem Bus in Verbindung steht, gesetzt wird und wobei das Anfragesignal, welches mit dem gesetzten Speicher-Master-Bus in Verbindung steht, gesetzt wird.
Als Antwort auf das gesetzte Anfragesignal setzt die Prioritätsentscheidungseinheit, wenn die Speicherprioritätsentscheidungseinheit, welche mit dem Speicherbereich der zugegriffenen Target-CPU in Verbindung steht, bestimmt, daß der angefragte Zugriff fortgeführt werden kann, daß Gewährungssignal, welches mit dem Speicher- Master-Bus in Verbindung steht. Wenn auf den aktuellen Speicherort, der mit der Adressausgabe auf dem Speicher- Master-Bus in Verbindung steht, zugegriffen worden ist und die darin gespeicherten Daten auf den Lesedatenbus des Speicher-Master-Busses ausgegeben worden sind, dann setzt die Prioritätsentscheidungseinheit das Signal VALID, welches mit dem Speicher-Master-Bus in Verbindung steht, um anzuzeigen, daß die Daten nun bereit sind, um zu der Host-CPU zurückgesendet zu werden. Als Antwort auf das gesetzte VALID-Signal steuert die Ablaufsteuereinheit 252 die Busauswahls- und Routing-Steuerungslogik über Leitung 272, um die Daten auf den Lesedatenbus des Speicher-Master-Busses in das Datenregister 244 zu laden. Das in das Datenregister 244 geladene Datenwort wird dann auf den Übertragungsdatenbus TXDATA über den Informationsbus 256 hinausgeschoben, und zwar ein Byte pro Zeiteinheit, und an die Host-CPU zurückgesendet. Ein Anfrage-, Gewährungs- und Gültigkeits-Setzen von Signalen wird für jedes übertragene Datenwort verlangt.
Nachdem das in das Datenregister 244 geladene Datenwort zurück an die Host-CPU geschoben worden ist, steuert die Ablaufsteuereinheit 252 die Dekrementierungssteuerung 246 über Leitung 260 an, um die Wortzählung, welche in dem Kopfregister 240 enthalten ist, über die Steuerungsleitung 241 um eins zu vermindern. Wenn die Wortzählung nicht eins ist, dann wird die Inkrementierungssteuerung 248 durch die Ablaufsteuereinheit 252 über Leitung 262 angesteuert, um die in dem Adressenregister 242 enthaltene Adresse über die Steuerungsleitung 243 zu erhöhen, und eine solche Adresse wird erneut durch die Busauswahls- und Routing-Logik 254 auf dem Speicher-Master-Bus 222 ausgegeben und zwar in Verbindung mit dem Setzen des Anfragesignals und des Lesesteuerungssignals. Auf diese Weise wird der nächste darauffolgende Speicherort in dem Target-CPU-Speicherbereich gelesen und der Inhalt davon in das Datenregister 244 des Nachrichtenwandlers 160 geschrieben. Erneut wird ein solches Datenwort Byte für Byte auf den Sendedatenbus TXDATA an die Host-CPU hinausgeschoben und die Wortzählung in dem Kopfregister wird erneut um eins dekrementiert. Ein solcher Zyklus wird wiederholt, bis die in dem Kopfregister 240 enthaltene Wortzählung gleich eins ist, d. h. keine Datenwörter mehr übrig sind.
Die Target-CPU selbst kann eine Poke- oder eine Peek- Nachricht auslösen, um entweder Daten zu schreiben oder Daten von dem Speicherbereich der Host-CPU 200 zu lesen. Das Auslösen eines Pokes oder eines Peeks durch die Target-CPU wird durch die Ablaufsteuereinheit 252 erkannt, welche den Speicher-Slave-Bus 220 des Target-CPU-Bereichs und seine in Verbindung stehenden Steuerungssignale überwacht und identifiziert, daß eine Adressausgabe auf dem Adressenbus durch die Target-CPU innerhalb des Adressbereichs der Host-CPU und nicht der Target-CPU ist, in Verbindung mit entweder einem Lese- oder einem Schreibsteuerungssignal. Im Gegensatz zu den Pokes und Peeks, welche durch die Target-CPU ausgelöst werden, wie oben diskutiert, welche Mehrfachwörter-Peeks und -Pokes ausführen kann, kann die Target-CPU nur Einzelwort-Peeks und -Pokes ausführen.
Wenn die Target-CPU einen Poke auslöst, wird dies durch die Ablaufsteuereinheit 252 erkannt, welche ein mit dem Schreibdatenbus des Speicher-Slave-Bus in Verbindung stehendes Schreibsignal identifiziert, und ein mit dem Speicher-Slave-Bus in Verbindung stehendes Anfragesignal wird gesetzt. Zusätzlich erkennt die Ablaufsteuereinheit 252, daß die Adresse, welche mit den durch den Speicher-Slave- Bus angefragten Schreibdaten in Verbindung steht, außerhalb des Speicherbereichs des Target-CPU-Bereichs ist. Als Antwort auf solche Bedingungen lädt die Ablaufsteuereinheit 252 ein vorgeladenes Poke-Kopfbyte, wie in Fig. 6(a) gezeigt, direkt in das Kopfregister 240 über Steuerungsleitungen 266. Ein solches Poke-Kopfbyte weist eine Wortzählung auf, welche ein Datenwort anzeigt. Das Adresswort auf dem Adressdatenbus des Speicher-Slave- Busses wird dann unter der Steuerung der Ablaufsteuereinheit 252 in das Adressenregister 242 durch die Busauswahls- und Routing-Logik 254 geladen, und die Schreibdaten auf dem Schreibdatenbus des Speicher-Slave-Busses werden gleichermaßen in das Datenregister 244 des Datenadapters 160 geladen. Unter der Steuerung der Ablaufsteuereinheit 252 wird dann das Poke-Byte in dem Kopfregister 240 auf dem Sendedatenbus TXDATA an die Host-CPU ausgegeben, nacheinander gefolgt von den vier Adressenbytes, welche in dem Adressenregister 242 enthalten sind, und den vier Datenbytes, welche in dem Datenregister 244 enthalten sind.
Gleichermaßen wird die Ablaufsteuereinheit 252, in Antwort darauf, daß die Ablaufsteuereinheit 252 auf dem Speicher-Slave-Bus ein Lesesignal in Verbindung mit einem Anfragesignal und einer Adresse auf dem Adressenbus des Speicher-Slave-Busses identifiziert, welches außerhalb des Adressenbereiches des Target-CPU-Bereichs ist, in das Kopfregister 240 das in Fig. 6(b) gezeigte Kopfbyte laden, welches einem Peek-Kopfbyte entspricht. In diesem Fall wird das Kopfbyte eine Wortzählung von eins enthalten, d. h. keine Datenwörter anzeigen. Gleichermaßen, wie oben beschrieben, wird die Ablaufsteuereinheit 252 auch den Datenadapter 160 ansteuern, um die Adresse auf dem Adressenbus des Speicher-Slave-Busses in das Adressenregister 242 zu laden. Das Kopfbyte, welches in dem Kopfregister 240 enthalten ist, wird dann auf dem Sendedatenbus TXDATA ausgegeben, gefolgt von vier aufeinander folgenden Bytes, welche in dem Adressenregister 242 gespeichert sind.
Zu diesem Zeitpunkt hat der Nachrichtenwandler 160 die target-ausgelöste Peek-Nachricht beendet, aber die Target-CPU hat nicht das VALID-Signal auf dem Speicher- Slave-Bus 220 empfangen und als Folge ist die Target-CPU "festgesteckt" (d. h. gesperrt oder fortwährend wartend) und kann nichts anderes tun (auch nicht eine Blockierung (stall) oder eine andere Unterbrechung). Der Nachrichtenwandler 160 steckt jedoch nicht fest. Er ist in der Lage, mit jeder seiner anderen Aktivitäten fortzufahren (obwohl er kein target-ausgelöste Peek- oder Poke-Anfrage empfangen wird, weil die CPU feststeckt).
Somit ist der Nachrichtenwandler, wenn er die Speicherzugriffsnachricht an den chipexternen Host-Prozessor gesendet hat, frei, um sich mit nachfolgenden Nachrichten oder Anfragen zu befassen.
Als Antwort auf einen Poke oder einen Peek, welcher durch die Target-CPU ausgelöst wurde, kann die Host-CPU mit einer peek-enthaltenden Nachricht antworten. Der Empfang einer peek-enthaltenden Nachricht von der Host-CPU wird durch die Ablaufsteuereinheit 252 identifiziert, welche einen Kopfbyte in dem Kopfregister, welcher der Struktur von Fig. 6(c) entspricht, erkennt. Die nächsten vier Informationsbytes von dem Empfangsdatenbus RXDATA werden in das Datenregister 244 geschoben und das darin geladene Datenwort durch die Busauswahls- und Routing-Logik 254 an den Datenbus des Speicher-Slave-Busses 220 des Target- CPU-Bereichs unter Steuerung der Ablaufsteuereinheit 252 übertragen, in Verbindung mit dem Setzen des mit dem Speicher-Slave-Bus in Verbindung stehenden VALID-Signals, womit der Speicherprioritätsentscheidungseinheit, welche mit dem Speicherplatz der Target-CPU in Verbindung steht, angezeigt wird, daß die durch seine Peek-Anfrage angefragten Daten jetzt verfügbar sind. Da die Target-CPU nur Einzelwort-Peeks auslösen kann, wird die peek-enthaltende Nachricht von der Host-CPU nur ein einzelnes Datenwort enthalten. Sobald die Target-CPU das VALID-Signal empfangen hat, ist es nicht mehr länger "festgesteckt".
Der Speicher-Slave-Bus 220 wird durch die Target-CPU verwendet, um auf die chipintegrierten Diagnosefunktionen zuzugreifen, auf welche durch die Host-CPU durch den Nachrichtenwandler 160 zugegriffen werden kann. Dies ist der gleiche Bus, wie er für target-ausgelöste Peeks/Pokes verwendet wird, und der Adressbereich bestimmt, ob dies ein Zugriff auf die chipintegrierten Diagnosefunktionen ist oder nicht. Als Antwort auf jegliche Aktionen, welche auf dem Speicher-Slave-Bus 220 durch die Target-CPU ausgelöst werden, steuert die Ablaufsteuereinheit 252 die Busauswahls- und Routing-Logik 254 über die Leitung 272 an, um jegliche Informations- oder Steuerungssignale auf dem Speicher-Slave-Bus 220 an den Diagnosebus 234 zu übertragen.
Bezugnehmend auf Fig. 11 wird dort in schematischer Form die Zwischenverbindung zwischen dem Nachrichtenwandler 160 der Fig. 8 und 10 und dem chipintegrierten Ziel- /Quellenlogik- oder Targetbereich und der Host-CPU dargestellt. Wie oben unter Bezugnahme auf Fig. 5 beschrieben, umfaßt die integrierte Schaltung 2 die TAP-Steuerung 4, den Datenadapter 90, die Target-CPU 162 einschließlich CPU-Registern 163 und den chipintegrierten Speicher 164. Zusätzlich umfaßt die integrierte Schaltung 2 von Fig. 11 Diagnoseeinrichtungen 300 einschließlich Diagnoseregistern 301, einem Cachespeicher 302, einer externen Speicher-Interface-Steuerung 304 und den Nachrichtenwandler 160, wie in Fig. 10 im Detail beschrieben. In Fig. 11 wird gezeigt, daß die Host-CPU 200 als Interface mit der TAP-Steuerung 4 der integrierten Schaltung 2 über einen Host-Übertragungsadapter 308 in Verbindung steht. Der Host-Übertragungsadaptet 308 umfaßt in dem beschriebenen Ausführungsbeispiel den TAP-Steuerungsinitialisierer 176, den Datenadapter 180 und den Speicherbusadapter 194, welche unter Bezugnahme auf Fig. 5 oben beschrieben sind. Zusätzlich umfaßt der Host-Übertragungsadapter 308 einen Nachrichtenwandler, welcher gleichwertig zu dem Nachrichtenwandler 160 ist, welcher auf der integrierten Schaltung 2 bereitgestellt ist, um Nachrichten an und von der Host-CPU 200 umzuwandeln. Unter weiterer Bezugnahme auf Fig. 11 kann gesehen werden, daß der Nachrichtenwandler 160 mit den Diagnoseeinrichtungen 300 über den Diagnosebus 234 Daten austauscht. Die Diagnoseeinrichtungen 300 und die Target-CPU 162 tauschen miteinander Daten über einen Bus 310 aus. Der Speicherüberwachungsbus 226 und der Speicher-Slave-Bus 220 des Nachrichtenwandlers 160 sind beide an einen allgemeinen Bus 312 zwischen der Target-CPU und dem Cachespeicher 302 angeschlossen. Zusätzlich sind die Target-CPU und der Cachespeicher 302 über einen CPU-Befehlsabrufbus 314 zwischenverbunden. Der Speicher-Master-Bus 222 auf dem Nachrichtenwandler 160 ist an den Cachespeicher 302 angeschlossen, welcher wiederum an den Speicherbus 166 der chipintegrierten Ziel- /Quellenlogik angeschlossen ist. Wie oben unter Bezugnahme auf Fig. 5 beschrieben, ist der Speicherbus 166 an den chipintegrierten Speicher 164 angeschlossen. Zusätzlich ist der Speicherbus 166 an die externe Speicher- Interface-Steuerung 304 angeschlossen, welche als Interface den chipintegrierten Ziel-/Quellenlogik-Speicherbus 166 an einen chipexternen Speicherbus 316 anschließt, welcher als Interface mit dem chipexternen Speicher 174 verbunden ist.
Die Struktur von Fig. 11 kann verwendet werden, um verschiedene Diagnoseprozeduren zu implementieren, indem Nachrichten zwischen der chipintegrierten Ziel- /Quellenlogik und der Host-CPU gesendet werden.
Der Diagnosebus 234 erlaubt Lesen und Schreiben auf und von den Diagnoseregistern 301 der Diagnoseeinrichtungen 300 und erlaubt auch das Erzeugen von getriggerten Ereignissen. Steuerungsinformation, welche mit der Target-CPU in Verbindung steht, wird von den Diagnoseeinrichtungen 300 gelesen. Der Befehlszeiger und andere Steuerungssignale, welche mit der Target-CPU in Verbindung stehen, werden in den Diagnoseregistern 301 der Diagnoseeinrichtungen 300 gespeichert. Der Befehlszeiger wird fortlaufend in eines der Diagnoseregister 301 kopiert und auf ihn kann durch eine Anfrage auf dem Diagnosebus 234 zugegriffen werden. Um den Status der Target-CPU anzusehen, ist es notwendig, eines der Diagnoseregister 301 der Diagnoseeinrichtungen 300 anzusehen. Die Diagnoseregister 301 können verschiedene Steuerungssignale der Target-CPU speichern, zum Beispiel STALL AT INTERRUPT POINT, TRAP AT INTERRUPT POINT. Diese Signale werden über bestimmte Leitungen an die CPU übertragen.
Die Host-CPU kann über den Diagnosebus 234 Register innerhalb der Diagnoseeinrichtungen 300 beschreiben, in gleicher Weise, wie die Host-CPU Speicherorte innerhalb des Target-CPU-Speicherbereichs über den Speicher-Master- Bus 222 beschreiben kann, wie oben diskutiert. Als Antwort auf das Beschreiben der Register der Diagnoseeinrichtungen 300 durch die Host-CPU, können getriggerte Ereignisse auftreten. Solche getriggerten Ereignisse werden in dem Nachrichtenwandler 160 durch die Ablaufsteuereinheit 252 entdeckt, welche ein Anfragesignal, welches mit einem das getriggerte Ereignis identifizierenden Ursachencode in Verbindung steht, identifiziert. Als Antwort auf das Anfragesignal lädt die Ablaufsteuereinheit 252 den Ursachencode, welcher mit dem getriggerten Ereignis in Verbindung steht, zusammen mit den zwei Bits 11, welche ein getriggertes Kopfbyte identifizieren, in das Kopfregister 240. Das getriggerte Kopfbyte, welches in dem Kopfregister 240 gespeichert ist, wird dann auf den Sendedatenbus TXDATA an die Target-CPU ausgegeben.
Wie oben erwähnt, kann die Target-CPU selbst auf die Diagnoseeinrichtungen 300 über den Speicherüberwachungsbus 226 und den Diagnosebus 234 zugreifen. Gleichermaßen, wenn die Target-CPU die Diagnoseeinrichtungen beschreibt und ein getriggertes Ereignis als Antwort zu einem solchen Beschreiben auftritt, dann wird die Ablaufsteuereinheit 252 das getriggerte Kopfbyte, welches in dem Kopfregister 240 enthalten ist, zurück an die Target-CPU ausgeben. Die Ablaufsteuereinheit 252 speichert, ob ein Beschreiben auf dem Diagnosebus 234 durch die Target-CPU oder die Host-CPU vorgenommen worden ist, und sendet entsprechend das getriggerte Ereignis zu dem richtigen Ziel zurück.
Der Nachrichtenwandler gemäß dem beschriebenen Ausführungsbeispiel, welcher in der in Fig. 11 gezeigten Umgebung implementiert ist, ermöglicht die Unterstützung einer Vielzahl von höheren Diagnosemerkmalen, einschließlich Laden von Testzugriffports, "Hot plug"-Einschub und Host- und Target-Synchronisierung.
Somit wird gemäß dem beschriebenen Ausführungsbeispiel ein Nachrichtenwandler bereitgestellt, welcher in einer integrierten Schaltung eingefügt wird und für Datenaustausch zwischen einer Host-CPU und einer chipintegrierten Ziel-/Quellenlogik über eine beschränkte Pin-Zählung sorgt. Ein solcher Wandler kann Zugriff auf eine Vielzahl von chipintegrierten Betriebsmitteln haben. Einige von diesen können einfach überwacht werden, andere können gesteuert oder sowohl überwacht und gesteuert werden. Überwachung von jeglichem Betriebsmittel ist nicht- beeinflußend und hat keinen Einfluß auf die Leistung oder Wartezeit der Funktionalität des Chips. Dies ist ideal für Diagnosezwecke. Der Nachrichtenwandler vollführt die Funktionen der Interpretation von empfangenen Nachrichten, der Kompilierung von Sendenachrichten und der Auswahl oder Ausrichtung von Information zu/von der chipintegrierten Ziel-/Quellenlogik. Der Nachrichtenwandler arbeitet unabhängig von jeglicher chipintegrierten Funktionalität und ist daher nicht-beeinflußend, bis oder außer daß er dazu ausgerichtet wird, einen beeinflußenden Arbeitsvorgang durchzuführen.
Bezugnehmend auf Fig. 11 kann die dortige Struktur angepaßt werden, indem der Cachespeicher 302 entfernt wird und der allgemeine Bus 312 und der CPU-Befehlsabrufbus 314 direkt an den Speicherbus 166 angeschlossen werden. Ferner kann die Struktur angepaßt werden, um einen zusätzlichen Master oder chipintegrierte autonome Funktionalität, welche an den Speicherbus 166 angeschlossen wird, zu umfassen. Ferner kann die Target-CPU 162 entfernt werden und der Speicher-Slave-Bus 220, der Speicher-Master-Bus 22 und der Speicher-Monitor-Bus 226 direkt an den Speicher-Bus 166 angeschlossen werden.
Gemäß dem folgenden beschriebenen Ausführungsbeispiel umfassen die Diagnoseeinrichtungen 300 eine Befehlsüberwachungssteuerung 400. Beispielhaft wird auf Fig. 12 Bezug genommen. Fig. 12 stellt die Target-CPU 162 mit ihren internen Registern dar, einschließlich einem Befehlszeigerregister 406. Das Befehlszeigerregister hält einen Befehlszeiger, welcher typischerweise ein 32-Bit- Speicheradressenwert ist, welcher eine Adresse im Speicher eines Befehls identifiziert, welcher von der CPU auszuführen ist. Das Befehlszeigerregister kann Befehlszeiger ein wenig im voraus vor der Stufe der Ausführung der CPU halten, so daß die Befehle rechtzeitig bevor sie zur Ausführung benötigt werden, vom Speicher abgerufen werden können. Die Befehle werden vom Speicher entlang dem Befehlsabrufbus 312 abgerufen, welcher über den Speicherbus 166 an den chipintegrierten Speicher 164 angeschlossen ist. Befehle können von alternativen Speicherorten abgerufen werden, wie dies vorstehend beschrieben wurde.
Der in dem Befehlszeigerregister 406 gehaltene Befehlszeiger wird der Befehlsüberwachungssteuerung zusätzlich entlang Bus 310 zugeführt. Er wird zusammen mit Steuerungssignalen zugeführt, welche anzeigen, wenn der Befehlszeiger gültig ist, wenn die CPU abgelenkt worden ist und dergleichen. Die Steuerungssignale umfassen insbesondere ein Signal, welches anzeigt, daß die nächste abzurufende Adresse eine nicht-sequentielle Adresse ist und stellt eine Diskontinuität in Adressen dar. Dies wird im folgenden ausführlicher beschrieben.
In Fig. 12 ist die Befehlsüberwachungssteuerung 400 an einen anwendungsspezifischen Speicher oder Überwachungspuffer 402 zum Halten von Überwachungsadressen über einen Überwachungsbus 404 angeschlossen. Der anwendungsspezifische Speicher 402 stellt Speicherüberwachungsplätze zum Halten von Überwachungsadressen bereit, welche bei Diskontinuitäten in dem Befehlszeiger identifiziert werden, wie nachfolgend ausführlicher beschrieben wird.
Fig. 13 stellt eine alternative Umgebung dar, in welcher eine Befehlsüberwachungssteuerung 400 bereitgestellt werden kann. Diese unterscheidet sich von der Umgebung von Fig. 12 lediglich darin, daß die Befehlsüberwachungssteuerung keinen anwendungsspezifischen Speicher wie den Speicher 402 mehr hat. Anstatt dessen ist sie an den Speicherbus 166 über einen Überwachungsbus 404' angeschlossen. Die Überwachungsspeicherplätze zum Speichern der Überwachungsadressen können somit an jeglichem Speicher bereitgestellt werden, welcher über den chipintegrierten Speicherbus 166 zugänglich ist, wie der chipintegrierte Speicher 164, ein chipexterner, an den Speicherbus 166 angeschlossener Speicher, wie der Speicher 174 in Fig. 11, oder ein Host-Speicher, welcher über die TAP-Steuerung und den Nachrichtenwandler, wie vorher beschrieben, zugänglich ist.
In beiden Fig. 12 und 13 ist die Befehlsüberwachungssteuerung 400 an den Nachrichtenwandler über den Diagnosebus 234 angeschlossen.
Fig. 14 stellt die Bauelemente der Befehlsüberwachungssteuerung 400 dar. Sie weist ein Jump-From-Register 408 auf, welches einen Befehlszeiger hält, welcher einer Diskontinuität vorhergeht. Es kann mehr als ein solches Register geben. Die Befehlsüberwachungssteuerung weist ferner ein Jump-To-Register 410 auf, welches einen Befehlszeiger auf den ersten Befehl hält, welcher einer Diskontinuität folgt. Es kann mehr als ein solches Register geben. Ein Adressenregister 412 zeigt an, wo die Überwachungsspeicherplätze gefunden werden können, um die Überwachungsadressen, welche in dem Jump-From-Register und/oder dem Jump-To-Register identifiziert wurden, zu halten. Wo die Überwachungsspeicherplätze in einem anwendungsspezifischen Speicher (oder Überwachungspuffer) bereitgestellt werden, wird ein Größenregister 414 zum Anzeigen der Größe des Überwachungspuffers bereitgestellt. Ein Optionssteuerungsbitregister 416 hält Optionssteuerungsbits, deren Funktion nachstehend beschrieben werden wird. Die Befehlsüberwachungssteuerung umfaßt ferner einen Inkrementierer 419, welcher die Adressenregister 412 inkrementiert, um den Überwachungspuffer mit einer Überlauf-Fähigkeit auszustatten, so daß wenn er voll ist, Überwachungsadressen über vorher gespeicherte Überwachungsadressen am Anfang des Überwachungspuffers gespeichert werden können. Die Befehlsüberwachungssteuerung 400 umfaßt auch eine Steuerungslogik 418, welche angeschlossen ist, um die Befehlssteuerungssignale, welche mit dem Befehlszeiger von der CPU entlang dem Bus 310 gesendet werden, zu empfangen. Die Steuerungslogik 418 ist auch an das Optionssteuerungsbitregister 416 angeschlossen. Jedes der Register 408, 410, 412, 414, 416 und die Steuerungslogik 418 sind an einem internen Bus 420 angeschlossen, welcher selbst an den Diagnosebus 234 und den Überwachungsbus 404 angeschlossen ist. Der Befehlszeiger wird auf Bus 310 von der CPU an das Jump-From-Register 408 und das Jump-To-Register 410 geliefert.
Die Befehlsüberwachungssteuerung arbeitet wie folgt. Die in dem Befehlszeigerregister 406 der CPU sequentiell gehaltenen Befehlszeiger werden der Befehlsüberwachungssteuerung 400 durch einen Bus 310 zugeführt. Wenn die zu dem Befehlszeiger gehörigen Befehlssteuerungssignale anzeigen, daß es eine Diskontinuität gegeben hat, wird der Befehlszeiger an dieser Diskontinuität veranlaßt, an einem Überwachungsspeicherplatz gespeichert zu werden, welcher durch das Adressenregister 412 identifiziert wird. Der Befehlszeiger an der Diskontinuität wird vorübergehend in dem Jump-From-Register 408 gehalten, während auf den passenden Überwachungsspeicherplatz zugegriffen wird. Nachdem der Befehlszeiger an dem identifizierten Überwachungsspeicherplatz gespeichert worden ist, kann er entweder von dem Jump-From-Register 408 entfernt werden oder, als eine Verfeinerung, darin für nachfolgenden Zugriff für zusätzliche Diagnosezwecke verbleiben.
Eine Diskontinuität in diesem Sinn ist, wenn der nachfolgende Befehlszeiger nicht an dem Platz ist, welcher dem des vorherigen Befehls gleich folgt. Die Ursache der Diskontinuität kann in einem Programmbefehl liegen, welcher einen Sprung verursacht, oder in einem Einfluß, wie einem Ausnahme-Trap oder einer Ausnahme-Unterbrechung, welcher verursacht, daß der Befehlsablauf abgelenkt wird. In dem beschriebenen Ausführungsbeispiel wird der Befehlsüberwachungssteuerung eine solche Diskontinuität durch ein Steuerungssignal von der CPU mitgeteilt, genannt LOAD NEW EPTR. Dies ist ein Signal, welches durch die Ausführungseinheit der CPU erzeugt wird, um der Abrufeinheit mitzuteilen, mit dem Abrufen von einem neuen Speicherort anzufangen. Der Befehlszeiger, welcher der Befehlsüberwachungssteuerung von der CPU zugeführt wird, trägt sowohl den Zeiger auf den nächsten auszuführenden Befehl als auch, für irgendeine Diskontinuität, den Zeiger auf den Ort des Starts eines neuen Ablaufs, von welchem die Abrufeinheit nun wieder anfangen muß abzurufen. Obwohl dies einiges im voraus zu dem nächsten auszuführenden Befehl geschieht, ist es immer noch gültig in dem Sinne, daß er immer noch ein gültiger Zeiger auf den nächsten Befehl ist, welchen die CPU ausführen wird.
Die Befehlsüberwachungssteuerung empfängt die Adresse des letzten vor einer Diskontinuität ausgeführten Befehls und die Adresse eines ersten Befehls des neuen Ablaufs. Wie oben beschrieben, wird die Adresse des letzten vor einer Diskontinuität ausgeführten Befehls in dem Jump-From- Register gehalten. Die Adresse des ersten Befehls des neuen Ablaufs wird in dem Jump-To-Register 410 gehalten, während auf einen passenden Überwachungsspeicherplatz zugegriffen wird, um sie zu speichern. Wie zuvor kann sie dann von dem Jump-To-Register entfernt werden oder darin für nachfolgende Diagnosezwecke gehalten werden.
Es wird anerkannt werden, daß die Bestimmung von Diskontinuitäten und das Speicher von Überwachungsadressen lediglich um diese Diskontinuitäten herum die Speichermenge, welche für Überwachungsadressen erforderlich ist, bedeutend vermindert. Es wird jedoch offensichtlich sein, daß das genaue Verhältnis von dem Befehlszeiger relativ zu der festgestellten Diskontinuität nicht wichtig ist, solange die Kriterien zum Speichern der Überwachungsadressen an den Überwachungsspeicherplätzen gleichbleibend sind und dem Benutzer das Verhältnis bewußt ist. Zum Beispiel könnte die Befehlsüberwachungssteuerung den Zeiger auf den zweitletzten ausgeführten, den letzten ausgeführten oder den nächsten vor einer Diskontinuität auszuführenden speichern.
Die Steuerungslogik 418 kann auch ein Signal erzeugen, um die CPU zu blockieren. Dies kann unter Verhältnissen nützlich sein, bei welchen das Speichern der Überwachungsadressen relativ langsam ist und es ratsam sein würde, die CPU zu blockieren, bis die Überwachungsadressen vollständig gespeichert worden sind.
Das Optionssteuerungsbitsregister 416 steuert, welche der oben diskutierten Optionen tatsächlich durch die Befehlsüberwachungssteuerung implementiert wird. Somit kann es steuern, ob oder ob nicht das Jump-From-Register verwendet wird oder das Jump-To-Register oder beide. Darüber hinaus kann es bestimmen, ob oder ob nicht ein Blockierungs-CPU-Signal zu senden ist, wenn die Überwachungsspeicherplätze nicht leicht verfügbar sind.
Wie bereits erwähnt, können die Überwachungsspeicherplätze in einem von einer Vielzahl von verschiedenen Speichern sein, abhängig von der Umgebung, in welcher die Befehlsüberwachungssteuerung zu arbeiten hat.
Die Anordnung von Fig. 12, bei welcher die Befehlsüberwachungssteuerung einen privat-anwendungsspezifischen Speicher 402 verwendet, ist vorteilhaft, um der Befehlsüberwachungssteuerung zu ermöglichen, in einer nicht- beeinflussenden Weise zu arbeiten, welche die Leistung oder Unterbrechungswartezeit der CPU oder irgendeiner anderen Funktionalität nicht beeinflußt. Somit ist der Speicher 402 ein Privat-Speicher, welcher von dem CPU- Speicher und den normalen Speicherbussen getrennt ist. Der Privat-Speicher 402 kann nichtsdestoweniger über den Diagnosebus 234 und den Überwachungsbus 404 in einer Weise untersucht werden, welche nicht-beeinflussend zum Normalbetrieb der CPU ist. Somit kann eine Befehlsüberwachung gehalten und auf sie zugegriffen werden, alles, ohne den Normalbetrieb der chipintegrierten CPU zu beeinflussen.
Die Anordnung von Fig. 13 erfordert keinen Privat- Speicher 402, sondern nutzt anteilig die normalen Einrichtungen, welche für die Target-CPU 162 bereitgestellt sind. Dies ist somit stärker beeinflussend als die Anordnung von Fig. 12, aber beeinflußt den Betrieb der CPU immer noch nicht wirklich. Wie oben beschrieben, erfordert die Befehlsüberwachungssteuerung lediglich, auf die Überwachungsspeicherplätze im Speicher an Diskontinuitäten zuzugreifen. Es ist möglich, diesen Zugriff herzustellen, wenn die CPU den ersten Befehl des neuen Ablaufs dekodiert. Für bestimmte CPU-Architekturen oder unter bestimmten Bedingungen bedeutet dies, daß die Befehlsüberwachungssteuerung die Leistung oder Wartezeit der CPU überhaupt nicht beeinflußt. Jedoch könnte es andere Situationen geben, zum Beispiel, wenn der Speicherbus stark belastet ist, in welchen die anteilige Nutzung des Speicherbusses durch die Befehlsüberwachungssteuerung einen geringen Einfluß auf die Leistung haben könnte. Dies könnte jedoch durch den verminderten Gesamtspeicherbedarf ausgeglichen werden.
Die Befehlsüberwachungssteuerung kann auch Speicher verwenden, welcher über das TAP-Steuerungsinterface und die serielle Datenübertragungsverbindung, wie vorher beschrieben, zugänglich ist. Dies würde viel langsamer sein, als ein normaler Speicherzugriff, aber vorausgesetzt, daß Diskontinuitäten nicht in schneller Folge auftreten und die Datenübertragungsbandbreite ausreichend ist, kann die Befehlsüberwachungssteuerung diese Methode in einer nicht-beeinflussenden Weise nutzen. Wenn die Bandbreite tatsächlich nicht ausreichend war, um eng beabstandete Diskontinuitäten zu handhaben, wäre die Befehlsüberwachungssteuerung in der Lage, einen Teil der Überwachungsinformation abzulegen. Eine praktische Sache ist, daß falls Diskontinuitäten eng zusammen auftreten, und sogar wenn ein Teil der Überwachungsinformation abgelegt wird, normalerweise ausreichend Information erhalten bleiben würde, um die fehlenden Diskontinuitäten abzuleiten.
Das Adressenregister 412 bestimmt, welcher Speichertyp zu verwenden ist. Es kann arrangiert werden, zu inkrementieren, jedes Mal nachdem ein Befehlszeiger an die Überwachungsspeicherplätze geschrieben wird, so daß sie in aufeinanderfolgenden Orten in dem Speichertyp, welcher auch immer ausgewählt worden ist, gespeichert werden. Somit bestimmt in dem hier beschriebenen Ausführungsbeispiel, welches Verbindungen zu mehreren Speichertypen umfaßt, das Adressenregister, welcher dieser Speichertypen in jedem einzelnen Fall zu verwenden ist. Das Adressenregister selbst kann anfänglich über den Diagnosebus 234 oder durch Verwendung der chipintegrierten CPU über den Überwachungsbus 404 geladen werden. Jeder dieser Übertragungswege kann auch dazu verwendet werden, die anderen Register in der Befehlsüberwachungssteuerung 400 anfänglich einzustellen.
In dem oben beschriebenen Ausführungsbeispiel zeigen die Befehlssteuerungssignale, welche mit dem Befehlszeiger von der CPU zugeführt werden, der Befehlsüberwachungssteuerung die Diskontinuitäten an. Als eine Alternative hierzu könnte die Befehlsüberwachungssteuerung selbst Diskontinuitäten feststellen, indem sie den nächsten Befehlszeiger mit einem Erwartungswert vergleicht. Normalerweise folgt der Befehlszeiger einer linearen Sequenz und ein Code wird von aufeinanderfolgenden Speicherplätzen abgerufen. Somit wäre der Erwartungswert ein Adressplatz mehr als der vorherige. Wenn er dies nicht war, dann wäre es eine Diskontinuität und könnte als solche identifiziert werden. Sogar für Variable-Längen-Code-CPUs wäre dieser Ansatz gültig. Für einen Variable-Längen- Code, obwohl die Befehlsabrufe von fortlaufenden Speicherorten sind, folgt die Ausführung nicht von einem Speicherort zu dem nächsten, weil dies von der Größe des ausgeführten Befehls abhängt. Jedoch würde die Tatsache, daß das Abrufen immer noch von fortlaufenden Speicherplätzen geschieht, bedeuten, daß eine Diskontinuität immer noch identifiziert werden könnte, indem der nächste Befehlszeiger mit einem Erwartungswert verglichen wird.
Ferner, wie in dem obigen Ausführungsbeispiel beschrieben, wird der Befehlszeiger von dem Befehlszeigerregister 406 der CPU 162 der Befehlsüberwachungssteuerung 400 zugeführt. Als eine Alternative hierzu wäre es für die Befehlsüberwachungssteuerung möglich, den Befehlsabrufbus 312 zu überwachen, als eine Alternative dazu, den Befehlszeiger direkt von der CPU anzusehen, vorausgesetzt, daß Befehle vom Speicher abgerufen werden müssen, bevor sie ausgeführt werden. Eine solche Alternative kann in Situationen wirkungsvoll sein, in welchen ein einfacher Befehlsplan angewandt wird. Es würde auch eine Information darüber erfordern, wie weit das Befehlsabrufen vor der Befehlsausführung liegt.

Claims

1. Integriertes Einchip-Schaltungselement, mit:

einer chipintegrierten (on-chip) CPU (162) mit einer Abruf- und Ausführungsschaltung zum Abrufen und Ausführen von Befehlen aus einem Speicher (164), und einem Befehlszeigerregister (406) zum sequentiellen Halten von Adressen von Befehlen im Speicher, die von der CPU auszuführen sind; dadurch gekennzeichnet, daß vorhanden sind:

eine Befehlsüberwachungssteuerung (400), welche die Adressen überwachen kann und welche verbunden ist, um Speicherplätze zu überwachen, um zu bewirken, daß ausgewählte Adressen an den Überwachungsspeicherplätzen gespeichert werden, abhängig von der Feststellung, daß eine der Speicheradressen nicht die nächste sequentielle Adresse im Speicher nach der vorhergehenden Adresse ist.

2. Integriertes Einchip-Schaltungselement nach Anspruch 1, welches einen Speicherbus (166) aufweist, um die Übertragung von Befehlen von dem Speicher zu der CPU-Abruf- und Ausführungsschaltung zu ermöglichen.

3. Integriertes Schaltungselement nach Anspruch 2, bei welchem die Befehlsüberwachungssteuerung (400) mit dem Speicherbus (166) verbunden ist, um die ausgewählten Adressen in Überwachungsspeicherplätzen im Speicher (164) zu speichern.

4. Integriertes Schaltungselement nach Anspruch 2, bei welchem die Befehlsüberwachungssteuerung (400) mit den Überwachungsspeicherplätzen über einen vom Speicherbus (166) getrennten Überwachungsspeicherbus (404) verbunden ist.

5. Integriertes Schaltungselement nach Anspruch 4, bei welchem der Überwachungsspeicherbus (404) verbunden ist, um Speicherplätze in dem Speicher zu verfolgen.

6. Integriertes Schaltungselement nach Anspruch 4, bei welchem der Überwachungsspeicherbus (404) verbunden ist, um Speicherplätze in einem von dem Speicher (164) getrennten Überwachungspuffer zu verfolgen.

7. Integriertes Einchip-Schaltungselement nach einem der vorstehenden Ansprüche, bei welchem die Befehlsüberwachungssteuerung (400) mit dem Befehlszeigerregister (406) zum Überwachen von Adressen verbunden ist.

8. Integriertes Schaltungselement nach einem der vorstehenden Ansprüche, bei welchem ein chipexterner (off-chip) Übertragungspfad zum Zugreifen auf Überwachungsspeicherplätze vorgesehen ist, um eine chipexterne Befehlsüberwachung bereitzustellen.

9. Integriertes Schaltungselement nach einem der vorstehenden Ansprüche, bei welchem die ausgewählten Adressen in aufeinanderfolgenden Überwachungsspeicherplätzen gespeichert werden.

10. Integriertes Schaltungselement nach einem der vorstehenden Ansprüche, bei welchem die Befehlsüberwachungssteuerung (400) ein Zieladressenregister aufweist, welches die Adresse des nächsten Überwachungsspeicherplatzes hält, in welchem die nächste ausgewählte Adresse zu speichern ist.

11. Integriertes Schaltungselement nach Anspruch 1, welches einen chipexternen seriellen Verbindungsabschnitt aufweist, der mit einer Host-CPU mit zugehörigem Host-Speicher verbunden ist, wobei die Überwachungsspeicherplätze in dem Host-Speicher bereitgestellt sind.

12. Integriertes Schaltungselement nach einem der vorstehenden Ansprüche, bei welchem die Befehlsüberwachungssteuerung (400) betreibbar ist, um den Normalbetrieb der CPU (162) zu blockieren, um zu ermöglichen, daß die Adressen in den Überwachungsspeicherplätzen gespeichert werden können.

13. Integriertes Schaltungselement nach einem der vorstehenden Ansprüche, bei welchem die Befehlsüberwachungssteuerung (400) ein erstes Register zum Speichern von einer der Adressen unmittelbar vor der Feststellung von einer nicht-sequentiellen Adresse aufweist.

14. Integriertes Schaltungselement nach einem der vorstehenden Ansprüche, bei welchem die Befehlsüberwachungssteuerung (400) ein zweites Register zum Speichern von einer der Adressen unmittelbar nach Feststellung von einer nicht- sequentiellen Adresse aufweist.

15. Integriertes Schaltungselement nach Anspruch 6, bei welchem nachfolgend ausgewählte Adressen, die zu speichern sind, auf vorher ausgewählte Adressen, die in dem Überwachungspuffer gespeichert sind, geschrieben werden, wenn der Überwachungspuffer voll ist.

16. Integriertes Schaltungselement nach einem der vorstehenden Ansprüche, bei welchem die Befehlsüberwachungssteuerung (400) Mittel zum Feststellen von einer nicht-sequentiellen Adresse aufweist.

17. Integriertes Schaltungselement nach einem der Ansprüche 1 bis 16, bei welchem die CPU (162) der Befehlsüberwachungssteuerung (400) anzeigt, daß die nächste Adresse eine nicht-sequentielle Adresse ist.

18. Verfahren zum Bereitstellen einer Befehlsüberwachung von einer chipintegrierten CPU in einem integrierten Einchip-Schaltungselement, bei welchem Adressen im Speicher von durch die CPU auszuführenden Befehlen sequentiell in einem Befehlszeigerregister der CPU gehalten werden, dadurch gekennzeichnet, daß die Adressen durch eine Befehlsüberwachungssteuerung auf dem integrierten Einchip- Schaltungselement überwacht werden, wobei die Befehlsüberwachungssteuerung bewirken kann, daß ausgewählte Adressen an vorbestimmten Überwachungsspeicherplätzen abhängig von der Feststellung gespeichert werden, daß eine der Adressen nicht die nächste sequentielle Adresse im Speicher nach einer vorhergehenden Adresse ist.

19. Verfahren nach Anspruch 18, bei welchem die ausgewählten Adressen in aufeinanderfolgenden Überwachungsspeicherplätzen gespeichert werden.

20. Verfahren nach Anspruch 18 oder 19, bei welchem die Befehlsüberwachungssteuerung betrieben wird, um einen Normalbetrieb der CPU zu blockieren, um zu ermöglichen, daß die Adressen in den Überwachungsspeicherplätzen gespeichert werden.

21. Verfahren nach einem der Ansprüche 18 bis 20, bei welchem die ausgewählten Adressen temporär in einem Überwachungspuffer innerhalb der Befehlsüberwachungssteuerung gehalten werden, bevor sie in Überwachungsspeicherplätzen gespeichert werden.

22. Verfahren nach einem der Ansprüche 18 bis 21, bei welchem die Befehlsüberwachungssteuerung betreibbar ist, um eine nicht-sequentielle Adresse festzustellen.

23. Verfahren nach einem der Ansprüche 18 bis 21, bei welchem die CPU der Befehlsüberwachungssteuerung anzeigt, daß die nächste Adresse eine nicht- sequentielle Adresse ist.