DE4142161C2 - Busemulationsvorrichtung - Google Patents

Description

Die Erfindung betrifft eine Busemulationsvorrichtung nach dem Oberbegriff des An­ spruchs 1. Eine solche Vorrichtung dient zur Entwicklung von kundenspezifischen eigenständigen Mikroprozessor- und Mikrocontrollersteuerungen ("Embedded Sy­ stems"), bei denen ein Zielsystem (Zielrechner) mit Hilfe eines Entwicklungssystems (Entwicklungsrechner) programmiert und getestet werden soll.

Bei der Entwicklung derartiger Steuerungen soll zunächst eine für die spezielle An­ wendung entworfene Hardware in Betrieb genommen werden, auf diese Hardware ein Anwendungsprogramm geladen und darauf zur einwandfreien Funktion gebracht werden. Danach sollen die üblichen Hard- und Softwaretests am Zielsystem vorge­ nommen werden. Hierfür werden beispielsweise sogenannte In-Circuit-Emulatoren eingesetzt. Dabei wird die CPU (central processing unit = Zentraleinheit) des Ziel­ systems durch einen Emulator ersetzt, welcher mit einem Entwicklungsrechner kom­ muniziert. Der Entwicklungsrechner dient zum Erstellen des Programms, zu dessen Übersetzen und Binden und fungiert als Terminal. Der Emulator weist selbst eine CPU auf, welche identisch mit der zu emulierenden CPU sein kann, zumindest aber dieselbe Architektur und denselben Befehlssatz aufweisen muß. Da in der Entwick­ lungsphase die Busse, der Speicher und die Peripherie des Zielsystems noch fehlerhaft sein können, die Arbeit des Systems aber dennoch gewährleistet sein soll, werden die Busse des Emulators (Daten-, Adreß- und Steuerbus) in kritischen Bereichen vom Zielsystem über Puffer isoliert.

Ein Nachteil dieser In-Circuit-Emulatoren ergibt sich aus den durch diese Puffer ent­ stehenden Signallaufzeiten, welche das Zeitverhalten des Systems verfälschen. Ein weiterer Nachteil ist die aufwendige Steckverbindung; bei modernen CPUs müssen über hundert Kontaktstifte zuverlässig kontaktiert werden, was insbesondere in der SMD-Technik (Surface Mounted Devices) ein großes Problem darstellt. Weiterhin wird für jede Ausführungsform der CPU ein eigener Emulator oder zumindest ein eigener teurer Adapter benötigt. Die Kosten für ein Emulationssystem für mehrere Prozessoren liegen im Bereich von einigen 10.000 DM. Ein gewichtiger Nachteil er­ gibt sich schließlich daraus, daß das Zielsystem nicht vollständig zugänglich ist und damit nicht vollständig getestet werden kann. Beispielsweise wird ein Interrupt­ vektor für den Emulator benötigt, der dann im Zielsystem nicht mehr verwendet werden kann. Außerdem muß für die Kommunikation mit dem Monitor eine serielle Schnittstelle des Zielsystems verwendet werden, welche dann im Zielsystem ebenfalls nicht mehr zur Verfügung steht. Schließlich ist bei den In-Circuit-Emulatoren von Nachteil, daß zu ihrem Einsatz die bereits verlötete CPU wieder herausgenommen werden muß, was bei über hundert Kontaktstiften sehr aufwendig und zeitraubend ist und oft sogar zur Zerstörung des Bauteils führt.

Zur Kommunikation zwischen verschiedenen Zentraleinheiten sind weiterhin soge­ nannte Multiprozessorbusse, beispielsweise der VME-Bus, bekannt. Die verschiede­ nen Prozessoren, welche völlig verschiedene Kerne und Befehlssätze haben können, werden dabei über spezielle Schnittstellen und lokale Programme mit dem prozes­ sorunabhängigen VME-Bus verbunden und können so miteinander und mit Peri­ pherieeinheiten, wie Ein- und Ausgabegeräten, kommunizieren.

Der VME-Bus kann jedoch nicht dazu benutzt werden, ein Zielsystem mit Hilfe eines Entwicklungssystems zu programmieren und zu testen, da zur Verbindung der lokalen Busse mit dem VME-Bus immer eine spezielle Schnittstelle und/oder ein lokales Programm eingesetzt werden muß. Eine unmittelbare Beeinflussung des lo­ kalen Busses des Zielsystems durch das Entwicklungssystem ist damit nicht möglich.

