DE10127170A1 - Fehlersuchverfahren und Fehlersuchvorrichtung - Google Patents

Abstract

Zur vereinfachten Bedienung und Kontrolle der Fehlersuche in einem System (1) mit mehreren unterschiedlichen Modellen (2, 3, 4), wie beispielsweise einem Hardware-Modell, einem Software-Programm und einem Testbench-Modell, aktiviert der Benutzer einen einheitlichen Debugger (11), der seinerseits verschiedene untergeordnete Debugger (5, 6, 7) aufruft und ausführt, welche jeweils den unterschiedlichen Modellen (2, 3, 4) zugeordnet sind. Die untergeordneten Debugger (5, 6, 7) greifen dann jeweils auf die ihnen zugeordneten unterschiedlichen Modelle zum Ausführen entsprechender Fehlersuchoperationen zu.

Description

Die vorliegende Erfindung betrifft ein Fehlersuchverfahren für ein System mit unterschiedlichen Simulationsmodellen, wie beispielsweise einem Hardware-Modell, einem Software-Programm und/oder einem Testbench-Modell, sowie eine Vorrichtung zur Fehlersuche in einem System mit derartigen unterschiedlichen Simulationsmodellen, welche bevorzugt beim Entwurf elektroni­ scher Schaltungen einsetzbar ist, d. h. in diesem Fall handelt es sich bei dem zu simulierenden System um eine elektronische Schaltung.

Es gibt zu simulierende Systeme, die mittels einer kontrol­ lierten und instrumentierten Abarbeitung von Programm­ schritten (sog. Debuggen) in einer Testumgebung auf Fehler untersucht werden sollen und durch unterschiedliche Simulati­ onsmodelle simuliert werden. Im Rahmen dieser Erfindung wer­ den unter dem Begriff "Simulationsmodell" insbesondere Hard­ ware-Modelle, Software-Programme und Testbench-Modelle ver­ standen. Ein solches System kann zum Beispiel mit Hilfe von drei Klassen von Sprachen beschrieben werden: mit einer oder mehreren Hardware-Beschreibungssprachen ("Hardware Descripti­ on Language", HDL) für die Hardware, mit einer oder mehreren Programmiersprachen ("Programming Language", PL) für die Software und mit einer Testbenchsprache ("Test Language", TL oder "Hardware Verification Language", HVL) für die Testbench.

Bei der Fehlersuche in Datenverarbeitungsprogrammen wird üb­ licherweise das auf Fehler zu untersuchende Modell bzw. Pro­ gramm unter Kontrolle einer Fehlersucheinrichtung bzw. eines Fehlersuchprogramms, eines sogenannten Debuggers, ausgeführt. Hierzu wird das Fehlersuchprogramm aufgerufen, das wiederum das zu untersuchende Modell bzw. Programm aufruft, welches in der Regel einen Unterbrechungspunkt enthält. Bei Erreichen dieses Unterbrechungspunktes wird die weitere Abarbeitung des zu untersuchenden Programms gestoppt und zum Debugger zurück­ gekehrt.

Bei herkömmlichen Fehlersuchverfahren wird für jede Klasse der oben angegebenen Sprachen, d. h. für jedes Modell, ein ei­ genes Fehlersuchprogramm mit eigenen Kommandos und einer ei­ genen Oberfläche verwendet. Dem Vorteil, dass für jede Klasse von Sprachen ein optimaler Debugger eingesetzt werden kann, steht der Nachteil gegenüber, dass sich die verschiedenen De­ bugger für die unterschiedlichen Modelle unterschiedlich ver­ halten und dass vom Benutzer viele Kommando-Schnittstellen und Fenster am Bildschirm seines Rechnerarbeitsplatzes zu kontrollieren sind.

Es ist daher eine Aufgabe der vorliegenden Erfindung, ein Fehlersuchverfahren für ein System mit unterschiedlichen Si­ mulationsmodellen, das die obigen Nachteile vermeidet und insbesondere vom Benutzer einfach bedient und kontrolliert werden kann, sowie eine entsprechende Fehlersuchvorrichtung bereitzustellen.

