DE10213837A1

DE10213837A1 - Systemsimulator, Simulationsverfahren und Simulationsprogramm

Info

Publication number: DE10213837A1
Application number: DE10213837A
Authority: DE
Inventors: Eiji Shamoto; Masahiro Fukuda
Original assignee: NEC Corp
Current assignee: NEC Electronics Corp
Priority date: 2001-03-30
Filing date: 2002-03-27
Publication date: 2002-12-12
Also published as: US20020143512A1; JP4529063B2; US7246052B2; JP2002297414A

Abstract

Der Systemsimulator umfasst Mastersimulatoren (1f, 1s, 2f und 2s) zum Simulieren eines Bus-Masters, einen Slave-Simulator (L) zum Simulieren eines Bus-Slave, einen Funktionsmanager (F) zum aufeinanderfolgenden Betätigen des Mastersimulators (1f, 1s, 2f und 2s) und des Slave-Simulators (L) durch Verwendung eines Funktionsaufrufs und einen Pfadmanager (S) zum Betätigen des Mastersimulators (1f, 1s, 2f und 2s) durch Verwendung von Pfadumschaltung. Wenn der durch Verwendung des Funktionsaufrufs von dem Funktionsmanager (F) aktivierte Mastersimulator (1f, 1s, 2f und 2s) auf den Slave-Simulator (L) zugreift und eine Zugriffsblockierung verursacht wird, steuert der Mastersimulator (1f, 1s, 2f und 2s) den Pfadmanager (S) derart, dass der Mastersimulator (1f, 1s, 2f und 2s) durch Verwendung der Pfadumschaltung aktiviert wird, die durch den Pfadmanager (S) ausgeführt wird. Auf diese Weise ist es möglich, die Simulation bei einer hohen Geschwindigkeit auszuführen, ohne in einen Verklemmungszustand [Deadlock] zu geraten, der durch Zugriffsblockierung verursacht wird, und ohne Änderung des Simulators zum Simulieren eines konventionellen Bus-Masters.

Description

Hintergrund der Erfindung 1. Gebiet der Erfindung

Die vorliegende Erfindung betrifft einen Systemsimulator, ein Simulationsverfahren und ein Simulationsprogramm. Genauer ausgedrückt, betrifft die vorliegende Erfindung eine Technik zum Simulieren eines solchen Systems, bei dem ein Bus-Master und ein Bus- Slave miteinander durch einen Bus verbunden sind.

2. Beschreibung des verwandten technischen Gebiets

Konventionell ist als ein Gerät, an das ein Mikroprozessor angelegt wird, ein solches Sys tem bekannt, bei dem ein Bus-Master (im folgenden lediglich als "Master" bezeichnet) und ein Bus-Slave (im folgenden lediglich als "Slave" bezeichnet) miteinander durch einen Bus verbunden sind. Die für dieses System angewendete Software wird typischerweise durch Verwendung der Hardware entwickelt, nachdem die Hardwareumgebung zum Bedienen der Software hergestellt ist, mit anderen Worten, nach Abschluss der Entwicklung der Hardware.

Bei dem oben genannten konventionellen Entwicklungsverfahren wird jedoch eine lange Zeit zum Entwickeln des Systems benötigt. Deshalb wird seit kurzem zum Verringern der Entwicklungszeitspanne ein solches Entwicklungsverfahren verwendet, dass die Entwick lung der Software auf einem Systemsimulator durchgeführt wird. Durch Verwendung die ses Verfahrens kann die Entwicklung der Software parallel mit der Entwicklung der Hard ware durchgeführt werden. Als Ergebnis kann die Entwicklungszeitspanne verkürzt wer den.

Fig. 1 zeigt eine Konfiguration eines konventionellen Systemsimulators (im folgenden als "Systemsimulator gemäß einer ersten konventionellen Technik" bezeichnet), der für die Entwicklung der Software verwendet wird. Dieser Systemsimulator umfasst einen ersten Master, einen zweiten Master, einen Slave und einen Manager.

Der erste Master ist ein Simulator, der aus einem Programm zum Simulieren einer Opera tion einer als ein Master verwendeten Einrichtung so wie einer CPU und DMA besteht. Der zweite Master ist ein anderer Simulator, der aus einem Programm zum Simulieren einer als der Master verwendeten anderen Einrichtung besteht. Der Slave ist ein Simulator, der aus einem Programm zum Simulieren einer als ein Slave verwendeten Peripherie schaltung so wie ein Zeitglied, ein serieller Eingangausgangsanschluss, ein gewöhnlicher Eingangsausgangsanschluss und ein Speicher besteht. Der Manager ist das Steuerpro gramm zum Bedienen des ersten Masters, des zweiten Masters und des Slave synchron miteinander.

Der Systemsimulator gemäß der ersten konventionellen Technik mit der oben genannten Konfiguration wird verwendet, um die Korrektheit des Programm nachzuprüfen, das in jedem des ersten Masters, des zweiten Masters und des Slave enthalten ist.

Bei dem Systemsimulator gemäß dieser ersten konventionellen Technik schreitet die Si mulation fort, während der Manager nacheinander einen Funktionsaufruf an den ersten Master, den zweiten Master und den Slave durchführt. Genau ausgedrückt, führt der Ma nager zuerst den Funktionsaufruf an den ersten Master durch. Dementsprechend führt der ersten Master einen Prozess entsprechend einem Takt aus. Wenn zum Beispiel das Ziel des Funktionsaufrufs eine in einem Takt abzuschließende Anweisung ist, wird die Ausführung der Anweisung durchgeführt. Danach wird die Steuerung zu dem Manager zurückgeführt. Wenn das Ziel des Funktionsaufrufs eine Anweisung ist, die eine Mehrzahl von Takten erfordert, wird die Steuerung nach Abschluss eines dem einen Takt entsprechenden Pro zesses zu dem Manager zurückgeführt.

Als nächstes führt der Manager den Funktionsaufruf an den zweiten Master durch, ähnlich zu dem oben genannten Fall. Anschließend führt der Manager den Funktionsaufruf an den Slave durch. Danach wird die Simulation dadurch vorgerückt, dass dieser Funktionsaufruf an den ersten Master → den zweiten Master → den Slave → den ersten Master →. . . . zy klisch durchgeführt wird. Es soll festgestellt werden, dass, wenn das Ziel des Funktions aufrufs die Anweisung ist, die die Mehrzahl von Takten benötigt, die Ausführung der An weisung durch Ausführung der Mehrzahl von Funktionsaufrufen bis zu dem Ziel vervoll ständigt wird.

Wie oben beschrieben, führen der erste Master, der zweite Master und der Slave nachei nander den Prozess aus, der dem einen Takt für jede Ausführung des Funktionsaufrufs von dem Manager entspricht. Daher werden der erste Master, der zweite Master und der Slave bedient, als wenn sie synchron mit dem Takt sind. Das heißt, es kann angenommen wer den, dass der erste Master, der zweite Master und der Slave derart bedient werden, dass die Betriebszeitabläufe von dem Manager gegeben werden. Folglich ist es möglich, die Simu lation durchzuführen, in der die Betriebszeitabläufe berücksichtigt werden.

Fig. 2 zeigt eine Konfiguration eines anderen konventionellen Systemsimulators (im fol genden als "Systemsimulator gemäß einer zweiten konventionellen Technik" bezeichnet), der ein Semaphor als einen Synchronisiermechanismus zum Synchronisieren einer Mehr zahl von Simulatoren miteinander verwendet. Der Systemsimulator gemäß der zweiten konventionellen Technik führt immer einen Mehrpfadbetrieb aus.

Der Systemsimulator gemäß dieser zweiten konventionellen Technik umfasst einen ersten Master, einen zweiten Master, einen Slave, einen Manager und einen Bus. Der erste Mas ter, der zweite Master, der Slave und der Manager weisen jeweils ähnliche Funktionen wie diejenigen des oben genannten konventionellen Systemsimulators gemäß der ersten kon ventionellen Technik auf. Der Bus ist der Simulator zum Simulieren der Operation des Busses, wenn der erste Master und der zweite Master auf den Slave zugreifen.

In Fig. 2 kennzeichnen Symbole "o" in dem ersten Master, dem zweiten Master, dem Ma nager und dem Bus die Semaphore. Ein Symbol "P" kennzeichnet eine Ausführung einer Eingabe, ein Symbol "W" kennzeichnet eine Ausführung eines Wartevorgangs, und eine Symbol "T" kennzeichnet eine Ausführung eines Warteversuchs. Der Warteversuch ist eine Funktion der Durchführung einer Anfrage an den Bus. Der Systemsimulator gemäß dieser zweiten konventionellen Technik wird so gesteuert, um nur einen des ersten Mas ters, des zweiten Masters und des Managers gleichzeitig zu aktivieren.

Grundlegend führt der Manager die Eingabe "P" an das Semaphor des ersten Masters und des zweiten Masters aus (im folgenden können sie lediglich gemeinsam als "Master" be zeichnet werden) und aktiviert dadurch den Pfad des Masters, und der Manager tritt in den Warte-Zustand "W" ein. Ferner führt der Master die Eingabe "P" an das Semaphor des Managers aus, und führt dadurch die Steuerung zurück zum Manager, und der Master selbst tritt in den Warte-Zustand "W" ein. Der Slave wird aktiviert, wenn der Manager den Funktionsaufruf an den Slave ausführt, ähnlich zu dem Systemsimulator gemäß der ersten konventionellen Technik.

