DE4142161A1

DE4142161A1 - Busemulator

Info

Publication number: DE4142161A1
Application number: DE19914142161
Authority: DE
Inventors: Nikolaus Dr Techn Tichawa
Original assignee: Individual
Current assignee: Individual
Priority date: 1991-12-20
Filing date: 1991-12-20
Publication date: 1993-06-24
Anticipated expiration: 2011-12-21
Also published as: DE4142161C2

Description

Die Erfindung betrifft einen Busemulator nach dem Oberbegriff des Anspruchs 1. Ein solcher Busemulator dient zur Entwicklung von kundenspezifischen eigenständi gen Mikroprozessor- und Mikrocontrollersteuerungen ("Embedded Systems"), bei denen ein Zielsystem mit Hilfe eines Entwicklungssystems programmiert und gete stet 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 wie sie z. B. von den Firmen Intel, Grammar Engine Inc. (Promice) und Softaid Inc. (Icebox) laut dem Anmelder vorliegenden Prospekten vertrieben werden. Dabei wird die CPU (central processing unit = Zentraleinheit) des Zielsystems durch einen Emulator ersetzt, welcher mit einem Entwicklungsrechner kommuniziert. 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 Archi tektur und denselben Befehlssatz aufweisen muß. Da in der Entwicklungsphase 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.

Es stellt sich daher die Aufgabe, einen Busemulator so weiterzubilden, daß mit ei nem Entwicklungssystem unmittelbar ein Zielsystem programmiert und vollständig getestet werden kann.

Gelöst wird diese Aufgabe durch die kennzeichnenden Merkmale 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 sollen im folgenden anhand der Zeich nungen näher beschrieben werden. Dabei zeigen:

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

Fig. 2 eine Ausführungsform des Busemulators mit Ansteuerung des Zielsystems von der Druckerschnittstelle des Entwicklungsrechners;

Fig. 3 eine weitere Ausführungsform des Busemulators mit direkter Ansteuerung des Zielsystems vom lokalen Bus des Entwicklungsrechners;

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

In Fig. 1 ist ein typisches Zielsystem 1 schematisch dargestellt, welches aus einer CPU 2, einem Speicher 3 und Peripherieeinheiten 4 besteht. Zwischen CPU 2, Spei cher 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 Zielsystems 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 Zielsystemstecker 5 der Busemulator 42 angeschlossen.

Ein solcher Busemulator 42 ist in Fig. 2 dargestellt und wird mittels des Ent wicklungsrechnersteckers 9 auch an den Entwicklungsrechner angeschlossen. Bei dem in Fig. 2 dargestellten Ausführungsbeispiel geschieht dies über die parallele 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 das Zielsystem 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 Zielsystems 1 und werden mit diesem physikalisch über den Stecker 5 verbunden.

Zur Datenübertragung vom Zielsystem 1 auf den Entwicklungsrechner enthält der Datenbus 6 des Busemulators 42 ein Datenregister 22, welches als Register oder vorzugsweise als FIFO-Speicher ausgelegt sein kann. Weiterhin umfaßt der Buse mulator 42 eine Multiplexeinheit 20, durch die der Inhalt der Busleitungen 6, 7 und 8 über die Statusleitungen 12 und den Entwicklungsrechnerstecker 9 dem Ent wicklungssystem zugeführt wird. Schließlich weist der Busemulator 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 den beschriebenen Busemulator 42 kann der Entwicklungsrechner unmittelbar auf den Bus des Zielsystems 1 zugreifen. Ist im Zielsystem 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 Diagno seprogramme Busleitungen 6, 7 und 8, Speicher 3 und Peripherie 4 des Zielsystems testen oder dessen über den Bus ansprechbare Peripherie 4 direkt bedienen. In diesem Falle werden die Datenregister 17 und 22 nur als einfache Register benutzt. Ist das Zielsystem 1 bereits mit einer CPU 2 ausgerüstet, dann kann der Entwick lungsrechner die CPU 2 des Zielsystems 1 anhalten und die Kontrolle über den Bus ergreifen, um Tests auszuführen oder Programme herunterzuladen. Danach kann er den Bus für die CPU 2 des Zielsystems 1 wieder freigeben und diese starten. Bei ak tiver CPU 2 des Zielsystems 1 dient das Register 17 als Datenpuffer variabler Größe vom Entwicklungsrechner zum Zielsystem 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 des Busemulators 42 kann das Zielsystem 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 der gesamte Busemula tor 42 sehr kompakt und leicht aufgebaut und kann daher auch ohne weiteres an bereits installierte Zielsysteme in jeder Position angesteckt werden. Der gesamte Busemulator 42 hat in etwa die Größe einer Handfläche. Im Vergleich zu bekann ten Systemen ist die Verbindung zum Zielsystem 1 wesentlich dünner, da sie nur 25-40 Leitungen anstatt 40-200 Leitungen umfaßt. Außerdem ist diese Ver bindung erheblich kürzer, da der Busemulator 42 unmittelbar auf das Zielsystem 1 aufgesteckt wird, wodurch 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 Zielsystems 1 auch Klammern oder geeignete Adapter verwendet werden.