Die US 4,868,822 beschreibt einen Emulator zum Testen eines einen Mikroprozessor und einen Speicher umfassenden Zielsystems, wobei dieser Emulator über ein Ka­ bel mit dem Steckplatz des Zielsystemsspeichers verbunden wird. Hierbei kann der Speicher aus dem Zielsystem entfernt oder darin belassen werden. Diese Vorrichtung weist verschiedene Nachteile auf. Zum einen ist eine Anpassung des Emulators erfor­ derlich, insbesondere der Logikschaltung und des Emulations-RAMS. Dies hat zur Folge, daß für verschiedene Zielsysteme ein Hardwarewechsel im Emulator notwen­ dig ist. Ein weiterer Nachteil besteht darin, daß der Emulator einen eigenen Mikro­ prozessor aufweisen muß sowie das hierfür erforderliche, die Programme für diesen Mikroprozessor enthaltene POD-RAM. Hierdurch wird der Emulator sehr teuer und unflexibel. Außerdem ist das Emulations-RAM notwendig ein sogenanntes Dual- Port-RAM, weil zwei Prozessoren über zwei Busse hierauf zugreifen müssen. Ein solches Dual-Port-RAM ist jedoch, verglichen mit gewöhnlichen RAMs erheblich teuerer. Schließlich ist kein direkter Zugriff der Entwicklungshilfe auf den Bus des Zielsystems möglich, sondern nur ein Zugriff auf den dazwischen geschalteten Emula­ tionsspeicher. Ist der Zielsystembus so stark gestört oder ist der Zielsystemprozessor fehlerhaft, ist ein Testen des Zielsystems nicht möglich, weil der Emulationsspei­ cher nicht auf das Zielsystem zugreifen kann und der Prozessor des Zielsystems bei gestörtem Bus nicht ausführen kann. Außerdem muß der Mikroprozessor des Ziel­ systems immer vorhanden sein, weil kein Entwicklungsrechner unmittelbar auf den Zielsystembus zugreifen kann.

Die DD 2 86 092 A7 beschreibt ein Entwicklungsgerät für einen Anwenderrechner, dessen Bussystem mit dem aus einem Emulatormikrocomputer herausgeführten Bus­ system verbindbar ist. Diese Verbindung erfolgt über ein von einem Monitorrechner kontrolliertes Steuerwerk. Auch hier müssen drei Prozessoren vorhanden sein, und zwar für den Monitorrechner, den Emulator und das Zielsystem. Außerdem wird eine große Zahl von Umschaltern benötigt und es ist ein speziell adaptiertes Zielsy­ stem notwendig, welches unter anderem den Anwenderprogrammspeicher und den darüberliegenden Schalter und die Steuerleitung hierfür enthalten muß. Der Bus des Emulatorprozessors muß mit dem Bus des Zielsystemprozessors identisch sein, das heißt es ist kein universeller Einsatz eines Emulatorprozessors möglich. Busfehler im Zielsystem verhindern immer eine ordnungsgemäße Programmausführung. Der Monitorrechner selbst hat keinen unmittelbaren Zugriff auf den Zielsystembus.

In der Zeitschrift Computer Design, April 1980, Seite 119 bis 126 ist ein Entwick­ lungsrechner beschrieben, welcher ein Testprogramm in einen Speicher schreibt, auf welchen das Zielsystem anschließend zugreift. Eine unmittelbare Verbindung des lokalen Busses des Zielsystems mit dem Bus des Emulators erfolgt hierbei nicht. Es handelt sich also um eine reine Speicheremulation und keine Busemulation des Zielsystems.

Ausgehend von der oben genannten DD 2 86 092 A7 stellt sich daher die Aufgabe, eine Busemulationsvorrichtung so auszubilden, daß ein direkter Zugriff des Entwick­ lungshilfsmittels auch auf einen defekten oder gestörten Zielsystembus und damit eine Fehlerdiagnose des Zielsystembusses möglich ist.

Gelöst wird diese Aufgabe mit den kennzeichnenden Merkmalen des Anspruchs 1. Vorteilhafte Ausgestaltungen sind den Unteransprüchen entnehmbar.

