DE69027471T2

DE69027471T2 - Fehlersuchperipherie für Mikrorechner, Mikroprozessoren und Kernprozessor beinhaltende integrierte Schaltungen und Vorrichtung die diese Fehlersuchperipherie verwendet

Info

Publication number: DE69027471T2
Application number: DE69027471T
Authority: DE
Inventors: Nigel John Allison; Rand Lee Gray; Jay Alan Hartvigsen
Original assignee: Motorola Inc
Current assignee: Motorola Solutions Inc
Priority date: 1989-04-03
Filing date: 1990-03-23
Publication date: 1997-01-02
Anticipated expiration: 2010-03-24
Also published as: JPH02287635A; US5053949A; JP3105223B2; HK1000737A1; EP0391173A2; EP0391173A3; DE69027471D1; KR0168656B1; EP0391173B1; KR900016866A

Description

Gebiet der Erfindung

Die Erfindung betrifft Entwicklungssystem-Hilfsprogramme und insbesondere eine Standard-Fehlersuchperipherie zur Schaffung von Entwicklungssystemunterstützung

Hintergrund der Erfindung

Heutige Hochleitungsmikroprozessoren und Mikrocomputer stellen immer größer werdende Anforderungen an Entwicklungsystemhilfsprogramme, die zur Fehlersuche in diesen hochentwickelten integrierten Schaltungen verwendet werden. Außerdem erfordert die erhöhte Vielfalt von standardisierten und kundenspezifischen Mikrocomputer-(MCU-) eine fundamentale Änderung im Design von Entwicklungssystem-Hilfsprogrammen. Neue Mikroprozessoren (MPU), die entworfen sind, um bei hohen Taktgeschwindigkeiten oberhalb von 33 MHz betrieben zu werden, treiben die Entwicklungssystemtechnologie an ihre Grenzen. Mittlerweile stellen die weitverbreitete Verwendung von existierenden Zentralverarbeitungseinheits-(CPU-)Designs für den Prozessorkern in MCUs Beschränkungen des Designs der Entwicklungssystem-Hilfprogramme dar. Mit der Verkürzung des Designzyklus für diese standardisierten und kundenspezifischen Kern-MCUs wird eine gleichsame Verfügbarkeit von Entwicklungssystem-Hilfprogrammen ständig problematischer. Konsequenterweise ist das Problem derart, daß Hochleistungsentwicklungssystem-Hilfsprogramme zeitig zur Verfügung stehen, um die große Vielfalt an Mikroprozessoren und Mikrocomputern, die auf den Markt kommen, zu unterstützen.
Der herkömmliche Designansatz für Entwicklungssystemunterstützung vertraut auf eine In-Circuit-Emulation zur Fehlersuche (zum Debuggen) der MCU/MPU-Prototyp-Software/Hardware. Typischerweise erlaubt die In-Curcuit-Emulation dem Software- Designer, die Ausführung der Software durch Unterbrechen der Programmausführung zu verschiedenen Zeitpunkten und durch Untersuchen des Inhalts der internen Register, Speicherstellen, und dergleichen zu verfolgen. In einigen Designs arbeitet der In-Curcuit-Emulator in einem Vordergrund- und Hintergrundmodus, wodurch der Emulator das Anwendungsprogramm (Nicht- Emulation) in dem Vordergrundmodus und das Fehlersuchprogramm (Emulation) in dem Hintergrundmodus verarbeitet. Demgemäß schaltet der In-Curcuit-Emulator Bänke zwischen Vordergrundund Hintergrundspeicherplatz während der Ausführung und dem Debuggen des Benutzerprogramms, weshalb die MCU in einem erweiterten Modus arbeiten muß, der die Rekonstruktion der I/O- Ports zu der externen Bus-Schnittstelle, die verloren worden sind, ermöglicht. Im allgemeinen erfordert das Vor- und Zurückschalten zwischen den Vordergrund- (Benutzer-) und Hintergrund- (Fehlersuch-) Speicherbänken ein substantielles Ausmaß an externer Pufferschaltung, um dem Betrieb der MCU in einem erweiterten Modus zu ermöglichen. Oftmals degradiert diese zusätzliche Pufferschaltung die Performance des Emulators und verhindert somit eine Echtzeitschaltungsemulation. Da die Implementierung des Vordergrund/Hintergrund- Speicherbankschalters ein wesentliches Ausmaß an externer Schaltung erfordert, wird eine Emulatorprüfeinrichtung anstelle einer kleinen Nebenplatinenprüfeinrichtung verwendet. Das Design der resultierenden Emulatorprüfeinrichtung ist zeitaufwendig und kostenaufwendig aufgrund der erforderlichen Entwicklungssystem-Entwicklungsausgaben.
Die europäische Patentanmeldung EP-A-0191632 lehrt die Verwendung von einem ROM-Emulator zum diagnoseförmigen Prüfen eines auf einem Mikroprozessor basierenden Systems. Der ROM- Emulator erzielt eine Steuerung des Mikroprozessors in dem zu testenden Gerät (DUT) und veranlaßt dann, daß der Mikroprozessor eine Reihe von Diagnosetests ablaufen läßt, die durch einen externen Computer (d.h. ein Entwicklungssystem) gesteuert werden. Im Benutzermodus liefert ein ROM Betriebsbefehle an den Mikroprozessor. Im Fehlersuchmodus liefert der ROM- Emulator die Betriebsbefehle an den Mikroprozessor. Somit setzt die in dieser europäischen Patentanmeldung beschriebene Anordnung im wesentlichen den ROM in dem DUT außer Kraft und setzt einen ROM-Emulator, der über ein Bandkabel durch einen parallelen I/O-Port mit dem DUT verbunden ist, ein. Der ROM- Emulator dieser Anwendung illustriert die oben beschriebenen Probleme; das Vorwärts- und Rückwärtsschalten zwischen der Vordergrund- (Benutzer-)Speicherbank und der Hintergrund (Fehlersuch-)Speicherbank erfordert ein wesentliches Ausmaß an externer Pufferschaltung, um den Betrieb des DUT in einem erweiterten Modus zu ermöglichen.
In Systemen gemäß dem Stand der Technik haben Designer Port- Ersetzungseinrichtungen oder Entkontaktierungseinrichtungen (bond out devices) beim Versuch eingesetzt, das Ausmaß an erforderlicher externer Schaltung zu verringern. Der primäre Nachteil bei Verwendung einer Port-Ersetzungs- oder Entkontaktiereinrichtung ist das Erfordernis nach zusätzlichen Design- und nach Wartungsressourcen. Im wesentlichen muß der Systemdesigner Designressourcen für die Port-Ersetzungs- oder Entkontaktierungseinrichtung, zusätzlich zu den Ressourcen, die für das MCU/MPU-Design erforderlich sind, zur Verfügung stellen. Noch ein weiterer Ansatz, der in der EP-A-0313848 von Motorola, Inc. offenbart ist, ist es, einen Background- Modus in den CPU-Kern zu integrieren. Diese Lösung ist in einigen Fällen optimal, aber sie ist oft unpraktisch, um andere als kleinere Modifikationen an existierenden CPU-Kernen durchzuführen.