Diese Aufgabe wird durch ein Fehlersuchverfahren mit den Merkmalen von Patentanspruch 1 bzw. durch eine Fehlersuchvor­ richtung mit den Merkmalen von Patentanspruch 9 gelöst. Vor­ teilhafte Ausgestaltungen und Weiterbildungen der Erfindung sind Gegenstand der Unteransprüche.

Erfindungsgemäß wird zur Fehlersuche in einem System mit meh­ reren unterschiedlichen Simulationsmodellen, wie zum Beispiel einem Hardware-Modell, einem Software-Modell/Programm und ei­ nem Testbench-Modell, vom Benutzer eine übergeordnete Feh­ lersucheinrichtung (Debugger) ausgeführt, welche ihrerseits mit verschiedenen untergeordneten Fehlersucheinrichtungen (Debugger), die jeweils den unterschiedlichen Simulationsmo­ dellen zugeordnet sind, kommuniziert und diese aktiviert. Die untergeordneten Fehlersucheinrichtungen greifen dann jeweils entsprechend auf das ihnen zugeordnete Simulationsmodell zu, um einen Fehler in dem System (bzw. in dem jeweiligen Simula­ tionsmodell) aufzufinden. Durch die Bereitstellung der über­ geordneten einheitlichen und gemeinsamen Fehlersucheinrich­ tung kann dem Benutzer eine einheitliche Schnittstelle mit eigenen Kommandos, eigenem Kommandointerpreter und eigener Oberfläche zur Verfügung gestellt werden, um die Fehlersuche in den einzelnen Simulationsmodellen für den Benutzer zu ver­ einfachen. Gleichzeitig können für die unterschiedlichen Si­ mulationsmodelle jeweils optimale Debugger als untergeordnete Fehlersucheinrichtungen verwendet werden, so dass trotz der vereinfachten Bedienung für den Benutzer ein optimales Ergeb­ nis der Fehlersuche gewährleistet werden kann.

Die übergeordnete Fehlersucheinrichtung kann gegebenenfalls auch direkt, d. h. ohne Zwischenschaltung einer entsprechenden untergeordneten Fehlersucheinrichtung, auf das jeweilige Si­ mulationsmodell kontrollierend und analysierend zugreifen.

Vorzugsweise erfolgt die Kommunikation zwischen der einheit­ lichen übergeordneten Fehlersucheinrichtung und den einzelnen untergeordneten und speziellen Fehlersucheinrichtungen in Form einer Master-Worker- oder Master-Slave-Kommunikation, wobei die übergeordnete Fehlersucheinrichtung als Master und die untergeordneten Fehlersucheinrichtungen als Workers oder Slaves fungieren.

Die vorliegende Erfindung kann bevorzugt bei der Entwicklung bzw. bei der Simulation/Verifikation von elektrischen Schal­ tungen (Hardwareentwurf) eingesetzt werden.

Die vorliegende Erfindung wird nachfolgend anhand ver­ schiedener Ausführungsbeispiele unter Bezugnahme auf die bei­ liegende Zeichnung näher erläutert. Darin zeigen:

Fig. 1 eine schematische Darstellung des Aufbaus eines ersten Ausführungsbeispiels einer Vorrichtung zur Fehlersuche gemäß der vorliegenden Erfindung;

Fig. 2 eine schematische Darstellung des Aufbaus eines zweiten Ausführungsbeispiels einer Vorrichtung zur Fehlersuche gemäß der vorliegenden Erfindung;

Fig. 3 ein grob skizziertes Ablaufdiagramm zur Erläuterung eines Funktionsablaufs eines Fehlersuchverfahrens gemäß der vorliegenden Erfindung;

Fig. 4 ein grob skizziertes Ablaufdiagramm zur Erläuterung eines weiteren Funktionsablaufs eines Fehlersuch­ verfahrens gemäß der vorliegenden Erfindung; und