Ein erfindungswesentlicher Aspekt besteht darin, mit einem Prozessor eines Ent­ wicklungssystems den Bus eines anderen Prozessortyps eines Zielsystems zu emu­ lieren wodurch der emulierende Prozessor auf den fremden Bus wie auf seinen eige­ nen zugreifen kann. Dazu benötigt der emulierende Prozessor des Entwicklungssy­ stems Informationen über die Adreßräume, deren anwendungsspezifische Belegung mit Speicher und Peripherie, Anzahl und Art der Bussignale und Prozeduren und Schaltungen entsprechend den Bustransaktionen und Speicherzugriffsmechanismen des Zielsystems.

Einige Ausführungsbeispiele der Erfindung werden im folgenden anhand der Zeich­ nungen näher beschrieben. Dabei zeigen:

Fig. 1 eine schematische Darstellung des typischen Aufbaus eines Zielrechners;

Fig. 2 eine Ausführungsform der Busemulationsvorrichtung mit Ansteuerung des Zielrechners von der Druckerschnittstelle des Entwicklungsrechners;

Fig. 3 eine weitere Ausführungsform der Busemulationsvorrichtung mit direkter Ansteuerung des Zielrechners vom lokalen Bus des Entwicklungsrechners;

Fig. 4 eine alternative Ausführungsform zu Fig. 3, ebenfalls mit direkter Ansteue­ rung des Zielrechners vom lokalen Bus des Entwicklungsrechners.

In Fig. 1 ist ein typischer Zielrechner 1 schematisch dargestellt, welcher aus ei­ ner CPU 2, einem Speicher 3 und Peripherieeinheiten 4 besteht. Zwischen CPU 2, Speicher 3 und Peripherie 4 bestehen jeweils Verbindungen über einen Daten-, Adreß- und Steuerbus 6, 7, 8. Der Datenbus 6 kann eine Breite von 4 bis 32 Bit aufweisen, der Adreßbus 7 ist typischerweise 16 bis 32 Bit breit und der Steuerbus 8 ist 3 bis 10 Bit breit. Bei der Entwicklung eines solchen Zielrechners 1 können Fehler auftreten im Speicher 3 und in der über den Bus ansprechbaren Peripherie 4 sowie in den drei Bussystemen 6, 7 und 8. Unmittelbar an die Busleitungen von Daten-, Adreß- und Steuerbus 6, 7 und 8 wird über den Zielrechnerstecker 5 die Busemulationsvorrichtung 42 angeschlossen.

Eine solche Busemulationsvorrichtung 42 ist in Fig. 2 dargestellt und wird mittels des Entwicklungsrechnersteckers 9 auch an den Entwicklungsrechner angeschlossen. Bei dem in Fig. 2 dargestellten Ausführungsbeispiel geschieht dies über die paral­ lele Druckerschnittstelle des Entwicklungsrechners. Der Entwicklungsrechnerstecker 9 weist im wesentlichen zwei Ausgänge und einen Eingang auf. Ausgänge sind die Steuerleitungen 10, welche den Entwicklungsrechnerstecker 9 mit einem Adreßdeko­ der 13 verbinden, der interne Strobesignale zum Abspeichern von Daten in interne Register und externe Strobesignale für den Zielrechner 1 zur Verfügung stellt. Der zweite Ausgang des Entwicklungsrechnersteckers 9 sind die Datenleitungen 11, den Eingang bilden die Statusleitungen 12.

Die von der Druckerschnittstelle 9 des Entwicklungsrechners ausgehenden Daten fließen über die Datenleitungen 11 dem Kommandoregister 15, dem Adreßregister 16 und dem Datenregister 17 zu. Dabei ist das Datenregister 17 entweder als Re­ gister oder als "First-In-First-Out" (FIFO)-Speicher ausgelegt. Die Ausgänge von Kommandoregister 15, Adreßregister 16 und Datenregister 17 entsprechen bereits dem lokalen Bus des Zielrechners 1 und werden mit diesem physikalisch über den Stecker 5 verbunden.