Zusammenfassung der Erfindung

Eine Aufgabe der vorliegenden Erfindung ist es, die Möglichkeit einer Hintergrundmodusverarbeitung in einem existierenden CPU-Kern ohne Modifikation des Kerndesigns zu schaffen.
Eine andere Aufgabe der vorliegenden Erfindung ist es, Realzeit-In-Curcuit-Emulatoren für MCUs oder MPUs beliebig hoher Taktgeschwindigkeiten zu schaffen.
Eine weitere Aufgabe der vorliegenden Erfindung ist es, ein Verfahren zur wesentlichen Verringerung der Designzykluszeit für Entwicklungssystem-Hilfsprogramme zu schaffen.
Gemäß der vorliegenden Erfindung wird geschaffen eine Fehlersuchperipherie für ein Datenverarbeitungssystem, wobei das Datenverarbeitungssystem an eine externe Quelle gekoppelt ist und einen Datenprozessor zum Ausführen einer ersten Befehlssequenz, die von einem Befehlsspeicher über einen internen Kommunikationsbus empfangen wird, und zum Ausführen einer Sequenz von Fehlersuchbefehlen, die von der Fehlersuchperiphene über den internen Kommunikationsbus empfangen wird, hat, wobei die Fehlersuchperipherie aufweist:
eine Mehrzahl von externen Anschlüssen;
eine Steuereinrichtung, die an wenigstens eine der Mehrzahl der externen Anschlüsse gekoppelt ist, um ein Fehlersuchstartsignal von der externen Quelle zu empfangen, und um eine Steuerung des Prozessors durch Liefern eines Fehlersuch- Interrupt-Signals an den Prozessor als Antwort auf das Fehlersuchstartsignal zu übernehmen;
eine Registereinrichtung, die an den internen Kommunikationsbus gekoppelt ist, um Informationen zu speichern, die von dem Prozessor empfangen wird, und um die alternierende Befehlssequenz zu speichern, die von der externen Quelle empfangen wird, wobei die Registereinrichtung aufweist:
ein serielles Interface, das an die externe Quelle über wenigstens einen der Mehrzahl der externen Anschlüsse gekoppelt ist, um die extern zur Verfügung gestellten Fehlersuchbefehle zu empfangen und um gleichzeitig in einem Fehlersuchmodus über die Steuereinrichtung Daten, die von dem Prozessor empfangen wurden, an die externe Quelle zu liefern,
ein paralleles Interface, das über den internen Kommunikationsbus an den Prozessor gekoppelt ist, um die extern gelieferten Fehlersuchbefehle an den Prozessor zu liefern und um in dem Fehlersuchmodus Daten von dem Prozessor zu empfangen; und
eine Adreß-Decodereinrichtung, die an die Registereinrichtung gekoppelt ist, um die Registereinrichtung als Antwort auf eine alternierende Sequenz von Befehlsadressen, die von dem Prozessor über das parallele Interface empfangen wird, freizugeben, wobei die alternierende Sequenz von Befehlsadressen in ihrer Anzahl einer vorbestimmten Anzahl von Speicheradressen, die für die Fehlersuchperipherie vorgesehen sind, entspricht.
Ein Datenverarbeitungssystem, das eine Fehersuchperipherie gemäß der Erfindung aufweist, ist auch offenbart und in Anspruch 2 der beigefügten Ansprüche beansprucht.
Kurze Beschreibung der Zeichnungen
Fig. 1 ist ein Blockdiagramm, das eine bevorzugte Ausführungsform eines Datenverarbeitungssystems mit Kernprozessor beinhaltender integrierter Schaltung darstellt.
Fig. 2 ist ein Blockdiagramm, das eine bevorzugte Ausführungsform der internen Architektur der Fehlersuchperipherie darstellt.

