DE69705813T2

DE69705813T2 - Diagnosesystem und Verfahren bei einer integrierten Halbleiterschaltung

Info

Publication number: DE69705813T2
Application number: DE69705813T
Authority: DE
Inventors: Robert Warren
Original assignee: STMicroelectronics Ltd Great Britain; SGS Thomson Microelectronics Ltd
Current assignee: STMicroelectronics Ltd Great Britain
Priority date: 1996-12-19
Filing date: 1997-12-12
Publication date: 2002-10-24
Anticipated expiration: 2017-12-13
Also published as: DE69705813D1; EP0849668B1; GB9626401D0; JPH10222393A; JP4493739B2; EP0849668A1; US6134652A

Description

Diese Erfindung betrifft Diagnoseprozeduren in einem integrierten Schaltungsbauelement und insbesondere das Erkennen der Ausführung durch eine CPU eines bestimmten Befehls, welcher durch seine Speicheradresse identifiziert wird, und das Unterbrechen des Normalbetriebs einer CPU, insbesondere um das Durchführen von Diagnoseprozeduren zu erlauben.
Es gibt viele Entwürfe und Architekturen für CPUs, welche auf einem Siliziumchip integriert sind, bei welchem die CPU die Mehrheit der Siliziumfläche oder nur einen Anteil davon darstellt, und bei welchen die CPU Befehle ausführt, welche in einem chipintegrierten oder chipexternen Speicher gespeichert sind. Typischerweise enthält eine solche CPU ein Register, welches als der Zeiger auf einen Ausführungsbefehl, oder die Speicheradresse davon, agiert, welcher vielfach als Befehlszeiger (Instruction Pointer = Iptr), Programmzähler (Program Counter = PC) und andere bekannt ist. Es können mehrere Register vorhanden sein, welche verschiedene Versionen der Befehlszeiger enthalten, wie etwa: der Zeiger zu dem derzeit ausgeführten Befehl, der Zeiger zu dem als nächstes auszuführenden Befehl, der Zeiger zu dem nächsten Befehl, welcher vom Speicher abgerufen wird, etc.
Gemäß der verschiedenen möglichen Architekturen kann die Aufgabe, Befehle vom Speicher abzurufen, durch eine unterscheidbare Befehlsabrufeinheit durchgeführt werden. Weitere Variationen umfassen es, einer solchen Befehlsabrufeinheit unabhängig von normalen CPU-Datenzugriffen Zugriff zum Speicher zu gewähren, einen Cachespeicher einzufügen, oder einzelne Befehle und Datenzwischenspeicher zwischen der CPU und dem Hauptspeicher einzufügen.
Die Kenntnis des Wertes des Befehlszeigerregisters ist von besonderer Bedeutung, wenn Diagnosefunktionen auf Software durchgeführt werden, welche auf einer CPU laufen. Im einfachsten Fall kann der Wert des Befehlszeigers durch Überwachen des Speicheradresswertes auf einem externen Speicherbus abgeleitet werden. In komplexeren Beispielen ist der Wert des Iptr jedoch in den Tiefen der CPU verborgen.
Ein weiteres wichtiges Merkmal für Softwarediagnosen ist die Fähigkeit, die CPU anzuhalten, oder eine andere Maßnahme zu ergreifen, wenn sie einen bestimmten Befehl erreicht. Dies ist allgemein als Unterbrechung an einem Unterbrechungspunkt (breakpointing) bekannt. Wenn der Iptr von externen Pins abgeleitet werden kann, dann kann die Unterbrechung durch externe Hardware unterstützt werden. Wenn dies nicht möglich ist, gibt es zwei Betriebsweisen, welche allgemein angewandt werden, um eine Unterbrechung zu erreichen.
Gemäß der einen Betriebsweise wird "Software- Unterbrechung" durch Modifizieren des Speichers am Ort des zu unterbrechenden Befehls implementiert, um ihn durch einen Befehl zu ersetzen, welcher die CPU anstelle des unterbrochenen Befehls ausführt und welcher die gewünschte Wirkung wie Anhalten erreicht. Diese Lösung basiert jedoch auf Beeinflussung, sie funktioniert nicht, wenn die Befehle in einem Festspeicher gespeichert sind und erfordert einen bedeutsamen zusätzlichen Platzbedarf, um den richtigen Befehl zu ersetzen, wenn der Benutzer nach einer Unterbrechung fortzufahren wünscht. Eine solche "Software-Unterbrechung" wurde bereits in M. Johnson: "IN-CIRCUIT EMULATION MAKES SOFTWARE DEVELOPMENT MANAGE- ABLE", COMPUTER DESIGN, Bd. 25, Nr. 7, April 1986, beschrieben.
Gemäß einer zweiten Betriebsweise wird ein oder mehrere Register und eine Vergleichslogik hinzugefügt, wobei jedes solches Register den Unterbrechungswert enthält. Wenn der Iptr mit einem der Unterbrechungsregisterwerte übereinstimmt, wird die CPU angehalten. Diese Lösung macht es notwendig, daß die Hardware in der CPU vorhanden oder sehr eng mit dieser verbunden ist und so nicht auf einfache Weise für Herstellungsvarianten entfernt werden kann. Es benötigt einen Mechanismus zum Laden jeglicher Unterbrechungsregister, welcher entweder auf Beeinflußung basiert, wenn dies über die CPU selbst erfolgen soll, oder erfordert andere Hardwareunterstützung wie zusätzliche externe Pins. Die Situation wird kompliziert, wenn Befehle abgerufen, aber nicht ausgeführt werden können und zwar aufgrund einer Unterbrechung zum gleichen Zeitpunkt als die CPU dabei war, den unterbrochenen Befehl auszuführen. Ferner kann ein solcher Mechanismus nur erfolgreich arbeiten, wenn die CPU bei dem unterbrochenen Befehl sicher anhalten kann. Aus der Patentanmeldung EP-A- 0636976 ist bereits eine solche Unterbrechung ("breakpointing") in Form eines Grenzabtastinterfaces bekannt, welches dazu benutzt wird, um auf die Unterbrechungsregister, welche sich innerhalb der CPU befinden, zuzugreifen.
Es ist ein Ziel der vorliegenden Erfindung, ein verbessertes Unterbrechungssystem bereitzustellen.
Gemäß eines ersten Gesichtspunktes der vorliegenden Erfindung wird ein integriertes Einchip- Schaltungsbauelement bereitgestellt, mit:
einer chipintegrierten CPU mit einer Abruf- und Ausführungsschaltung zum Abrufen und Ausführen von Befehlen aus einem Speicher und einem Befehlszeigerregister zum Halten einer Adresse im Speicher eines nächsten auszuführenden Befehls;
einem Bus, der mit der CPU verbunden ist, um einen Zugriff der CPU auf den Speicher zu ermöglichen; dadurch gekennzeichnet, daß es aufweist:
eine chipintegrierte Unterbrechungseinheit, welche angeschlossen ist, um die Inhalte des Befehlszeigerregisters über einen Adressenübertragungspfad zu empfangen, und ein Unterbrechungsregister zum Halten einer Unterbrechungsadresse aufweist, bei welcher der Normalbetrieb der CPU für Diagnosezwecke unterbrochen wird, wobei die chipintegrierte Unterbrechungseinheit ferner eine Vergleicherschaltung aufweist, welche die Unterbrechungsadresse mit den Inhalten des Befehlszeigerregisters vergleicht und ein Unterbrechungsignal an einem Unterbrechungssignalpfad erzeugt, wenn eine Übereinstimmung vorliegt;
eine chipintegrierte Steuerungslogik, welche mit dem Unterbrechungssignalpfad verbunden und angeordnet ist, um den Normalbetrieb der CPU zu unterbrechen, wenn das Unterbrechungsignal empfangen wird;
wobei die chipintegrierte Unterbrechungseinheit eine Schaltung zum Verhindern einer Erzeugung des Unterbrechungssignals für den nächsten Befehl bei Wiederaufnahme des Normalbetriebes der CPU aufweist, nachdem er unterbrochen wurde.
Das Unterbrechungssignal kann bewirken, daß die CPU eine Befehlssequenz (sogenannte "Trap-Befehle") anstelle des nächsten Befehls, welchen die CPU normalerweise ausgeführt hätte, abruft und ausführt. Alternativ hierzu kann das Unterbrechungssignal jede weitere Ausführung von Befehlen der CPU verhindern (STALL AT INTERRUPT), während eine Diagnoseprozedur stattfindet.
Somit wird eine Unterbrechungseinheit auf dem Chip bereitgestellt, welche ein oder mehrere Unterbrechungsregister enthält, den Befehlszeiger von der CPU überwacht und die CPU zum Anhalten bringen kann oder eine spezielle Maßnahme ergreifen kann, wenn die CPU einen Befehl ausgeführt hätte, auf den durch ein Unterbrechungsregister gezeigt worden ist. Die chipintegrierte Steuerungslogik kann innerhalb der CPU selbst oder in enger Verbindung mit dieser bereitgestellt werden und diese implementiert die Funktion des Anhaltens oder des Ergreifens einer anderen speziellen Maßnahme, wenn die CPU einen durch eine Unterbrechungsadresse definierten Befehl ausgeführt hätte. Eine besondere Ausführungsform ist für die spezielle Maßnahme gedacht, daß die CPU eine Trap annimmt. Andere Implementierungen können einen Abbruch, Halt, Stop, eine nicht-maskierbare Unterbrechung oder andere geeignete Maßnahmen implementieren.
Eine Sperrung der Erzeugung des Unterbrechungssignals für den nächsten Befehl auf Wiederaufnahme des Normalbetriebes der CPU, nachdem sie unterbrochen wurde, ist wichtig, um eine Endlosschleife zu verhindern, bei welcher die CPU fortwährend eine Unterbrechungsmaßnahme vornimmt, jedes Mal, nachdem sie die spezielle Maßnahme, welche von der Unterbrechung gefordert wird, abgeschlossen hat.
Die oben beschriebene Unterbrechungseinheit ist besonders nützlich im Zusammenhang mit einer integrierten Schaltung, welche einen Nachrichtenwandler umfaßt, welcher mit der chipintegrierten Unterbrechungseinheit über einen Übertragungspfad verbunden ist und welche zuläßt, daß das Unterbrechungsregister mit der Unterbrechungsadresse geladen wird, ohne daß die chipintegrierte CPU einbezogen wird. Der Nachrichtenwandler kann mit dem chipintegrierten Bus zum Empfangen von Nachrichten verbunden sein, um das Unterbrechungsregister mit einer Unterbrechungsadresse zu laden. Der Nachrichtenwandler kann zusätzlich mit einem chipexternen Übertragungspfad zum Empfangen von Nachrichten von einer chipexternen CPU verbunden sein, um das Unterbrechungsregister zu laden.
Bei der beschriebenen Ausführungsform ist der Adressenübertragungspfad ein paralleler Standbus, welcher das Befehlszeigerregister mit der chipintegrierten Unterbrechungseinheit verbindet. Dies ermöglicht der Unterbrechungseinheit autonom zu sein, so daß sie entfernt oder verändert werden kann, ohne daß der Normalbetrieb der CPU beeinflußt wird.
Der Adressenübertragungspfad kann durch den Bus bereitgestellt werden, um der CPU den Zugriff auf den Speicher zu ermöglichen, wobei die chipintegrierte Unterbrechungseinheit eine Überwachungsschaltung zum Überwachen von Speicherzugriffen auf dem Bus für Abrufbefehle aufweist.
Die chipintegrierte Unterbrechungseinheit kann angeschlossen sein, um ein Gültig-Adressensignal zu empfangen, um anzuzeigen, daß die Adresse in dem Befehlszeigerregister gültig ist.
In einer Situation, bei welcher die chipintegrierte CPU Befehle abrufen und ausführen kann, um mehrere unterschiedliche Prozesse zu implementieren, kann eine Verhinderung der Erzeugung des Unterbrechungssignals gesetzt werden, um lediglich in Bezug zu einem dieser Prozesse zu arbeiten, bei welchem der Normalbetrieb unterbrochen worden ist, jedoch nicht für andere Prozesse. Auf diese Weise werden multi-verkettete Unterbrechungen ermöglicht.
Die Unterbrechungseinheit kann einen Zähler beinhalten, so daß das Unterbrechungssignal lediglich erzeugt wird, nachdem ein Befehl an der Unterbrechungsadresse eine vorgegebene Anzahl von Wiederholungen ausgeführt hat.
Die Unterbrechungseinheit kann eine Mehrzahl von Unterbrechungsregistern zum jeweiligen Halten von einer Mehrzahl von Unterbrechungsadressen beinhalten.
Ferner könnte mehr als eine Unterbrechungseinheit auf einem integrierten Einchip-Schaltungsbauelement bereitgestellt werden.
Gemäß eines weiteren Gesichtspunktes der vorliegenden Erfindung wird ein Verfahren zur Unterbrechung eines Normalbetriebes einer chipintegrierten CPU, insbesondere zum Durchführen von Diagnoseprozeduren, bereitgestellt, wobei Adressen von durch die CPU auszuführenden Befehlen überwacht und jede mit einer Unterbrechungsadresse verglichen werden, bei welcher der Normalbetrieb der CPU für Diagnosezwecke zu unterbrechen ist, dadurch gekennzeichnet, daß ein Unterbrechungssignal erzeugt wird, wenn eine Übereinstimmung zwischen der Überwachtadresse und der Unterbrechungsadresse vorliegt, wobei ein Empfang des Unterbrechungssignal durch die CPU eine Unterbrechung des Normalbetriebes verursacht, wobei das Verfahren ferner den Schritt der Verhinderung der Erzeugung des Unterbrechungssignals für den nächsten Befehl bei Wiederaufnahme eines Normalbetriebes der CPU umfaßt, nachdem er unterbrochen wurde.
Zum besseren 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ührungsbeispiel 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 die Benutzung einer Unterbrechungseinheit mit einer CPU darstellt; und
Fig. 13 ein Blockdiagramm einer Unterbrechungseinheit ist.
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 2 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 SCAN- MODE 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 51 und 52 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 51 und 52 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 51 und 52, 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 RXSEN- DACK 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 TXSEN- DACK 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 51, 52 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 51, 52 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 51 und 52 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 host" (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 VALID-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 "Register"-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 Leitwegführungslogik 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 Leitwegführungssteuerungssignal auf Leitung 272 an die Busauswahls- und Leitwegführungslogik 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 Leitwegführungslogik 254. Zusätzlich trägt der Informationsbus 256 die Ausgangssignale von der Busauswahls- und Leitwegführungslogik 254, dem Datenregister 244, dem Adressenregister 242 und dem Kopfregister 240 zu dem Sendedatensignal TXDATA. Die Busauswahls- und Leitwegführungslogik 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 and 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 len 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 Leitwegführungslogik 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 peek- enthaltenden 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 anderen Worten wird das Peek-Kopfbyte als ein peek- enthaltendes 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 Leitwegführungslogik 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 VA- LID, 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 Leitwegführungssteuerungslogik ü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 Leitwegführungslogik 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 Leitwegführungslogik 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 Leitwegführungslogik 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 Leitwegführungslogik 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-Übertragungsadapter 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 beschriebenen Ausführungsbeispiel dieser Erfindung umfassen die Diagnoseeinrichtungen 300 eine Unterbrechungseinheit 400 und eines oder mehrere der Diagnoseregister wird/werden als Unterbrechungsregister genutzt. Es wird Bezug genommen auf Fig. 12. Die Unterbrechungsregister sind durch Bezugszeichen 402, 404 bezeichnet. Der Befehlszeiger der Target-CPU 162 wird in einem Befehlszeiger (Iptr)-Register 406 der Target-CPU gehalten und der Unterbrechungseinheit 400 über dem Bus 310 zugeführt. Der Befehlszeiger ist der Zeiger für den Befehl, welchen die CPU als nächstes auszuführen erwartet, wenn die CPU nicht unterbrochen oder auf andere Weise abgelenkt wird. Wie klar sein wird, wird der Befehlszeiger auf Bus 310 zusammen mit Steuerungssignalen zugeführt, welche anzeigen, wenn der Befehlszeiger gültig ist, wenn die CPU abgelenkt worden ist und dergleichen.
Zusätzlich zu den früher genannten Steuerungssignalen, d. h. STALL AT INTERRUPT POINT; TRAP AT INTERRUPT POINT wird durch die Unterbrechungseinheit 400 ein neues Steuerungssignal TRAP AT NEXT INSTRUCTION erzeugt. Die Unterbrechungseinheit 400 erzeugt das Steuerungssignal STALL AT INTERRUPT POINT auf Leitung 408 und das Steuerungssignal TRAP AT NEXT INSTRUCTION auf Leitung 407, wobei beide Steuerungssignale einer Befehlsausführungsschaltung 411 der Target-CPU 162 zugeführt werden. Die Ausführungsschaltung 411 reagiert auf die Steuerungssignale TRAP AT NEXT INSTRUCTION und STALL AT NEXT INTERRUPT POINT, um den Normalbetrieb der Target-CPU 162 zu unterbrechen. Das Signal TRAP AT NEXT INSTRUCTION wird angelegt, um die Target-CPU zu veranlassen, eine "Trap anzunehmen", d. h. eine vordefinierte Sequenz von Trap-Befehlen abzurufen und auszuführen, anstelle des nächsten Befehls, welchen die CPU normalerweise ausgeführt hätte. Diese Trap- Befehle werden ausgewählt, um die CPU zu veranlassen, bestimmte Aufgaben durchzuführen, welche diagnostiziert werden können, um die Betriebsweise der CPU zu überprüfen. Um dies zu tun, sendet die Ausführungssteuerungslogik 454 der Ausführungsschaltung 411 der CPU ein Steuerungssignal auf Leitung 401 zu einer Befehlsabrufeinheit 410 der CPU 162 zusammen mit einer Adresse auf Bus 456 und es wird in Übereinstimmung mit dem normalen Verhalten der Befehlsabrufseinheit 410 und dem Trapmechanismus der CPU ein Befehl auf Befehlsbus 409 erzeugt. Das Signal STALL AT INTERRUPT POINT wird angelegt, um zu verhindern, daß die CPU irgendwelche weiteren Befehle ausführt, während ein Diagnoseprozeß stattfindet.
Obwohl die hauptsächliche Funktion der Unterbrechungseinheit darin liegt, ein Trap zu verursachen oder die CPU zu blockieren, wie oben beschrieben, ist die Diagnosesteuerung auch zu anderen Interaktionen fähig. Andere mögliche Aktionen in Antwort auf das Erkennen einer Unterbrechungsadresse sind eine "getriggerte" Nachricht chipextern über die TAP-Steuerung zu senden, ohne die CPU einzubeziehen oder diese zu stören, ein Signal über eine externe Verbindungs-Triggerausgabe zu senden, ebenfalls ohne die CPU einzubeziehen, oder einen Zähler zu dekrementieren, so daß die nth-Ausführung des unterbrochenen Befehls eine der möglichen oben beschriebenen Antworten verursacht, wobei n die gewünschte Anzahl von Unterbrechungsbefehlen ist, welche zum Triggern der Antwort erforderlich ist.
Es soll bemerkt werden, daß das TRAP AT NEXT INSTRUCTION der CPU nur signalisiert, einen "Trap anzunehmen" oder anzuhalten, anstatt den nächsten Befehl auszuführen, wenn sie wirklich dabei war, diesen Befehl auszuführen. Wenn die CPU unterbrochen wird, einen Trap annimmt (durch eine andere Ursache), oder einen Programmsprung, dann wäre der nächste Befehl nicht ausgeführt worden, so daß der Unterbrechungstrap nicht angenommen wird.
Fig. 13 stellt die Komponenten der Unterbrechungseinheit im größeren Detail dar. Mit jedem Unterbrechungsregister 402, 404 steht eine Vergleichsschaltung 412, 414 in Verbindung. Die Vergleichseinheiten empfangen beide den Befehlszeiger auf Bus 310. Zusätzlich empfängt jede Vergleichseinheit 412, 414 eine entsprechende Adresse von seinem in Verbindung stehenden Unterbrechungsregister 402, 404. Auf die in den Unterbrechungsregistern gehaltenen Adressen wird hier als Unterbrechungsadressen Bezug genommen. Eine Logikschaltung 416 empfängt die Ausgangssignale von der Vergleichsschaltung 412, 414 und den Befehlszeiger und bestimmt, wann der Befehlszeiger gültig ist und legt entweder das Signal TRAP AT NEXT INSTRUCTION oder das Signal STALL AT INTERRUPT POINT an, wenn eine der Komparatoren die Übereinstimmung zwischen dem Befehlszeiger und der in dem entsprechenden Unterbrechungsregister gespeicherten Unterbrechungsadresse anzeigt. Die Logikschaltung 416 ist auch an einen Zustandsbitspeicher 418 angeschlossen, welcher ein Zustandsbit speichert, welches verhindert, daß die TRAP AT NEXT INSTRUCTION- und STALL AT INTERRUPT POINT-Signale sofort nach dem Zurücksenden von einem vorhergehenden Unterbrechungspunkt angelegt werden. Der Zustandsbit wird durch ein Signal von der CPU auf Leitung 420 gesetzt, welche der Unterbrechungseinheit 400 mitteilt, daß der nächste Befehl der Rücksprung oder die Wiederaufnahme, welche einer vorhergehenden Unterbrechungsaktion folgt, ist.
Die Unterbrechungseinheit 400 ist mit einem Konfigurationsmittel ausgestattet, wie einem Bit in einem Eigenschaftenregister der Unterbrechungseinheit, um zu bestimmen, welches der Signale TRAP AT NEXT INSTRUCTION oder STALL AT INTERRUPT POINT die Logikschaltung 416 anlegt. Im Ausführungsbeispiel von Fig. 13 liefert ein Konfigurationsbitspeicher 450 des Konfigurationsmittels der Logikschaltung 416 ein Signal auf Leitung 452, um zu bestimmen, welches Steuerungssignal angelegt wird. Der Konfigurationsbitspeicher wird über den Diagnosebus 234 geladen.
Die Unterbrechungsadressen werden in die Unterbrechungsregister 402, 404 über den Diagnosebus 234 geladen. Sie können alternativ durch den Speicherbus 312 geladen werden, obwohl die Schaltungsverbindungen, um dies zu implementieren, hier nicht dargestellt sind.
Die Unterbrechungseinheit 400 arbeitet wie folgt. Der Befehlszeiger von der CPU wird mit jeder Unterbrechungsadresse in den Vergleichsschaltungen 412, 414 verglichen. Wenn eine Übereinstimmung auftritt, wird, unter der Annahme, daß der Befehlszeiger gültig war und das Zustandsbit nicht gesetzt ist, eines der TRAP AT NEXT INSTRUCTION- oder STALL AT INTERRUPT POINT-Signale auf Leitung 407 bzw. 408 in einer ausreichend kurzen Zeit angelegt, um zu verhindern, daß die CPU den nächsten Befehl ausführt, den sie normalerweise ausgeführt hätte. Die Ausführungssteuerungslogik 455 der Ausführungsschaltung 411 stellt sicher, daß die CPU 162 richtig auf eines der angelegten TRAP AT NEXT INSTRUCTION- oder STALL AT INTERRUPT POINT- Signale antwortet. Das Zustandsbit 418 sperrt die Unterbrechungsfunktion für einen Befehl, welcher einem RETURN FROM TRAP oder einer anderen Wiederaufnahme der normalen CPU-Ausführung folgt. Dies ist wichtig, um eine Unendlichkeitsschleife zu verhindern, bei welcher die CPU fortwährend die Unterbrechungsaktion durchführt, jedesmal nachdem sie die spezielle Aktion beendet hat, welche der Unterbrechungspunkt erforderte.
Es wäre möglich, einen weiterentwickelten Standmechanismus anstatt dem Standbit 418 einzubeziehen, was mehrfach verkettetes Unterbrechen erlauben würde. Das heißt, der Standbit könnte gesetzt werden, um ein erneutes Erfassen (re-trapping) des RETURN FROM TRAP am gleichen Unterbrechungspunkt zu verhindern, aber dem Unterbrechungsmechanismus zu erlauben, für andere Unterbrechungsadressen zu arbeiten.
Wie oben erwähnt, kann die Unterbrechungseinheit einen Zähler umfassen, so daß die Unterbrechungsaktion stattfindet, nachdem der unterbrochene Befehl eine vorgegebene Anzahl von Wiederholungen ausgeführt hat. Von besonderer Bedeutung sind in diesem Fall die CPU-Implementierungen, welche es erlauben, Befehle an einem Mittelpunkt während ihrer Ausführung zu unterbrechen und sie wieder zu starten, wenn die Unterbrechung beendet ist. Um dies zu erreichen, sollte der Zähler die Beendigung von Befehlen und nicht den Start von Befehlen zählen. Ein solcher Zähler ist in Fig. 13 dargestellt und durch Bezugszeichen 422 bezeichnet, und angeschlossen, um den Befehlszeiger auf Bus 310 zu empfangen und die Logikschaltung 416 zu benachrichtigen, wenn der passende Zählstand erreicht worden ist.
In den oben beschriebenen Ausführungsbeispiel wird der Befehlszeiger direkt an die Unterbrechungseinheit zugeführt. Alternativ hierzu kann der Befehlsabrufbus 314 überwacht werden, da Befehle vom Speicher abgerufen werden müssen, um ausgeführt zu werden. Diese Alternative kann in Situationen wirkungsvoll sein, in denen ein einfaches Befehlabrufschema verwendet wird. Es soll bemerkt werden, daß Information, betreffend wie weit das Befehlabrufen der Befehlsausführung voraus ist, erforderlich wären, im Falle, daß es wichtig ist, daß der Unterbrechungsbefehl vor Ausführung des nächsten Befehls stattfindet.
Die hier beschriebene Unterbrechungseinheit ist zu nicht- beeinflußender Arbeitsweise fähig, bis eine Unterbrechungsübereinstimmung auftritt. Das heißt, die Unterbrechungsregister können geladen werden und der Befehlszeiger kann kontinuierlich überwacht werden, ohne die Leistung der CPU oder einer anderen chipintegrierten Funktionalität zu stören oder zu beeinflussen. Darüber hinaus kann sie, da sie eine autonome Einheit darstellt, von dem Chip entfernt werden, zum Beispiel für Herstellungsvarianten, bei welchen Software-Diagnosemerkmale nicht erforderlich sind, ohne das irgendwelche Veränderungen an der CPU erforderlich wären. In diesem Fall wäre die Ausführungssteuerungslogik 454 innerhalb der CPU einfach redundant.