Zur Datenübertragung vom Zielrechner 1 auf den Entwicklungsrechner enthält der Datenbus 6 der Busemulationsvorrichtung 42 ein Datenregister 22, welches als Regi­ ster oder vorzugsweise als FIFO-Speicher ausgelegt sein kann. Weiterhin umfaßt die Busemulationsvorrichtung 42 eine Multiplexeinheit 20, durch die der Inhalt der Bus­ leitungen 6, 7 und 8 über die Statusleitungen 12 und den Entwicklungsrechnerstecker 9 dem Entwicklungsrechner zugeführt wird. Schließlich weist die Busemulationsvor­ richtung 42 noch einen überlagerbaren Speicher 21 auf, welcher an alle Busleitungen 6, 7 und 8 sowie an die Datenleitungen 11 der Druckerschnittstelle angeschlossen ist.

Über die beschriebene Busemulationsvorrichtung 42 kann der Entwicklungsrechner unmittelbar auf den Bus des Zielrechners 1 zugreifen. Ist im Zielrechner 1 entweder keine CPU 2 vorhanden oder ist diese durch interne oder externe Puffer vom Bus abgetrennt, dann ist der Entwicklungsrechner der einzige Busbenutzer und kann über Diagnoseprogramme Busleitungen 6, 7 und 8, Speicher 3 und Peripherie 4 des Zielrechners 1 testen oder dessen über den Bus ansprechbare Peripherie 4 direkt be­ dienen. In diesem Falle werden die Datenregister 17 und 22 nur als einfache Register benutzt. Ist der Zielrechner 1 bereits mit einer CPU 2 ausgerüstet, dann kann der Entwicklungsrechner die CPU 2 des Zielrechners 1 anhalten und die Kontrolle über den Bus ergreifen, um Tests auszuführen oder Programme herunterzuladen. Da­ nach kann er den Bus für die CPU 2 des Zielrechners 1 wieder freigeben und diese starten. Bei aktiver CPU 2 des Zielrechners 1 dient das Register 17 als Datenpuffer variabler Größe vom Entwicklungsrechner zum Zielrechner 1 und das Register 22 als Datenpuffer variabler Größe vom Zielsystem 1 zum Entwicklungsrechner. Aus diesem Grund ist, um Tests in Echtzeit durchführen zu können, eine Auslegung der Datenregister 17 und 22 als "First-In-First-Out" (FIFO)-Speicher vorteilhaft.

Durch Verwendung der Busemulationsvorrichtung 42 kann der Zielrechner 1 mit oder ohne CPU 2 sowie mit oder ohne Speicher 3 getestet werden. Dabei können sowohl Hardware- als auch Software-Tests durchgeführt werden. Im Gegensatz zu allen bisherigen Lösungen, insbesondere zu den In-Circuit-Emulatoren, ist die ge­ samte Busemulationsvorrichtung 42 sehr kompakt und leicht aufgebaut und kann daher auch ohne weiteres an bereits installierte Zielrechner in jeder Position ange­ steckt werden. Die gesamte Busemulationsvorrichtung 42 hat in etwa die Größe einer Hardfläche. Im Vergleich zu bekannten Systemen ist die Verbindung zum Zielrechner 1 wesentlich dünner, da sie nur 25-40 Leitungen anstatt 40-200 Leitungen umfaßt. Außerdem ist diese Verbindung erheblich kürzer, da die Buse­ mulationsvorrichtung 42 unmittelbar auf den Zielrechner 1 aufgesteckt wird, wo­ durch die unerwünschten Kapazitäten und Induktivitäten der Leitungen sowie die Signallaufzeiten darin erheblich reduziert werden. Anstelle von Steckern können zur schnelleren Kontaktierung des Zielrechners 1 auch Klammern oder geeignete Adapter verwendet werden.

Während die in der Einleitung beschriebenen In-Circuit-Emulatoren prozessorspe­ zifisch ausgelegt sind, kann die erfindungsgemäße Busemulationsvorrichtung 42 mit einer gesamten Prozessorfamilie arbeiten. Dabei ist es sogar möglich, Prozessoren unterschiedlicher Architektur, jedoch mit ähnlichem Bus mit derselben Busemula­ tionsvorrichtung 42 zu unterstützen. Beispiele hierfür sind der für die Prozessoren 68xx und 65Cxx kompatible sowie der für die Prozessoren 8051 und 8085 fast iden­ tisch gemultiplexte Bus. Schließlich kann die Busemulationsvorrichtung 42 auch bei Systemen mit unterschiedlichem Prozessor und unterschiedlichem Bus verwendet werden. In diesem Fall stellt die Menge der benötigten Bussignale eine Untermenge der an der Busemulationsvorrichtung 42 verfügbaren Signale dar.