Während die in der Einleitung beschriebenen In-Circuit-Emulatoren prozessorspe zifisch ausgelegt sind, kann der erfindungsgemäße Busemulator 42 mit einer gesam ten Prozessorfamilie arbeiten. Dabei ist es sogar möglich, Prozessoren unterschied licher Architektur, jedoch mit ähnlichem Bus mit demselben Busemulator 42 zu unterstützen. Beispiele hierfür sind der für die Prozessoren 68xx und 65Cxx kompa tible sowie der für die Prozessoren 8051 und 8085 fast identisch gemultiplexte Bus. Schließlich kann der Busemulator 42 auch bei Systemen mit unterschiedlichem Pro zessor und unterschiedlichem Bus verwendet werden. In diesem Fall stellt die Menge der benötigten Bussignale eine Untermenge der am Busemulator 42 verfügbaren Sig nale dar.

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

Gegenüber den bekannten In-Circuit-Emulatoren sind bei dem erfindungsgemäßen Busemulator 42 alle Interrupts sowie der gesamte Adreß- und Speicherbereich des Zielsystems 1 verfügbar. Dies wird nur von einigen sehr teuren In-Circuit- Emulatoren erfüllt, welche jedoch dann immer noch den Nachteil aufweisen, daß das Zielsystem 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 Zielsystems 1 zu ersetzen bzw. zu überlagern, da er dessen Funktionen übernimmt. Üblicherweise wird bei der Programmentwicklung das Programm in den Schreib-/Lesespeicher des Zielsystems 1 geladen und erst nach Programmfer tigstellung in einen Festwertspeicher des Zielsystems 1 gebracht. Der überlagerbare Speicher 21 ersetzt sowohl den Schreib-/Lesespeicher als auch den Festwertspeicher des Zielsystems 1, wodurch der gesamte Speicher 3 des Zielsystems 1 zu Testzwecken zur Verfügung steht. Weiterhin ist zum Ausführen komplexer Testprogramme oft mals mehr Schreib-/Lesespeicher nötig, als das Zielsystem 1 aufweist. Der über lagerbare Speicher 21 dient dann zur Ergänzung des Schreib-/Lesespeichers des Zielsystems 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 Zielsystem 1. Mit den einzelnen Bits jeden 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 Zielsystems 1 zugeführt werden, um dort eine Programmunterbrechung auszulösen, was vom Entwicklungssystem oder Drittgeräten auswertbar ist.

Im folgenden soll das oben behandelte Ausführungsbeispiel des Busemulators 42 auf ein Zielsystem des Typs Intel i8051 angewendet werden. Dieses Zielsystem 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 des aktiviert.

Bei diesem Zielsystem 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 Zielsystem-CPU 2 der Entwicklungsrechner auf Adressen des Zielsystems 1 wie auf seine eigenen Adressen zugreifen.

Zugriffe im Datenspeicher (3) des Zielsystems 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 Zielsystems 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 Abb. 3 zeigt einen Busemulator 42, bei dem der globale Bus auch mit dem lokalen Bus des Entwicklungssystems im wesentlichen identisch ist. Dieser 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 Steuerleitungen 27. Die Übertragung von Daten vom Entwicklungsrechner zum Zielsystem 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 Zielsystems 1 führt. Der Multiplexbus 34 des Zielsy stems 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 Zielsystems 1 aus. Beide Register 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 Zielsystems 1 zum Zielsystemstecker 5, von den Registern 29 und 30 führt der Multiplexbus 34 des Zielsystems 1 ebenfalls zu diesem Stecker 5.

Zum Rücklesen der Steuerleitungen dient der Puffer 31, welcher auf Zielsystem 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 systems 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 einen Busemulator 42 mit direkter Ansteuerung vom lokalen Bus des Entwicklungsrechners. Im Unterschied zu dem unter Fig. 3 beschriebenen 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 zielsystembe zogener Adressen aus den Adressen des Entwicklungsrechners. Aus diesem Umko dierer 37 geht auf Zielsystemseite der Adreßbus 7 des Zielsystems 1 hervor und führt zum Zielsystemstecker 5. Der Steuerbus 25 des Entwicklungsrechners führt zu einem Umkodierer 36 zum Generieren zielsystembezogener Steuersignale aus den Steuer signalen des Entwicklungsrechners. Den Ausgang dieses Umkodierers 36 bildet der Steuerbus 8 des Zielsystems 1, welcher ebenfalls zum Zielsystemstecker 5 führt. Wie im vorigen Ausführungsbeispiel führen Adreß- und Steuerbus (24, 25) des Entwick lungsrechners auch zum Dekoder 35. Der Datenbus 26 des Entwicklungsrechners führt zu einem Register 38, welcher die Daten auf den Datenbus 6 des Zielsystems 1 ausgibt und zur Verbesserung der Kommunikation auch als Schieberegister oder FIFO ausgebildet sein kann. Der Datenbus 6 der Zielsystemseite führt ebenfalls zum Zielsystemstecker 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 Da tenbusses 6 des Zielsystems 1 zum Entwicklungsrechner. Auch dieser Puffer 41 kann als Schieberegister oder FIFO ausgebildet sein.