Claims

1. Integriertes Einchip-Schaltungsbauelement, mit:

einer chipintegrierten (On-Chip) CPU (162) mit einer Abruf- (410) und Ausführungsschaltung (411) zum Abrufen und Ausführen von Befehlen aus einem Speicher und einem Befehlszeigerregister (406) zum Halten einer Adresse im Speicher eines nächsten auszuführenden Befehls;

einem Bus (314), der mit der CPU verbunden ist, um einen Zugriff der CPU auf den Speicher zu ermöglichen;

dadurch gekennzeichnet, daß es aufweist:

eine chipintegrierte Unterbrechungseinheit (400), welche angeschlossen ist, um die Inhalte des Befehlszeigerregisters über einen Adressenübertragungspfad (310) zu empfangen, und ein Unterbrechungsregister (402) zum Halten einer Unterbrechungsadresse aufweist, bei welcher der Normalbetrieb der CPU für Diagnosezwecke unterbrochen wird, wobei die chipintegrierte Unterbrechungseinheit ferner eine Vergleicherschaltung (412) aufweist, welche die Unterbrechungsadresse mit den Inhalten des Befehlszeigerregisters vergleicht und ein Unterbrechungsignal an einem Unterbrechungssignalpfad (407) erzeugt, wenn eine Übereinstimmung vorliegt;