Bei der Programmentwicklung kann der Entwicklungsrechner über den Bus 6, 7 und 8 direkt auf die über den Bus ansprechbare Peripherie 4 des Zielrechners 1 zugrei­ fen. Das Programm kann mit dem gesamten am Entwicklungsrechner verfügbaren Komfort getestet und verbessert werden. In einer zweiten Stufe der Programment­ wicklung dient der Zielrechner 1 mit einem kleinen Monitorprogramm als Schnitt­ stelle zur zu steuernden Umgebung, schließlich kann das entwickelte Programm am Zielrechner 1 ausgeführt und auf sein Echtzeitverhalten überprüft werden.

Gegenüber den bekannten In-Circuit-Emulatoren sind bei der erfindungsgemäßen Busemulationsvorrichtung 42 alle Interrupts sowie der gesamte Adreß- und Spei­ cherbereich des Zielrechners 1 verfügbar. Dies wird nur von einigen sehr teuren In- Circuit-Emulatoren erfüllt, welche jedoch dann immer noch den Nachteil aufweisen, daß der Zielrechner 1 langsamer wird. Damit ist ein Test des Echtzeitverhaltens im Sinn von Bustransaktionen nicht möglich.

Der überlagerbare Speicher 21 dient dazu, bei der Programmentwicklung den Spei­ cher 3 des Zielrechners 1 zu ersetzen bzw. zu überlagern, da er dessen Funktionen übernimmt. Üblicherweise wird bei der Programmentwicklung das Programm in den Schreib-/Lesespeicher des Zielrechners 1 geladen und erst nach Programmfer­ tigstellung in einen Festwertspeicher des Zielrechners 1 gebracht. Der überlagerbare Speicher 21 ersetzt sowohl den Schreib-/Lesespeicher als auch den Festwertspeicher des Zielrechners 1, wodurch der gesamte Speicher 3 des Zielrechners 1 zu Testzwecken zur Verfügung steht. Weiterhin ist zum Ausführen komplexer Testprogramme oft­ mals mehr Schreib-/Lesespeicher nötig, als der Zielrechner 1 aufweist. Der überla­ gerbare Speicher 21 dient dann zur Ergänzung des Schreib-/Lesespeichers des Ziel­ rechners 1. Der überlagerbare Speicher 21 teilt sich auf in zwei Speichergruppen. Die Funktion der ersten Speichergruppe wurde soeben beschrieben, bei der zweiten Speichergruppe entspricht jedem Wort ein Segment des Adreßraums im Zielrechner 1. Mit den einzelnen Bits jedes Worts wird für das entsprechende Segment der am Emulator vorhandene Programm- bzw. Datenspeicher zu- oder weggeschaltet, die FIFO in diesem Segment aktiviert, bei Zugriff auf den Programm- bzw. Daten­ speicher ein Unterbrechungssignal ausgelöst, wobei die Unterbrechungssignale der CPU 2 des Zielrechners 1 zugeführt werden, um dort eine Programmunterbrechung auszulösen, was vom Entwicklungsrechner oder Drittgeräten auswertbar ist.

Im folgenden soll das oben behandelte Ausführungsbeispiel der Busemulationsvor­ richtung 42 auf einen Zielrechner des Typs Intel i8051 angewendet werden. Dieser Zielrechner weist einen gemultiplexten 8-Bit Daten-/Adreßbus sowie einen 8-Bit Adreßbus für die oberen acht Adressen auf. Programm- und Datenspeicher liegen in separaten Adreßräumen. Die Steuersignale sind wie folgt definiert:

ALE CPU gibt gültige Adressen aus
RD CPU liest von Speicher/Peripherie
WR CPU schreibt auf Speicher/Peripherie
PSEN CPU liest Instruktion
RST CPU wird desaktiviert.

Bei diesem Zielrechner werden die Busoperationen wie folgt bewerkstelligt:

Emulatorinterne Primitiven

Daten schreiben:
Daten an Druckerschnittstelle 9 aufsetzen
Adresse des Registers 15, 16 oder 17 aufsetzen
Strobe setzen (13)
Strobe rücksetzen (13)
Daten lesen:
Adresse des ersten Nibble ( 4 bit) aufsetzen (9)
Multiplexer 20 einlesen
Adresse des zweiten Nibble aufsetzen (9)
Multiplexer 20 einlesen
Beide Nibbles zu einem Byte zusammensetzen