Fig. 5 ein grob skizziertes Ablaufdiagramm zur Erläuterung eines nochmals weiteren Funktionsablaufs eines Feh­ lersuchverfahrens gemäß der vorliegenden Erfindung.

In Fig. 1 ist zunächst der grundsätzliche Aufbau eines ersten Ausführungsbeispiels einer Vorrichtung zur Durchführung des erfindungsgemäßen Fehlersuchverfahrens dargestellt.

Das zu simulierende System 1 ist im vorliegenden Fall aus drei unterschiedlichen Simulationsmodellen 2-4, die nachfol­ gend der Einfachheit halber verkürzt als Modell bezeichnet werden, aufgebaut. Die (in Fig. 1 mit I bis III bezeichneten) Modelle 2, 3, 4 sind beispielsweise ein Hardware-Modell, ein Software-Modell/Programm und ein Testbench-Modell, in denen das System jeweils durch entsprechende Sprachen wie eingangs erläutert beschrieben ist. Weiter kommunizieren die in ge­ speicherter Form vorliegenden unterschiedlichen Modelle 2, 3, 4 üblicherweise auch untereinander. Die Anzahl der zum Ein­ satz kommenden Modelle bzw. Klassen von Sprachen ist dabei nicht festgelegt, wobei auch lediglich zwei Sprachen, z. B. eine Hardware-Beschreibungssprache und eine Testbenchsprache, verwendet werden können, d. h. es ist insbesondere auch mög­ lich, ein nur aus einem Hardware-Modell und einem Software- Programm bestehendes System zu simulieren und auf Fehler zu untersuchen.

Alle Modelle 2, 3, 4 des zu simulierenden Systems 1 verfügen über eine entsprechende Schnittstelle 8, 9, 10 zu einer spe­ ziell auf das jeweilige Modell abgestimmten Fehlersuchein­ richtung in Form von Debuggern 5-7, d. h. für jedes Modell 2, 3, 4 ist ein optimaler Debugger mit eigenen, unterschiedli­ chen Kommandos vorgesehen.

Im Gegensatz zu herkömmlichen Fehlersuchvorrichtungen muss der Benutzer bei der erfindungsgemäßen Fehlersuchvorrichtung jedoch nicht mit den mehreren unterschiedlichen speziellen Debuggern 5-7 arbeiten und diese kontrollieren. Dem Benutzer steht vielmehr eine übergeordnete Fehlersucheinrichtung in Form eines einheitlichen Debuggers 11 zur Verfügung, auf die er über eine geeignete Benutzer-Schnittstelle 12 zugreifen kann. Dieser einheitliche Debugger 11 besitzt einen eigenen Kommando-Interpreter mit eigenen Kommandos und gegebenenfalls einer eigenen graphischen Oberfläche. Dieser Kommando- Interpreter setzt seine eigenen Kommandos in die jeweiligen Kommandos der unterschiedlichen speziellen Debugger 5, 6, 7 um und führt die so umgesetzten Kommandos den einzelnen spe­ ziellen Debuggern 5, 6, 7 zur Abarbeitung entsprechender Feh­ lersuchoperationen durch Zugriff auf das jeweilige Modell zu. Umgekehrt setzt der Kommando-Interpreter des einheitlichen Debuggers 11 die ihm von den verschiedenen speziellen Debug­ gern 5, 6, 7 zugeleiteten Kommandos bzw. Ausgaben und Rück­ meldungen derart um, dass sie dem Benutzer über die Benutzer- Schnittstelle 12 in einer einheitlichen Form dargestellt und ausgegeben werden können.

Bei der Fehlersuchvorrichtung gemäß diesem Ausführungsbei­ spiel muss der Benutzer nicht wie bei bisherigen Systemen mehrere Debugger 5-7 parallel kontrollieren, sondern der Be­ nutzer bedient bzw. kontrolliert nur den einheitlichen Debug­ ger 11. Somit ist die Durchführung der Fehlersuche für den Benutzer wesentlich vereinfacht.