Beschreibung der Erfindung

Die Begriffe "Behaupten", "Behauptung", "Negieren" und "Negierung" werden verwendet, um eine Unklarheit bei Behandlung einer Mischung von "positiv logischen" und "negativ logischen" Signalen zu vermeiden. "Behaupten" und "Behauptung" werden verwendet, um anzuzeigen, daß ein Signal aktiv oder logisch wahr gemacht wird. "Negieren" und "Negierung" werden verwendet, um anzuzeigen, daß ein Signal unaktiv oder logisch falsch gemacht wird.
In Fig. 1 ist ein Blockdiagramm eines Datenverarbeitungssystems mit Kernprozessor beinhaltender integrierter Schaltung 10 gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung gezeigt. Das Datenverarbeitungssystem 10 umfaßt im allgemeinen eine Zentralverarbeitungseinheit (CPU) 12, einen Speicher 14 und eine Fehlersuchperipherie 16. Ein CPU- interner Bus 18 ermöglicht die Kommunikation zwischen der CPU 12 und der Fehlersuchperipherie 16 und dem Speicher 14. Ein Entwicklungssystem 20 arbeitet mit dem Datenverarbeitungssystern zusammen, um beim "Debuggen" von Software und Hardware des Datenverarbeitungssystems 10 zu assistieren. Die externe Emulatorschaltung des Entwicklungssystems 20 ermöglicht es dem Verwender, verschiedene Funktionen durchzuführen, wie beispielsweise das Setzen von und Antworten auf bedingte Programmstopps, das Anhalten von Programmausführung der CPU 12, um den Inhalt verschiedener interner Register zu untersuchen und zu ändern, und die Softwareausführung zu verfolgen.
In einer bevorzugten Ausführungsform arbeitet das Verarbeitungssystem 10 in zwei Modi, einem Benutzermodus und einem Fehlersuchmodus (Debug-Modus). In dem Benutzermodus arbeitet das Datenverarbeitungssystem 10 auf konventionelle Art und Weise. Die CPU 12 ruft einen Befehl von dem Speicher 14 ab, decodiert den Befehl, führt den Befehl aus, und ruft den nächsten Befehl in der Sequenz zur Ausführung ab. Typischerweise läuft die Ausführung des Programms auf sequentielle Art und Weise weiter bis die CPU 12 einen bedingten Befehl oder eine Unterbrechung (interrupt) empfägt. Die Art und Weise, mit welcher die CPU 12 eine Unterbrechung behandelt, ist eine Funktion des Prozessordesigns. Im allgemeinen bewirkt das Auftreten einer Unterbrechung, daß die CPU 12 ihren normalen Betrieb aussetzt und beginnt eine Ausnahmeverarbeitung oder eine Unterbrechungsserviceroutine auszuführen. In der vorliegenden Erfindung tritt die CPU 12 als Antwort auf eine Unterbrechungsanfrage, die als Ergebnis eines internen Ereigniserkenners oder von einer externen Quelle, wie beispielsweise dem Entwicklungssystem 20, resultieren kann, in den Debug(Emulations-)Modus ein. Während der Emulation (Debug-Modus) ruft die CPU 12 Befehle von der Debug-Periphene 16 anstatt von dem Speicher 14 ab. Demgemäß setzt die CPU 12 die Ausführung des Benutzer-(Anwendungs-)Programms, das in dem Speicher 14 gespeichert ist, aus, und beginnt die Ausführung von Befehlen, die von der Debug-Periphene 16 erhalten werden. Im wesentlichen funktioniert die Debug-Periphene 16 als ein alternativer Speicher in dem Datenverarbeitungssystem 10.
In Fig. 2 ist ein Blockdiagramm gezeigt, das eine bevorzugte Ausführungsform der internen Architektur der Debug-Periphene 16 zeigt. Die Debug-Periphene 16 ist ein Einzelwort-Dualport-Speicher mit parallelem Lese-Schreib-Zugriff auf einer Seite und synchronem, seriellem Duplex-Lese-Schreib-Zugriff auf der anderen Seite. In der bevorzugten Ausführungsform umfaßt die Debug-Periphene 16 ein Schieberegister 22, einen Adreß-Decodierer 24 und einen Controller 26. Die serielle Seite der Debug-Periphene 16 ist mit dem Entwicklungssystem 20 über einen seriellen Eingabeblock (SI) 28, einem seriellen Takt/Programmstopp-Eingabeblock (SCLK/BRK*) 30 une einem seriellen Ausgabe/Abruf-Block (SO/ATTN*) 32, der entsprechende Signale SERIAL IN, SCLK/BRK*, und SERIAL OUT/ATTN* liefert, verbunden. Demgemäß steuern die SERIAL IN, SCLK/BRK* und SERIAL OUT/ATTN* Signale den seriellen Datentransfer zwischen der Debug-Periphene 16 und dem Entwicklungssystem 20. Ein Parallelzugriff auf die Debug-Periphene 16 wird durch die Verbindung des Befehls/Datenbus 34 zu dem CPU-internen Bus 18 geschaffen, und auf die Debug-Periphene 16 wird im wesentlichen auf dieselbe Art und Weise wie auf jede andere Peripherie auf einen Chip zugegriffen. Da die Befehle mehrere Wortlängen sein können, ist die Debug-Periphene 16 an 16 benachbarten Stellen in dem Speicherplatz der CPU 12 adressiert. Aus Gründen der Einfachheit wird die Anfangsadresse der Debug-Peripherie 16 im folgenden als DEBUG bezeichnet und somit sind die Adressen, bei denen die CPU 12 auf die Debug-Penphene 16 zugreifen kann, DEBUG bis DEBUG+$F.
Das Datenverarbeitungssystem 10 tritt bei Auftreten einer Programmstopp-Bedingung, die zu einer Unterbrechung der CPU 12 führt, in den Debug-Modus ein. Der Programmstopp kann extern das Ergebnis der Behauptung des BRK-Signals (durch das Entwicklungssystem 20) oder das Ergebnis eines internen Ereigniserkenners, der aus einem Register und einem Komparator (nicht gezeigt) besteht, sein. In dem Fall, in dem die Unterbrechung durch ein externes BRK-Signal bewirkt wird, antwortet der Controller 26 durch Behauptung eines Debug- Unterbrechung-Anforderungs-(DEBUG IRQ*-)Signals an die CPU 12. Der Controller 26 setzt das DEBUG IRQ*-Signal auf den CPU-internen Bus 18, was bewirkt, daß die CPU 12 durch Behaupten einer Debug-Unterbrechungsbestätigungssignals (DEBUG IACK*) anwortet, und beginnt die Ausführung einer Debug- Unterbrechungsserviceroutine. Die CPU 12 adressiert automatisch (autovector) die Debug-Periphene 16 auf die Adresse DEBUG durch Plazieren der DEBUG-Adresse auf den CPU-internen Bus 18. Als Antwort auf den Empfang der DEBUG-Adresse startet der Adreß-Decoder 24 das Schieberegister 22 über ein SELECT- Eingabesignal.
Die CPU 12 startet einen Befehlsabruf zyklus von der Debug- Peripherie 16 bei der Adresse DEBUG. Wenn der Befehlszyklus beginnt, antwortet das Schieberegister 22 durch Behaupten eines seriellen Ausgabesignals (SO). Der Controller 26, der mit dem Schieberegister 22 gekoppelt ist, empfängt das SO-Signal und behauptet das ATTN*-Signal, wodurch angezeigt wird, daß die Peripherie einen Abruf erfordert, und das Entwicklungssystem 20 von dem Beginn des Debug-Instruktionszyklus benachrichtigt wird. Im wesentlichen wird der Start des Instruktionsabrufzyklus extern durch Steuern des SO-Anschlusses von seinem ruhigen Hochpegel auf einen Tiefpegel extern reflektiert. Das Entwicklungssystem 20 antwortet durch Schreiben eines Befehls von dem Befehlssatz der CPU 12 in das Schieberegister 22 über den SI-Eingang 28. Der Controller 26 empfängt das SCLK-Signal von dem Entwicklungssystem 20 und liefert das SCLK-Signal an das Schieberegister 22. Konsequenterweise wird der von dem Entwicklungssystem 20 gelieferte Befehl mit dem SCLK-Signal in das Schieberegister 22 über den SI-Eingabeblock 28 getaktet. Wenn die Daten in das Schieberegister 22 geschrieben werden, kann jeglicher vorherige Schreibzugriff, den die CPU 12 auf die Debug-Periphene 16 gemacht hat, simultan über den SO-Ausgabeblock 32 zum Entwicklungssystem 20 ausgelagert werden. Konsequenterweise wird die CPU 12, wenn die CPU 12 einen Schreibzugriff auf die Debug-Peripherie 16 durchführt, bevor der derzeitige Befehl oder die Daten, welche in der Debug-Periphene 16 resident sind, angefordert werden, das derzeitige Wort in der Debug- Peripherie 16 für ungültig erklären. In dem Fall, daß dies auftritt, wird die Debug-Periphene 16 das Entwicklungssystem 20 über ein Status-Bit in dem seriellen Ausgabestrom in Kenntnis setzen, um das Wort neu zu laden.
Wenn der Befehl vollständig in dem Schieberegister 22 (ohne Fehler) zusammengesetzt ist, wird der derzeitige Befehl auf den Befehls/Datenbus 34 über den parallelen I/O-Port gesetzt. Der Controller 26 behauptet dann ein READY-Signal, wodurch die CPU 12 in Kenntnis gesetzt wird, daß der Befehl übertragen werden kann. Die CPU 12 überträgt den Befehl von dem Instruktions/Datenbus 34 und vervollständigt den Befehisabrufzyklus. Die CPU 12 fährt mit der Ausführung des Befehls fort. Um die Programmausführung innerhalb des 16-Byte-DEBUG- Adreßraums zu halten, sind die nachfolgenden Befehle, die durch die CPU 12 abgerufen werden, entweder Sprung- oder Verzweigungsbefehle zurück zu DEBUG. Das Design des Adreßschemas ist derart, daß jede der 16 benachbarten Adressen die CPU 12 zu dem Schieberegister 22 der DEBUG-Periphene 16 zurückverweist. Somit fährt die CPU 12 fort, Befehle von der DEBUG Peripherie 16 an den bezeichneten Adressen DEBUG bis $F abzurufen, bis das Debug-Vorprogramm abgeschlossen ist und der Benutzer wünscht, mit der Ausführung des Anwendungscodes fortzufahren. Konsequenterweise ist der Betriebsrnodus, normal oder debug, für die CPU 12 transparent, da in jedem Betriebsmodus (normal oder debug) die CPU 12 denselben Befehlssatz ausführt. Im wesentlichen kann die CPU 12 den Unterschied zwischen dem Befehlstyp in jedem der Betriebsmodi nicht unterscheiden. Auf Beendigung des Debug-Vorprogramms hin ist der letzte Befehl, der über den SI-Eingabeblock 28 in die Debug-Peripherie 16 geschrieben wird, ein Rücksprung von der Unterbrechung. Die Befehle, die während der Dauer des Debug- Vorprogramms ausgeführt werden, werden verwendet, um interne Register, Speicher zu lesen und zu schreiben, oder für irgendwelche anderen Operationen, die mit dem Debuggen des Systems zusammenhängen. Demgemäß kann das Entwicklugssystem 20 die herkömmlichen In-Curcuit-Emulationsbasiseinheiten implementieren, einschließlich dem Einsetzen von und der Antwort auf Programmstopps, dem Halten der Auführung des Datenprozessors, um den Inhalt von Systemregistern zu untersuchen, und dem Verfolgen der Software-Ausführung.
Das serielle Protokoll für die Debug-Periphene 16 unterstützt eine einfache Fehlererkennung durch Verwendung von Start-, Stopp- und Paritäts-Bits. Das Protokoll erfordert N+7 Bits pro Transfer, weshalb der serielle Takt von dem Entwicklungssystem 20 gezählt wird, um die N+7 Takte, die erforderlich sind, um den Transfer zu vervollständigen, zu schaffen. Die folgende Tabelle stellt die Funktion eines jeden Bits in dem seriellen Ein- und Ausgabe-Bitstrom dar. TABELLE 1 SERIELLES PROTOKOLL
Die Debug-Periphene 16 vermeidet das Erfordernis eines großen Ausmaßes an komplexer externer Emulatorschaltung, weshalb die Größe der Emulationsprüfeinrichtung in ihrer Größe wesentlich verringert ist. Die Prüfeinrichtung kann eine Nebenplatine in der Schaltungsplatine des Benutzers sein, die direkt in die MCU/MPU gesteckt oder an dieselbe angeklemmt wird. Beispielsweise wird eine typische Emulationssonde mit den Dimensionen 9 x 12 x 2 Inch durch Verwendung der Debug-Periphene 16 auf 3 x 4 x 1 Inch (oder weniger) verringert. Die Vermeidung des Emulatorkabels, das im allgemeinen bei herkömmlichen In-Curcuit-Emulatoren erforderlich ist, mindert das Erfordernis, den Prozessor vollständig zu puffern. Die Verringerung des Ausmaßes an Pufferschaltung ermöglicht eine Realzeitemulation mit Hochgeschwindigkeits-MPU/MCU- Chips ohne signifikante Zeitablaufverschlechterung.
Die Debug-Periphene 16 schafft einen Ladepfad zu dem Speicher 14 (RAN) auf dem Chip, wodurch das Erfordernis nach einem Urlader-ROM vermieden wird. Wenn das BRK*-Eingabesignal auf die Negierung des RESET-Signals (nicht gezeigt) der CPU 12 hin behauptet wird, fordert die CPU 12 ihren ersten Befehl von der Debug-Periphene 16 an. Dieses Merkmal ermöglicht, daß das Entwicklungssystem 20 ein beliebiges Programm in den Speicher 14 auf dem Chip über das Schieberegister 22 der Debug-Periphene 16 schreibt. Wenn das Programm einmal geladen ist, kann die Debug-Periphene 16 die Steuerung an das Programm weitergeben.
Die Debug-Periphene 16 erweitert die Prüfbarkeit der MCU/MPU im Test auf eine Vielzahl von Arten. Beispielsweise kann der Inhalt eines maskierten ROMs durch das serielle Interface verifiziert werden ohne in irgendeinen speziellen Testmodus einzutreten. Außerdem können Prozessorregister, ein RAM auf dein Chip und andere Peripherien auf dem Chip getestet werden, ohne das Erfordernis, in einen speziellen Testmodus einzutreten. Demgemäß schafft die Debug-Periphene 16 ein flexibles effizientes Standarddesign, das bei minimalen Kosten leicht von einer integrierten Schaltung zu einer anderen portiert werden kann.
Während die Erfindung in einer bevorzugten Ausführungsform beschrieben worden ist, ist es für den Fachmann klar, daß die offenbarte Erfindung auf vielzahlige Weisen modifiziert werden kann und viele Ausführungsformen, die anders als die speziell dargelegte und oben beschriebene sind, annehmen kann. Beispielsweise kann die CPU 12 den Unterbrechungsvektor direkt von der Debug- Peripherie 16 erhalten, im Gegensatz zu der bevorzugten Ausführungsform, in welcher das Unterbrechungssignal bewirkt, daß die CPU 12 die Adresse (DEBUG) der Debug-Periphene 16 automatisch adressiert. Demgemäß ist beabsichtigt, durch die beigefügten Ansprüche alle Modifikationen der Erfindung, die in den Umfang der Erfindung fallen, abzudecken.