Primitiven

Adresse_Setzen:
Obere 8 Adreßbit am Adreßbus 7 aufsetzen
Untere 8 Adreßbit (Daten_Setzen) am Datenbus 6 aufsetzen
ALE setzen
ALE zurücksetzen
Daten_Setzen:
8 Datenbit in FIFO 17 schreiben
Daten-/Adreßbus 6, 7 auf Schreiben schalten
Daten_Lesen:
8 Datenbit aus FIFO 17 lesen.

Dabei kann durch die Emulation der Zielrechner-CPU 2 der Entwicklungsrechner auf Adressen des Zielrechners 1 wie auf seine eigenen Adressen zugreifen.

Zugriffe im Datenspeicher (3) des Zielrechners 1

Byte_Lesen:
Adresse_Setzen
Datenbus 6 auf Lesen umschalten
RD setzen
RD zurücksetzen
Daten_Lesen
Byte_Schreiben:
Adresse_setzen
Daten_Setzen
WR setzen
WR zurücksetzen

Zugriffe im Programmspeicher (3) des Zielrechners 1

Byte_Lesen:
Adresse_Setzen
Datenbus 6 auf Lesen umschalten
PSEN setzen
PSEN zurücksetzen
Daten_Lesen
Byte_Schreiben:
Adresse_setzen
Daten_Setzen
WR setzen
WR zurücksetzen.

Die Transaktion "Byte_Schreiben" wird dabei meist nur vom Entwicklungsrechner beim Herunterladen des Programms durchgeführt.

Tests

Datenbustest: erkennt eine gegen Masse oder andere Busleitung kurzgeschlossene Datenleitung 6′. Vorgehen:

• • Alle externen Adreßleitungen 7′ tief setzen.
• • Alle Steuerleitungen 8′ tief setzen.
• • Acht Testmuster mit genau einer gesetzten Datenleitung 6′ ausgeben, rücklesen und vergleichen, bei Ungleichheit Anzeige der fraglichen Da­ tenleitung 6′.
• • Alle externen Adreßleitungen 7′ hoch setzen.
• • Alle Steuerleitungen 8′ hoch setzen.
• • Acht Testmuster mit genau einer zurückgesetzten Datenleitung 6′ ausge­ ben, rücklesen und vergleichen, bei Ungleichheit Anzeige der fraglichen Datenleitung 6′.

Steuerbustest: Analog zum Datenleitungstest.

Adreßbustest: Obere Adressen werden analog zu den Datenleitungen 6′ gete­ stet. Ein direkter Test der unteren Adreßleitungen 7′ ist mit der angegebenen Busspezifikation nicht möglich, da der Adreßbus 7 keine separaten unteren Adreßleitungen aufweist. Ein indirekter Test kann mit Hilfe eines externen Spei­ chers mit einem der bekannten Speichertestalgorithmen durchgeführt werden.

Speichertests: Durchzuführen mit Hilfe der Funktionen Byte_Schreiben und Byte_Lesen.

Peripherietests: Durch periodische Anzeige einer Eingabeschnittstelle und peri­ odisches Schreiben und Rücklesen auf eine Ausgabeschnittstelle.

Die Abbildung 3 zeigt eine Busemulationsvorrichtung 42, bei welcher der Zielrechner­ bus auch mit dem Bus des Entwicklungsrechners im wesentlichen identisch ist. Die­ ser setzt sich zusammen aus dem Adreßbus 24, dem Steuerbus 25 und dem Datenbus 26. Der Steuerbus 25 führt zu einem Dekoder 35 zum Generieren interner Steuerlei­ tungen 27. Die Übertragung von Daten vom Entwicklungsrechner zum Zielrechner 1 erfolgt zunächst über den Datenbus 26 des Entwicklungsrechners, welcher zu einem Register 28 für Steuerleitungen, zu einem oberen Register 29 und zu einem unteren Register 30 für den Multiplexbus 34 des Zielrechners 1 führt. Der Multiplexbus 34 des Zielrechners 1 ist ein kombinierter Daten- und Adreßbus. Das obere Register 29 bzw. das untere Register 30 gibt Adressen und Daten auf die obere bzw. die untere Hälfte des genannten Multiplexbusses 34 des Zielrechners 1 aus. Beide Re­ gister können zur Verbesserung der Kommunikation auch als Schieberegister oder FIFO ausgebildet sein. Vom Register für Steuerleitungen 28 führt der Steuerbus 8 des Zielrechners 1 zum Zielrechnerstecker 5, von den Registern 29 und 30 führt der Multiplexbus 34 des Zielrechners 1 ebenfalls zu diesem Stecker 5.