Eine alternative Ausführungsform der erfindungsgemäßen Feh­ lersuchvorrichtung ist in Fig. 2 dargestellt. Gleiche Be­ standteile der Anordnung sind dabei mit den gleichen Bezugs­ zeichen wie bei dem ersten Ausführungsbeispiel von Fig. 1 versehen.

Das zweite Ausführungsbeispiel unterscheidet sich von dem in Fig. 1 dargestellten Ausführungsbeispiel dadurch, dass der spezielle Debugger 6 für das Software-Programm 3 entfällt. Dies bedeutet, dass der einheitliche Debugger 11 in diesem Fall direkt auf die Debugger-Schnittstelle 9 des Software- Programms 3 kontrollierend und analysierend zugreift. In UNIX-Betriebssystemen wird im Zusammenhang mit einer derarti­ gen Debugger-Schnittstelle 9 der Begriff "Common Object For­ mat" verwendet. Für den Fall, dass auch bezüglich des Hard­ ware-Modells 2 und/oder des Testbench-Modells 4 derartige allgemeine Schnittstellen 8 bzw. 10 vorhanden sind, können analog der Hardware-Debugger 5 und der Testbench-Debugger 7 entfallen, da der einheitliche Debugger 11 dann direkt auf das Hardware-Modell 2 bzw. das Testbench-Modell 4 zugreifen kann.

Die Kommunikation zwischen dem einheitlichen Debugger 11 und den verwendeten speziellen untergeordneten Debuggern 5, 6, 7 beruht bei beiden Ausführungsbeispielen der erfindungsgemäßen Fehlersuchvorrichtung vorzugsweise auf einer sogenannten Mas­ ter-Slave-Kommunikation. Dabei fungiert während der gesamten Simulation der einheitliche Debugger 11 als Master, während die einzelnen speziellen Debugger 5, 6, 7 als Slaves arbei­ ten. Somit wird jede Anfrage des einheitlichen Debuggers 11 an einen der eingesetzten Debugger 5, 6, 7 von diesem mit ei­ ner Bestätigung quittiert. Eine solche Bestätigung kann bei­ spielsweise lediglich ein Prompt, d. h. eine erneute Eingabe­ aufforderung des jeweiligen Debuggers 5-7, sein. Zusätzlich zu dieser Bestätigung können bei Bedarf, zum Beispiel wenn von dem übergeordneten einheitlichen Debugger 11 ein Befehl zur Berechnung des Wertes eines Objekts an einen untergeord­ neten speziellen Debugger 5-7 gegeben wird, von dem jeweili­ gen speziellen Debugger 5, 6, 7 an den einheitlichen Debugger 11 weitere Informationen, wie beispielsweise der Wert dieses Objekts, zurückgegeben werden. Dabei läuft die Kommunikation zwischen dem einheitlichen Debugger 11 und den speziellen De­ buggern 5-7 vollautomatisiert und rechnergestützt ab, d. h. von dem einheitlichen Debugger 11 wird automatisch eine Be­ nutzereingabe erfasst und in eine entsprechende Ansteue­ rung/Aktivierung der speziellen Debugger 5-7 umgesetzt, wel­ che ihrerseits die entsprechenden Fehlersuchoperationen auto­ matisch/rechnergestützt durchführen.

Anhand der Fig. 3 bis 5 werden nun beispielhaft verschiedene Funktionsabläufe erläutert, die bei einem Fehlersuchverfahren mit der oben beschriebenen Fehlersuchvorrichtung auftreten können. Selbstverständlich ist das Fehlersuchverfahren gemäß der vorliegenden Erfindung nicht auf diese drei grundlegenden Funktionsabläufe beschränkt, sondern diese dienen lediglich dem besseren Verständnis der Erfindung, und der Fachmann wird den erfindungsgemäßen Aufbau ohne weiteres auf weitere Funk­ tionsabläufe übertragen, die bei einer Fehlersuche in Syste­ men mit mehreren unterschiedlichen Modellen benötigt werden.