Die tatsächlichen Operationen des Systemsimulators gemäß dieser zweiten konventionel len Technik sollen im folgenden unter Bezugnahme auf die Fig. 3 bis 5 beschrieben werden.

Fig. 3 ist ein Erklärungsdiagramm, das die Übertragungsoperation zwischen dem Manager und dem ersten Master zeigt. Gestrichelte Linien zeigen den Fluss der Steuerung an. Der Manager führt zuerst die Eingabe an das Semaphor des ersten Masters durch, und der Ma nager selbst tritt in den Wartezustand ein. Diese Eingabeoperation aktiviert den Pfad des ersten Masters, der sich im Wartezustand befindet, und der Warteversuch wird am Sema phor des Busses durchgeführt. Dann, wenn dieser Warteversuch nicht erfolgreich ist, führt der ersten Master die Eingabe an das Semaphor des Managers aus, und der erste Master tritt in den Wartezustand ein.

Fig. 4 ist ein Erklärungsdiagramm, das die Übertragungsoperation zwischen dem Manager und dem zweiten Master zeigt. Gestrichelte Linien zeigen die Fluss der Steuerung an.

Wenn die Steuerung wie oben erwähnt dadurch an den Manager übertragen wird, dass der erste Master die Eingabe an das Semaphor des Managers ausführt, führt der Manager dann die Eingabe an das Semaphor des zweiten Masters durch, und der Master selbst tritt in den Wartezustand ein. Diese Eingabeoperation aktiviert den Pfad des zweiten Masters, der sich im Wartezustand befindet, und der Warteversuch wird an dem Semaphor des Busses durchgeführt. Wenn dieser Versuch nicht erfolgreich ist, führt der zweite Manager die Ein gabe an das Semaphor des Managers aus, und der zweite Master tritt in den Wartezustand ein.

Fig. 5 ist ein Erklärungsdiagramm, das die Übertragungsoperation zwischen dem Manager und dem Slave zeigt. Gestrichelte Linien geben den Fluss der Steuerung an. Wenn die Steuerung wie oben erwähnt dadurch zu dem Manager übertragen wird, dass der zweite Master die Eingabe an das Semaphor des Managers ausführt, führt der Manager dann den Funktionsaufruf an den Slave durch. Wenn der Slave bei einem Zustand reaktionsfähig auf eine Zugriffsanfrage von dem ersten Master und dem zweiten Master wird, führt der Slave die Eingabe an das Semaphor des Busses durch. Dies impliziert, dass die durch den ersten und zweiten Master durchgeführten nächsten Warteversuche erfolgreich sind. Danach wird die Steuerung vom Slave zum Manager zurückgeführt. Anschließend werden die oben ge nannten Operationen wiederholt.

Wie oben erwähnt, führen der erste und zweite Master, während der Durchführung der Pfadumschaltung, nacheinander den Prozess durch, der dem einen Takt in jedem Pfad ent spricht, und der Slave führt den Prozess aus, der dem einen Takt für jede Durchführung des Funktionsaufrufs von dem Manager entspricht. Daher werden der erste Master, der zweite Master und der Slave betätigt, als wenn sie mit dem Takt synchron sind. Folglich ist es möglich, die Simulation auszuführen, bei der die Betriebszeitabläufe berücksichtigt wer den.

In diesen System gemäß der zweiten konventionellen Technik gibt es, wenn der Master auf den Slave zugreift, selbst wenn eine Zugriffsblockierung erfolgt, nämlich selbst dann, wenn der Master in dem Warteversuch des Busses versagt, keinen Fall, dass der Master fortfährt, auf die Reaktion zu warten. Daher gibt es keinen Fall, dass dieser Systemsimu lator in einen Verklemmungszustand [Deadlock] gerät.

Als eine verwandte Technik offenbart die japanische offengelegte Patentanmeldung (JP-A- Heisei 11-296408) einen Softwarelogiksimulator für ein zusammengebautes Gerät. Dieser Softwarelogiksimulator kann eine Simulation für Hardware durch eine Vielzahl von An wendungen erreichen und eine Verkettungsoperation zwischen ihnen durchführen und da durch die Beschreibung der Hardwareoperationen vereinfachen und ferner eine Fehler sucheffizienz von Software verbessern. Diesem Simulator zufolge ist es möglich, wenn die Fehlersuchoperation in Verkettung zwischen Hardwaresimulator und der Software durch geführt wird, die Probleme zu lösen, dass die Geschwindigkeit der Simulation der Hard wareoperation sehr langsam ist und dass die Beschreibung der Hardware einen Defekt aufweist.

Der Systemsimulator gemäß der ersten konventionellen Technik birgt jedoch das folgende Problem. Das heißt, das Programm des Masters enthält die Anweisung, auf den Slave zu zugreifen. Wenn der Master diese Anweisung ausführt, wenn der Slave auf diese innerhalb einer dem einen Takt entsprechenden Zeit antworten kann, tritt kein Problem auf. Die meisten der Slaves benötigen jedoch mehrere Takte für die Antwort. Das oben genannte Phänomen, dass der Slave nicht sofort auf den Zugriff von dem Master antworten kann, wird als "Zugriffsblockierung" bezeichnet. Die Zugriffsblockierung umfasst eine Lesern griffsblockierung und eine Schreibzugriffsblockierung.

Wenn die Zugriffsblockierung auftritt, tritt der Master in den Wartezustand zum Warten auf die Antwort von dem Slave ein, und die Steuerung wird nicht zum Manager zurückge führt. Folglich wird der Takt nicht dem Slave zugeführt. Daher setzt der Master weiter den Wartezustand fort, und der Systemsimulator gerät in den Verklemmungszustand.

Dieses Problem kann durch derartiges Ändern der Spezifikation des Slave auf dem Sys temsimulator gelöst werden, dass die Antwort in einem Takt zurückgeführt wird. Da bei diesem Ansatz jedoch die Spezifikation des Slave auf dem Systemsimulator sich von der jenigen des tatsächlichen Slave unterscheidet, ist es unmöglich, die Simulation durch Be rücksichtigen des Betriebszeitablaufs durchzuführen. Das oben genannte Problem kann auch durch derartige Auslegung des Programms des Masters gelöst werden, dass der sich im Warte zustand zum Warten auf die Antwort von dem Slave befindende Master gezwun genermaßen die Steuerung zum Manager zurückführt. Bei diesem Ansatz ist es jedoch er forderlich, das konventionelle Programm des Masters neu auszulegen. Wenn es neu aus gelegt ist, wird außerdem die Struktur des Programms komplex. Daher erfordert die Ent wicklung des Programms des Masters eine große Anzahl von Schritten.

Der Systemsimulator gemäß der zweiten konventionellen Technik gerät nicht in den Ver klemmungszustand. Er birgt jedoch das folgende Problem. Dies besteht darin, dass bei diesem Systemsimulator das Pfadumschalten immer unter der Steuerung eines Pfadkon trollers durchgeführt wird. Daher verursacht diese Pfadumschaltung das Auftreten einer Verlustzeit. Die Größe der Verlustzeit wird abhängig von dem im Master installierten Pro gramm bestimmt. Der Messung durch die Ertmder der vorliegenden Erfindung zufolge; ist die Simulationszeit des Systemsimulators gemäß der zweiten konventionellen Technik gleich etwa dem 20- bis 40-fachen der Simulationszeit des Systemsimulators gemäß der ersten konventionellen Technik.

Zusammenfassung der Erfindung

Deshalb besteht eine Aufgabe der vorliegenden Erfindung in der Schaffung eines System simulators, eines Simulationsverfahrens und eines Simulationsprogramms, die eine Simu lation bei einer hohen Geschwindigkeit ausführen können, ohne in einen Verklemmungs zustand zu geraten und ohne einen Simulator zum Simulieren eines konventionellen Bus- Masters zu ändern.

Mittel zum Lösen der Aufgabe sollen im folgenden unter Verwendung von Bezugsziffern und Symbolen beschrieben werden, die in "Ausführungsformen der Erfindung" verwendet werden. Diese Bezugsziffern und Symbole werden hinzugefügt, so dass der Bezug zwi schen der Beschreibung von "Umfang des zu beanspruchenden Patents" und der Beschrei bung von "Ausführungsformen der Erfindung" verdeutlicht wird. Es ist jedoch nie erlaubt, die Bezugsziffern und Symbole für die Interpretation der technischen Umfänge der in "Umfang des zu beanspruchenden Patent" beschriebenen Erfindungen und der Beschrei bung von "Ausführungsformen der Erfindung" zu verwenden.