eine chipintegrierte Steuerungslogik (454), welche mit dem Unterbrechungssignalpfad verbunden und angeordnet ist, um den Normalbetrieb der CPU zu unterbrechen, wenn das Unterbrechungsignal empfangen wird;

wobei die chipintegrierte Unterbrechungseinheit (400) eine Schaltung zum Verhindern einer Erzeugung des Unterbrechungssignals für den nächsten Befehl bei Wiederaufnahme des Normalbetriebes der CPU aufweist, nachdem er unterbrochen wurde.

2. Integrierte Schaltung nach Anspruch 1, bei welcher die chipintegrierte Steuerungslogik (454) in Reaktion auf das Unterbrechungssignal betrieben wird, um zu bewirken, daß die CPU eine Befehlssequenz anstelle des nächsten Befehls abruft und ausführt, welchen die CPU im Normalbetrieb ausgeführt hätte.

3. Integrierte Schaltung nach Anspruch 1, bei welcher die chipintegrierte Steuerungslogik (454) in Reaktion auf das Unterbrechungsignal betrieben wird, um jede weitere Ausführung von Befehlen der CPU zu verhindern, während eine Diagnoseprozedur durchgeführt wird.

4. Integrierte Schaltung nach einem der vorstehenden Ansprüche, welche einen Nachrichtenwandler (160) aufweist, der mit der chipintegrierten Unterbrechungseinheit (400) über einen Übertragungspfad verbunden ist und welcher dem Unterbrechungsregister (402) ermöglicht, mit der Unterbrechungsadresse ohne Einbeziehung der chipintegrierten CPU geladen zu werden.