In Fig. 3 ist zunächst der Funktionsablauf für ein Kommando dargestellt, das von dem einheitlichen Debugger 11 an alle vorhandenen speziellen Debugger 5-7 geschickt wird.

Bei dem gezeigten Beispiel wird von dem Benutzer über die Be­ nutzer-Schnittstelle 12 beispielsweise das Kommando "Start" an den einheitlichen Debugger 11 gegeben. Der einheitliche Debugger bzw. Haupt-Debugger 11 setzt das Kommando "Start" in die äquivalenten Kommandos der speziellen Debugger 5, 6, 7, wie beispielsweise "run" oder "start", um und leitet diese umgesetzten Kommandos an die einzelnen speziellen Debugger 5, 6, 7 weiter. Wie bei dem in Fig. 1 gezeigten Fall werden als spezielle untergeordnete Debugger ein Hardware-Debugger (HW- Debugger) 5, der auf ein Hardware-Modell (HW-Modell) 2 zu­ greift, ein Software-Debugger (SW-Debugger) 6, der auf ein Software-Programm/Modell (SW-Programm) 3 zugreift, und ein Testbench-Debugger (TB-Debugger) 7, der auf ein Testbench- Modell (TB-Modell) 4 zugreift, verwendet.

Nachdem alle Debugger 5, 6, 7 aufgrund des von dem einheitli­ chen Debugger 11 zugeführten Startkommandos die Abarbeitung ihrer Modelle bzw. Programme 2, 3, 4 begonnen haben, beginnt in der Regel eine beliebige Abfolge von Interaktionen zwi­ schen den Modellen bzw. Programmen, wie dies in Fig. 3 durch Pfeile angedeutet ist. Ist die Ausführung der Modelle 2, 3, 4 beendet, dann schicken die zugeordneten Debugger 5, 6, 7 je­ weils eine spezifische "Ende"-Meldung an den einheitlichen Debugger 11, wobei diese "Ende"-Meldungen möglicherweise auch korreliert erfolgen können. Das Haupt-Fehlersuchprogramm 11 setzt dann diese "Ende"-Meldungen um und gibt eine entspre­ chende "Ende"-Rückmeldung an die Benutzer-Schnittstelle 12 aus.

Zur Verwaltung aller an einer Simulation des Systems 1 betei­ ligten Objekte muss der einheitliche Debugger 11 die Objekte aller Modelle 2, 3, 4 zusammenfassen. Dies bedeutet, dass un­ terschiedliche Namensbereiche (Hardware, Software, Testbench) gemeinsam verwaltet werden müssen. Da grundsätzlich die Mög­ lichkeit besteht, dass zum Beispiel eine Variable des Soft­ ware-Programms 3 den gleichen Namen wie ein Signal des Hard­ ware-Modells 2 besitzt, ist es von Vorteil, wenn der einheit­ liche Debugger 11 in der Lage ist, die lokalen Namensbereiche der einzelnen Modelle 2, 3, 4 intern zu globalen Namen zu er­ weitern, um sie unterscheiden zu können.

Anhand von Fig. 4 wird nun der Funktionsablauf für ein vom Benutzer eingegebenes Kommando zur Abfrage des Wertes eines Objekts von einem bestimmten Modell erläutert.

Zunächst muss der einheitliche Debugger 11 anhand des globa­ len Objektnamens, zu dem der Wert abgefragt werden soll, bestimmen, in welchem Modell 2, 3, 4 das gewünschte Objekt vorhanden ist. Dann ermittelt der einheitliche Debugger 11 den entsprechenden lokalen Namen des Objekts und fragt mit­ tels entsprechendem Kommando den Wert des Objekts bei dem je­ weiligen untergeordneten speziellen Debugger (im vorliegenden Fall bei dem Software-Debugger 6) ab, unter dessen Kontrolle das bestimmte Modell 3 abläuft, zu dem das Objekt gehört. Der spezielle Debugger 6 gibt dann den gewünschten Wert des Ob­ jekts an den einheitlichen Debugger 11 zurück, welcher diesen Wert, gegebenenfalls nach einer weiteren Bearbeitung, an die Benutzer-Schnittstelle 12 weiterleitet.