Zum Lösen der oben genannten Aufgabe umfasst ein Systemsimulator gemäß einem ersten Aspekt der vorliegenden Erfindung einen Mastersimulator (1f, 1s, 2f und 2s), einen Slave- Simulator (F), einen Funktionsmanager (F) und einen Pfadmanager (S). Der Mastersimu lator (1f, 1s, 2f und 2s) simuliert einen Bus-Master. Der Slave-Simulator (L) simuliert ei nen Bus-Slave. Der Funktionsmanager (F) aktiviert nacheinander den Mastersimulator (1f, 1s, 2f und 2s) und den Slave-Simulator (L) durch Verwendung eines Funktionsaufrufs. Der Pfadmanager (S) aktiviert den Mastersimulator (1f, 1s, 2f und 2s) durch Verwendung einer Pfadumschaltung. Wenn der durch Verwendung des Funktionsaufrufs von dem Funkti onsmanager (F) aktivierte Mastersimulator (1f, 1s, 2f und 2s) bei diesem Systemsimulator auf den Slave-Simulator (L) zugreift und eine Zugriffsblockierung verursacht wird, steuert der Mastersimulator (1f, 1s, 2f und 2s) den Pfadmanager (S) derart, dass der Mastersimu lator (1f, 1s, 2f und 2s) durch Verwendung der durch den Pfadmanager (S) durchgeführten Pfadumschaltung aktiviert wird.

Dieser Systemsimulator kann derart ausgelegt sein, dass der Pfadmanager (S) weiter den Slave-Simulator (L) durch Verwendung des Funktionsaufrufs aktiviert. Ferner steuert der Pfadmanager (S) nach Aufhebung der Zugriffsblockierung den Funktionsmanager (F) der art, dass der Mastersimulator (1f, 1s, 2f und 2s) durch Verwendung des Funktionsaufrufs aktiviert wird.

Zum Lösen der oben genannten Aufgabe, umfasst ein Simulationsverfahren gemäß einem zweiten Aspekt der vorliegenden Erfindung die folgenden Schritte: (1) Vorsehen eines Mastersimulators (1f, 1s, 2f und 2s) zum Simulieren eines Bus-Masters und eines Slave- Simulators (L) zum Simulieren eines Bus-Slave, (2) nacheinander Aktivieren des Master simulators (1f, 1s, 2f und 2s) und des Slave-Simulators (L) durch Verwendung eines Funktionsaufrufs und (3) Betätigen des Mastersimulators (1f, 1s, 2f und 2s) durch Ver wendung einer Pfadumschaltung, wenn der durch Verwendung des Funktionsaufrufs akti vierte Mastersimulator (1f, 1s, 2f und 2s) auf den Slave-Simulator (L) zugreift und eine Zugriffsblockierung verursacht.

Dieses Simulationsverfahren kann derart ausgelegt werden, dass der Schritt (3) ferner den Slave-Simulator (L) durch Verwendung des Funktionsaufrufs aktiviert. Weiter umfasst das Simulationsverfahren die Betätigung des Mastersimulators (1f, 1s, 2f und 2s) durch Ver wendung des Funktionsaufrufs nach Aufhebung der Zugriffsblockierung.

Zum Lösen der oben genannten Aufgabe umfasst ein Systemsimulationsprogramm gemäß einem dritten Aspekt der vorliegenden Erfindung ein Mastersimulationsprogramm (1f, 1s, 2f und 2s), ein Slave-Simulationsprogramm (L), ein Funktionsmanagerprogramm (F) und ein Pfadmanagerprogramm (S). Das Mastersimulationsprogramm (1f, 1s, 2f und 2s) simu liert einen Bus-Master. Das Slave-Simulationsprogramm (L) simuliert einen Bus-Slave. Das Funktionsmanagerprogramm (F) aktiviert nacheinander das Mastersimulationspro gramm (1f, 1s, 2f und 2s) und das Slave-Simulationsprogramm (L) durch Verwendung eines Funktionsaufrufs. Das Pfadmanagerprogramm (S) aktiviert das Mastersimulations programm (1f, 1s, 2f und 2s) durch Verwendung einer Pfadumschaltung. Wenn in diesem Systemssmulationsprogramm das durch Verwendung des Funktionsaufrufs von dem Funk tionsmanagerprogramm (F) aktivierte Mastersimulationsprogramm (1f, 1s, 2f und 2s) auf das Slave-Simulationsprogramm (L) zugreift und eine Zugriffsblockierung verursacht wird, steuert das Mastersimulationsprogramm (1f, 1s, 2f und 2s) das Pfadmanagerpro gramm (S) derart, dass das Mastersimulationsprogramm (1f, 1s, 2f und 2s) durch Verwen dung der durch das Pfadmanagerprogramm (S) durchgeführten Pfadumschaltung aktiviert wird.

Dieses Systemsimulationsprogramm kann derart ausgelegt sein, dass das Pfadmanagerpro gramm (S) weiter das Slave-Simulationsprogramm (L) durch Verwendung des Funktions aufrufs aktiviert. Ferner steuert das Pfadmanagerprogramm (S) nach Aufhebung der Zu griffsblockierung das Funktionsmanagerprogramm (F) derart, dass das Mastersimulations programm (1f, 1s, 2f und 2s) durch Verwendung des Funktionsaufrufs aktiviert wird.

Kurze Beschreibung der Zeichnungen

Fig. 1 zeigt eine Konfiguration eines Systemsimulators gemäß einer ersten konventio nellen Technik;

Fig. 2 zeigt eine Konfiguration eines anderen Systemsimulators gemäß einer zweiten konventionellen Technik;

Fig. 3 ist ein Erklärungsdiagramm, das die Übertragungsoperation zwischen einem ersten Master und einem Manager in dem in Fig. 2 gezeigten Systemsimulator zeigt;

Fig. 4 ist ein Erklärungsdiagramm, das die Übertragungsoperation zwischen einem zweiten Master und dem Manager in dem in Fig. 2 gezeigten Systemsimulator zeigt;

Fig. 5 ist ein Erklärungsdiagramm, das die Übertragungsoperation zwischen einem Slave und dem Manager des in Fig. 2 gezeigten Systemsimulators zeigt;

Fig. 6 ist ein Funktionsblockdiagramm, das eine Konfiguration eines Systemsimulators gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;

Fig. 7 ist ein Erklärungsdiagramm, das eine Operation zeigt, wenn keine Zugriffsblo ckierung auftritt, in dem Systemsimulator gemäß der Ausführungsform der vor liegenden Erfindung;

Fig. 8 ist ein Erklärungsdiagramm, das eine Operation (Nr. 1) zeigt, wenn Zugriffs blockierung auftritt, in dem Systemsimulator gemäß der Ausführungsform der vorliegenden Erfindung;

Fig. 9 ist ein Erklärungsdiagramm, das eine Operation (Nr. 2) zeigt, wenn die Zugriffs blockierung auftritt, in dem Systemsimulator gemäß der Ausführungsform der vorliegenden Erfindung;

Fig. 10 ist ein Erklärungsdiagramm, das eine Operation (Nr. 3) zeigt, wenn die Zugriffs blockierung auftritt, in dem Systemsimulator gemäß der Ausführungsform der vorliegenden Erfindung;

Fig. 11 ist ein Erklärungsdiagramm, das eine Operation (Nr. 4) zeigt, wenn die Zugriffs blockierung auftritt, in dem Systemsimulator gemäß der Ausführungsform der vorliegenden Erfindung;

Fig. 12 ist ein Ablaufdiagramm, das einen Hauptprozess in dem Systemsimulator gemäß der Ausführungsform der vorliegenden Erfindung zeigt;

Fig. 13 ist ein Ablaufdiagramm, das detailliert einen Prozess zum Erzeugen eines Pfads eines Masters S in Fig. 12 zeigt;

Fig. 14 ist ein Ablaufdiagramm, das detailliert einen Prozess zum Vorrücken der Sys temzeit eines Managers F um einen Takt in Fig. 12 zeigt;

Fig. 15 ist ein Ablaufdiagramm, das detailliert einen Prozess zum Vorrücken der Sys temzeit eines Managers S um einen Takt in Fig. 12 zeigt;

Fig. 16 ist ein Ablaufdiagramm, das detailliert einen Prozess eines Schritts S27 in Fig. 14 zeigt;

Fig. 17 ist ein Ablaufdiagramm, das detailliert einen Prozess eines Schritts S64 in Fig. 16 zeigt;

Fig. 18 ist ein Ablaufdiagramm, das detailliert einen Prozess eines Schritts S71 in Fig. 17 zeigt;

Fig. 19 ist ein Ablaufdiagramm, das detailliert einen Prozess eines Schritts S75 in Fig. 17 zeigt;

Fig. 20 ist ein Ablaufdiagramm, das detailliert einen Prozess eines Schritts S42 in Fig. 15 zeigt; und

Fig. 21 ist ein Ablaufdiagramm, das detailliert einen Prozess eines Schritts S95 in Fig. 20 zeigt.

Beschreibung der bevorzugten Ausführungsform

Eine Ausführungsform der vorliegenden Erfindung soll im folgenden ausführlich unter Bezugnahme auf die beigefügten Zeichnungen beschrieben werden.

Fig. 6 ist ein Funktionsblockdiagramm, dass die Konfiguration eines Systemsimulators gemäß einer Ausführungsform der vorliegenden Erfindung zeigt. Dieser Simulator wird an einem Informationsverarbeitungsgerät, so wie einem Personalcomputer, einer Workstation oder einem Mehrzweckcomputer durch Installierung von Software eingesetzt. Die Konfi guration und der Betrieb des Informationsverarbeitungsgeräts sind gut bekannt. Deshalb sind ihre Erklärungen weggelassen worden.