5. Integrierte Schaltung nach Anspruch 4, bei welcher der Nachrichtenwandler (160) mit dem chipintegrierten Bus zum Empfangen von Nachrichten verbunden ist, um das Unterbrechungsregister (402) mit einer Unterbrechungsadresse zu laden.

6. Integrierte Schaltung nach Anspruch 4 oder 5, bei welcher der Nachrichtenwandler (160) mit einem chipexternen (Off-Chip) Übertragungspfad zum Empfangen von Nachrichten von einer chipexternen CPU verbunden ist, um das Unterbrechungsregister (402) zu laden.

7. Integrierte Schaltung nach einem der vorstehenden Ansprüche, bei welcher der Adressenübertragungspfad (310) ein paralleler Standbus ist, welcher das Befehlszeigerregister mit der chipintegrierten Unterbrechungseinheit (400) verbindet.

8. Integrierte Schaltung nach einem der Ansprüche 1 bis 6, bei welcher der Adressenübertragungspfad (310) durch den Bus bereitgestellt wird, um der CPU einen Zugriff auf den Speicher (302) zu ermöglichen, wobei die chipintegrierte Unterbrechungseinheit (400) eine Überwachungsschaltung zum Überwachen von Speicherzugriffen am Bus bei Abrufbefehlen aufweist.