Zum Rücklesen der Steuerleitungen dient der Puffer 31, welcher auf Zielrechner­ seite mit dem Steuerbus 8 und auf Entwicklungsrechnerseite mit dem Datenbus 26 verbunden ist. Der Puffer 32 dient zum Rücklesen des Multiplexbusses 34 des Ziel­ rechners 1 zum Entwicklungsrechner und ist vorzugsweise als Register oder als FIFO ausgebildet.

Die Funktion des überlagerbaren Speichers 33, die Testmöglichkeiten und die Vorzüge gegenüber den bekannten Systemen entsprechen dem unter Fig. 2 be­ schriebenen Ausführungsbeispiel.

Fig. 4 zeigt ebenfalls eine Busemulationsvorrichtung 42 mit direkter Ansteuerung vom lokalen Bus des Entwicklungsrechners. Im Unterschied zu dem unter Fig. 3 be­ schriebenen Ausführungsbeispiel findet hier kein Multiplexbus Verwendung, sondern ein nach Daten-, Adreß- und Steuerbus (6, 7 und 8) getrennter Bus. Der Adreßbus 24 des Entwicklungsrechners führt zu einem Umkodierer 37 zum Generieren zielsy­ stembezogener Adressen aus den Adressen des Entwicklungsrechners. Aus diesem Umkodierer 37 geht auf Zielrechnerseite der Adreßbus 7 des Zielrechners 1 hervor und führt zum Zielrechnerstecker 5. Der Steuerbus 25 des Entwicklungsrechners führt zu einem Umkodierer 36 zum Generieren zielsystembezogener Steuersignale aus den Steuersignalen des Entwicklungsrechners. Den Ausgang dieses Umkodierers 36 bildet der Steuerbus 8 des Zielrechners 1, welcher ebenfalls zum Zielrechnerstecker 5 fährt. Wie im vorigen Ausführungsbeispiel führen Adreß- und Steuerbus (24, 25) des Entwicklungsrechners auch zum Dekoder 35. Der Datenbus 26 des Entwick­ lungsrechners führt zu einem Register 38, welcher die Daten auf den Datenbus 6 des Zielrechners 1 ausgibt und zur Verbesserung der Kommunikation auch als Schiebe­ register oder FIFO ausgebildet sein kann. Der Datenbus 6 der Zielrechnerseite führt ebenfalls zum Zielrechnerstecker 5. Zum Rücklesen der Steuer- und Adreßleitungen dienen die Puffer 39 und 40. Ein weiterer Puffer 41 ist vorgesehen zum Rücklesen des Datenbusses 6 des Zielrechners 1 zum Entwicklungsrechner. Auch dieser Puffer 41 kann als Schieberegister oder FIFO ausgebildet sein.

Claims (16)

1. Busemulationsvorrichtung (42) zum Testen der Hard- und Software eines Ziel­ rechners (1) mit Hilfe eines Entwicklungsrechners, welche einerseits mit min­ destens einem Bus (6, 7, 8) des Zielrechners (1) und andererseits mit dem Entwicklungsrechner verbindbar ist, wonach die durch den Prozessor des Ziel­ rechners (1) festgelegten Bustransaktionen emulierbar sind und ein Datenaus­ tausch zwischen Entwicklungs- und Zielrechner stattfinden kann, dadurch gekennzeichnet, daß sie Umsetzer zur Bereitstellung und/oder Anpassung der zwischen Entwicklungs- und Zielrechner übertragenen Daten-, Adreß- und Steuersignale enthält, welche mit dem mindestens einen Bus (6, 7, 8) des Zielrechners (1) unmittelbar und unter Verwendung des gleichen Busprotokolls verbunden sind.

2. Busemulationsvorrichtung nach Anspruch 1, dadurch gekennzeichnet, daß sie mit dem Entwicklungsrechner über dessen Druckerschnittstelle (9) verbunden ist.