Dieser Systemsimulator besteht aus einem ersten Master 1f für eine Funktion (im folgen den als "erster Funktionsmaster 1f" bezeichnet), einem ersten Master 1s für einen Pfad (im folgenden als "erster Pfadmaster 1s" bezeichnet), einem zweiten Master 2f für eine Funk tion (im folgenden als "zweiter Funktionsmaster 2f" bezeichnet), einem zweiten Master 2s für einen Pfad (im folgenden als "zweiter Pfadmaster 2s" bezeichnet), einem Funktionsma nager F, einem Pfadmanager S. einem Slave L und einem Bus B.

Fig. 6 zeigt auch die Übertragung der Steuerung in diesem Systemsimulator. Das heißt, in dem ersten Pfadmaster 1s, dem zweiten Pfadmaster 2s, dem Funktionsmanager F, dem Pfadmanager S und dem Bus B enthaltene Symbole "o" kennzeichnen Semaphore. Ferner kennzeichnet ein Symbol "P" die Ausführung einer Eingabe, ein Symbol "W" kennzeich net die Ausführung eines Wartevorgangs, und ein Symbol "T" kennzeichnet die Ausfüh rung eines Warteversuchs. In Fig. 6 kennzeichnet ein Pfeil einer Linie aus abwechselnd langen und kurzen Strichen die Übertragung der Steuerung, die aus dem Funktionsaufruf resultiert, ein Pfeil einer durchgezogenen Linie kennzeichnet die aus der Eingabe resultie rende Übertragung der Steuerung, ein Pfeil einer gestrichelten Linie kennzeichnet die aus dem Wartevorgang resultierende Übertragung der Steuerung, und ein Pfeil einer Linie aus abwechselnden langen und zwei kurzen Strichen kennzeichnet die aus dem Warteversuch resultierende Übertragung der Steuerung. Außerdem kennzeichnet ein Pfeil aus einer dop pelten Linie eine Ausführung des Pfads.

Der erste Funktionsmaster 1f ist ein Simulator, der aus einem Programm zum Simulieren einer Operation einer als ein Master verwendeten Einrichtung so wie CPU und DMA be steht. Dieser erste Funktionsmaster 1f führt einen Lesezugriff und einen Schreibzugriff auf den Slave L durch den Bus B aus. Dieser erste Funktionsmaster 1f ist der gleiche Pfad wie der Funktionsmanager F und beginnt eine Operation in Übereinstimmung mit dem Funkti onsaufruf für jeden einen Takt von dem Funktionsmanager F. Nach der Ausführung der Simulation entsprechend dem einen Takt, wird die Steuerung zu dem Funktionsmanager F zurückgeführt.

Der ersten Pfadmaster 1s ist ein Simulator, der aus einem Programm zum Simulieren der Operation der als der Master verwendeten Einrichtung besteht, ähnlich dem oben genann ten ersten Funktionsmaster 1f. Dieser erste Pfadmaster 1s führt den Lesezugriff und den Schreibzugriff auf den Slave L durch den Bus B aus. Dieser erste Pfadmaster 1s ist ein anderer Pfad als der des Funktionsmanagers F. Der erste Pfadmaster 1s beginnt die Aus führung, wenn der Pfadmanager S, der auch ein anderer Pfad als der des Funktionsmana gers F ist, die Eingabe an das Semaphor des ersten Pfadmasters 1s durchführt. Nach Ab schluss der Ausführung wird die Steuerung zu dem Pfadmanager S durch Durchführung des Wartevorgangs an dem Semaphor übertragen.

Der erste Funktionsmaster 1f und der erste Pfadmaster 1s werden als ein Modul gebildet, und sie sind unterschiedliche Pfade, obwohl sie den gleichen Text aufweisen. Tatsächlich unterscheiden sich der erste Funktionsmaster 1f und der erste Pfadmaster 1s nur durch eine Ausführungsstartposition in dem Modul.

Der zweite Funktionsmaster 2f ist ein Simulator, der aus einem Programm zum Simulieren einer Operation einer als ein Master verwendeten Einrichtung besteht, ähnlich wie der oben genannte erste Funktionsmaster 1f. Dieser zweite Funktionsmaster 2f führt einen Le sezugriff und den Schreibzugriff auf den Slave L durch den Bus B durch. Dieser zweite Funktionsmaster 2f ist der gleiche Pfad wie der Funktionsmanager F und beginnt eine Ope ration in Übereinstimmung mit dem Funktionsaufruf für jeden einen Takt von dem Funk tionsmanager F. Nach der Ausführung der Simulation entsprechend dem einen Takt wird die Steuerung zum Funktionsmanager F zurückgeführt.

Der zweite Pfadmaster 2s ist ein Simulator, der aus einem Programm zum Simulieren der Operation der als der Master verwendeten Einrichtung besteht, ähnlich dem oben genann ten zweiten Funktionsmaster 2f. Dieser zweite Pfadmaster 2s führt den Lesezugriff und den Schreibzugriff auf den Slave L durch den Bus B aus. Dieser zweite Pfadmaster 2s ist ein anderer Pfad als der Funktionsmanager F. Der zweite Pfadmaster 2s beginnt die Aus führung, wenn der Pfadmaster S, der auch ein anderer Pfad als derjenige des Funktionsma nagers F ist, die Eingabe an das Semaphor des zweiten Pfadmasters 2s durchführt. Nach dem Abschluss der Ausführung wird die Steuerung durch Ausführung des Wartevorgangs zu dem Semaphor an den Pfadmaster S übertragen.

Der zweite Funktionsmaster 2f und der zweite Pfadmaster 2s werden als ein Modul gebil det, und sie sind unterschiedliche Pfade, obwohl sie den gleichen Text aufweisen. Tatsäch lich unterscheiden sich der zweite Funktionsmaster 2f und der zweite Pfadmaster 2s nur durch eine Ausführungsstartposition in dem Modul.

Der Slave L ist ein Simulator, der aus einem Programm zum Simulieren einer als ein Slave verwendeten Peripherieschaltung besteht, so wie einem Zeitglied, einem seriellen An schluss oder einem allgemeinen Eingangsausgangsanschluss. Dieser Slave L führt eine vorbestimmte Operation als Reaktion auf den Lesezugriff und den Schreibzugriff aus, der durch dem Bus B von dem ersten Funktionsmaster 1f, dem ersten Funktionsmaster 1s, dem zweiten Funktionsmaster 2f und dem zweiten Pfadmaster 2s durchgeführt wird. Dieser Slave L beginnt eine Ausführung in Übereinstimmung mit dem Funktionsaufruf von dem Funktionsmanager F und dem Pfadmanager S.

Der Bus B ist ein Simulator, der aus einem Programm zum Simulieren eines Busses be steht, durch den der Slave L und jeder des ersten Funktionsmaster If, des ersten Pfadmas ters 1s, des zweiten Funktionsmasters 2f und des zweiten Pfadmasters 2s verbunden sind. Dieser Bus B führt die Informationen zurück, die anzeigen, ob der Slave L sofort reagieren kann, nämlich, ob die Zugriffsblockierung auftritt oder nicht, als Reaktion auf eine An frage durch Verwendung des Warteversuchs von dem ersten Funktionsmaster 1f, dem ers ten Pfadmaster 1s, dem zweiten Funktionsmaster 2f und dem zweiten Pfadmaster 2s.

Der Funktionsmanager F ist ein Steuerprogramm zum Durchführen des Funktionsaufrufs der Reihe nach an dem ersten Funktionsmaster 1f, dem ersten Pfadmaster 1s und dem Slave L, und ermöglicht ihnen synchron miteinander zu arbeiten.

Der Pfadmanager S ist ein Steuerprogramm zum Ausführen der Pfadumschaltung, um dem ersten Pfadmaster 1s und dem zweiten Pfadmaster 2s zu erlauben, zu arbeiten und zum Ausführen des Funktionsaufrufs an den Slave, damit diesem Arbeit erlaubt wird.

Eine Operation des Systemsimulators gemäß der Ausführungsform der vorliegenden Er findung mit der oben genannten Konfiguration soll im folgenden beschrieben werden. Die ser Systemsimulator wird so gesteuert, um nur einen des ersten Funktionsmasters 1f, des ersten Pfadmasters 1s, des zweiten Funktionsmasters 2f, des zweiten Pfadmasters 2s, des Funktionsmanagers F und des Pfadmanagers S gleichzeitig zu aktivieren.

Zuerst ist die Operation, wenn keine Zugriffsblockierung auftritt, unter Bezugnahme auf Fig. 7 beschrieben. In diesem Fall wird der Systemsimulator ähnlich dem Simulator gemäß der ersten konventionellen Technik betätigt. Das heißt, die Simulation schreitet fort, wäh rend der Funktionsmanager F den Funktionsaufruf der Reihe nach an den ersten Funkti onsmaster 1f, den zweiten Funktionsmaster 2f und den Slave L durchführt.