Claims

1. Busemulator zum Testen der Hard- und Software eines Zielsystems mit Hilfe eines Entwicklungssystems, wobei dieser Busemulator zwischen Entwicklungs system und Zielsystem geschaltet ist und das Zielsystem mindestens einen Prozessor umfaßt, dieser Prozessor eine CPU, einen lokalen Bus und einen lokalen Speicher sowie eine Schnittstelle zu einem globalen Bus aufweist, der Busemulator ein Testprogramm ausführt und dessen Ergebnisse auf Richtigkeit überprüft und hierbei Zugriff zum globalen Bus hat, dadurch gekennzeich net, daß der lokale Bus (6, 7, 8) des Zielsystems (1) im wesentlichen identisch mit dem globalen Bus und mit diesem physikalisch verbunden ist, der globale Bus über den Busemulator (42) mit dem Entwicklungssystem verbunden ist und in einem ersten Betriebszustand vom Entwicklungssystem für das Ziel system (1) festgelegte und zur Durchführung des Testprogramms benötigte Daten-, Adreß- und Steuersignale auf den globalen Bus gegeben werden sowie in einem zweiten möglichen Betriebszustand ein Datenaustausch zwischen Ent wicklungssystem und Zielsystem (1) über den globalen Bus stattfinden kann.

2. Busemulator nach Anspruch 1, dadurch gekennzeichnet, daß der globale Bus von der Druckerschnittstelle (9) des Entwicklungssystems angesteuert wird.

3. Busemulator nach Anspruch 2, dadurch gekennzeichnet, daß er ein Kom mandoregister (15) zur Bereitstellung interner und zielsystembezogener Steu ersignale und/oder ein Adreßregister (16) zur Bereitstellung der Adreßleitun gen (7′) zum Zugriff auf das Zielsystem (1) und/oder ein Datenregister (17) zur Datenübertragung vom Entwicklungsrechner zum Zielsystem (1) umfaßt.

4. Busemulator nach Anspruch 3, dadurch gekennzeichnet, daß zusätzlich ein Datenregister (22) zur Datenübertragung vom Zielsystem (1) auf den Entwick lungsrechner vorhanden ist.

5. Busemulator nach Anspruch 4, dadurch gekennzeichnet, daß mindestens eines der Datenregister (17, 22) als "First-In-First-Out" (FIFO) Speicher aus gelegt ist.

6. Busemulator nach einem der Ansprüche 2 bis 5, dadurch gekennzeichnet, daß er zur Datenübertragung vom Daten-, Adreß- und Steuerbus (6, 7, 8) des Zielsystems (1) zum Entwicklungssystem eine Multiplexeinheit (20) umfaßt.

7. Busemulator nach Anspruch 1, dadurch gekennzeichnet, daß der globale Bus auch mit dem lokalen Bus des Entwicklungssystems im wesentlichen iden tisch ist.

8. Busemulator nach Anspruch 7, dadurch gekennzeichnet, daß er ein Steu erleitungsregister (28) sowie ein oder mehrere jeweils ein Byte breite Register (29, 30) zum Zugriff auf mindestens Teile des Daten- und Adreßbusses (34) des Zielsystems (1) umfaßt.

9. Busemulator nach Anspruch 8, dadurch gekennzeichnet, daß er zur Ver wendung bei einem Zielsystem (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 Zielsystembusses (34) dient.

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

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

12. Busemulator nach Anspruch 11, dadurch gekennzeichnet, daß mindestens der zweite Puffer (32) ein FIFO-Speicher ist.

13. Busemulator nach einem der voranstehenden Ansprüche, dadurch gekenn zeichnet, daß er einen überlagerbaren Speicher (21) umfaßt, welcher mit allen Busleitungen (6, 7, 8) des Zielsystembusses sowie mit dem Entwicklungssystem verbunden ist.

14. Busemulator nach Anspruch 13, dadurch gekennzeichnet, daß der überla gerbare Speicher (21) mindestens zum Teil die Funktionen des Speichers (3) des Zielsystems (1) übernimmt.

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

16. Busemulator nach einem der voranstehenden Ansprüche, dadurch gekenn zeichnet, daß er in einem Gehäuse eingebaut ist, welches unmittelbar an einem Zielsystem (1) angebracht werden kann und dabei alle Busleitungen (6′, 7′, 8′) des Busemulators (42) mit denen des Zielsystems (1) verbunden wer den.

17. Busemulator nach einem der voranstehenden Ansprüche, dadurch gekenn zeichnet, daß vom Entwicklungssystem periodische Signale auf den Bus ge geben werden können.