3. Busemulationsvorrichtung nach Anspruch 2, dadurch gekennzeichnet, daß die Umsetzer aus einem Kommandoregister (15) zur Bereitstellung interner und zielsystembezogener Steuersignale und/oder einem Adreßregister (16) zur Be­ reitstellung der Adreßsignale zum Zugriff auf den Zielrechner (1) und/oder einem Datenregister (17) zur Datenübertragung vom Entwicklungsrechner zum Zielrechner (1) bestehen.

4. Busemulationsvorrichtung nach Anspruch 3, dadurch gekennzeichnet, daß als zusätzlicher Umsetzer ein Datenregister (22) zur Datenübertragung vom Ziel­ rechner (1) auf den Entwicklungsrechner vorhanden ist.

5. Busemulationsvorrichtung nach Anspruch 4, dadurch gekennzeichnet, daß min­ destens eines der Datenregister (17, 22) als "First-In-First-Out" (FIFO) Spei­ cher ausgelegt ist.

6. Busemulationsvorrichtung nach einem der Ansprüche 2 bis 5, dadurch ge­ kennzeichnet, daß sie zur Datenübertragung vom Daten-, Adreß- und Steu­ erbus (6, 7, 8) des Zielrechners (1) zum Entwicklungsrechner eine Multiplexein­ heit (20) umfaßt.

7. Busemulationsvorrichtung nach Anspruch 1, dadurch gekennzeichnet, daß sie unmittelbar mit dem lokalen Bus des Entwicklungsrechners verbindbar ist.

8. Busemulationsvorrichtung nach Anspruch 7, dadurch gekennzeichnet, daß die Umsetzer aus einem Steuerleitungsregister (28) sowie einem oder mehreren je­ weils ein Byte breiten Registern (29, 30) zum Zugriff auf mindestens Teile des Daten- und Adreßbusses (34) des Zielrechners (1) bestehen.

9. Busemulationsvorrichtung nach Anspruch 8, dadurch gekennzeichnet, daß sie zur Verwendung bei einem Zielrechner (1) mit einem 16 Bit breiten Bus zwei jeweils ein Byte breite Register, also ein oberes (29) und ein unteres Register (30), umfaßt wobei das obere Register (29) der Ausgabe von Adressen und Daten auf die obere Hälfte und das untere Register (30) der Ausgabe von Adressen und Daten auf die untere Hälfte des Busses (34) des Zielrechners (1) dient.

10. Busemulationsvorrichtung nach Anspruch 9, dadurch gekennzeichnet, daß zu­ mindest das untere oder das obere Register (30, 29) als "First-In-First-Out" (FIFO) Speicher ausgelegt ist.

11. Busemulationsvorrichtung nach einem der Ansprüche 7 bis 10, dadurch ge­ kennzeichnet, daß ein erster Puffer (31) zum Rücklesen der Steuerleitungen und ein zweiter Puffer (32) zum Rücklesen des Datenbusses (34) vom Zielrech­ ner (1) auf den Entwicklungsrechner vorhanden ist.

12. Busemulationsvorrichtung nach Anspruch 11, dadurch gekennzeichnet, daß min­ destens der zweite Puffer (32) ein FIFO-Speicher ist.

13. Busemulationsvorrichtung nach einem der voranstehenden Ansprüche, da­ durch gekennzeichnet, daß sie einen überlagerbaren Speicher (21) umfaßt, welcher mit allen Busleitungen (6, 7, 8) des Busses des Zielrechners (1) sowie mit dem Entwicklungsrechner verbunden ist.

14. Busemulationsvorrichtung nach Anspruch 13, dadurch gekennzeichnet, daß der überlagerbare Speicher (21) mindestens zum Teil die Funktionen des Speichers (3) des Zielrechners (1) übernimmt.

15. Busemulationsvorrichtung nach einem der Ansprüche 13 oder 14, dadurch gekennzeichnet, daß der Entwicklungsrechner Zugriff auf den überlagerbaren Speicher (21) hat.

16. Busemulationsvorrichtung nach einem der voranstehenden Ansprüche, da­ durch gekennzeichnet, daß sie in einem Gehäuse eingebaut ist, welches unmittelbar an einem Zielrechner (1) angebracht werden kann und dabei alle Busleitungen (6, 7, 8) der Busemulationsvorrichtung (42) mit denen des Ziel­ rechners (1) verbunden werden.