Claims

1. Eine Fehlersuchperipherie für ein Datenverarbeitungssystem (10), wobei das Datenverarbeitungssystem an eine externe Quelle (20) gekoppelt ist und einen Datenprozessor (12) zum Ausführen einer ersten Befehlssequenz, die von einem Befehlsspeicher (14) über einen internen Kommunikationsbus (18) empfangen wird, und zum Ausführen einer Sequenz von Fehlersuchbefehlen, die von der Fehlersuchperipherie (16) über den internen Kommunikationsbus (18) empfangen wird, hat, wobei die Fehlersuchperipherie aufweist:

eine Mehrzahl von externen Anschlüssen (30, 32);

eine Steuereinrichtung (26) , die an wenigstens eine der Mehrzahl der externen Anschlüsse (30, 32) gekoppelt ist, um ein Fehlersuchstartsignal von der externen Quelle (20) zu empfangen, und um eine Steuerung des Prozessors (12) durch Liefern eines Fehlersuch-Interrupt-Signals an den Prozessor (12) als Antwort auf das Fehlersuchstartsignal zu übernehmen;

eine Registereinrichtung (22, 28, 34), die an den internen Kommunikationsbus (18) gekoppelt ist, um Informationen zu speichern, die von dem Prozessor empfangen wird, und um die alternierende Befehlssequenz zu speichern, die von der externen Quelle empfangen wird, wobei die Registereinrichtung aufweist:

ein serielles Interface (28) , das an die externe Quelle (20) über wenigstens einen der Mehrzahl der externen Anschlüsse (30, 32) gekoppelt ist, um die extern zur Verfügung gestellten Fehlersuchbefehle zu empfangen und um gleichzeitig in einem Fehlersuchmodus über die Steuereinrichtung (26) Daten, die von dem Prozessor (12) empfangen wurden, an die externe Quelle (20) zu liefern,

ein paralleles Interface (34), das über den internen Kommunikationsbus (18) an den Prozessor (12) gekoppelt ist, um die extern gelieferten Fehlersuchbefehle an den Prozessor (12) zu liefern und um in dem Fehlersuchmodus Daten von dem Prozessor (12) zu empfangen; und

eine Adress-Decodereinrichtung (24) , die an die Registereinrichtung (22, 28, 34) gekoppelt ist, um die Registereinrichtung (22, 28, 34) als Antwort auf eine alternierende Sequenz von Befehlsadressen, die von dem Prozessor (12) über das parallele Interface (34) empfangen wird, freizugeben, wobei die alternierende Sequenz von Befehlsadressen in ihrer Anzahl einer vorbestimmten Anzahl von Speicheradressen, die für die Fehlersuchperipherie vorgesehen sind, entspricht.

2. Ein Datenverarbeitungssystem (10) , das an eine externe Quelle (20) gekoppelt ist, wobei das Datenverarbeitungssystem (10) aufweist:

einen Prozessor (12) zum Ausführen einer ersten Befehlssequenz, die von dem Prozessor (12) als Antwort auf eine erste Sequenz von Befehlsadressen empfangen wird, und zum Ausführen einer alternierenden Sequenz von extern zur Verfügung gestellten Befehlen, die durch den Prozessor (12) als Antwort auf eine alternierende Sequenz von Befehlsadressen empfangen wird;

einen internen Prozessorkommunikationsbus (18) , der an den Prozessor (12) gekoppelt ist;

einen Speicher (14) , der an den internen Prozessorkommunikationsbus (18) gekoppelt ist, zur Speicherung einer Mehrzahl von Befehlen und um die erste Befehlssequenz an den Prozessor (12) als Antwort auf die erste Sequenz der Befehlsadressen, die von dem Prozessor (12) empfangen wird, zu liefern; und

eine Fehlersuchperipherie (16) , die an den internen Prozessorkommunikationsbus (18) gekoppelt ist, um die Steuerung des Prozessors (12) als Antwort auf ein Fehlersuchstartsignal, das von einer externen Quelle (20) geliefert wird, zu übernehmen, wobei die Fehlersuchperipherie (16) die alternierende Sequenz von extern zur Verfügung gestellten Befehlen von der externen Quelle (20) empfängt, und um die alternierende Sequenz von extern zur Verfügung gestellten Befehlen an den Prozessor (12) als Antwort auf die alternierende Sequenz von Befehlsadressen zu liefern, wobei die Fehlersuchperipherie (16) weiter Daten speichert, die von dem Prozessor (12) empfangen werden, und Daten an die externe Quelle (20) liefert, wobei die Fehlersuchperipherie (16) aufweist:

eine Mehrzahl von externen Anschlüssen (30, 32)

eine Steuereinrichtung (26) , die an wenigstens eine der Mehrzahl der externen Anschlüsse (30, 32) gekoppelt ist, um die Steuerung des Prozessors (12) durch Liefern eines Fehlersuch- Interrupt-Signals an den Prozessor (12) als Antwort auf das Fehlersuchstartsignal zu übernehmen;

eine Registereinrichtung (22, 28, 34), die an den internen Prozessorkommunikationsbus (18) und die Steuereinrichtung (26) gekoppelt ist, um Information, die von dem Prozessor empfangen wird, zu speichern und die alternierende Sequenz von Befehlen, die von der externen Quelle empfangen wird, zu speichern, wobei die Registereinrichtung aufweist:

ein serielles Interface (28) , das an die externe Quelle (20) gekoppelt ist, um die alternierende Sequenz von extern zur verfügung gestellten Befehlen zu empfangen und um die von dem Prozessor (12) empfangenen Daten an die Steuereinrichtung (26) im Fehlersuchmodus zu liefern;

ein paralleles Interface (34) , das an den Prozessor (12) über den internen Kommuniktionsbus (18) gekoppelt ist, um die alternierende Sequenz der extern zur Verfügung gestellten Befehle an den Prozessor (12) zu liefern und um Daten von dem Prozessor im Fehlersuchmodus zu empfangen; und

eine Adress-Decodereinrichtung (24), die an den internen Prozessorkommunikationsbus (18) gekoppelt ist, um die Registereinrichtung (22, 28, 34) als Antwort auf die alternierende Sequenz von Befehlsadressen, die von dem Prozessor (12) empfangen wird, freizugeben, wobei die alternierende Sequenz von Befehisadressen in ihrer Anzahl einer vorbestimmten Anzahl an Speicheradressen, die für die Fehlersuchperipherie vorgesehen sind, entspricht.