Genau ausgedrückt, führt der Funktionsmanager F zuerst den Funktionsaufruf an den ers ten Funktionsmaster 1f durch. Dementsprechend führt der erste Funktionsmaster 1f einen einem Takt entsprechenden Prozess durch. Wenn zum Beispiel das Ziel des Funktionsauf rufs eine in einem Takt abzuschließende Anweisung darstellt, wird die Steuerung zu dem Funktionsmanager F nach Abschluss der Ausführung der Anweisung zurückgeführt. In diesem Prozess wird angenommen, dass die Zugriffsblockierung nicht auftritt. Selbst in einem Fall eines Prozesses für Zugriff auf den Bus B, wird der Prozess daher in einem Takt abgeschlossen. Es sollte festgestellt werden, dass, wenn das Ziel des Funktionsaufrufs eine Anweisung darstellt, die eine Mehrzahl von Takten erfordert, die Steuerung zu dem Funktionsmanager F nach Abschluss eines dem einen Takt entsprechenden Prozesses zu rückgeführt wird.

Als nächstes, ähnlich dem oben genannten konventionellen Fall, führt der Funktionsmana ger F den Funktionsaufruf an den zweiten Funktionsmaster 2f durch und führt dann den Funktionsaufruf an den Slave L durch. Danach wird die Simulation durch die zyklische Ausführung des Funktionsaufrufs an den ersten Funktionsmaster 1f → den zweiten Funk tionsmaster 2f → den Slave L → den ersten Funktionsmaster 1f →. . . vorgerückt. Es soll festgestellt werden, dass, wenn das Ziel des Funktionsaufrufs die Anweisung ist, die eine Mehrzahl von Takten erfordert, die Anweisung durch Ausführung der Mehrzahl von Funktionsaufrufen bis zum Ziel abgeschlossen wird.

Wenn keine Zugriffsblockierung auftritt, führen der erste Funktionsmaster 1, der zweite Funktionsmaster 2f und der Slave L wie oben erwähnt nacheinander den Prozess durch, der dem einen Takt für jede Ausführung des Funktionsaufrufs von dem Funktionsmanager F entspricht. Daher werden sie betätigt, als wenn sie synchron mit dem Takt sind. Folglich ist es möglich, die Simulation auszuführen, in der die Betriebszeitabläufe berücksichtigt wer den.

Als nächstens sollen die Operationen in den Fall des Auftretens der Zugriffsblockierung unter Bezugnahme auf die Fig. 8 bis 11 beschrieben werden. In diesem Fall wird der Systemsimulator gemäß dieser Ausführungsform in ähnlicher Weise wie der Simulator gemäß der zweiten konventionellen Technik betätigt.

Fig. 8 ist ein Erklärungsdiagramm, das eine Operation zeigt, wenn die Zugriffsblockierung in dem Prozess des ersten Funktionsmasters 1f auftritt, an dem der Funktionsmanager F den Funktionsaufruf durchführt und die Steuerung zu dem Pfadmanager S übertragen wird. Gestrichelte Linie zeigen den Fluss der Steuerung an.

Der Funktionsmanager F führt zuerst den Funktionsaufruf an den ersten Funktionsmaster 1f aus. Dementsprechend führt der erste Funktionsmaster 1f den dem einen Takt entspre chenden Prozess aus. In diesem Prozess führt der erste Funktionsmaster 1f den Wartever such an dem Semaphor des Busses B durch. Wenn der Warteversuch erfolgreich ist, näm lich wenn die Zugriffsblockierung nicht auftritt, schließt der erste Funktionsmaster 1f den dem einen Takt entsprechenden Prozess ab, wie oben ausgeführt, und die Steuerung wird zurück zu dem Funktionsmanager F geführt.

Wenn andererseits der Warteversuch nicht erfolgreich ist, nämlich, wenn die Zugriffsblo ckierung auftritt, wie durch einen Pfeil aus gestrichelten Linien gezeigt ist, führt der erste Funktionsmaster 1f die Eingabe an das Semaphor des Pfadmasters S durch und führt den Wartevorgang an dem Semaphor des Funktionsmanagers F durch. Daher wird die Steue rung von dem Funktionsmanager F zu dem Pfadmanager S übertragen. Das heißt, der Pfadmanager S wird aktiviert, und der Funktionsmanager F tritt in einen Ruhezustand ein.

Danach wird die Simulation basierend auf der Pfadumschaltung unter der Steuerung des Pfadmanagers S begonnen.

Fig. 9 ist ein Erklärungsdiagramm, das eine Operation zeigt, wenn die Zugriffsblockierung in dem Prozess des zweiten Pfadmasters 2s auftritt, in dem der Pfad durch den Pfadmana ger S aktiviert wird und die Steuerung zu dem Pfadmanager S übertragen wird. Die gestri chelte Linie zeigt den Fluss der Steuerung an.

Nach der in Fig. 8 gezeigten Operation führt der Pfadmanager S die Eingabe an das Sema phor des zweiten Pfadmasters 2s durch und aktiviert dadurch den Pfad des zweiten Pfad masters 2s. Dann tritt der Pfadmanager S selbst in den Wartezustand ein. Der Pfad des zweiten Pfadmasters 2s führt den Warteversuch an dem Semaphor des Busses B durch.

Wenn der Warteversuch erfolgreich ist, nämlich wenn keine Zugriffsblockierung auftritt, führt der zweite Pfadmaster 2s, wie durch einen Pfeil einer gestrichelten Linie in Fig. 9 gezeigt, nach Abschluss des dem einen Takt entsprechenden Prozesses die Eingabe an das Semaphor des Pfadmanagers S durch und tritt in den Wartezustand ein. Wenn andererseits der Warteversuch nicht erfolgreich ist, nämlich wenn die Zugriffsblockierung auftritt, führt der zweite Pfadmaster 2s sofort die Eingabe an das Semaphor des Pfadmanagers 5 durch und tritt in den Wartezustand ein.

Fig. 10 ist ein Erklärungsdiagramm, das eine Operation zeigt, wenn der Slave L, an den der Pfadmanager S den Funktionsaufruf durchführt, den Prozess abschließt und die Steuerung dann zu dem Pfadmanager S übertragen wird. Die gestrichelte Linie zeigt den Fluss der Steuerung an.

Nach der in Fig. 9 gezeigten Operation führt der Pfadmanager S den Funktionsaufruf an den Slave L durch. Dementsprechend führt der Slave L den Prozess entsprechend dem ei nem Takt durch. Wenn in dem Slave L Daten als Reaktion auf eine Leseanforderung von dem ersten Funktionsmaster 1f, dem ersten Pfadmaster 1s, dem zweiten Funktionsmaster 2f und dem zweiten Pfadmaster 2s erzeugt werden, führt der Slave L die Eingabe an das Semaphor des Busses B aus. Dementsprechend wird der Zugriffsblockierzustand in dem Bus B aufgehoben. Danach wird die Steuerung zu dem Pfadmanager S zurückgeführt.

Fig. 11 ist ein Erklärungsdiagramm, das eine Operation zeigt, wenn Zugriffsblockierung nicht in dem Prozess des ersten Pfadmasters 1s auftritt, an den der Pfadmanager S den Funktionsaufruf durchführt, und die Steuerung zu dem Funktionsmanager F übertragen wird. Die gestrichelte Linie zeigt den Fluss der Steuerung an.

Nach den in Fig. 10 gezeigten Operationen führt der Pfadmanager S die Eingabe an das Semaphor des Funktionsmanagers F durch. Dementsprechend wird der erste Funktions master 1f aktiviert, der aufgrund des Versagens des Warteversuchs in dem Wartezustand ist, und der ersten Funktionsmaster 1f führt erneut den Warteversuch zu dem Semaphor des Busses B durch. Wenn der Warteversuch erfolgreich ist, nämlich wenn die Zugriffsblo ckierung nicht auftritt, schließt der erste Funktionsmaster 1f den dem einen Takt entspre chenden Prozess ab, und die Steuerung wird zu dem Funktionsmanager F zurückgeführt.

Wenn andererseits der Warteversuch nicht erfolgreich ist, nämlich wenn die Zugriffsblo ckierung nicht aufgehoben ist, wie unter Bezugnahme auf Fig. 8 beschrieben ist, führt der erste Funktionsmaster 1f die Eingabe an das Semaphor des Pfadmanagers S durch. Danach werden die Operationen ähnlich denjenigen des oben genannten Falls wiederholt. Wenn die Zugriffsblockierung aufgehoben wird, werden alle die Master entsprechend dem Funk tionsaufruf ausgeführt.

Bei dem Systemsimulator gemäß der Ausführungsform der vorliegenden Erfindung mit der oben genannten Konfiguration kann der bereits entwickelte, hinsichtlich der Anweisungen eingestellte Simulator zum Simulieren einer einzigen CPU als der Simulator des Masters in seinem Originalzustand verwendet werden. Daher ist es nicht erforderlich, den Simulator neu auszulegen.

Auch wenn die Zugriffsblockierung auftritt, wird er von der Simulation basierend auf dem Funktionsaufruf zu der Simulation basierend auf der Pfadumschaltung umgeschaltet. An ders als bei den konventionellen Techniken, verursacht das Auftreten der Zugriffsblockie rung daher nie, dass der Systemsimulator in den Verklemmungszustand gerät.

Außerdem wird die Simulation, außer wenn die Zugriffsblockierung auftritt, in Überein stimmung mit dem Funktionsaufruf durchgeführt, und die auf Pfadumschaltung basierende Operation wird nicht durchgeführt. Als Ergebnis ist es möglich, den durch die Pfad umschaltung verursachten Zeitverlust auf ein Minimum zu reduzieren, und es ist dadurch möglich, die Simulation bei einer hohen Geschwindigkeit zu erreichen.