Auf ähnliche Weise können durch den Benutzer Abbruch­ bedingungen gesetzt oder gelöscht oder Werte von Objekten ge­ setzt werden. In solchen Fällen wird dann von dem jeweiligen speziellen Debugger 5, 6, 7 anstelle des Wertes des Objekts, wie oben beschrieben, nur eine Bestätigung an den einheitli­ chen Debugger 11 zurückgegeben.

Schließlich wird als drittes Beispiel eines Funktionsablaufs anhand von Fig. 5 die Abarbeitung eines Einzelschritt- Kommandos veranschaulicht.

Aufgrund eines vom Benutzer über die Benutzer-Schnittstelle 12 eingegebenen Einzelschritt-Kommandos generiert der ein­ heitliche Debugger 11 ein entsprechendes Einzelschritt- Kommando für das gewünschte Modell (im vorliegenden Fall das Testbench-Modell 4) und gibt dieses an den dem Modell 4 zuge­ ordneten Debugger 7 weiter. Daraufhin wird das Modell 4 im Einzelschritt-Modus betrieben, während die anderen Modelle 2, 3 auch ohne Unterbrechung und nicht im Einzelschritt-Modus ablaufen können. Nach Beendigung des Einzelschritts gibt der Debugger 7 eine Bestätigung, dass der Einzelschritt von dem Modell 4 abgeschlossen ist, an den einheitlichen Debugger 11 zurück, der diese Bestätigung in ein entsprechendes Kommando für die Benutzer-Schnittstelle 12 umsetzt.

Bei dem oben beschriebenen Funktionsablauf ist es im allge­ meinen unerheblich, ob ein Einzelschritt über eine einzige Einzelanweisung oder über mehrere zusammengefasste Einzelan­ weisungen abläuft. Außerdem kann das Einzelschritt-Kommando je nach Kommando des Benutzers sowohl nur für ein Modell als auch für mehrere oder für alle Modelle 2, 3, 4 gelten.

Claims (19)

1. Fehlersuchverfahren für ein durch mehrere unterschiedli­ che Simulationsmodelle simuliertes System,
wobei das System (1) in den einzelnen Simulationsmodellen (2-­ 4) durch Beschreibungssprachen unterschiedlicher Klassen be­ schrieben wird, und
wobei den einzelnen Simulationsmodellen (2-4) unterschiedli­ che erste Fehlersucheinrichtungen (5-7) zum Auffinden eines Fehlers jeweils mittels Zugriff auf das entsprechende Simula­ tionsmodell (2-4) zugeordnet sind,
gekennzeichnet durch die Schritte

• a) automatisches Erfassen einer Benutzereingabe mit Hilfe einer zweiten Fehlersucheinrichtung (11), welche den ersten Fehlersucheinrichtungen (5-7) übergeordnet ist, und
• b) automatisches Ansteuern der ersten Fehlersucheinrichtun­ gen (5-7) durch die zweite Fehlersucheinrichtung (11) in Ab­ hängigkeit von der Benutzereingabe, um durch Zugriff auf das jeweilige Simulationsmodell (2-4) einen Systemfehler zu fin­ den.

2. Fehlersuchverfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein Simulationsmodell (2) ein Hardware-Simulationsmodell ist, in dem das System (1) durch eine Hardware- Beschreibungssprache beschrieben ist, wobei diesem Simulati­ onsmodell (2) als eine entsprechende erste Fehlersucheinrich­ tung ein Hardware-Debugger (5) zugeordnet ist.

3. Fehlersuchverfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass ein Simulationsmodell (4) ein Testbench- Simulationsmodell ist, in dem das System (1) durch eine Testbench-Sprache beschrieben ist, wobei diesem Simulations­ modell (4) als eine entsprechende erste Fehlersucheinrichtung ein Testbench-Debugger (7) zugeordnet ist.

4. Fehlersuchverfahren nach einem der vorhergehenden An­ sprüche, dadurch gekennzeichnet, dass ein Simulationsmodell (3) ein Software-Simulationsmodell ist, in dem das System (1) durch eine Programmiersprache be­ schrieben ist, wobei diesem Simulationsmodell (3) als eine entsprechende erste Fehlersucheinrichtung ein Software- Debugger (6) zugeordnet ist.

5. Fehlersuchverfahren nach einem der vorhergehenden An­ sprüche, dadurch gekennzeichnet, dass die übergeordnete zweite Fehlersucheinrichtung (11) di­ rekt auf mindestens ein Simulationsmodell (3) ohne Zwischen­ schaltung einer ersten Fehlersucheinrichtung zugreift.

6. Fehlersuchverfahren nach einem der vorhergehenden An­ sprüche, dadurch gekennzeichnet, dass von der zweiten Fehlersucheinrichtung (11) eine Benut­ zereingabe automatisch in entsprechende Kommandos für die einzelnen ersten Fehlersucheinrichtungen (5-7) umgesetzt wird.

7. Fehlersuchverfahren nach einem der vorhergehenden An­ sprüche, dadurch gekennzeichnet, dass von den ersten Fehlersucheinrichtungen (5-7) automatisch in Abhängigkeit von der Ansteuerung durch die zweite Fehler­ sucheinrichtung (11) durch Zugriff auf das jeweilige Simula­ tionsmodell (2-4) eine entsprechende Fehlersuchoperation durchgeführt wird, wobei von der zweiten Fehlersucheinrich­ tung (11) automatisch eine von den einzelnen ersten Fehler­ sucheinrichtungen (5-7) im Laufe der jeweiligen Fehlersuch­ operation generierte Rückmeldung erfasst und an den Benutzer ausgegeben wird.

8. Fehlersuchverfahren nach einem der vorhergehenden An­ sprüche, dadurch gekennzeichnet, dass die Kommunikation zwischen der zweiten Fehlersuchein­ richtung (11) und den ersten Fehlersucheinrichtungen (5-7) in Form einer Master-Worker-Kommunikation erfolgt, wobei die zweite Fehlersucheinrichtung (11) als Master und die ersten Fehlersucheinrichtungen (5-7) als Workers fungieren.

9. Vorrichtung zur Fehlersuche für ein durch mehrere unter­ schiedliche Simulationsmodelle simuliertes System,
wobei das System (1) in den einzelnen Simulationsmodellen (2-­ 4) durch Beschreibungssprachen unterschiedlicher Klassen be­ schrieben ist,
mit mehreren unterschiedlichen ersten Fehlersucheinrichtungen (5-7), welche jeweils einem entsprechenden Simulationsmodell (2-4) zugeordnet sind, zum Auffinden eines Systemfehlers mit­ tels Zugriff auf das entsprechende Simulationsmodell (2-4),
dadurch gekennzeichnet,
dass eine den ersten Fehlersucheinrichtungen (5-7) übergeord­ nete zweite Fehlersucheinrichtung (11) vorgesehen ist,
wobei die zweite Fehlersucheinrichtung (11) zum automatischen Erfassen einer Benutzereingabe und zum automatischen Ansteu­ ern der ersten Fehlersucheinrichtungen (5-7) in Abhängigkeit von der Benutzereingabe zum Auffinden eines Fehlers durch Zugriff auf das jeweilige Simulationsmodell (2-4) ausgestal­ tet ist.