9. Integrierte Schaltung nach einem der vorstehenden Ansprüche, bei welcher die chipintegrierte Unterbrechungseinheit (400) angeschlossen ist, um ein Gültig-Adressensignal zu empfangen, um anzuzeigen, daß die Adresse in dem Befehlszeigerregister (406) gültig ist.

10. Integriertes Schaltungsbauelement nach einem der vorstehenden Ansprüche, bei welchem die chipintegrierte CPU Befehle abrufen und ausführen kann, um mehrere unterschiedliche Prozesse durchzuführen, wobei die Verhinderung der Erzeugung des Unterbrechungssignals lediglich in bezug auf diejenigen dieser Prozesse arbeitet, bei welchen der Normalbetrieb unterbrochen ist, jedoch nicht für andere Prozesse.

11. Integriertes Schaltungsbauelement nach einem vorstehenden Ansprüche, bei welchem das Unterbrechungsignal lediglich erzeugt wird, nachdem ein Befehl an der Unterbrechungsadresse eine vorgegebene Anzahl von Wiederholungen ausgeführt wurde.

12. Integriertes Einchip-Schaltungsbauelement nach einem der vorstehenden Ansprüche, bei welchem die chipintegrierte Unterbrechungseinheit (400) mehrere Unterbrechungsregister (402, 404) zum jeweiligen Halten von einer Mehrzahl von Unterbrechungsadressen aufweist.