Zum besseren Verständnis der vorliegenden Erfindung sollen die Prozesse zum Erreichen der oben aufgeführten Operationen im folgenden weiter unter Bezugnahme auf die Ab laufdiagramme beschrieben werden, hauptsächlich bei der Umschaltoperation zwischen dem Funktionsmanager F und dem Pfadmanager S.

Fig. 12 ist ein Ablaufdiagramm, das den Hauptprozess in dem Systemsimulator gemäß dieser Ausführungsform zeigt.

In diesem Systemsimulator werden der Funktionsmanager F (im folgenden lediglich als "Manager F" bezeichnet) und der Pfadmanager S (im folgenden lediglich als "Manager S" bezeichnet), der erste Funktionsmaster 1f, der erste Pfadmaster 1s, der zweite Funktions master 2f und der zweite Pfadmaster 2s (im folgenden können sie gemeinsam lediglich als "Master" bezeichnet werden) durch eine Tabelle verwaltet. Es soll festgestellt werden, dass im folgenden der erste Funktionsmaster 1f und der zweite Funktionsmaster 2f manchmal lediglich als "Master f" bezeichnet werden können und der erste Pfadmaster 1s und der zweite Pfadmaster 2s manchmal lediglich als "Master s" bezeichnet werden können.

Ein aktueller Mastertabellenindex "current_master_table_index" ist ein Tabellenindex ei nes Masters zum Vorrücken eines Taktes, welcher durch einen Manager F und einen Ma nager S gemeinsam genutzt wird.

Wenn die Simulation in dem Systemsimulator begonnen wird, werden zuerst ein aktueller Mastertabellenindex "current_master_table_index" und ein aktueller Slave-Tabellenindex "current_slave_table_index" zunächst auf null gesetzt (Schritt S10, S11). Dann wird der in der Simulation zu verwendende Pfad des Managers S erzeugt (Schritt S12).

Als nächstes wird nach der Ausführung des Pfaderzeugungsprozesses des Masters s (Schritt S13), wie später ausführlich in bezug zu dem Manager F beschrieben ist, ein Pro zess zum Vorrücken von Systemzeit des Managers F um einen Takt wiederholt, bis ein Ende der Simulation angezeigt wird (Schritte S14, S15). Andererseits wird in bezug zu dem Manager S der Wartevorgang an dem Semaphor des Managers S durchgeführt (Schritt S16). Dann wird ein Prozess zum Vorrücken von Systemzeit des Managers S um einen Takt wiederholt, bis das Ende der Simulation angezeigt wird (Schritt S17, S18). Daher wird die Simulation begonnen, wenn der Funktionsmanager F den Funktionsaufruf (Schritt S14 und S15) am Ausgangszustand ausführt. Danach werden die Prozesse an den Schritten S14 und S17 geeignet abhängig von dem Vorliegen oder Nichtvorliegen der Zu griffsblockierung durchgeführt.

Der bei dem Schritt S13 durchgeführte Pfaderzeugungsprozess des Masters s soll im fol genden detailliert unter Bezugnahme auf das in Fig. 13 gezeigte Ablaufdiagramm be schrieben werden.

Ein aktueller Masterindex "current_master_index" ist ein Index eines Masters s, der den Takt durch den Manager S vorzurücken ist.

In dem Pfaderzeugungsprozess des Masters s wird zuerst ein aktueller Masterindex "cur rent_master_index" zu Beginn auf null gesetzt (Schritt S20). Als nächstes wird geprüft, ob der aktuelle Masterindex kleiner als eine Mastertabellengröße "master_table_size" ist (Schritt S21). Wenn er als kleiner beurteilt wird, wird der Pfad des Masters s entsprechend dem aktuellen Masterindex "current_master_index" erzeugt (Schritt S22).

Während als nächstes der Prozess zum Vorrücken der Systemzeit des Masters s um einen Takt durchgeführt wird (Schritt S24), wird, wie später ausführlich beschrieben ist, ein Wert des aktuellen Masterindex "current_master_index" um eins erhöht (Schritt S23). Dann kehrt die Abfolge zum Erzeugen eines Pfads eines nächsten Masters s zurück zum Schritt S21, und die oben genannten Operationen werden wiederholt. Beim Schritt S21 wird der Pfaderzeugungsprozess des Masters s beendet, wenn der aktuelle Masterindex als gleich oder größer als die Mastertabellengröße beurteilt wird.

Der beim Schritt S14 durchgeführte Prozess zum Vorrücken der Systemzeit des Managers F um einen Takt soll im folgenden ausführlich unter Bezugnahme auf das in Fig. 14 ge zeigte Ablaufdiagramm wiederholt werden.

In diesem Prozess wird zuerst geprüft, ob der aktuelle Mastertabellenindex "current_mas ter_table_index" kleiner als die Mastertabellengröße "master_table_size" ist oder nicht (Schritt S25). Wenn er als kleiner beurteilt wird, wird ein Prozess "cur_index = cur rent_master_table_index++" ausgeführt zum Einsetzen eines Werts des aktuellen Master tabellenindex "current_master_table_index" in einen aktuellen Index "cur_index" und an schließenden Erhöhen des Werts des aktuellen Mastertabellenindex "current_master_ta ble_index" um eins (Schritt S26).

Als nächstes wird ein Prozess zum Vorrücken einer Zeit um einen Takt durchgeführt, wenn der Tabellenindex des Masters den Funktionsaufruf an den Master des aktuellen Index "cur-index" durchführt (Schritt S27). Dieser Prozess soll später ausführlich beschrieben werden. Dann wird geprüft, ob ein Assoziationsarray, in dem die Information des Masters gespeichert wird, in dem Zugriffsblockierung auftritt, leer ist oder nicht (Schritt S28). Wenn das Assoziationsarray als leer beurteilt wird, wird erkannt, dass die Zugriffsblockie rung nicht auftritt. Dann kehrt die Abfolge zurück zum Schritt S25 und die oben genannten Operationen werden für einen nächsten Master wiederholt.

Wenn andererseits das Assoziationsarray nicht als leer beurteilt wird, wird erkannt, dass die Zugriffsblockierung auftritt, und die Eingabe wird an das Semaphor des Managers S ausgeführt (Schritt S29), und der Wartevorgang wird an dem Semaphor des Managers F durchgeführt (Schritt S30). Dementsprechend wird die Steuerung von dem Manager F zu dem Manager S übertragen. Dann wird die Simulation basierend auf der Pfadumschaltung unter der Steuerung des Managers S begonnen. Danach kehrt die Abfolge zurück zum Schritt S25, und die oben genannten Operationen werden für einen nächsten Master wie derholt.

Wenn beim Schritt S25 der aktuelle Mastertabellenindex "current_master_table_ index" als gleich oder größer als die Mastertabellengröße "master_table_size" beurteilt wird, wird der aktuelle Mastertabellenindex "current_master_table_index" auf null zurückgestellt (Schritt S31).

Als nächstes wird geprüft, ob der aktuelle Slave-Tabellenindex ""current_slave_table_in dex" kleiner als eine Slave-Tabellengröße "slave_table_size" ist oder nicht (Schritt S32). Wenn er als kleiner beurteilt wird, wird ein Prozess "cur_index = current_slave_table_in dex++" zum Einsetzen eines Werts des aktuellen Slave-Tabellenindex "current_slave_ta ble_index" in den aktuellen Index "cur_index" durchgeführt und anschließend wird der Wert des aktuellen Slave-Tabellenindex "current_slave_table_index" um eins erhöht (Schritt S33).

Als nächstes wird ein Prozess zum Vorrücken einer Zeit um einen Takt ausgeführt, wenn der Tabellenindex des Slave den Funktionsaufruf an den Slave des aktuellen Index "cur_index" durchführt (Schritt S34). Danach kehrt die Abfolge zurück zum Schritt S25, und die oben genannten Operationen werden für einen nächsten Slave wiederholt.

Wenn beim Schritt S32 der aktuelle Slave-Tabellenindex "current_slave_table_index" als gleich oder größer als die Slave-Tabellengröße "slave_table_size" beurteilt wird, wird der aktuelle Slave-Tabellenindex "current_slave_table_index" auf null zurückgesetzt (Schritt S35). Nach Ausführung dieses Schritts wird der Prozess zum Vorrücken der Systemzeit des Managers F um einen Takt beendet, und die Abfolge kehrt zum Hauptprozess zurück.

Der am Schritt S17 ausgeführte Prozess zum Vorrücken der Systemzeit des Managers S um einen Takt soll im folgenden ausführlich unter Bezugnahme auf das in Fig. 15 gezeigte Ablaufdiagramm beschrieben werden.

In diesem Prozess wird zuerst geprüft, ob der aktuelle Mastertabellenindex "current_mas ter_table_index" kleiner als die Mastertabellengröße "master_table_size" ist oder nicht (Schritt S40). Wenn er als kleiner beurteilt wird, wird ein Prozess "cur_index = cur rent_master_table_index++" zum Einsetzen des Werts des aktuellen Mastertabellenindex "current_master_table_index" in den aktuellen Index "cur_index" und anschließenden Erhöhen des Werts des aktuellen Mastertabellenindex "current_master_table_index" um eins (Schritt S41) durchgeführt.