10. Vorrichtung zur Fehlersuche nach Anspruch 9, dadurch gekennzeichnet, dass ein Simulationsmodell (2) ein Hardware-Simulationsmodell ist, in dem das System (1) durch eine Hardware- Beschreibungssprache beschrieben ist, wobei diesem Simulati­ onsmodell (2) als eine entsprechende erste Fehlersucheinrich­ tung ein Hardware-Debugger (5) zugeordnet ist.

11. Vorrichtung nach Anspruch 9 oder 10, dadurch gekennzeichnet, dass ein Simulationsmodell (4) ein Testbench- Simulationsmodell ist, in dem das System (1) durch eine Testbench-Sprache beschrieben ist, wobei diesem Simulations­ modell (4) als eine entsprechende erste Fehlersucheinrichtung ein Testbench-Debugger (7) zugeordnet ist.

12. Vorrichtung zur Fehlersuche nach einem der Ansprüche 9-­ 11, dadurch gekennzeichnet, dass ein Simulationsmodell (3) ein Software-Simulationsmodell ist, in dem das System (1) durch eine Programmiersprache be­ schrieben ist, wobei diesem Simulationsmodell (3) als eine entsprechende erste Fehlersucheinrichtung ein Software- Debugger (6) zugeordnet ist.

13. Vorrichtung zur Fehlersuche nach einem der Ansprüche 9-­ 12, dadurch gekennzeichnet, dass die zweite Fehlersucheinrichtung (11) direkt auf mindes­ tens ein Simulationsmodell (3) ohne Zwischenschaltung einer entsprechenden ersten Fehlersucheinrichtung zugreift.

14. Vorrichtung zur Fehlersuche nach einem der Ansprüche 9-­ 13, dadurch gekennzeichnet, dass die zweite Fehlersucheinrichtung (11) zur automatischen Umsetzung der Benutzereingabe in entsprechende Kommandos für die einzelnen ersten Fehlersucheinrichtungen (5-7) ausgestal­ tet ist.

15. Vorrichtung zur Fehlersuche nach einem der Ansprüche 9-­ 14, dadurch gekennzeichnet,
dass die einzelnen ersten Fehlersucheinrichtungen (5-7) zur automatischen Durchführung entsprechender Fehlersuchoperatio­ nen in Abhängigkeit von der Ansteuerung durch die zweite Feh­ lersucheinrichtung (11) durch Zugriff auf das jeweilige Simu­ lationsmodell (2-4) ausgestaltet sind, und
dass die zweite Fehlersucheinrichtung (11) zum automatischen Erfassen von Rückmeldungen, welche von den ersten Fehlersuch­ einrichtungen (5-7) im Laufe der jeweiligen Fehlersuchopera­ tionen generiert werden, ausgestaltet ist, um diese an den Benutzer auszugeben.

16. Vorrichtung zur Fehlersuche nach einem der Ansprüche 9-­ 15, dadurch gekennzeichnet, dass die einzelnen ersten Fehlersucheinrichtungen (5-7) und die zweite Fehlersucheinrichtung (11) zur Realisierung einer Master-Slave-Kommunikation zwischen der ersten Fehlersuchein­ richtung (11) als Master einerseits und den einzelnen zweiten Fehlersucheinrichtungen (5-7) als Workers andererseits aus­ gestaltet sind.

17. Vorrichtung zur Fehlersuche nach einem der Ansprüche 9-­ 16, dadurch gekennzeichnet, dass den einzelnen Simulationsmodellen (2-4) jeweils eine Schnittstelle (8-10) zur Anbindung an die jeweilige erste Fehlersucheinrichtung (5-7) zugeordnet ist.

18. Vorrichtung zur Fehlersuche nach einem der Ansprüche 9-­ 17, dadurch gekennzeichnet, dass die einzelnen Simulationsmodelle (2-4) durch Einrichtun­ gen realisiert sind, welche zur Kommunikation untereinander ausgestaltet sind.

19. Verwendung einer Vorrichtung nach einem der Ansprüche 9-­ 18 für den Entwurf von elektronischen Schaltungen.