13. Integriertes Einchip-Schaltungsbauelement nach einem der vorstehenden Ansprüche, welches mehrere Unterbrechungseinheiten (400) aufweist, welche jeweils ein oder mehrere Unterbrechungsregister (402) aufweisen.

14. Verfahren zur Unterbrechung eines Normalbetriebes einer chipintegrierten (On-Chip) CPU, insbesondere zum Durchführen von Diagnoseprozeduren, wobei Adressen von durch die CPU auszuführenden Befehlen überwacht und jede mit einer Unterbrechungsadresse verglichen werden, bei welcher der Normalbetrieb der CPU für Diagnosezwecke zu unterbrechen ist, dadurch gekennzeichnet, daß ein Unterbrechungssignal erzeugt wird, wenn eine Übereinstimmung zwischen der Überwachtadresse und der Unterbrechungsadresse vorliegt, wobei ein Empfang des Unterbrechungssignal durch die CPU eine Unterbrechung des Normalbetriebes verursacht, wobei das Verfahren ferner den Schritt der Verhinderung der Erzeugung des Unterbrechungssignals für den nächsten Befehl bei Wiederaufnahme eines Normalbetriebes der CPU umfaßt, nachdem er unterbrochen wurde.

15. Verfahren nach Anspruch 14, bei welchem das Unterbrechungssignal bewirkt, daß die CPU eine Befehlssequenz anstelle des nächsten Befehles abruft und ausführt, welchen die CPU im Normalbetrieb ausführen würde.

16. Verfahren nach Anspruch 14, bei welchem das Unterbrechungssignal die CPU von jeder weiteren Ausführung von Befehlen sperrt, während eine Diagnoseprozedur durchgeführt wird.

17. Verfahren nach einem der Ansprüche 14 bis 16, bei welchem die Unterbrechungsadresse in einem Unterbrechungsregister gehalten wird, welches ohne Einbeziehung der chipintegrierten CPU geladen werden kann.

18. Verfahren nach einem der Ansprüche 14 bis 17, bei welchem die chipintegrierte CPU Befehle zum Durchführen einer Mehrzahl von unterschiedlichen Prozessen abrufen und ausführen kann, wobei die Verhinderung der Erzeugung des Unterbrechungssignals lediglich in bezug auf diejenigen dieser Prozesse arbeitet, deren Normalbetrieb unterbrochen ist, jedoch nicht für andere Prozesse.

19. Verfahren nach einem der Ansprüche 14 bis 18, bei welchem das Unterbrechungssignal lediglich erzeugt wird, nachdem ein Befehl bei der Unterbrechungsadresse eine vorgegebene Anzahl von Wiederholungen ausgeführt wurde.