Als nächstes wird ein Prozess durchgeführt, in dem der Tabellenindex des Masters die Zeit des Masters s des aktuellen Index "cur_index" um einen Takt vorrückt (Schritt S42). Die ser Prozess soll später ausführlich beschrieben werden. Wenn hier festgelegt wird, dass die Eingabe an das Semaphor des Managers F in Übereinstimmung mit einer ein Auftreten der Zugriffsblockierung anzeigenden Meldung ausgeführt wird, wird die Eingabe an das Se maphor des Managers F ausgeführt. Ansonsten wird die Eingabe an den entsprechenden Master s ausgeführt.

Als nächstes wird der Wartevorgang an dem Semaphor des Managers S durchgeführt (Schritt S43). Dann wird geprüft, ob das Assoziationsarray leer ist oder nicht (Schritt S44). Wenn das Assoziationsarray als leer beurteilt wird, wird erkannt, dass die Zugriffsblockie rung nicht auftritt. Dann kehrt die Abfolge zurück zum Schritt S40, und die oben genann ten Operationen werden für einen nächsten Master wiederholt.

Wenn andererseits das Assoziationsarray als nicht leer beurteilt wird, wird erkannt, dass die Zugriffsblockierung auftritt, und die Eingabe wird an das Semaphor des Managers F (Schritt S45) ausgeführt, und der Wartevorgang wird an dem Semaphor des Managers S durchgeführt (Schritt S46). Dementsprechend wird die Steuerung von dem Manager S zu dem Manager F übertragen. Dann wird die Simulation basierend auf dem Funktionsaufruf unter der Steuerung des Managers F durchgeführt. Danach kehrt die Abfolge zurück zum Schritt S40 und die oben genannten Operationen werden für einen nächsten Master wie derholt.

Wenn beim Schritt S40 der aktuelle Mastertabellenindex "current_master_table_index" als gleich oder größer als die Mastertabellengröße "master_table_size" beurteilt wird, wird der aktuelle Mastertabellenindex "current_master_table_index" auf null zurückgesetzt (Schritt S47).

Als nächstes wird geprüft, ob der aktuelle Slave-Tabellenindex "current_slave_table_in dex" kleiner als die Slave-Tabellengröße "slave_table_size" ist oder nicht (Schritt S48). Wenn er als kleiner beurteilt wird, wird der Prozess "cur_index = current_slave_table_in dex++" zum Einsetzen des Werts des aktuellen Slave-Tabellenindex "current_slave_ta ble_index" in den aktuellen Index "cur_index" und anschließenden Erhöhen des Werts des aktuellen Slave-Tabellenindex "current_slave_table_index" um eins durchgeführt (Schritt S49).

Als nächstes wird ein Prozess zum Vorrücken einer Zeit um einen Takt durchgeführt, wenn der Tabellenindex des Slave den Funktionsaufruf an den Slave des aktuellen Index "cur_index" durchführt (Schritt S50). Danach kehrt die Abfolge zurück zum Schritt S48 und die oben genannten Operationen werden für einen nächsten Slave wiederholt.

Wenn andererseits am Schritt S48 der aktuelle Slave-Tabellenindex "current_slave_ta ble_index" als gleich oder größer als die Slave-Tabellengröße "slave_table_size" beurteilt wird, wird der aktuelle Slave-Tabellenindex "current_slave_table_index" auf null zurück gesetzt (Schritt S51). Nach Durchführung dieses Schritts wird der Prozess zum Vorrücken der Systemzeit des Managers S um einen Takt beendet, und die Abfolge kehrt zu dem Hauptprozess zurück.

Der bei dem in Fig. 14 gezeigten Schritt S27 durchgeführte Prozess zum Vorrücken der Zeit des Masters um einen Takt soll im folgenden ausführlich unter Bezugnahme auf das in Fig. 16 gezeigte Ablaufdiagramm beschrieben werden. Es soll festgestellt werden, dass ein Fall, in dem eine CPU als der Master verwendet wird, in der folgenden Erklärung als Bei spiel genommen wird.

In diesem Prozess wird zuerst eine Anweisung abgerufen (Schritt S60). Als nächstes wird die abgerufene Anweisung dekodiert (Schritt S61). Eine jegliche einer NOP-Anweisung (Schritt S62), einer ADD-Anweisung (Schritt S63), einer LOAD-Anweisung (Schritt S64) wird auf der Basis des dekodierten Ergebnisses ausgeführt. Wenn die entsprechende An weisung nicht als das dekodierte Ergebnis vorhanden ist, wird ein Fehlerprozess ausgeführt (Schritt S65).

Eine Operation der in Übereinstimmung mit dem Funktionsaufruf von dem Manager F aus geführten LOAD-Anweisung soll im folgenden unter Bezugnahme auf das in Fig. 17 ge zeigte Ablaufdiagramm beschrieben werden.

Wenn diese LOAD-Anweisung ausgeführt wird, wird zuerst geprüft, ob Ladedaten durch den Bus von dem Slave erhalten werden können oder nicht (Schritt S70). Wenn in diesem Schritt S70 beurteilt wird, dass die Ladedaten nicht erhalten werden können, wird ein Pro zess zum Melden eines Auftretens von Zugriffsblockierung gemeinsam für den Master f und den Master s ausgeführt (Schritt S71). Dieser Prozess zum Melden des Auftretens von Zugriffsblockierung ist detailliert in dem Ablaufdiagramm von Fig. 18 gezeigt.

In diesem Prozess zum Melden des Auftretens von Zugriffsblockierung wird zuerst ge prüft, ob ein Assoziationsarray, in dem die Information über Blockierung des Masters ge speichert ist, leer ist oder nicht (Schritt S80). Wenn es als leer beurteilt wird, wenn der Ma nager S die Zeit des Masters vorrückt, wird er derart eingestellt, dass die Eingabe an das Semaphor des Managers F durchgeführt wird (Schritt S81). Wenn es andererseits als nicht leer beurteilt wird, wird der Prozess am Schritt S81 übersprungen. Als nächstes wird der Master in dem Assoziationsarray zum Speichern der Information aufgezeichnet, dass der Master blockiert ist (Schritt S82). Danach kehrt die Abfolge zum Schritt S72 in Fig. 17 zu rück.

Beim Schritt S72 wird die Eingabe an das Semaphor des Managers S ausgeführt. Als nächstes wird der Wartevorgang an dem Semaphor des Managers F durchgeführt (Schritt S73). Anschließend kehrt die Abfolge zurück zum Schritt S70, und die oben genannten Operationen werden wiederholt. Dementsprechend wird geprüft, ob die Ladedaten von dem Slave für jeden einen Takt erhalten werden oder nicht.

Wenn am Schritt S70 beurteilt wird, dass die Ladedaten durch den Bus von dem Slave er halten werden können, wird dann geprüft, ob der Prozess zum Melden des Auftretens von Zugriffsblockierung gemeinsam für den Master f und den Master s aufgerufen wird oder nicht, nämlich, ob der Prozess am Schritt S71 ausgeführt wird (Schritt S74). Wenn beur teilt wird, dass der Prozess zum Melden des Auftretens von Zugriffsblockierung gemein sam für den Master f und den Master s aufgerufen ist, wird ein Prozess zum Melden des Endes der Zugriffsblockierung gemeinsam für den Master f und den Master s ausgeführt (Schritt S75). Dieser Prozess zum Melden des Endes der Zugriffsblockierung ist ausführ lich in dem Ablaufdiagramm von Fig. 19 gezeigt.

Dieser Prozess zum Melden des Endes der Zugriffsblockierung löscht den Master aus dem Assoziationsarray zum Speichern der Information, dass der Master blockiert ist (Schritt S85). Wenn dann der Manager S die Zeit des Masters vorrückt, wird eingestellt, dass die Eingabe an das Semaphor des Masters s durchgeführt wird (Schritt S86). Danach kehrt die Abfolge zurück zum Schritt S76 von Fig. 17.

Am Schritt S76 werden die durch den Bus von dem Slave erhaltenen Ladedaten in ein Re gister (nicht gezeigt) eingeschrieben, das durch die LOAD-Anweisung angewiesen wird. Dementsprechend wird die Ausführung der LOAD-Anweisung abgeschlossen.

Der beim Schritt S42 durchgeführte Prozess zum Vorrücken der Zeit des Masters um einen Takt soll im folgenden ausführlich unter Bezugnahme auf das in Fig. 20 gezeigte Ablauf diagramm beschrieben werden. Es soll festgestellt werden, dass ein Fall, in dem eine CPU als der Master verwendet wird, in der folgenden Erklärung als Beispiel aufgeführt ist.

In diesem Prozess wird der Wartevorgang zuerst an dem Semaphor des Masters s durchge führt (Schritt S90). Als nächstes wird die Anweisung abgerufen (Schritt S91). Dann wird die abgerufene Anweisung dekodiert (Schritt S92). Eine jegliche der NOP-Anweisung (Schritt S93), der ADD-Anweisung (Schritt S94), der LOAD-Anweisung (Schritt S95),. . . wird auf der Basis des dekodierten Ergebnisses durchgeführt. Wenn die entsprechende An weisung nicht als das dekodierte Ergebnis existiert, wird der Fehlerprozess durchgeführt (Schritt S96). Dann wird die Eingabe an das Semaphor des Managers S ausgeführt (Schritt S97).

