DE69715558T2 - Mikrorechner mit Urladungsystem - Google Patents
Mikrorechner mit UrladungsystemInfo
- Publication number
- DE69715558T2 DE69715558T2 DE1997615558 DE69715558T DE69715558T2 DE 69715558 T2 DE69715558 T2 DE 69715558T2 DE 1997615558 DE1997615558 DE 1997615558 DE 69715558 T DE69715558 T DE 69715558T DE 69715558 T2 DE69715558 T2 DE 69715558T2
- Authority
- DE
- Germany
- Prior art keywords
- cpu
- chip
- external
- memory
- event
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 230000004044 response Effects 0.000 claims description 21
- 238000000034 method Methods 0.000 claims description 16
- 230000005540 biological transmission Effects 0.000 claims description 15
- 230000006854 communication Effects 0.000 claims description 14
- 238000004891 communication Methods 0.000 claims description 14
- 230000008859 change Effects 0.000 claims description 3
- 238000006243 chemical reaction Methods 0.000 claims description 2
- 239000000872 buffer Substances 0.000 description 27
- 238000012546 transfer Methods 0.000 description 12
- 230000002457 bidirectional effect Effects 0.000 description 3
- 238000013519 translation Methods 0.000 description 3
- 230000007175 bidirectional communication Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000002401 inhibitory effect Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3648—Software debugging using additional hardware
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1417—Boot up procedures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Quality & Reliability (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Debugging And Monitoring (AREA)
- Microcomputers (AREA)
Description
- Die Erfindung betrifft Mikrocomputer.
- Es sind Einchip-Mikrocomputer bekannt, die externe Kommunikationsports umfassen, so daß der Chip in einem Netzwerk verbunden werden kann, wobei dies zum Beispiel auch die Verbindung zu einem Host-Mikrocomputer zur Verwendung in Debugroutinen umfassen kann. Es sind solche Systeme bekannt, bei denen jeder der verbundenen Mikrocomputerchips seinen eigenen lokalen Speicher hat. Solche Mikrocomputer können den Betrieb der CPU unterbrechen ohne den Zustand auf dem Chip zurückzusetzen. Als weitere Möglichkeit können in einem Reset-Vorgang alle Schaltungen auf dem Chip zurückgesetzt werden. In diesem Fall ist Boot-Code notwendig, um den Betrieb der CPU wieder aufzunehmen.
- EP-A-0 652 516 beschreibt einen integrierten Prozessor, bei dem die Layouts eines Standalone- Mikroprozessors und einer oder mehrerer Funktionseinheiten sich auf einem gemeinsamen Halbleiterplättchen befinden und durch einen gemeinsamen lokalen Bus verbunden sind. Eine Schaltung zum Austesten, die sich auch auf dem Halbleiterplättchen befindet und an den gemeinsamen Bus angeschlossen ist, reagiert auf Testbefehlsignale, die von außerhalb des integrierten Prozessors stammen. In einer Ausführungsform befindet sich der integrierte Prozessor auf einem Zielcomputer, der über einen JTAG oder einen anderen Testprotokollbus mit einem Hostrechner verbunden ist. Zur Speicherung von Debug-Software, die vom Hostrechner geladen wird, wird ein Debug-Speicherbereich im Hauptsystemspeicher des Zielcomputers reserviert. Wenn der Prozessor auf dem Zielcomputer in einen Debugmodus wechselt, wird die so gespeicherte Debug-Software ausgeführt.
- Es ist Ziel der vorliegenden Erfindung, einen verbesserten Mikrocomputer und ein verbessertes Verfahren zum Betrieb eines Mikrocomputers zu bereit zu stellen, bei welchen die externe Kommunikation vereinfacht ist und Boot- Code von außerhalb des Chips geladen werden kann.
- Die Erfindung stellt ein Computersystem mit einem Mikroprozessor auf einem integrierten Schaltungschip bereit, aufweisend eine chipinterne CPU mit einer Mehrzahl von Registern und einem Kommunikationsbus, wobei ein paralleler Übertragungspfad zwischen der CPU und einem ersten Speicher lokal bei der CPU bereitgestellt wird, wobei das integrierte Schaltungselement ferner einen externen Port und eine Logikschaltung aufweist, wobei der externe Port mit dem Bus auf dem integrierten Schaltungschip und einer externen Computervorrichtung, welche einen zweiten Speicher aufweist, verbunden ist, wobei die Logikschaltung auf eine Vielzahl von Ereignissen von der externen Computervorrichtung über den Port reagiert, welche ein Unterbrechungsereignis (suspend event) zum Unterbrechen der Ausführung von vom ersten Speicher erhaltenen Befehlen durch die CPU, ein Set/Reset-Handler- Ereignis, welches bewirkt, daß die CPU einen Boot-Code vom zweiten Speicher abruft, der von der CPU auszuführen ist, und ein Run-Ereignis, um den Betrieb der CPU unter Verwendung des Boot-Codes wiederaufzunehmen, umfassen.
- Vorzugsweise ist die CPU mit einer Logikschaltung ausgestattet, welche betreibbar ist, um die Ausführung einer Befehlssequenz durch die CPU zu unterbrechen, wobei die Logikschaltung einen Adressenspeicher zum Speichern einer Befehlspositionsadresse zur Verwendung bei Wiederaufnahme der Ausführung eines Befehls durch die CPU aufweist, wobei die Logikschaltung mit dem Kommunikationsbus verbunden ist, wodurch die Logikschaltung ein Signalpaket von der externen Computervorrichtung über den Port empfangen kann.
- Vorzugsweise weist die CPU eine Befehlszeigerschaltung zum Anzeigen einer nächsten Abrufadresse bei Ausführung einer Befehlssequenz auf und der Adressenspeicher der Logikschaltung ist betreibbar, um den Zeigerwert der Befehlszeigerschaltung in Reaktion auf ein Signalpaket von der externen Computervorrichtung zu verändern.
- Vorzugsweise weist die integrierte Einchip-Schaltung eine Mehrzahl von CPUs auf demselben Chip auf, die jeweils mit dem Kommunikationsbus und dem externen Port verbunden sind.
- Die Erfindung umfaßt ein Verfahren zum Booten eines Computersystems, welches einen Mikroprozessor auf einem integrierten Schaltungschip mit einer chipinternen CPU, einer Mehrzahl von Registern und einen Kommunikationsbus aufweist, wobei ein paralleler Übertragungspfad zwischen der CPU und einem ersten Speicher lokal bei der CPU bereitgestellt wird, wobei das integrierte Schaltungselement einen externen Port und eine Logikschaltung aufweist, die mit dem Bus und einer externen Computervorrichtung mit einem zweiten Speicher verbunden ist, wobei das Verfahren die Übertragung von einer Vielzahl von Ereignissen von der externen Vorrichtung über den externen Port umfaßt, wobei die Ereignisse ein Unterbrechungsereignis zum Unterbrechen der Ausführung von vom ersten Speicher erhaltenen Befehlen durch die CPU, ein Set/Reset-Handler-Ereignis, welches bewirkt, daß die CPU einen Boot-Code vom zweiten Speicher abruft, der von der CPU auszuführen ist, und ein Run-Ereignis, um den Betrieb der CPU unter Verwendung des Boot-Codes wiederaufzunehmen, umfassen.
- Vorzugsweise in Reaktion auf die Vielzahl von Ereignissen über den externen Port von der externen Computervorrichtung bewirkt die Logikschaltung, welche mit der chipinternen CPU verbunden ist, die Speicherung einer Befehlspositionsadresse für diese CPU in einem Adressenspeicher zur Verwendung bei Wiederaufnahme der Ausführung von Befehlen durch die CPU und, daß die CPU unter Verwendung des Boot-Codes die Ausführung wiederaufnimmt.
- Vorzugsweise werden Übertragungen auf dem Kommunikationsbus in einem bitparallelen Format durchgeführt und der externe Port wandelt Pakete in ein bitserielles Format um.
- Vorzugsweise ist die externe Computervorrichtung angeordnet, um über den externen Port das Unterbrechungsereignis zum Unterbrechen des Betriebes der CPU und das Set/Reset-Handler-Ereignis zum Übertragen eines Boot-Codes von dem zweiten Speicher über den externen Port zu dem ersten Speicher zu übertragen, um über den externen Port eine Anzeige des Ortes des Boot-Codes im ersten Speicher bereitzustellen und das Run-Ereignis zum Wiederaufnehmen des Betriebes der CPU unter Verwendung des Boot-Codes, zu übertragen.
- Vorzugsweise überträgt die externe Computervorrichtung über den externen Port das Unterbrechungsereignis, um den Betrieb der chipinternen CPU zu unterbrechen, stellt über den externen Port eine Anzeige einer Speicheradresse im zweiten Speicher bereit, in welcher sich der Boot-Code befindet, und überträgt über den externen Port das Run- Ereignis an die chipinterne CPU, um die Ausführung unter Verwendung des Boot-Codes, der in dem zweiten Speicher angeordnet ist, wiederaufzunehmen, wobei die chipinterne CPU die Ausführung unter Abrufen eines Boot-Codes von dem zweiten Speicher über den externen Port wiederaufnimmt.
- In einigen Ausführungsformen sind mehr als eine CPU auf dem Chip vorgesehen, wobei die externe Computervorrichtung betreibbar ist, um die Ausführung durch jede CPU auf dem Chip zu unterbrechen, einen Boot-Code von dem zweiten Speicher bereitzustellen, der durch eine erste CPU auf dem Chip auszuführen ist, ein Steuersignal zur übertragen, um eine zweite CPU in einem Unterbrechungszustand zu halten, und die Ausführung der ersten CPU unter Verwendung des Boot-Codes wiederaufzunehmen, während die zweite CPU unterbrochen bleibt.
- Die erste CPU kann verwendet werden, um einen Boot- Code für die zweite CPU bereitzustellen und die Ausführung der zweiten CPU wiederaufzunehmen, nachdem der Betrieb der ersten CPU durch die externe Computervorrichtung wiederaufgenommen wurde.
- Eine Ausführungsform der vorliegenden Erfindung wird jetzt anhand eines Beispiels mit Bezug auf die zugehörigen Figuren beschrieben, bei denen:
- Fig. 1 ein Blockdiagramm eines Mikrocomputerchips gemäß der vorliegenden Erfindung ist;
- Fig. 2 mehr Einzelheiten eines Debug-Ports des Mikrocomputers aus Fig. 1 darstellt;
- Fig. 3 die Eingabe eines digitalen Signalpakets über den Port aus Fig. 2 darstellt;
- Fig. 4 die Ausgabe eines digitalen Signalpakets auf den Port aus Fig. 2 darstellt;
- Fig. 5 den Zugriff auf Register im Port aus Fig. 2 darstellt;
- Fig. 6 das Format eines digitalen Signalanfragepakets darstellt, das im Mikrocomputer aus Fig. 1 verwendet werden kann;
- Fig. 7 das Format eines digitalen Signalantwortpakets darstellt, das im Mikrocomputer aus Fig. 1 verwendet werden kann;
- Fig. 8 ein Beispiel eines seriellen Anfragepakets darstellt, das über den Port aus Fig. 2 eingegeben oder ausgegeben werden kann;
- Fig. 9 weitere Einzelheiten einer CPU des Mikrocomputers aus Fig. 1 einschließlich spezieller Ereignislogik veranschaulicht;
- Fig. 10 weitere Einzelheiten der speziellen Ereignislogik aus Fig. 9 darstellt;
- Fig. 11 einen Mikrocomputer des in Fig. 1 dargestellten Typs zeigt, der zum Debuggen der CPU durch einen Hostrechner zu diesem Hostrechner verbunden ist;
- Fig. 12 eine Anordnung ähnlich zu Fig. 11 darstellt, in der eine zweite CPU auf dem selben Chip angeordnet ist und normal arbeitet, während die andere CPU durch den Host debuggt wird;
- Fig. 13 von einem wie in Fig. 1 dargestellten Mikrocomputer einen die CPU darstellenden Teil veranschaulicht, der zum Debuggen mit Überwachungspunkten (Watchpoints) zu einem Hostrechner verbunden ist;
- Fig. 14 einen Mikrocomputer des in Fig. 1 dargestellten Typs zeigt, der zu einem Hostrechner verbunden ist, wobei eine CPU auf dem Mikrocomputer durch die andere CPU auf dem selben Chip debuggt wird;
- Fig. 15 mehr Einzelheiten eines Teils der Logikschaltung aus Fig. 10 darstellt;
- Fig. 16 mehr Einzelheiten eines Teils der Logikschaltung aus Fig. 15 darstellt und
- Fig. 17 mehr Einzelheiten eines anderen Teils der Logikschaltung aus Fig. 15 darstellt.
- Die in Fig. 1 dargestellte vorteilhafte Ausführungsform umfaßt eine integrierte Einchip-Schaltung 11, auf der zwei CPU-Schaltungen 12 und 13 und eine Vielzahl von Modulen 14 angeordnet sind. Die CPUs 12 und 13 sowie jedes der Module 14 sind durch ein Busnetzwerk 15 verbunden, das eine bidirektionale Anbindung an jedes Modul hat. In diesem Beispiel wird das Busnetzwerk als P-Link bezeichnet. Es besteht für jedes der Module wie in Fig. 2 dargestellt aus einem parallelen Bus 20 zusammen mit einer zugeordneten Steuerleitung 21, um dieses Modul mit einer P- Link-Steuereinheit 22 zu verbinden. Jedes Modul ist mit einer P-Link-Schnittstelle 23 ausgestattet, das eine Zustandsmaschine beinhaltet, um Steuersignal zwischen der zugehörigen P-Link-Steuerleitung 21 und der Schnittstelle 23 auszutauschen und Daten in zwei entgegengesetzte Richtungen zwischen dem Datenbus 20 und der Schnittstelle 23 zu übertragen.
- In dem in Fig. 1 dargestellten Beispiel umfassen die verschiedenen Module 14 eine Videodisplay-Schnittstelle 25 mit einem externen Anschluß 26, eine Schaltung zur Unterstützung der Videodekodierung 27, eine Audioausgabe- Schnittstelle 28 mit einem externen Anschluß 29, einen Debug-Port 30 mit einem externen Anschluß 31, eine Schnittstelle für externen Speicher 32 mit einem externen Busanschluß 33, die zu einem externen Speicher verbindet, eine Taktschaltung 34, verschiedene mit einer Mehrzahl von Bus- und seriellen Ausgabeanschlüssen 36 ausgestatte Peripherie-Schnittstellen 35, eine Netzwerk-Schnittstelle 37 mit einem externen Anschluß 38 und die P-Link- Steuereinheit 22. Die zwei CPU-Einheiten 12 und 13 in diesem Beispiel sind im allgemeinen in der Konstruktion gleichartig und jede der CPU-Einheiten umfaßt eine Mehrzahl von Befehlsausführungseinheiten 40, eine Mehrzahl von Registern 41, einen Befehlscache 42 und einen Datencache 43. In diesem Beispiel umfaßt jede CPU auch eine Ereignis- Logikschaltung 44, die mit den Ausführungseinheiten 40 verbunden ist.
- Die CPUs können in konventioneller Weise betrieben werden, wobei die Befehle vom Befehlscache 42 auf dem Chip erhalten werden und Datenlese- und Schreibvorgänge mit dem Datencache 43 ausgeführt werden. Zusätzlich kann für Lese- und Schreibvorgänge über die Schnittstelle für externen Speicher 32 und den externen Busanschluß 33 ein Zugriff auf externen Speicher erfolgen. Eine wichtige Einrichtung in diesem Beispiel ist der Debug-Port 30, der genauer in den Fig. 2 bis 5 beschrieben wird. Wie in Fig. 2 dargestellt, umfaßt diese Schaltung einen Hard-Reset- Kontroller 45, der mit einem Hard-Reset-Pin 46 verbunden ist. Der Kontroller 45 ist mit allen Modulen auf dem Chip verbunden, die in Fig. 1 dargestellt sind, so daß falls ein Hard-Reset-Signal am Pin 46 gesetzt ist, alle Schaltungen auf dem Chip zurückgesetzt werden.
- Wie weiter unten beschrieben wird, stellt dieser Port 30 eine wichtige externe Kommunikation zur Verwendung in Debug-Vorgängen zur Verfügung. Die chipinternen CPUs 12 und 13 können über den Port 30 von einer externen Quelle Befehlscode zur Ausführung erhalten. Übertragungen auf dem P-Link-System 15 werden im bitparallelen Format ausgeführt. Übertragungen auf dem Datenbus 20 des P-Link 15 können in Mehrbytepaketen ausgeführt werden, z. B. 35 Byte für jedes Paket, so daß ein Paket in fünf aufeinander folgenden Acht- Byte-Übertragungen auf dem P-Link übertragen wird, wobei jede Übertragung in bitparallelem Format ist. Der Port 30 ist so konzipiert, daß die Parallelität der vom P-Link 15 erhaltenen Pakete reduziert wird, so daß sie in bitseriellem Format über die Ausgabe 31 oder alternativ in einem gegenüber dem auf dem P-Link 15 verwendeten Format stark reduzierten parallelen Format ausgegeben werden, um die für den externen Anschluß 31 notwendige Anzahl externer Anschlußpins zu reduzieren.
- Die Struktur des Ports 30 wird nun mit Bezug auf die Fig. 2 bis 5 beschrieben.
- In diesem Beispiel umfaßt der Port 30 einen an die P- Link-Schnittstelle 23 angeschlossenen Ausgangspaketisierungspuffer 50 und einen an die P-Link- Schnittstelle 23 angeschlossenen Eingangspaketisierungspuffer 51. Auf der Ausgangsseite besteht der externe Anschluß 31 in diesem Fall aus einem Ausgangspin 52 und einem Eingangspin 53. Der Port führt in diesem Fall eine vollständige Umwandlung zwischen dem parallelen Format des Datenbusses 20 und dem seriellen Format für die Eingangs- und Ausgangspins 52 und 53 durch. Die Pins 52 und 53 sind als Teil eines Ausgabe-Verbindungsmoduls 55 verbunden, das auch einen Serialisierer 56 und einen Deserialisierer 57 umfaßt, die jeweils zu dem Ausgangspaketisierungspuffer 50 und Eingangspaketisierungspuffer 51 verbunden sind. Zwischen den Puffern 50 und 51 sind durch bidirektionale Anschlüsse eine Registerbank 58 und eine Port- Zustandsmaschine 59 verbunden. Die Funktion des Ports 30 ist die Umwandlung von Bitpaketen zwischen dem chipinternen parallelen Format und dem externen bitseriellen Format. Zusätzlich ermöglicht er für Pakete, die über den Pin 53 eingegeben werden, den Zugriff auf die Register 58 im Port ohne Verwendung des P-Link-Systems 15. Ebenso können Pakete auf dem P-Link-System 15 auf die Register 58 des Ports zugreifen ohne die externen Pins 52 und 53 zu verwenden.
- Das Format der im Mikrocomputersystem verwendeten Multibitpakete wird beispielhaft in den Fig. 6, 7 und 8 dargestellt. Falls ein Paket von einem der an den P-Link 15 angeschlossenen Module 14 vom Port 30 ausgegeben werden soll, überträgt das Modul die parallele Darstellung des Pakets über den Datenbus 20. Das Paket kann, wie bereits beschrieben, eine Mehrzahl von Acht-Byte-Übertragungen umfassen. Jedes der Module 14, eingeschlossen der Port 30, hat eine gleichartige P-Link-Schnittstelle 23 und die Vorgänge, Daten vom Bus 20 zu holen oder auf den Bus 20 zu geben, sind jeweils gleichartig. Falls ein Modul ein Paket an ein anderes Modul zu senden hat, zum Beispiel zum Port 30, zeigt es dieses zuerst an, indem es ein Anforderungssignal auf der Leitung 60 an den zugehörigen Link 21 sendet, so daß das Modul mit der zentralen Steuerung 22 verbunden wird. Es gibt weiterhin auf einen Zielbus 61 ein Acht-Bit-Signal aus, um der Steuerung den gewünschten Empfänger des zu übertragenden Pakets anzuzeigen. Es versteht sich, daß der P-Link 21 selbst ein Bus ist. Ein Modul, wie etwa der Port 30, das in der Lage ist ein Paket vom Bus 20 zu empfangen, sendet ein "Empfangen-Freigabe"-Signal auf der Leitung 62, das auf dem zugehörigen Pfad 21 zur zentralen Steuerung 22 geliefert wird, ungeachtet dessen, ob ein Paket verfügbar ist, das zu diesem Empfänger gesendet werden soll oder nicht. Falls die zentrale Steuerung 22 feststellt, daß ein Modul ein Paket zu einem Empfänger senden will und daß unabhängig davon der Empfänger durch das Signal auf der Leitung 22 seine Empfangsbereitschaft für Pakete vom Bus 20 angezeigt hat, veranlaßt die Steuerung 22, daß die Übertragung stattfindet. Die Steuerung 22 sendet das "Senden-Freigabe"- Signal 63 über die zugehörige Leitung 21 zur passenden Schnittstelle 23 und veranlaßt so das sendende Modul, das Paket über den Bus 64, der die Schnittstelle 23 mit dem Datenbus 20 verbindet, auf den P-Link-Datenpfad 20 zu geben. Die Steuerung 22 sendet dann das "Senden-Signal" 65 des Empfängers, das ihm anzeigt, daß er die aktuellen Übertragungen auf dem P-Link-Datenbus 20 annehmen soll. Die Paketübertragung wird abgeschlossen, wenn der Sender seine "Ende-Paketsendung"-Leitung 66 zusammen mit der letzten Übertragung von Paketdaten auf dem Bus 20 setzt. Dieses Signal wird über den zugehörigen Pfad 21 an die zentrale Steuerung 22 gesendet, worauf die Steuerung das "Ende- Paketempfang"-Signal 67 an das empfangende Modul sendet, das dieses veranlaßt die Annahme von Daten auf dem P-Link- Datenbus 20 einzustellen nachdem die aktuelle Übertragung empfangen wurde.
- Die im Port 30 ausgeführte parallel-zu-seriell Übersetzung hat eine eins zu eins Entsprechung zwischen den parallelen und seriellen Paketen, so daß alle Daten, die in einer Paketform enthalten sind, auch in der anderen enthalten sind. Die Übersetzung schließt daher die Feststellung des Pakettyps ein sowie das Kopieren von Paketfeldern in einer Weise, die durch den Typ festgelegt wird. Falls ein Paket vom Datenbus 20 auf den Ausgangspaketisierungspuffer 50 gegeben wird, wird das Paket in seiner Ganzheit gehalten, da der Puffer 35 Byte groß ist, so daß er die längsten Pakete halten kann. Wie in Fig. 4 dargestellt, ist der Puffer 50 mit der Port- Zustandsmaschine 59 und mit einem Shiftregister 70 durch einen Transferbus 71 verbunden. Das Shiftregister 70 ist mit dem Serialisierer 56 verbunden. Die Zustandsmaschine 59 liefert Eingabesignale 72 an den Puffer 50, um unter der Kontrolle der Zustandsmaschine 59 bestimmte Bytes vom P- Link-Paket auf den Transferbus 71 zu kopieren. Zuerst wird das höchstwertige Byte des Pakets, das den Empfängerkopf 73 beinhaltet, auf den Bytebreiten Transferbus 71 gegeben. Die Zustandsmaschine 59 vergleicht diesen Wert mit den Werten, die anzeigen, daß das Paket für das Shiftregister und das serielle Ausgabemodul bestimmt ist. Falls das Paket für das serielle Ausgabemodul bestimmt ist, veranlaßt die Zustandsmaschine, daß das nächste Byte 74 des Pakets (das der Befehlscode ist, der den Pakettyp angibt) auf den Transferbus 71 gegeben wird. Aufgrund des Befehlscodes 74, der über den Transferbus 71 an die Zustandsmaschine 59 gesendet wird, bestimmt die Zustandsmaschine Länge und Format des Pakets, das vom Datenbus 20 kommt und bestimmt somit die Länge und das Format des seriellen Pakets, das sie zu erzeugen hat. Die Zustandsmaschine 59 gibt ein Byte auf den Transferbus 71 aus, das die Länge des seriellen Pakets anzeigt und das in die erste Byteposition des Shiftregisters 70 verschoben wird. Die Zustandsmaschine 59 bewirkt dann, daß Bytes vom Puffer SO auf den Bus 71 kopiert werden, wo sie in die nächsten Bytepositionen des Shiftregisters 70 verschoben werden. Dies wird fortgeführt bis alle Bytes vom Puffer 50 hinüberkopiert wurden. Die Reihenfolge der vom Puffer 50 geholten Bytes ist in der Zustandsmaschine 59 enthalten, da dies die Reformatierung in das serielle Format festlegt. Das serielle Paket kann dann durch das Ausgabemodul 55 über den Pin 52 auf externe, angeschlossene Schaltungen ausgegeben werden, wie es weiter unten mit Bezug auf die Fig. 11 bis 14 beschrieben wird.
- Wenn ein serielles Paket über den Pin 53 auf den Port 30 eingegeben wird, wird die Übersetzung wie folgt behandelt. Jedes Byte wird in das Shiftregister 80 geschoben, das einen Paketisierungspuffer bildet. Solch ein serielles Paket ist in Fig. 8 dargestellt, in dem das erste Byte 81 die Paketgröße anzeigt. Dadurch wird die Position des letzten Bytes des Pakets bestimmt. Mit Bezug auf Fig. 3 kopiert das Register 80 unter der Kontrolle der Zustandsmaschine 59 Bytes auf den Transferbus 83 in der einfachen Reihenfolge, in der sie aus dem Shiftregister geschoben werden. Die Zustandsmaschine 59 vergleicht das Zielbyte 84 des Pakets mit den Werten, die anzeigen, daß das Paket für das P-Link-System 15 bestimmt ist. Um den Pakettyp anzuzeigen (auch als Befehlscode bekannt) bewirkt die Zustandsmaschine 59, daß das nächste Byte 85 des Pakets auf den Transferbus geschoben wird und dadurch prüft die Zustandsmaschine die Länge und das Format des Pakets des seriellen Moduls und des P-Link-Pakets, das sie zu erzeugen hat. Die Zustandsmaschine 59 bewirkt, daß Bytes aus dem Register 80 auf den Bus 83 geschoben werden, wo sie in den Paketpuffer des P-Links 51 kopiert werden. Dies wird fortgesetzt, bis alle Bytes des seriellen Verbindungsmoduls kopiert wurden und die Position an die die Bytes in den Puffer 86 vom Shiftregister 80 kopiert wurden, wird durch die Festlegung der Zustandsmaschine 59 bestimmt. Das zeigt der Schnittstelle 23 an, daß ein Paket fertig ist auf den Bus 20 gegeben zu werden, und die Schnittstelle kommuniziert über den zugehörigen Übertragungspfad 21 mit der zentralen Steuerung 22 wie bereits weiter oben beschrieben wurde. Wenn das P-Link-System 15 bereit ist das Paket zu akzeptieren, antwortet die Schnittstelle indem es die ersten acht Byte des Pakets beim nächsten Takt (gesteuert vom Taktgeber 34) auf den Datenpfad 20 kopiert. Bei den folgenden Takten kopiert es nacheinander Achtbytestücke des Pakets auf den Bus 20 bis alle Paketbytes übertragen wurden. Die letzten acht Byte sind gemeinsam mit dem von der Schnittstelle auf der Leitung 66 gesendeten Ende-Paketsendung-Signal.
- Wie bereits beschrieben, kann es sein, daß ein am Port 23 ankommendes Paket (entweder parallel oder seriell) auf die Portregister 58 zugreifen will. Wenn das Zielbyte 84 eines ankommenden seriellen Bitpakets vom Pin 53 anzeigt, daß das Paket auf die Register 58 zugreifen soll, wird das bitserielle Paket wie bereits beschrieben in ein P-Link- Paket im Puffer 51 gewandelt, aber anstatt zu der P-Link- Schnittstelle 23 weitergeleitet zu werden, wird es verwendet, um auf die Register 58 zuzugreifen. Ein Byte (der Befehlscode) des Pakets zeigt an, ob der Zugriff auf das Register ein Lese- oder Schreibzugriff ist. Wenn der Zugriff ein Lesen ist, wird die Zustandsmaschine 59 ein Lesesignal auf der in Fig. 5 dargestellten Leitung 90 ausgeben. Zusammen damit werden die vier niedrigstwertigen Bits des Paketadressfelds auf die Leitung 91 gegeben. Einige Takte später kopiert die Registerbank 58 unter der Steuerung eines Steuerblocks 92 den Wert im Adressregister auf den Datenbus 93, ein Byte auf einmal, jedes Byte auf einen folgenden Takt. Jedes Byte auf der Datenleitung 93 wird in den Ausgabepuffer 50 geschoben und unter der Steuerung der Zustandsmaschine 59 werden die vom Register gelesenen Daten in ein P-Link-Paket im Puffer 50 umgewandelt und als eine "Lade-Antwort" spezifiziert. Das Zielfeld für dieses Antwortpaket wird von einem "Absender"- Feld eines anfragenden bitseriellen Pakets kopiert. Eine Transaktionskennung (transaction identifier, TID), die außerdem in jedem Paket vorhanden ist, wird auch mitkopiert. Ein Typbyte des Antwortpakets wird aus dem Typbyte des Anfragepakets erzeugt und folglich wird ein Antwort-P-Link-Paket im Ausgabepuffer 50 erzeugt in Reaktion auf ein Anfragepaket, das von einer externen Quelle über den Pin 53 eingegeben wurde.
- Falls der Typ des Zugriffs auf die Register 58 ein Schreibzugriff ist, wird die Schreibleitung 95 zusammen mit der Adressleitung 91 durch die Zustandsmaschine 59 gesetzt. Einige Takte später wird das niedrigstwertige Byte der Daten von einem Operandenfeld des Pakets im Puffer 51 auf den Datenbus 93 kopiert. Auf die folgenden sieben Takte werden Bytes aufeinanderfolgender Wertigkeit in das Register 58 kopiert, solange bis alle acht Bytes kopiert wurden. Daraufhin wird im Register 50 ein Antwortpaket erzeugt, außer, daß "Speicherungs-Antwort"-Pakete keine mit ihnen verbundenen Daten haben und nur ein Zielbyte, ein Typbyte und ein Transaktionskennungsbyte umfassen. Dieses Antwortpaket wird wie zuvor beschrieben in ein bitserielles Antwortpaket übersetzt, in das Shiftregister 70 geladen und über den Pin 52 ausgegeben, um dem Absender der Schreibanfrage anzuzeigen, daß eine Speicherung durchgeführt wurde.
- Eine ähnliche Operation wird ausgeführt falls das Zielbyte eines durch den Port 30 vom P-Link-System 15 erhaltenen Pakets untersucht wird und anzeigt, daß das Paket dazu bestimmt ist auf das Register 58 im Port 30 zuzugreifen. Anstatt einer Weiterleitung zum bitseriellen Register 70 wird das Typfeld des Pakets dazu verwendet zu bestimmen, ob der Zugriff ein Lese- oder Schreibzugriff ist. Falls der Zugriff ein Lesezugriff ist, wird die Leseleitung 90 aus Fig. 5 durch die Zustandsmaschine 59 gesetzt und die niedrigstwertigen vier Bits des Adressfelds des Pakets auf die Adressleitung 91 gegeben. Zwei Takte später kopiert die Registerbank Byte für Byte den im adressierten Register gehalten Wert auf die Datenleitung 93, jedes Byte in aufeinanderfolgenden Takten. Dies wird in den Puffer 51 geschoben und die Zustandsmaschine erzeugt ein P-Link-Paket, das als "Lese-Antwort"-Paket spezifiziert wird. Das Zielfeld für dieses Antwortpaket wird vom Absenderfeld des anfragenden bitseriellen Pakets kopiert. Die Transaktionskennung wird ebenso kopiert. Das Typbyte des Antwortpakets wird aus dem Typbyte des Anfragepakets erzeugt.
- Wenn der verlangte Zugriffstyp ein Schreibzugriff ist, setzt die Zustandsmaschine 59 die Schreibleitung 95 zusammen mit der Adressleitung 91. Einige Takte später wird das niedrigstwertige Byte der Daten vom Operandenfeld des Pakets im Puffer 50 auf die Datenleitung 93 kopiert. Auf die folgenden sieben Takte werden Bytes aufeinanderfolgender Wertigkeit auf die Datenleitungen 93 und in die Register kopiert, solange bis alle Bytes kopiert wurden. Es wird dann, wie weiter oben beschrieben, ein Antwortpaket erzeugt, mit der Außnahme, daß "Speicherungs- Antwort"-Pakete keine mit ihnen verbundenen Daten haben und nur ein Zielbyte, ein Typbyte und ein Transaktionskennungsbyte umfassen. Dieses Antwortpaket wird dann an die P-Link-Schnittstelle 23 weitergeleitet, wo es zum Absender des für den Zugriff auf das Portregister 58 über die P-Link-Schnittstelle 93 eingegebenen Anfragepakets zurückgesendet wird.
- Aus der obenstehenden Beschreibung geht hervor, daß die in den Fig. 6, 7 und 8 dargestellten Paketformate Pakete einschließen, die eine Anfrage oder Antwort für eine Lese- oder Schreiboperation bilden. Zusätzlich dazu, daß jedes Paket eine Zielkennung für das Paket (Bezugszeichen 73 in den Fig. 6 und 7 oder Bezugszeichen 84 in Fig. 8) einschließt, umfassen die Pakete eine Transaktionskennung (TID) 98 und eine Angabe des Absenders 99. Es ist möglich, daß die Pakete eine genauere Adresse für ein Ziel angeben müssen. Hierfür kann eine Adresskennung 100 vorgesehen werden. Wie bereits in Verbindung mit dem Registerzugriff am Port 30 beschrieben, bestimmt das Ziel den Port, während die Adresse 100 zur Angabe des genauen Registers im Port verwendet wird. Das Zielfeld ist ein Einbytefeld, das dazu verwendet wird, das Paket zu dem mit dem P-Link 15 verbundenen Zielsubsystem oder Modul weiterzuleiten. Für Anfragepakete ist es das höchstwertige Byte der Adresse, auf die zugegriffen werden soll. Für ein Antwortpaket bezeichnet es das Subsystem, von dem die Anfrage stammt. Das Absenderfeld ist ein Einbytefeld, das als eine Rücksendeadresse für das Antwortpaket verwendet wird. Das Adressfeld wird durch die drei niedrigstwertigen Bytes des Anfragepakets bestimmt. Das TID-Feld wird vom anfragenden Modul verwendet, um die Verbindung zwischen der Antwort und der Anfrage herzustellen.
- Es ist vorteilhaft, daß durch die Verwendung eines bitseriellen Ports ein kostengünstiger Zugriff auf einen Chip möglich ist, der nur eine kleine Anzahl von Pins erfordert und der insbesondere zum Debuggen einer CPU mit Hilfe eines externen Hosts verwendet werden kann.
- In diesem Beispiel ist jede der CPUs 12 und 13 eingerichtet, um eine Befehlssequenz in konventioneller Weise auszuführen. Der Befehlssatz umfaßt eine Vielzahl konventioneller Befehle für einen Mikrocomputer, aber dieses Beispiel umfaßt auch einen Befehl um ein "Ereignis" zu senden. Ein "Ereignis" ist ein außergewöhnlicher Vorfall, der normalerweise durch Umstände außerhalb einer Folge von Befehlen verursacht wird. Ereignisse können so verwendet werden, daß sie einen ähnlichen Effekt wie ein "Interrupt" oder ein "synchroner Trap" haben. Ereignisse können mit einer Priorität versehen sein, so daß sie eine Änderung der Prioritätsstufe bewirken, auf der die CPU arbeitet. Ein Ereignis kann durch die Ausführung eines Ereignisbefehls gesendet werden, obwohl Hardware in der Art der Ereignislogik 44 die Funktion einiger Ereignisse ohne die Ausführung von Befehlen in einer Service- oder Handlerroutine durchführen kann.
- Ereignisse, die von einer Ausführung eines Befehls durch die CPU stammen, sind durch die Ausführung des Ereignisbefehls verursacht. Dies kann dazu verwendet werden, ein "Ereignis" an eine CPU zu senden, wie etwa die eine oder die andere der CPUs 12 oder 13 auf dem selben Chip, oder es kann dazu verwendet werden, über eine externe Verbindung ein Ereignis an eine CPU auf einem anderen Chip zu senden. Die CPU, die den Ereignisbefehl ausführt, kann ebenso ein Ereignis an ein weiteres Modul senden, das an das P-Link-System 15 angeschlossen ist. Der Ereignisbefehl hat zwei 64-Bit Operanden, die Ereignisnummer und den Ereignisoperand. Hinsichtlich der Ereignisnummern 0-63 wird Bit 15 dazu verwendet festzulegen, ob das Ereignis ein "spezielles Ereignis" ist oder nicht. Wenn Bit 15 auf 1 gesetzt ist, werden die Bits 0-14 dazu verwendet, den Typ des speziellen Ereignisses festzulegen. Die Bits 16-63 der Ereignisnummer werden dazu verwendet, die Zieladresse der CPU oder des Moduls festzulegen, die oder das das spezielle Ereignis empfangen soll. Die Typen spezieller Ereignisse werden nachfolgend beschrieben:
- Diese speziellen Ereignisse können von einer der beiden CPUs 12 oder 13 zur anderen gesendet werden oder sie können alternativ über den Debugport 30 von einem externen Host zu einer der beiden CPUs 12 oder 13 gesendet werden. Das "Ereignis" wird als ein Bitpaket vom weiter oben beschriebenen Typ gesendet.
- Als Reaktion auf ein spezielles Ereignis kann jeder der CPUs 12 oder 13 dazu veranlaßt werden, Befehle zu holen oder auszugeben und in den unterbrochenen Zustand zu gehen.
- Wenn ein Unterbrechungsereignis von einer CPU empfangen wird, setzt diese ein Unterbrechungsflag. Dieses Flag wird mit dem Zustand des Unterbrechungspins oderverknüpft, um den Ausführungszustand der CPU zu bestimmen.
- Der unterbrochene Zustand kann erreicht werden durch:
- - Setzen des Unterbrechungspins. Dies stoppt alle CPUs auf dem Chip.
- - Senden eines Ereignis.Suspend zu einer CPU. Dies unterbricht nur die empfangende CPU.
- Der unterbrochene Zustand kann durch einen der folgenden Punkte aufgehoben werden:
- - Wechsel eines externen Unterbrechungspins vom gesetzten in den negierten Zustand. Dies veranlaßt alle CPUs, die nicht ihr Unterbrechungsflag gesetzt haben, die Ausführung wieder aufzunehmen.
- - Senden eines speziellen Ereignis.Run Ereignisses zu einer CPU. Dies löscht das Unterbrechungsflag. Falls der Unterbrechungspin negiert ist, veranlaßt dies die empfangende CPU die Ausführung wieder aufzunehmen.
- Die Unterbrechung einer CPU veranlaßt diese, die Ausführungspipelines zu leeren. Dies benötigt eine implementierungsabhängige Zeitspanne. Während eine CPU unterbrochen ist, kann ihr Ausführungskontext in einer der folgenden Weisen verändert werden:
- - Das Resetaddressen-Steuerregister Reset.Handler kann geändert werden.
- - Die CPU kann zurückgesetzt werden (Reset).
- - Externer Speicher kann durch DMA verändert werden, z. B. unter Verwendung des Debugports 30.
- Bei einem Hard-Reset (das ist das Zurücksetzen aller Zustände auf dem Chip) wird, falls der Unterbrechungspin auf der aktiven Flanke des Hard-Reset gesetzt wird, der Zustand der CPU(s) initialisiert, aber die CPU(s) wird/werden nicht booten. Wenn die CPUs in den Ausführungszustand gehen, booten sie von der im Reset.Handler enthaltenen Adresse, die vor dem Reset- Ereignis gesetzt wurde.
- Das Reset-Ereignis veranlaßt die empfangende CPU einen Soft-Reset durchzuführen. Dieser Resettyp veranlaßt den internen Zustand mit bekannten Werten initialisiert zu werden, während die alten Werte in dafür bestimmten Schattenregistern gesichert werden, damit eine Debugsoftware den Zustand der CPU zum Zeitpunkt des Reset bestimmen kann.
- Das Befehlsausführungssystem der CPUs 12 oder 13 und seine Beziehung zur Logikeinheit für spezielle Ereignisse 44 wird mit Bezug auf die Fig. 9 beschrieben. Im normalen Betrieb ist der Zyklus des Befehlsabrufs und der Befehlsausführung der CPU wie folgt. Ein Prefetcher (Befehlsabrufschaltung) 101 holt Befehle vom Befehlscache 42, und die Befehle werden angeordnet und fertig zur Dekodierung durch eine Dekodereinheit 102 in einem Puffer abgelegt. Die Dekodereinheit 102 standardisiert das Format von Befehlen, so daß diese zur Ausführung geeignet sind. Eine Dispatcher-Schaltung 103 steuert und entscheidet welche Befehle ausgeführt werden können und gibt die Befehle zusammen mit etwaigen Operanden an die Ausführungseinheit 104 oder an eine Lade/Speicher-Einheit 105. Der Mikrocomputerchip dieser Ausführungsform hat zusätzlich die Logikeinheit für spezielle Ereignisse 44. Diese Einheit 44 kann Befehle annehmen, die von Paketen auf dem P-Link-System 15 über die Schnittstelle 23 herrühren, um die normale Folge der Befehlsabrufe zu überschreiben. Beim Empfang eines "Unterbrechungsereignis"-Pakets veranlaßt die Logikeinheit für spezielle Ereignisse 44 den Prefetcher 101 das Abrufen neuer Befehle einzustellen und sie veranlaßt den Dispatcher 103 das Abfertigen der Befehle einzustellen. Die Ausführungspipeline für Befehle wird geleert. Ein "Run-Ereignis"-Paket veranlaßt die Logikeinheit für spezielle Ereignisse 44 dazu, den Prefetcher dazu zu veranlassen das Abrufen von Befehlen wieder aufzunehmen, falls der Unterbrechungspin nicht gesetzt ist. Zusätzlich zum Anhalten oder Starten der normalen Befehlsausführung kann die Logikeinheit für spezielle Ereignisse 44 bewirken, daß der Zustand des "Befehlsstroms" durch einen Soft-Reset reinitialisiert wird. Dies wird durch Software ausgelöst wenn der Chip bereits arbeitet und setzt nur einen Teil des Zustands auf dem Chip zurück. Außerdem kann ein Paket das Register überschreiben, das die Adresse beinhaltet, an der der Code nach einer Reset-Operation abgerufen wird.
- Die Logikeinheit für spezielle Ereignisse 44 wird nun mit Bezug auf Fig. 10 ausführlicher beschrieben.
- Fig. 10 stellt die Logikeinheit für spezielle Ereignisse 44 dar, die über die P-Link-Schnittstelle 23 mit dem P-Link-System 15 verbunden ist. Wie ausführlicher in Fig. 10 dargestellt ist, ist die Schnittstelle 23 über einen Bus 110 mit der Logikeinheit für spezielle Ereignisse 44 verbunden, die ausführlicher folgende Komponenten umfaßt. Eine Ereignishandler-Schaltung 111, die durch Leitung 112 zur Befehlsabrufschaltung 101 und durch Leitung 113 zum Befehlsdispatcher 103 verbunden ist. Der Bus 110 ist außerdem zur Ereignislogikschaltung 114 verbunden, die über die Leitung 115 eine bidirektionale Übertragung mit der Ereignishandler-Schaltung 111 hat. Die Ereignislogikschaltung 114 ist mit einer bidirektionalen Verbindung zur Zähler-und-Alarmschaltung 116 und zu einem Unterbrechungsflag 117 verbunden. Ein Unterbrechungspin 118 ist mit der Ereignislogik 114 verbunden. Ein Resethandler- Register 119 hat über Leitung 120 eine bidirektionale Kommunikation mit der Ereignislogik 114. Es ist außerdem mit einem Resethandler-Schattenregister 121 verbunden.
- Die Arbeitsweise der Schaltung aus Fig. 10 ist wie folgt. Ein Befehl kann chipintern ausgeführt oder vom Betrieb einer Schaltung auf einem externen Chip abgeleitet werden, was bewirkt, daß ein Paket auf dem P-Link-System 15 übertragen wird, das eine Zielkennung hat, die das in Fig. 10 dargestellte Modul bezeichnet. In diesem Fall wird das Paket über die Schnittstelle 23 und über den Bus 110 zum Ereignishandler 111 und zur Ereignislogik 115 gebracht. Die Ereignislogik hat zu bestimmen, ob das spezielle Ereignis ein "Run-Ereignis" oder "Reset-Ereignis" oder "Unterbrechungsereignis" oder "Set/Reset-Handler-Ereignis" ist.
- Beim Empfang eines "Unterbrechungs-Ereignis" veranlaßt die Ereignislogik 114, daß das Unterbrechungsflag 117 gesetzt wird. Die Ereignislogik 114 bildet aus dem Zustand des Unterbrechungsflags 117 und dem Zustand des Unterbrechungspins 118 ein logisches ODER. Das Ergebnis wird als Unterbrechungszustand bezeichnet. Wenn die Ankunft des "Unterbrechungs-Ereignis" den Unterbrechungszustand nicht geändert hat, wird nichts weiteres unternommen. Falls die Ankunft des "Unterbrechungs-Ereignis" den Unterbrechungszustand geändert hat, unterbindet die Ereignislogik 114 den Zugriff auf Befehle aus dem Cache 42, sie bewirkt dies durch ein Signal an den Eventhandler 111, der das Abrufen der Befehle durch den Fetcher 101 und das Abfertigen von Befehlen durch den Dispatcher 103 steuert. Befehle, die vor dem Empfang des "Unterbrechungs-Ereignis" abgerufen wurden, werden abgeschlossen, aber die zur Ereignislogik 114 gehörende CPU wird schließlich in einen Zustand gehen, in dem keine Befehle abgerufen oder ausgeführt werden.
- Beim Empfang eines "Run-Ereignis" veranlaßt die Ereignislogik 114, daß das Unterbrechungsflag 117 gelöscht wird. Die Ereignislogik 114 bildet ein logisches ODER aus dem Zustand des Unterbrechungsflags 117 und des Unterbrechungspins 118. Das Ergebnis ist als der Unterbrechungszustand bekannt. Wenn die Ankunft des "Run- Ereignis" den Unterbrechungszustand nicht geändert hat, wird nichts weiteres unternommen. Falls die Ankunft des "Run-Ereignis" den Unterbrechungszustand geändert, hat beendet die Ereignislogik 114 die Unterbindung des Zugriffs auf Befehle aus dem Cache 42. Ein über den Eventhandler 111 übertragenes Signal zeigt dem Fetcher 101 an, daß die CPU ihren Befehlsabruf-Ausführungszyklus an dem Punkt, an dem er unterbrochen wurde, wieder aufnehmen soll.
- Falls ein "Set-Resethandler-Ereignis" empfangen wird, veranlaßt die Ereignislogik 114 den Operanden, der das spezielle Ereignis im Paket begleitet, in das Resethandler- Register 119 kopiert zu werden, und der vorhergehende Wert im Register 119 wird im Resethandler-Schattenregister 121 abgelegt.
- Beim Empfang eines "Reset-Ereignis" veranlaßt die Ereignislogik 114 den Ereignishandler 111 seinen aktuellen Ausführungsthread zu beenden, indem dem Fetcher 101 auf der Leitung 112 ein neuer Befehlspunkt gegeben wird und so die Ausführung einer neuen Befehlssequenz gestartet wird, deren erster Befehl von der durch das Resethandler-Register 199 gegebenen Adresse abgerufen wird. Diese neue Adresse wird auf der Leitung 120 über die Ereignislogik 114 und zum Ereignishandler 111 abgerufen, bevor sie an den Fetcher 101 weitergegeben wird.
- Aus dem Bisherigen geht hervor, daß durch die Verwendung der speziellen Ereignisse, die in Paketen auf dem P-Link-System 15 bezeichnet sein können, chipinterne oder chipexterne Quellen verwendet werden können, um das Abrufen und die Ausführung von Befehlen durch eine CPU zu unterbrechen oder die Ausführung einer unterbrochenen CPU wieder aufzunehmen. Sie können außerdem verwendet werden, um eine CPU in einen initialen Zustand zurückzusetzen oder um neuen Boot-Code für die CPU von irgendwo auf dem P-Link- System zu beschaffen oder von irgendwo in einem verbundenen Netzwerk unter Verwendung des externen Ports 30, so daß das ganze Netzwerk, das von der CPU erreicht werden kann, einen Teil des physikalischen Adressraums bildet.
- Die Fig. 15, 16 und 17 zeigen ausführlichere Darstellungen der Logikeinheit für spezielle Ereignisse 44.
- Fig. 15 stellt das P-Link-System 15 dar, das einen Empfangspuffer 140 und einen Übertragungspuffer 141 benachbart zur Schnittstelle 23 umfaßt. Falls im Puffer 140 ein Paket empfangen wird, das ein spezielles Ereignis enthält, können auf den Leitungen 142, 143 und 144 Eingaben zur Dekodierlogik für spezielle Ereignisse 145 gemacht werden. Falls Bit 15 der Ereignisnummer auf 1 gesetzt ist und damit ein spezielles Ereignis anzeigt, wird auf der Leitung 142 ein P-gültig-Signal zur Dekodierlogik 145 gegeben. Gleichzeitig wird der Dekodierlogik 145 auf der Leitung 143 das Ereigniscodefeld des Pakets zugeführt und auf der Leitung 144 wird der Dekodierlogik 145 das Ereignisoperandenfeld zugeführt. Als Reaktion auf das Setzen des P-gültig-Signals auf der Leitung 142 dekodiert die Dekodierlogik 145 das Ereigniscodefeld wie in der folgenden Tabelle angegeben:
- Auf den auf das Dekodieren folgenden Takt gibt die Dekodierlogik 145 auf der Leitung 146 ein P-Ereignisfertig-Signal aus, um den Puffer 140 zu löschen. Abhängig vom Ergebnis der Dekodierung des Signals auf Leitung 143 kann die Dekodierlogik entweder ein Run-Ereignis-Signal auf Leitung 147 ausgeben oder ein Unterbrechungsereignis-Signal auf Leitung 148 zur Unterbrechungslogik 149, die mit dem Unterbrechungspin durch die Leitung 150 verbunden ist. Alternativ kann die Dekodierung des Signals auf der Leitung 143 die Dekodierlogik 145 dazu veranlassen auf der Leitung 151 ein Reset-Ereignis-Signal an die CPU-Pipeline-Schaltung 152 auszugeben. Alternativ kann die Dekodierlogik 145 ein Set-Resethandler-Ereignis-Signal auf der Leitung 153 zusammen mit dem Wert des Operanden auf dem Bus 156 an die Resethandler-Logik 154 ausgeben.
- Fig. 16 stellt die Unterbrechungslogik 149 dar. Die Leitungen 147 und 148 bilden Eingaben zu einem SR-Latch 157, der einen zweite Eingabe 158 für ein Oder-Gatter 159 liefert, wobei der Unterbrechungspin die andere Eingabe 150 liefert. Dadurch wird das Signal auf Leitung 147 mit dem Unterbrechungspin logisch oderverknüpft und erzeugt ein Befehlsabruf-Abschaltesignal auf Leitung 160, das ein Latch 161 einschließt, das das Unterbrechungsflag bereitstellt. Das Signal auf der Leitung 160 hat den Effekt, das Abrufen von Befehlen vom Befehlscache 42 zu unterbinden. Dies führt schließlich dazu, daß der CPU keine weiteren Befehle zur Verfügung stehen und die Ausführung der CPU wird unterbrochen. Im normalen Betrieb des SR-Latchs 157 löscht das Setzen des Signals auf Leitung 148 jedes vorher auf der Leitung 147 gesetzte Signal.
- Fig. 17 stellt die Resethandler-Logik 154 dar. Wenn auf der Leitung 153 das Set-Ereignis gesetzt wird, wird dies einer Resethandler-Zustandsmaschine 162 zugeführt, die an einen Registerbus 163 angeschlossen ist, der das Resethandler-Register 119, das Resethandler- Schattenregister 121 und den Befehlsszeigerbus 112 verbindet. Die Reaktion auf das Setzen des Signals 153 ist wie folgend:
- 1. Die Zustandsmaschine 162 setzt die Leseleitung 164 des Resethandler-Registers 119, wodurch der Wert im Resethandler-Register ausgelesen und auf den Registerbus 163 gegeben wird.
- 2. Die Zustandsmaschine 162 setzt die Schreibleitung 165 des Resethandler-Schattenregisters 121, wodurch der Wert auf dem Registerbus in das Resethandler-Schattenregister geschrieben wird.
- 3. Die Zustandsmaschine 162 veranlaßt, daß der Wert auf dem Ev_handle-Bus 156 auf den Registerbus gegeben wird.
- 4. Die Zustandsmaschine 162 setzt die Schreibleitung 164 des Resethandler-Registers 119, wodurch der Wert auf dem Registerbus in das Resethandler-Register 119 kopiert wird.
- Andererseits, falls von der CPU-Pipeline 152 ein Hole- Befehlszeiger-Signal auf der Leitung 166 gesetzt wird, passiert das folgende. Die Zustandsmaschine 162 setzt die Leseleitung (R/W) des Resethandler-Registers, wodurch der Wert im Resethandler-Register auf den Registerbus ausgelesen wird. Dieser Wert wird über die als IPTR bezeichnete Leitung übertragen.
- Das folgende Verfahren kann dazu verwendet werden, die eine oder die andere der CPUs 12 oder 13 aus Fig. 1 zu booten, falls der Chip entsprechend der in Fig. 11 dargestellten Anordnung über den Port 30 mit einem externen Mikrocomputer verbunden ist. Die beiden CPUs 12 und 13 können mit einem gemeinsamen Unterbrechungspin 118 verbunden werden. Falls Pin 118 gesetzt wird nachdem der Hard-Reset-Pin 46 gesetzt wurde, werden beide CPUs daran gehindert weitere Befehle abzurufen. Der externe Anschluß 30 und ein externer Mikrocomputer 123 können dann dazu verwendet werden, den minimalen chipinternen Zustand zu konfigurieren, indem direkt in die Steuerregister auf dem Chip 11 geschrieben wird und indem der notwendige Boot-Code im an den Bus 33 auf dem Chip 11 angeschlossenen DRAM- Speicher gespeichert wird. Wenn der Zustand des Unterbrechungspins geändert wird, kann eine der CPUs mit dem jetzt für den Chip 11 im DRAM gespeicherten Code booten. Um dies zu erreichen, wird der Unterbrechungspin 118 in einen gesetzten Zustand geändert, nachdem ein Hard- Reset gesetzt wurde. Wie in Fig. 11 dargestellt, sendet der externe Mikrocomputer 123 über den Port 30 Pakete, um den Boot-Code in den Speicher 120 zu schreiben. Der Host 123 führt dann einen Befehl aus, um das spezielle Ereignis "Set-Resethandler-Ereignis" zum Ausgewählten der beiden Mikrocomputer 12 oder 13 zu senden, wobei wir in diesem Beispiel die CPU 13 annehmen. Dies stellt im Resethandler- Register 119 eine neue Zieladresse für die CPU 13 bereit. Der Host 113 führt dann einen Befehl aus, um über den Port 30 ein spezielles Ereignis "Unterbrechungsereignis" zur anderen CPU 12 zu senden. Dies setzt das Unterbrechungsflag 117 der CPU 12. Das gesetzte Signal auf dem Unterbrechungspin 118 wird dann zurückgesetzt, so daß die CPU 13 mit der Ausführung von Code beginnt, der vom Speicher 120 von der im Resethandler-Register 119 gehaltenen Zielbootadresse geholt wird. Die CPU 12 bleibt unterbrochen, da ihr Unterbrechungsflag 117 gesetzt ist. Falls es notwendig wird, daß die CPU 12 wieder arbeitet, kann sie von der CPU 13 gestartet werden, indem diese einen Befehl ausführt, um an die CPU 12 den speziellen Befehl "Set-Resethandler-Ereignis" zu senden. Dies ändert die im Resethandlerregister 119 der CPU 12 gehaltene voreingestellte Bootadresse. Die CPU 13 muß dann einen Befehl ausführen, um das spezielle Ereignis "Run-Ereignis" zur CPU 12 zu senden, wodurch, wie oben beschrieben, die Ausführung der CPU 12 wieder mit Code startet, der von der Adresse im Resethandler-Register 119 der CPU 12 geholt wird.
- In dieser Weise kann der Mikrocomputer aus Fig. 1 gebootet werden ohne die Anforderung, daß gültiger Code in einem ROM liegt.
- Obwohl die oben beschriebene Boot-Prozedur Boot-Code verwendet, der in den lokalen Speicher 120 des Chips 11 geladen wird, ist ein ähnliches Vorgehen mit Code aus dem Speicher 125 möglich, der lokal auf dem externen Mikrocomputer 123 ist. Um dies zu erreichen, wird dasselbe Verfahren wie oben angewendet mit der Ausnahme, daß das zum Laden des Resethandler-Registers 119 der CPU 13 über den Port 30 gesendete spezielle Ereignis eine Zieladresse für den Boot-Code angibt, die im Adressraum des Ports 30 liegt. Wenn das gesetzte Signal am Unterbrechungspin 118 zurückgesetzt wird, wird dadurch die CPU 13 beginnen Code direkt vom externen Computer und aus dem externen Speicher abzurufen. Falls die CPU 12 gebraucht wird, kann sie wie bereits beschrieben von der CPU 13 gestartet werden.
- Indem dafür gesorgt wird, daß der Host 113 den speziellen Unterbrechungsereignis-Befehl zur CPU 12 sendet bevor das gesetzte Signal am Unterbrechungspin 118 zurückgesetzt wird, ist es möglich, die Menge an Befehlen, die über den Port 30 abgerufen werden zu reduzieren, da die CPU 13 alleine booten und danach dafür sorgen kann, daß CPU 12 bootet, anstatt beide CPUs 12 und 13 über den Port 30 vom externen Mikrocomputer zu booten.
- Überwachungspunktregister können verwendet werden, um die Ausführung eines Programms zu überwachen. Diese Register können dazu verwendet werden eine Debugroutine zu starten, falls eine bestimmte Speicherstelle adressiert wird oder im anderen Falle, falls Befehle von einer bestimmten Stelle ausgeführt werden.
- Verschiedene Beispiele zur Verwendung des Chips 11 in einem Netzwerk mit einer Mehrzahl an verbundenen Chips sind in den Fig. 11 bis 14 dargestellt.
- Im Beispiel aus der Fig. 11 wird der Chip 11 zur Vereinfachung nur mit der CPU 12 dargestellt, da die CPU 13 nicht an dem mit Bezug auf Fig. 11 beschriebenen Vorgang beteiligt ist. Der Chip ist über die externe Speicherschnittstelle und den Bus 33 mit einem Speicherchip 120 verbunden, der lokal bei der CPU 12 angeordnet ist und der einen Teil des lokalen Adressraums der CPU 12 bildet.
- Der Port 30 ist über zwei serielle Leitungen 121 und 122 mit einem weiteren Mikroprozessorchip 123 verbunden, der in diesem Fall einen Debug-Host für den Chip 11 darstellt. Die Leitung 121 stellt für den Chip 11 einen unidirektionalen Eingabepfad, die Leitung 122 für den Host 123 einen unidirektionalen Ausgabepfad zur Verfügung. Der Host 123 ist über einen Bus 124 mit einem Speicherchip 125 verbunden, der sich lokal beim Mikrocomputer 123 befindet und daher einen Teil des lokalen Adressraums des Host- Mikrocomputers 123 bildet. Um Debug-Vorgänge auf der CPU 12 durchführen zu können, kann der Host-Mikrocomputer Software ausführen, die chipintern im Mikrocomputer 123 oder von seinem lokalen Speicher 125 erhalten wird, so daß der Host 123 wie bereits beschrieben die Ausgabe spezieller Ereignisse in Paketen über die serielle Leitung 121 und über den Port 30 auf das P-Link-System 15 veranlaßt. Diese können mit der Zieladresse die CPU 12 bezeichnen, so daß dieses spezielle Ereignis in der Weise behandelt werden kann, die mit Bezug auf Fig. 10 bereits beschrieben wurde. Dies kann dazu verwendet werden, die CPU 12 zu jeder Zeit zu unterbrechen und den Wert in ihrem Resethandler-Register zu ersetzen und die CPU 12 zurückzusetzen, entweder von ihrem vorhergehenden Zustand oder von einem neuen Zustand, der durch den Wert im Register 119 angezeigt wird. Ein Teil des Adressraums der CPU 12 kann in den Adressen des Speichers 125 liegen, der sich lokal beim Host 123 befindet. Der Port 30 bildet einen Teil des lokalen Adressraums der CPU 12 und folglich kann ein Speicherzugriff auf den dem Port 30 zugeteilten Adressraum erfolgen und in diesem Falle kann die Antwort von Software erzeugt werden, die auf dem Host-Mikrocomputer 123 läuft. Es ist daher möglich das Resethandler-Register 119 auf eine Adresse zu setzen, die lokal beim Host liegt, anstatt auf eine lokale Adresse der CPU 12. Dadurch kann ein Host unabhängig vom Betrieb der CPU 12 sich selbst als Quelle von Befehlen und/oder Daten für die CPU 12 einrichten. Dieser Mechanismus kann zum Debuggen vom Host 123 aus verwendet werden. Im Falle eines Chip 11 mit zwei CPUs 12 und 13 ist es möglich Software, die auf der CPU 12 läuft, wie bereits beschrieben zu debuggen, während auf der CPU 13 laufende Software unbeeinträchtigt vom mit der CPU 12 durchgeführten Debugvorgang bleibt. Dies ist der Fall in Fig. 12, wo die zweite CPU 13 mit unterbrochenen Linien dargestellt ist und normal läuft, wobei sie Befehle von ihrem Befehlscache oder vom Speicher 120 erhält, unbeeinflußt vom Debugvorgang auf der CPU 12 in Verbindung mit dem Host 123.
- Fig. 13 stellt eine weitere mögliche Anordnung dar, in der das Netzwerk im wesentlichen ähnlich dem mit Bezug auf die Fig. 11 und 12 beschriebenen Netzwerk ist. Jedoch ist die CPU 12 in diesem Fall mit einem Daten- Überwachungspunkt-Register 130 und einem Code- Überwachungspunkt-Register 131 ausgestattet, in denen die jeweiligen Adressen für Datenwerte oder Befehlsstellen gehalten werden können, um eine Debugroutine zu starten, falls diese Überwachungspunkte erreicht werden. In diesem Beispiel kann der Host-Mikrocomputer 123 an jedem Punkt während der Ausführung eines Programms durch die CPU 12, die Ausführung der CPU 12 kurz anhalten und veranlassen, daß der Überwachungspunktzustand in den Registern 130 oder 131 geändert und die Kontrolle an das ursprüngliche Programm der CPU 12 zurückgegeben wird. Wenn die CPU 12 einen Befehl ausführt, die einen der in den Registern 130 oder 131 gesetzten Überwachungspunkte auslöst, stoppt sie das Abrufen von Befehlen in der normalen Abfolge und startet das Abrufen und Ausführen von Befehlen beginnend mit dem Befehl, die durch den Inhalt eines Debughandler- Registers 132 bezeichnet wird. Falls das Debughandler- Register 132 eine Adresse enthält, die lokal beim Mikrocomputer 123 liegt anstatt lokal bei der CPU 12, wird die CPU 12 anfangen Befehle vom Host 123 abzurufen. Dadurch kann der Host das Debuggen mit Überwachungspunkten eines bereits laufenden Programms erreichen, ohne irgendwelchen lokalen Speicher der CPU 12 zu verwenden und ohne vorauszusetzen, daß das Programm der CPU 12 sich kooperativ mit dem Debug-Host 123 verhält. Dadurch ermöglicht das beschriebene Beispiel nicht-kooperatives Debuggen. Das Betriebssystem und Anwendungsprogramme der CPUs auf dem Chip 11 benötigen keinerlei Kenntnis wie der Debug- Hostrechner 123 vorgehen wird oder welches Betriebssystem oder welche Programme auf dem Host 123 laufen.
- In konventionellen Computer-Architekturen werden Auslöser für Überwachungspunkte durch einen gemeinsamen Vektor für vom Betriebssystem verwaltete Traps oder Ereignisse behandelt. Diese Traps und Ereignisse verwenden einen konventionellen Satz von Registern 134, die die Adresse der Handlerroutine bereitstellen. Im beschriebenen Beispiel wird ein zusätzlicher Registersatz 135 verwendet, der das Debughandler-Register 132 und ein Resethandler- Register 136 umfaßt. Durch den zusätzlichen Registersatz 135, in dem die Adresse der Handlerroutine für Überwachungspunktbearbeitungsroutinen abgelegt werden kann, wird die Unabhängigkeit vom Betriebssystem erreicht.
- Fig. 14 stellt dasselbe Netzwerk dar, das zuvor mit Bezug auf Fig. 12 beschrieben wurde. In diesem Fall ist der Host 123 vorhanden und mit dem Port 30 verbunden, so daß er zum Debuggen und zum Übertragen von speziellen Ereignissen über den Port 30 wie bereits beschrieben vorgehen kann. Falls es jedoch notwendig ist, das Debuggen einer der CPUs 12 oder 13 so schnell wie möglich durchzuführen, wie zum Beispiel zum Debuggen von Real-Time- Code, kann dieses Beispiel dazu verwendet werden, das Debuggen einer der CPUs 12 oder 13 durch Verwendung der jeweils anderen der CPUs 12 oder 13 durchzuführen, anstatt durch den Host 123. Die Übertragung von Paketen über den chipinternen P-Link 15 kann schneller ausgeführt werden als die externe Kommunikation über den Port 30. In diesem Fall kann jede der CPUs 12 oder 13 Befehle ausführen, die spezielle Ereignisse zur anderen CPU auf dem selben Chip senden und dadurch Debugvorgänge durchführen, wie sie bereits mit Bezug auf die Verwendung des Host 123 beschrieben wurden, obwohl in diesem Fall die Steuerung durch eine der chipinternen CPUs vorgenommen wird, um einen Debugvorgang für die andere CPU auf dem selben Chip durchzuführen.
- Aus dem obigen Beispiel geht hervor, daß der externe Host 123 dazu verwendet werden kann, jede der chipinternen CPUs 12 oder 13 zu debuggen, ohne Einschränkungen in Bezug auf das Betriebssystem oder die Anwendungsprogramme jeder der chipinternen CPUs. Das Debuggen mit Überwachungspunkten kann ohne die Notwendigkeit durchgeführt werden lokalen Speicher der chipinternen CPUs zu verwenden. Jede der beiden chipinternen CPUs 11 und 12 und der extern verbundene Host 123 haben durch die Übertragung von Paketen über den Port 30 Zugriff auf den Zustand jedes anderen. Die chipinternen CPUs 12 und 13 können auf den externen Speicher 125 unabhängig von jedem Vorgang auf einer CPU im Host 123 zugreifen. Dies ermöglicht den chipinternen CPUs auf Code zuzugreifen, der auf einem extern verbundenen Mikrocomputer liegt.
- Der externe Host kann einen Computer oder eine Computervorrichtung, wie etwa ein programmierbares Logikgatter, umfassen. Legende zu den Figuren:
Claims (14)
1. Computersystem mit einem Mikroprozessor auf einem
integrierten Schaltungschip aufweisend eine
chipinterne CPU (12, 13) mit einer Mehrzahl von
Registern (41) und einem Kommunikationsbus (15),
wobei ein paralleler Übertragungspfad zwischen der
CPU und einem ersten Speicher (120) lokal bei der CPU
bereitgestellt wird, wobei das integrierte
Schaltungselement ferner einen externen Port (30) und
eine Logikschaltung (44) aufweist, wobei der externe
Port mit dem Bus auf dem integrierten Schaltungschip
und einer externen Computervorrichtung (123), welche
einen zweiten Speicher (125) aufweist, verbunden ist,
wobei die Logikschaltung (44) auf eine Mehrzahl von
Ereignissen von der externen Computervorrichtung
(123) über den Port (30) reagiert, welche ein
Unterbrechungsereignis zum Unterbrechen der
Ausführung von vom ersten Speicher (120) erhaltenen
Befehlen durch die CPU (12, 13), ein Set/Reset-
Handler-Ereignis, welches bewirkt, daß die CPU einen
Boot-Code vom zweiten Speicher (125) abruft, der von
der CPU auszuführen ist, und ein Run-Ereignis, um den
Betrieb der CPU unter Verwendung des Boot-Codes
wiederaufzunehmen, umfassen.
2. Computersystem nach Anspruch 1, bei welchem die CPU
(12, 13) mit einer Logikschaltung (44) ausgestattet
ist, welche betreibbar ist, um die Ausführung einer
Befehlssequenz durch die CPU zu unterbrechen, wobei
die Logikschaltung einen Adressenspeicher zum
Speichern einer Befehlspositionsadresse zur
Verwendung bei Wiederaufnahme der Ausführung eines
Befehls durch die CPU aufweist, wobei die
Logikschaltung mit dem Kommunikationsbus (15)
verbunden ist, wodurch die Logikschaltung ein
Signalpaket von der externen Computervorrichtung
(123) über den Port empfangen kann.
3. Computersystem nach Anspruch 2, bei welchem die CPU
(12, 13) eine Befehlszeigerschaltung zum Anzeigen
einer nächsten Abrufadresse bei Ausführung einer
Befehlssequenz aufweist und der Adressenspeicher der
Logikschaltung (44) betreibbar ist, um den Zeigerwert
der Befehlszeigerschaltung in Reaktion auf ein
Signalpaket von der externen Computervorrichtung
(123) zu verändern.
4. Computersystem nach einem der vorstehenden Ansprüche,
bei welcher der externe Port eine
Paketformatsumwandlungsschaltung (50, 56, 57, 58, 59)
zum Verändern von Bitpaketen von einem bitparallelen
chipinternen Format auf ein weniger parallels
externes Format.
5. Computersystem nach Anspruch 4, bei welchem das
externe Format bitseriell ist.
6. Computersystem nach einem der vorstehenden Ansprüche,
bei welchem die integrierte Einchip-Schaltung (11)
eine Mehrzahl von CPUs (12, 13) auf demselben Chip
jeweils mit dem Kommunikationsbus (15) und dem
externen Port (13) verbunden aufweist.
7. Computersystem nach Anspruch 6, bei welchem die
externe Computervorrichtung (123) betreibbar ist, um
die Ausführung durch eine CPU auf dem Chip zu
unterbrechen, während ein Boot-Code bereitgestellt
und eine andere CPU auf dem Chip erneut in Betrieb
gesetzt wird, wobei eine CPU durch Signalpakete
gebootet werden kann, welche über den externen Port
(30) eingegeben werden, während die oder jede andere
CPU auf dem Chip unterbrochen bleibt.
8. Verfahren zum Booten eines Computersystems, welches
einen Mikroprozessor auf einem integrierten
Schaltungschip (11) mit einer chipinternen CPU (12,
13), einer Mehrzahl von Registern (41) und einen
Kommunikationsbus (15) aufweist, wobei ein paralleler
Übertragungspfad zwischen der CPU und einem ersten
Speicher (120) lokal bei der CPU bereitgestellt wird,
wobei das integrierte Schaltungselement einen
externen Port (30) und eine Logikschaltung (44)
aufweist, die mit dem Bus und einer externen
Computervorrichtung (123) mit einem zweiten Speicher
(125) verbunden ist, wobei das Verfahren umfaßt:
Übertragen von einer Mehrzahl von Ereignissen von der
externen Vorrichtung (123) über den externen Port,
welche ein Unterbrechungsereignis zum Unterbrechen
der Ausführung von vom ersten Speicher (120)
erhaltenen Befehlen durch die CPU (12, 13), ein
Set/Reset-Handler-Ereignis, welches bewirkt, daß die
CPU einen Boot-Code vom zweiten Speicher (125)
abruft, der von der CPU auszuführen ist, und ein Run-
Ereignis, um den Betrieb der CPU unter Verwendung des
Boot-Codes wiederaufzunehmen, umfaßt.
9. Verfahren nach Anspruch 8, bei welchem in Reaktion
auf die Mehrzahl von Ereignissen über den externen
Port (30) von der externen Computervorrichtung (123)
die Logikschaltung, welche mit der chipinternen CPU
(12, 13) verbunden ist, für die CPU eine
Befehlspositionsadresse zur Verwendung bei
Wiederaufnahme der Ausführung von Befehlen durch die
CPU in einem Adressenspeicher speichert und bewirkt,
daß die CPU unter Verwendung des Boot-Codes die
Ausführung wiederaufnimmt.
10. Verfahren nach Anspruch 8 oder Anspruch 9, bei
welchem Übertragungen auf dem Kommunikationsbus (15)
in einem bitparalleln Format durchgeführt werden und
der externe Port Pakete in ein bitserielles Format
umwandelt.
11. Verfahren nach einem der Ansprüche 8 bis 10, bei
welchem die externe Computervorrichtung (123)
angeordnet ist, um über den externen Port (30) das
Unterbrechungsereignis zum Unterbrechen des Betriebes
der CPU und das Set/Reset-Handler-Ereignis zum
Übertragen eines Boot-Codes von dem zweiten Speicher
(125) über den externen Port zu dem ersten Speicher
(120) zu übertragen, um über den externen Port eine
Anzeige des Ortes des Boot-Codes im ersten Speicher
bereitzustellen und das Run-Ereignis zum
Wiederaufnehmen des Betriebes der CPU (12, 13) unter
Verwendung des Boot-Codes, zu übertragen.
12. Verfahren nach einem der Ansprüche 8 bis 10, bei
welchem die externe Computervorrichtung (123) über
den externen Port (30) das Unterbrechungsereignis
überträgt, um den Betrieb der chipinternen CPU zu
unterbrechen, über den externen Port eine Anzeige
einer Speicheradresse im zweiten Speicher (125)
bereitstellt, in welcher sich der Boot-Code befindet,
und über den externen Port das Run-Ereignis an die
chipinterne CPU überträgt, um die Ausführung unter
Verwendung des Boot-Codes, der in dem zweiten
Speicher (125) angeordnet ist, wiederaufzunehmen,
wobei die chipinterne CPU die Ausführung unter
Abrufen eines Boot-Codes von dem zweiten Speicher
(125) über den externen Port (30) wiederaufnimmt.
13. Verfahren nach einem der Ansprüche 8 bis 12, bei
welchem mehr als eine CPU (12, 13) auf dem Chip
vorgesehen sind, wobei die externe
Computervorrichtung (123) betreibbar ist, um die
Ausführung durch jede CPU auf dem Chip zu
unterbrechen, einen Boot-Code von dem zweiten
Speicher (125) bereitzustellen, der durch eine erste
CPU auf dem Chip auszuführen ist, ein Steuersignal
zur übertragen, um eine zweite CPU in einem
Unterbrechungszustand zu halten, und die Ausführung
der ersten CPU unter Verwendung des Boot-Codes
wiederaufzunehmen, während die zweite CPU
unterbrochen bleibt.
14. Verfahren nach Anspruch 13, bei welchem die erste CPU
verwendet wird, um einen Boot-Code für die zweite CPU
bereitzustellen und die Ausführung der zweiten CPU
wiederaufzunehmen, nachdem der Betrieb der ersten CPU
durch die externe Computervorrichtung (123)
wiederaufgenommen wurde.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GBGB9622684.0A GB9622684D0 (en) | 1996-10-31 | 1996-10-31 | An integrated circuit device and method of communication therwith |
GBGB9627080.6A GB9627080D0 (en) | 1996-10-31 | 1996-12-31 | Microcomputer |
Publications (2)
Publication Number | Publication Date |
---|---|
DE69715558D1 DE69715558D1 (de) | 2002-10-24 |
DE69715558T2 true DE69715558T2 (de) | 2003-05-22 |
Family
ID=26310313
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE1997615558 Expired - Fee Related DE69715558T2 (de) | 1996-10-31 | 1997-10-24 | Mikrorechner mit Urladungsystem |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP0840224B1 (de) |
JP (1) | JP4732554B2 (de) |
DE (1) | DE69715558T2 (de) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2003036251A (ja) * | 2001-07-23 | 2003-02-07 | Hitachi Ltd | 信号処理装置 |
CN114625639B (zh) * | 2022-03-03 | 2024-05-28 | 上海先楫半导体科技有限公司 | 一种基于片上系统的调试方法、系统以及芯片 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5435001A (en) * | 1993-07-06 | 1995-07-18 | Tandem Computers Incorporated | Method of state determination in lock-stepped processors |
EP0636976B1 (de) * | 1993-07-28 | 1998-12-30 | Koninklijke Philips Electronics N.V. | Mikrokontroller mit hardwaremässiger Fehlerbeseitigungsunterstützung nach dem Boundary-Scanverfahren |
EP0652516A1 (de) * | 1993-11-03 | 1995-05-10 | Advanced Micro Devices, Inc. | Integrierter Mikroprozessor |
JP2752592B2 (ja) * | 1994-12-28 | 1998-05-18 | 日本ヒューレット・パッカード株式会社 | マイクロプロセッサ、マイクロプロセッサ−デバッグツール間信号伝送方法及びトレース方法 |
US5704034A (en) * | 1995-08-30 | 1997-12-30 | Motorola, Inc. | Method and circuit for initializing a data processing system |
-
1997
- 1997-10-24 DE DE1997615558 patent/DE69715558T2/de not_active Expired - Fee Related
- 1997-10-24 EP EP19970308518 patent/EP0840224B1/de not_active Expired - Lifetime
- 1997-10-31 JP JP30117497A patent/JP4732554B2/ja not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
EP0840224B1 (de) | 2002-09-18 |
JP4732554B2 (ja) | 2011-07-27 |
JPH10240713A (ja) | 1998-09-11 |
EP0840224A1 (de) | 1998-05-06 |
DE69715558D1 (de) | 2002-10-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE69616462T2 (de) | Datenprozessor mit eingebauter Emulationsschaltung | |
DE69616917T2 (de) | Datenprozessor mit eingebauter Emulationsschaltung | |
DE69414985T2 (de) | Verzweigungsentscheidungskodierung | |
DE69616463T2 (de) | Datenprozessor mit eingebauter Emulationsschaltung | |
DE69616708T2 (de) | Datenprozessor mit eingebauter Emulationschaltung | |
DE69822221T2 (de) | Umleitung von interruptzielen unterstützende transaktionen sowie niveauabhängigeinterruptsemantik | |
DE69419525T2 (de) | Nachrichten-einrichtung für ein massiv paralleles verarbeitungsystem | |
DE69801220T2 (de) | Fehlersuchschnittstelle mit kompaktem ablaufdatenspeicher | |
DE3854361T2 (de) | Programmierbare Protokollvorrichtung. | |
DE3751514T2 (de) | Adressieranordnung für RAM-Puffer-Steuereinrichtung. | |
DE3751426T2 (de) | Busschnittstellenschaltung für digitalen Datenprozessor. | |
DE69708255T2 (de) | Diagnosesystem und Verfahren bei einer integrierten Schaltung | |
DE69331448T2 (de) | Dataprozessor mit einem Cachespeicher | |
DE69519926T2 (de) | Verfahren und vorrichtung zum einhalten der transaktionssteuerung und zur unterstützung von verzögerten antworten in einer busbrücke | |
DE69424114T2 (de) | Nachrichtenübertragungssystem für Multiprozessorsystem mit verteiltem gemeinsamen Speicher und dazu gehöriges Nachrichtenübertragungsverfahren | |
DE69622112T2 (de) | Auf-Chip-Schnittstelle zur Fehlerbeseitigung | |
DE69701141T2 (de) | Multithreaded mikroprozessor ausgestaltet zur ausführung von unterbrechungsverarbeitungsroutinen als threads | |
DE68927492T2 (de) | Verfahren und Vorrichtung zur gleichzeitigen Verteilung von Befehlen an mehrere funktionelle Einheiten | |
DE4208924A1 (de) | Verfahren zur kommunikation zwischen prozessoren und parallelverarbeitungscomputer hierfuer | |
DE102004004796B4 (de) | Vorrichtung zur Datenübertragung zwischen Speichern | |
DE69127992T2 (de) | Mikroprozessor zur Buszykluseinfügung zwecks Informationslieferung für eine Emulation | |
DE3852928T2 (de) | Datenprozessor mit A/D-Umsetzer, um mehrere analoge Eingabekanäle in Digitaldaten umzusetzen. | |
DE68926954T2 (de) | Schnittstelle zwischen einer Systemsteuereinheit und einer Dienst-Processoreinheit in einem Digitalrechner | |
DE69705813T2 (de) | Diagnosesystem und Verfahren bei einer integrierten Halbleiterschaltung | |
DE69817170T2 (de) | Emulation von unterbrechungsmechanismus in einem multiprozessorsystem |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8364 | No opposition during term of opposition | ||
8339 | Ceased/non-payment of the annual fee |