Eine Operation der durch den Master s aktivierten LOAD-Anweisung soll im folgenden unter Bezugnahme auf das in Fig. 21 gezeigte Ablaufdiagramm beschrieben werden.

Wenn diese LOAD-Anweisung ausgeführt wird, wird zuerst geprüft, ob die Ladedaten durch den Bus vom Slave erhalten werden können oder nicht (Schritt S100). Wenn in die sem Schritt S100 beurteilt wird, dass die Ladedaten nicht erhalten werden können, wird ein Prozess zum Melden eines Auftretens von Zugriffsblockierung gemeinsam für den Master f und den Master s ausgeführt (Schritt S101). Dieser Prozess zum Melden des Auftretens von Zugriffsblockierung wurde bereits ausführlich unter Bezugnahme auf das Ablaufdia gramm von Fig. 18 beschrieben.

Als nächstes wird die Eingabe an das Semaphor des Managers S ausgeführt (Schritt S102). Dann wird der Wartevorgang an dem Semaphor des Masters s durchgeführt (Schritt S103). Danach kehrt die Abfolge zurück zum Schritt S 100, und die oben genannten Operationen werden wiederholt. Dementsprechend wird geprüft, ob die Ladedaten von dem Slave für jeden einen Takt erhalten werden oder nicht.

Wenn beim Schritt S100 beurteilt wird, dass die Ladedaten durch den Bus vom Slave er halten werden können, wird anschließend geprüft, ob der Prozess zum Melden des Auftre tens der Zugriffsblockierung gemeinsam für den Master f und den Master s aufgerufen wird oder nicht, nämlich, ob der Prozess am Schritt S101 ausgeführt wird oder nicht (Schritt S104). Wenn beurteilt wird, dass der Prozess zum Melden des Auftretens von Zu griffsblockierung gemeinsam für den Master f und den Master s aufgerufen ist, wird ein Prozess zum Melden des Endes der Zugriffsblockierung gemeinsam für den Master f und den Master s ausgeführt (Schritt S105). Dieser Prozess zum Melden des Endes der Zu griffsblockierung wurde bereits ausführlich in dem Ablaufdiagramm von Fig. 19 beschrie ben.

Als nächstes werden die durch den Bus von dem Slave erhaltenen Ladedaten angewiesen durch die LOAD-Anweisung in das Register (nicht gezeigt) eingeschrieben (Schritt S106). Dementsprechend wird die Ausführung der LOAD-Anweisung abgeschlossen.

Die unter Bezugnahme auf die Fig. 7 bis 11 beschriebenen Operationen werden durch die oben ausgeführten Prozesse erreicht.

Es soll festgestellt werden, dass in der oben genannten Ausführungsform der Fall in der Si mulation des Geräts, das zwei Master und einen Slave enthält, als das Beispiel beschrieben ist. Bei der vorliegenden Erfindung ist die Anzahl der Master und die Anzahl der Slaves nicht auf diese begrenzt. Die Anzahl kann beliebig sein.

Wie oben ausgeführt, ist es gemäß der vorliegenden Erfindung möglich, den Systemsimu lator, das Simulationsverfahren und das Simulationsprogramm zu schaffen, die die Simula tion bei der hohen Geschwindigkeit ausführen können, ohne in den durch Zugriffsblockie rung verursachten Verklemmungszustand zu geraten und ohne den Simulator zum Simulie ren des konventionellen Bus-Masters zu ändern.

Claims

1. Systemsimulator mit:
einem Mastersimulator (1f, 1s, 2f und 2s), der einen Bus-Master simuliert;
einem Slave-Simulator (L), der einen Bus-Slave simuliert;
einem Funktionsmanager (F), der nacheinander den Mastersimulator (1f, 1s, 2f und 2s) und den Slave-Simulator (L) durch Verwendung eines Funktionsaufrufs aktiviert; und
einem Pfadmanager (S), der den Mastersimulator (1f, 1s, 2f und 2s) durch Verwen dung einer Pfadumschaltung aktiviert,
wobei, wenn der durch Verwendung des Funktionsaufrufs von dem Funktionsma nager (F) aktivierte Mastersimulator (1f, 1s, 2f und 2s) auf den Slave-Simulator (L) zu greift und eine Zugriffsblockierung verursacht wird, der Mastersimulator (1f, 1s, 2f und 2s) den Pfadmanager (S) derart steuert, dass der Mastersimulator (1f, 1s, 2f und 2s) durch Verwendung der Pfadumschaltung aktiviert wird, welche durch den Pfadmanager (S) durchgeführt wird.

2. Systemsimulator nach Anspruch 1, bei dem der Pfadmanager (S) ferner den Slave-Si mulator (L) durch Verwendung des Funktionsaufrufs aktiviert.

3. Systemsimulator nach Anspruch 2, bei dem nach Aufhebung der Zugriffsblockierung der Pfadmanager (S) den Funkti onsmanager (F) derart steuert, dass der Mastersimulator (1f, 1s, 2f und 2s) durch Verwen dung des genannten Funktionsaufrufs aktiviert wird.

4. Systemsimulator nach Anspruch 1, bei dem nach Aufhebung der Zugriffsblockierung der Pfadmanager (S) den Funktionsmanager (F) derart steuert, dass der Mastersimulator (1f, 1s, 2f und 2s) durch Verwendung des Funktionsaufrufs aktiviert wird.

5. Simulationsverfahren, mit:

1. (1) Vorsehen eines Mastersimulators (1f, 1s, 2f und 2s) zum Simulieren eines Bus- Masters und eines Slave-Simulators (L) zum Simulieren eines Bus-Slave;
2. (2) nacheinander Betätigen des Mastersimulators (1f, 1s, 2f und 2s) und des Slave- Simulators (L) durch Verwendung eines Funktionsaufrufs; und
3. (3) Betätigen des Mastersimulators (1f, 1s, 2f und 2s) durch Verwendung einer Pfadumschaltung, wenn der durch Verwendung des Funktionsaufrufs aktivierte Mastersi mulator (1f, 1s, 2f und 2s) auf den Slave-Simulator (L) zugreift und eine Zugriffsblockie rung verursacht.

6. Simulationsverfahren nach Anspruch 5, bei dem der Schritt (3) ferner den Slave-Simu lator (L) durch Verwendung des Funktionsaufrufs aktiviert.

7. Simulationsverfahren nach Anspruch 6, mit ferner:
Betätigung des Mastersimulators (1f, 1s, 2f und 2s) durch Verwendung des Funkti onsaufrufs, nachdem die Zugriffsblockierung aufgehoben ist.

8. Simulationsverfahren nach Anspruch 5, mit ferner:
Betätigung des Mastersimulators (1f, 1s, 2f und 2s) durch Verwendung des Funkti onsaufrufs, nachdem die Zugriffsblockierung aufgehoben ist.

9. Simulationsprogramm betrieben auf einem Computer, mit:
einem Mastersimulationsprogramm (1f, 1s, 2f und 2s), das einen Bus-Master simu liert;
einem Slave-Simulationsprogramm (L), das einen Bus-Slave simuliert;
einem Funktionsmanagerprogramm (F), das nacheinander das Mastersimulations programm (1f, 1s, 2f und 2s) und das Slave-Simulationsprogramm (L) durch Verwendung eines Funktionsaufrufs aktiviert; und
einem Pfadmanagerprogramm (S), das das Mastersimulationsprogramm (1f, 1s, 2f und 2s) durch Verwendung einer Pfadumschaltung aktiviert,
wobei, wenn das durch Verwendung des Funktionsaufrufs von dem Funktionsma nagerprogramm (F) aktivierte Mastersimulationsprogramm (1f, 1s, 2f und 2s) auf das Slave-Simulationsprogramm (L) zugreift und eine Zugriffsblockierung verursacht wird, das Mastersimulationsprogramm (1f, 1s, 2f und 2s) das Pfadmanagerprogramm (S) derart steuert, dass das Mastersimulationsprogramm (1f, 1d, 2f und 2s) durch Verwendung der Pfadumschaltung aktiviert wird, die durch das Pfadmanagerprogramm (S) durchgeführt wird.

10. Simulationsprogramm nach Anspruch 9, bei dem das Pfadmanagerprogramm (S) ferner das Slave-Simulationsprogramm (L) durch Verwendung des Funktionsaufrufs aktiviert.

11. Simulationsprogramm nach Anspruch 10, bei dem nach Aufhebung der Zugriffsblo ckierung das Pfadmanagerprogramm (S) das Funktionsmanagerprogramm (F) derart steu ert, dass das Mastersimulationsprogramm (1f, 1s, 2f und 2s) durch Verwendung des Funk tionsaufrufs aktiviert wird.

12. Simulationsprogramm nach Anspruch 9, bei dem nach Aufhebung der Zugriffsblockie rung das Pfadmanagerprogramm (S) das Funktionsmanagerprogramm (F) derart steuert, dass das Mastersimulationsprogramm (1f, 1s, 2f und 2s) unter Verwendung des Funktions aufrufs aktiviert wird.