DE19921128A1 - Verfahren zum Erzeugen von zielsystemspezifischen Programmcodes, Simulationsverfahren sowie Hardwarekonfiguration - Google Patents

Abstract

Es wird ein Verfahren zum automatischen Erzeugen maschinenlesbarer Ausgangs-Quellcodes aus maschinenlesbarem Eingangs-Quellcode bereitgestellt, die die folgenden Schritte aufweisen: Zusammenfassen der Anzahl elementarer Prozesse in eine vorbestimmte Anzahl disjuncter Aggregate gemäß einer vorbestimmten Granularität mit Bezug auf die Ziel-Verarbeitungssubsysteme, wobei jeder Aggregat aufweist: eine Anzahl von Prozessen der Anzahl elementarer Prozesse, die Aggregat-Interaktionen mit einer Anzahl der Anzahl von Aggregaten aufweisen, wobei jede Aggregat-Interaktion elementare Interaktionen der elementaren Prozesse enthält, die in dem jeweiligen Aggregat zusammengefaßt sind, mit den elementaren Prozessen eines anderen Aggregats, zusammenfassende Anzahl von Aggregaten, die im vorherigen Schritt erhalten wurden, in eine vorbestimmte Anzahl von disjuncten Aggregaten mit Bezug auf die Anzahl der Ziel-Subsysteme, rekursives Wiederholen des vorherigen Schrittes für einen oder mehrere der Aggregate, bis jeder resultierende Aggregat eine vorbestimmte Granularität hat, Transformieren der resultierenden Aggregate in Ausgabequellcodes.

Description

Die vorliegende Erfindung bezieht sich auf ein Verfahren zum automatischen Erzeugen von Ausgangs-Quellcode aus Eingangs-Quellcode, wobei der Eingangs- Quellcode ein Modell eines zu simulierenden Systems darstellt, und des weiteren auf ein Simulationsverfahren und eine Hardware-Konfiguration zum Durchführen einer Simulation.

Das Simulieren des Verhaltens eines realen Systems durch ein technisches System ist eine bedeutende Aufgabe in der Industrie von heute, etwa in Entwicklung und Produktion. Speziell die Existenz von Hochleistungs-Computersystemen ermöglicht es Entwicklern, sogar sehr komplexe Systeme zu simulieren.

Simulationswerkzeuge können Teil von Entwicklungssystemen sein, um das Verhalten von Produktentwürfen zu überprüfen, ehe die Produkte tatsächlich hergestellt werden; des weiteren kann, wenn die Geschwindigkeit des Simulationssystems größer oder gleich der Geschwindigkeit des realen Systems ist, die Simulation zur Steuerung des realen Systems verwendet werden, derart, daß das zukünftige Verhalten des realen Systems durch das Simulationssystem antizipiert wird, so daß das reale System rechtzeitig beeinflußt werden kann, ehe dieses Verhalten tatsächlich Realität wird. Andererseits kann, wenn die Simulationsgeschwindigkeit geringer als diejenige des realen Systems ist, die Simulation zur Analyse des Verhaltens des realen Systems dienlich sein.

Simulationssysteme bestehen aus der Software, die das Modell des zu untersu­ chenden Systems (SUT) darstellt, und der Hardware, auf der die Software ablau­ fen soll. Das Vorgehen bei der Erzeugung eines Simulators für ein System gemäß dem Stand der Technik kann folgendermaßen beschrieben werden. Auf der Basis des Modells wird die Simulationssoftware, welche die Simulation durchführt, entwickelt. Hierbei hängt die Gestalt der Simulationssoftware von der Ziel- Hardware ab, auf der die Simulation ausgeführt werden soll. Die Simula­ tionssoftware wird gewöhnlich, auf der Ebene von Quellcode-Programmen, in einer problemorientierten Programmiersprache entwickelt.

Das tatsächlich ablaufende Simulationsprogramm wird durch Compilieren der Quellcode-Programme im maschinenausführbaren Programmcode für das Zielsystem erzeugt. Besonders geeignete Zielsysteme sind parallele Rechner­ systeme. Hochleistung-Simulationssysteme werden unter Verwendung von Parallelrechen-Technologien realisiert, zusammen mit einem System bestehend aus mehreren Bearbeitungseinheiten, z. B. einem Netzwerk aus mehreren Workstations oder einem Multiprozessor-System, das aus einer homogenen oder inhomogenen Menge von Prozessoren besteht.

Jedoch wächst mit steigender Rechnerleistung der verfügbaren Hardware auch der Wunsch nach komplexeren Modellen für die Realität.

Hinsichtlich des Modellierens von Systemen und des Entwickelns von Simula­ tionsalgorithmen, die auf parallelen Computersystemen ausgeführt werden können, wurden in der Vergangenheit beträchtliche Anstrengungen unternommen.

Das US-Patent 4,901,260 offenbart ein diskretes Ereignissimulationssystem, bei welchem die Simulation iterativ voranschreitet durch Beschränken der Simulation von in eine Reihenfolge gebrachten Ereignissen für jedes Subsystem zu jeder beliebigen Zeit auf ein ausgewähltes simuliertes Zeitsegment, das mit der niedrigsten Simulationszeit beginnt, welche in den Subsystemen gefunden wurde. Mit jeder Simulations-Iteration wird eine "Risiko"-Demarkationszeit ausgewertet, und zwar auf der Basis nur einer Untermenge der Subsysteme, welche die Simulation des betrachteten Subsystems beeinflussen können. Ziel ist es, die "Risiko"-Demarkationszeit auszudehnen. Jedoch betrifft dieses Patent nicht das Problem, wie die Simulationssoftware für ein Zielcomputersystem am besten angepaßt werden kann.

US-Patent 5,375,074 betrifft effiziente Simulation durch Anwenden hocheffi­ zienten Ordnens der zu simulierenden Ereignisse.

US-Patent 5,801,938 beschreibt eine Datenverarbeitungsvorrichtung, welche verteilte Prozessoren zur parallelen diskreten Ereignissimulation physikalischer Prozesse aufweist, wobei die Prozesse durch die Übertragung von Botschaften mit virtuellem Zeitstempel auf logischen Kanälen zwischen den Prozessoren in Reihenfolge gebracht werden.

US-Patent 5,794,005 betrifft objektorientierte Simulation und ein System mit verbundenen parallel arbeitenden Prozessor-Knoten zur Simulation gegenseitiger Interaktionen einer Menge von diskreten Simulationsobjekten, die zwischen den Knoten als eine Folge von diskreten Ereignissen verteilt sind.

US-Patent 5,652,871 offenbart ein System zum Durchführen von Nachbarschafts- Detektion in Computersimulationen auf parallel arbeitenden Architekturen unter Verwendung einer Verteilungsliste, welche Bewegtkörper- und Sensorüberdeckungen umfaßt, welche in Rasterelemente eintreten und aus diesen austreten.

Das Leistungsverhalten der Simulation auf parallelen Systemen hängt in hohem Maße von der Anpassung der Simulationssoftware an das gegebene Si­ mulationsmodell ab, ebenso wie von der Anpassung der resultierenden Simulationssoftware an die Hardware, auf der die Software ablaufen soll. Dieser Aspekt, der hier als Granularität der Software bzw. der Hardware bezeichnet wird, wurde im Stand der Technik nicht genügend beachtet. In diesem Zusammenhang sei die Granularität definiert als (durchschnittliche, maximale oder minimale) benötigte Zeit zum Bearbeiten von Daten aus Eingangsdaten, dividiert durch die benötigte Zeit zur Übertragung der Daten an ein Ziel. Noch genauer ist die Granularität der Software definiert als die Anzahl von Schritten zum Durchführen einer Operation, dividiert durch die Anzahl von Ergebnisbits zur Übertragung, die durch diese Operation produziert werden. Die Granularität der Hardware ist definiert als Zeit pro Schritt dividiert durch die zum Übertragen eines Bits be­ nötigte Zeit. In beiden Fällen kann der Nenner weiter in eine Summe aus Latenz und Kehrwert der Bandbreite aufgelöst werden.

Simulationssoftware des Standes der Technik gestattet nicht die Eigenschaft der Abstimmbarkeit bezüglich der Ziel-Hardware, für welche die Software entwickelt worden ist.

Insbesondere ist die Zuweisung der Verarbeitungseinheiten auf bestimmte Teile (d. h. Prozesse) des zu simulierenden Systems ein entscheidendes Problem. Die Lösung für dieses Problem besteht nicht einfach darin, die Anzahl von CPUs zu maximieren, da eine erhöhte Anzahl von CPUs zu einem erhöhten Aufkommen von Kommunikation zwischen CPUs und Synchronisationsbedarf führt, was andererseits die Gesamtgeschwindigkeit des Systems beschränkt. Dies führt zu einem Mißverhältnis zwischen der Granularität der Software und der Granularität der Hardware. Dieses Problem wird weiter verschärft, wenn das Zielsystem ein heterogenes System verschiedener Maschinen mit verschiedenen Verarbeitungskapazitäten (d. h. verschiedenen Hardware-Granularitäten) ist. Mit anderen Worten besteht das Problem darin, für ein gegebenes Zielsystem mit mehreren Verarbeitungseinheiten, deren jeden individuelle Rechengeschwindigkeit, Speicherkapazität und weitere Hardware-spezifische Parameter aufweist, eine optimale Verteilung der Simulation über das Zielsystem zu finden.

Des weiteren, wenn während der Laufzeit des konkreten Simulationsexperiments das Leistungsverhalten des Simulators verschlechtert wird aufgrund einer systematischen Überlast verschiedener Verarbeitungseinheiten, wäre es vorteilhaft, die Hardware-Struktur des Simulationssystems auf sich ändernde Anforderungen anpassen zu können. Diese Anpassung kann erreicht werden durch Hinzufügen weiterer Verarbeitungseinheiten zu denjenigen Einheiten, die überlastet sind, oder durch Ersetzen überlasteter Einheiten durch schnellere Einheiten. Bei bekannten Simulationssystemen muß dann jedoch auch die Si­ mulationssoftware an die modifizierte Hardware angepaßt werden, d. h. das Quellcode-Programm muß durch den Programmierer modifiziert und neu com­ piliert werden, um ein neues ausführbares Programm zu erzeugen. Jedoch erhöht die Notwendigkeit, das Programm auf Quellcode-Niveau manuell zu überarbeiten, die Kosten erheblich und verschlechtert darüber hinaus die Zuverlässigkeit eines solchen Simulationssystems.

Wenn andererseits die Leistungsfähigkeit der Simulation nur für eine (voraus­ sichtlich) kurze Zeit beeinträchtigt wird, wäre die Möglichkeit des Durchführens einer Lastverteilung zwischen einigen der Verarbeitungseinheiten während der Laufzeit (d. h. ohne Wiederholen des gesamten Simulationsexperiments von Anfang an), sehr wünschenswert.

Es ist daher ein Ziel der vorliegenden Erfindung, ein Verfahren zum automati­ schen Erzeugen, aus einer Eingangssimulations-Modellbeschreibung, von Ausgangs-Quellcodes der Beschreibung zu schaffen, wobei die Quellcodes auf unterschiedliche spezifische (verteilte oder parallele) Verarbeitungsumgebungen anpaßbar sind, ohne die Modellbeschreibung zu modifizieren und ohne menschliches Eingreifen.

Ein weiteres Ziel der vorliegenden Erfindung ist es, ein Verfahren und eine Hardware-Konfiguration zum Durchführen einer Simulation zu schaffen, welche auf sich ändernde Verarbeitungserfordernisse anpaßbar sind, ohne die Mo­ dellbeschreibung ändern zu müssen.

Diese Ziele werden erreicht durch das Verfahren gemäß Anspruch 1, das Si­ mulationsverfahren gemäß Anspruch 15 und die Hardware-Konfiguration gemäß Anspruch 18. Vorteilhafte Weiterbildungen sind in den abhängigen Ansprüchen definiert.

Gemäß der Erfindung geschaffen wird ein Verfahren zum automatischen Er­ zeugen von maschinenlesbaren Ausgangs-Quellcodes aus maschinenlesbarem Eingangs-Quellcode, wobei der Eingangs-Quellcode ein Modell eines zu simulie­ renden Systems (SUT) - insbesondere eines Kommunikationsnetzwerkes - dar­ stellt, wobei die Ausgangs-Quellcodes dazu bestimmt sind, compiliert zu werden oder auf einem Ziel-Hardwaresystem, das mehrere Verarbeitungsuntersysteme aufweist, ausgeführt zu werden, wobei das Modell das System (SUT) darstellt als eine Anzahl von elementaren Prozessen P₁, . . ., P_n, wobei jeder elementare Prozeß P_i elementare Interaktionen eI_ij, . . ., eI_ik mit einer Anzahl von anderen P_j, . . ., P_k der elementaren Prozesse P₁, . . ., P_n auszutauschen in der Lage ist, wobei das Verfahren die folgenden Schritte aufweist:

• A) Zusammenfassen der Anzahl elementarer Prozesse P₁, . . ., P_n in eine vorbestimmte Anzahl N disjunkter Aggregate A₁, . . ., A_N gemäß einer vorbestimmten Granularität mit Bezug auf die Ziel- Verarbeitungssubsysteme, wobei jeder Aggregat A_i
  • a) eine Anzahl p_i von Prozessen P_a, . . ., P_b der Anzahl elementarer Prozesse P₁, . . ., P_n aufweist,
  • b) Aggregat-Interaktionen aI_ij mit einer Anzahl der Anzahl von Aggregaten A₁, . . ., A_N hat, wobei jede Aggregat- Interaktion aI_ij elementare Interaktionen eI_ac, . . ., eI_ad; eI_bc, . . ., eI_bd der elementaren Prozesse P_a, . . ., P_b umfaßt, welche in dem jeweiligen Aggregat A_i zusammengefaßt sind, mit den elementaren Prozessen P_c, . . ., P_d eines anderen Aggregats A_j,
• B) Zusammenfassen der Anzahl von Aggregaten A₁, . . ., A_N, die im vorangegangenen Schritt erhalten wurden, in eine vorbestimmte Anzahl disjunkter Aggregate mit Bezug auf die Anzahl von Ziel- Subsystemen, wobei jeder Aggregat A_ii
  • 1. eine Anzahl a_i der Anzahl von Aggregaten A₁, . . ., A_N aufweist,
  • 2. Aggregat-Interaktionen aI_ij mit einer Anzahl der Anzahl von Aggregraten A₁, . . ., A_N aufweist, wobei jede Aggregat-Interak­ tion aI_ij Aggregat-Interaktionen aI_ac, . . ., aI_ad; aI_bc, . . ., aI_bd derjenigen Aggregate A_a, . . ., A_b aufweist, die in dem jeweiligen Aggregat A_ii zusammengefaßt sind, mit anderen Aggregaten A_c, . . ., A_d eines anderen Aggregats A_jj,
• C) rekursives Wiederholen des Schritts B) für einen oder mehrere der Aggregate A_i , bis jeder resultierende Aggregat A_ii eine vorbestimmte Granularität aufweist,
• D) Transformieren der resultierenden Aggregate A_ii in Ausgangs-Quellcodes.

Somit hat das Verfahren gemäß der Erfindung als Eingang eine Modellbe­ schreibung eines zu simulierenden Systems, wie sie durch typische Modellier­ werkzeuge von dritter Seite geliefert wird. Diese Modellbeschreibung hat die Form von elementaren Prozessen und elementaren Interaktionen, wobei die Beschreibung vollständig Hardware-unabhängig sein kann, und wird automatisch in Codes transformiert, die an eine spezielle Ziel-Hardwareumgebung angepaßt sind. Als zusätzliche Eingabe benötigt das Verfahren gemäß Anspruch 1 lediglich die Information hinsichtlich des Typs und der Struktur der Ziel-Hardware und des geforderten Simulationsstils.

Sinn der Aggregationsschritte ist es, eine Modellbeschreibung zu verarbeiten unter Verwendung der feinsten Granularität, wobei als technische Parameter diejenige Detail-Tiefe genommen wird, welches geeignet ist, das System darzustellen. Dann werden separate elementare Prozesse automatisch zusam­ mengefaßt, ("miteinander verschmolzen"), um größere Prozesse, genannt Ag­ gregate, zu bilden, bis der Grad der Granularität des Modells demjenigen des Ziel- Hardwaresystems entspricht. Der Prozeß des Zusammenfassens wird durchgeführt unter Verwendung von im Stand der Technik bekannten Algorithmen zum Simulieren der jeweiligen Submodelle (d. h. der Aggregate, die auf einer Verarbeitungseinheit ausgeführt werden sollen). Die Simulation jedes Aggregats wird wiederum als ein durch einen Simulator tieferen Niveaus zu simulierender Prozeß behandelt. Zum Simulieren eines Aggregats kann derjenige Algorithmus verwendet werden, der hinsichtlich des Submodells und der Ziel-Hardware am besten optimiert ist. Wenn beispielsweise ein Submodell auf einer Einheit mit einem einzigen Prozessor ausgeführt werden soll, kann ein sequentieller Algorithmus verwendet werden. Alternativ können, wenn die Ziel-Hardware heterogen ist, z. B. eine Mehrzahl von Workstations und spezielle parallele Maschinen aufweist, die Submodelle, die auf den Workstations ablaufen sollen, unter Verwendung sequentieller Algorithmen ausgeführt werden, wohingegen ein spezieller paralleler Simulationsalgorithmus auf der parallelen (Sub)-Maschine verwendet werden kann. Die zusammengefaßten Submodelle können somit unter Verwendung eines gröberkörnigen parallelen Algorithmus synchronisiert werden.

Die Anwendung des Verfahrens gemäß Anspruch 1 führt zu einer Menge von Quellcodes, deren jeder zur Ausführung auf jeweiligen Hardware-Subsystemen abgestimmt ist.

Vorteilhafterweise sind Zeitmarken-gestempelte Interaktionen zwischen ele­ mentaren Prozessen und/oder Aggregaten innerhalb Zeitintervallen begrenzt, derart, daß das Simulationsproblem unter Verwendung eines einheitlichen zeit­ gesteuerten Ansatzes verwirklicht werden kann. Bei Verwendung dieser Art der Verarbeitung können Simulationsalgorithmen implementiert werden, welche einen akkumulierten Lookahead (Vorausschau) des Aggregat-Submodells in Richtung von Simulatoren tieferen Niveaus bieten. Das Bereitstellen akkumulierten Lookaheads zu Simulatoren höheren Niveaus wird erreicht durch Markieren der Endzeit des Eingangsintervalls des Aggregats unter Verwendung von Protokoll-Ereignissen (d. h. Ereignissen, die nicht in dem SUT, sondern nur in der Simulation auftreten). Wenn ein derartiges Protokoll-Ereignis zu der virtuellen Zeit t simuliert wird, dann ist der Zielprozeß des Ereignisses temporär beendet, was bedeutet, daß, obwohl die Simulationszeit für den Simulator des Aggregats weiter voranschreiten wird, dieser spezifische Zielprozeß nicht länger in der Lage ist, Ereignisse zu verarbeiten. Als ein weiteres Ergebnis der Beendigung werden neue Protokoll-Ereignisse in die Reihenfolge eingeführt, die sich bei all denjenigen Prozessen ereignen, mit welchen der Zielprozeß Interaktionen hat. Der Zeitstempel dieser Protokoll-Botschaften ist t + Li, wobei Li die Voraussicht des Zielprozesses in Richtung des Zielprozesses i der neuen Protokoll-Botschaft ist. Wenn ein reales Ereignis bei einem beendeten Prozeß ausgeführt wird, wird es vorgemerkt, jedoch tatsächlich nicht berechnet. Es wird erst dann aufgeführt werden, wenn der Zustand des Simulators höheren Niveaus (d. h. des Aggregats) bis zu einer späteren Zeit bekannt ist. Diese Technik kann auf alle (sequentiellen und parallelen) Simulationsverfahren des Standes der Technik angewendet werden. Die resultierenden Algorithmen stellen für jedes Eingangsintervall für den Aggregat die Menge der spätestmöglichen Ausgangsintervalle bereit, die das Verhalten des gesamten Aggregats repräsentieren.

Weiter vorteilhafterweise weist das Verfahren einen Schritt auf, bei welchem die Ausgabequellcodes in Ziel-Hardware spezifische ausführbare Codes compiliert werden. Dies führt zu ausführbaren Programmen für die gegebenen spezifischen Hardware-Systeme, auf welchen die jeweiligen Programme ablaufen sollen.

Vorteilhafterweise werden die Zusammenfassungsschritte derart durchgeführt, daß sie die Granularität der ausführbaren Programmcodes mit Bezug auf die vorbestimmte Ziel-Hardware optimieren.

Die automatische Auswahl der zusammenzufassenden Prozesse zu einem Ag­ gregat kann durchgeführt werden gemäß jedem beliebigen Optimierungsalgo­ rithmus, wie z. B. "simulated annealing" oder genetischen Algorithmen oder dergleichen. Die Auswahl spezieller Optimierungsalgorithmen kann von Hardware-Eigenschaften des Entwurfs-Computersystems abhängig gemacht werden, auf welchem das erfindungsgemäße Verfahren gemäß Anspruch 1 ausgeführt wird.

Weiter vorteilhafterweise können die erzeugten Ausgangscodes Simulationsal­ gorithmen aufweisen, die geeignet sind, für jeden Eingang ein Ausgangsintervall entsprechend dem Verhalten des jeweiligen gesamten Aggregats zu berechnen. Algorithmen, die das spätestmögliche Ausgangsintervall (bezüglich des verfügbaren Eingangs) präsentieren, sind besonders geeignet zur Verwendung zum Simulieren zusammengefaßter Prozesse, da sie eine maximale Information für den Simulationsalgorithmus bereitstellen, so daß optimale Effizienz erreicht werden kann.

Die Simulationsalgorithmen, die zum Simulieren der elementaren Prozesse sowie der Aggregate (auf höherem Niveau) verwendet werden, werden vorteil­ hafterweise gemäß Eigenschaften der jeweiligen Aggregate und des Subsystems der Ziel-Hardware ausgewählt. Dies führt zu einem optimierten Simula­ tionssystem.

Besonders vorteilhaft ist, daß das erfindungsgemäße Verfahren zum Erzeugen spezifischer Quellcodes für jeden beliebigen speziellen Typ der Ziel-Hardware angewendet werden kann, sei es ein homogenes oder heterogenes Computer­ netzwerk, ohne daß die Modellbeschreibung selbst geändert werden müßte.

In einem weiteren Aspekt der Erfindung wird eine Möglichkeit bereitgestellt, die Hardware-Konfiguration während der Laufzeit des Simulationsprogramms zu verändern. Derartige Veränderungen betreffen die Anzahl und den Typ der Verarbeitungseinheiten, Peripherieeinheiten oder Kommunikationseinheiten. In dieser Weise kann die Hardware (bzw. deren Granularität) auf die konkrete Lastsituation während des Simulationsprozesses angepaßt werden. Des weiteren ermöglicht es das erfindungsgemäße Verfahren, eine Last von einer Verar­ beitungseinheit auf eine andere Verarbeitungseinheit "fliegend", d. h. ohne Neustarten der Simulationsausführung von Anfang an, durchzuführen.

Compilieren der erzeugten Ausgangs-Quellcodes führt zu der eigentlichen Si­ mulationssoftware, welche die ausführbaren Programmcodes für das Zielsystem enthält. Die Simulationssoftware bringt während ihrer Ausführung die Strukturen, technischen Merkmale und Vorteile gemäß den durch das erfindungsgemäße Erzeugungsverfahren hergestellten Ausgangs-Quellcodes zum Vorschein.

Die Hardware-Konfiguration zum Ausführen der Simulation kann jedes geeignete Computernetzwerk aufweisen.

Die Erfindung und Beispiele werden mit Bezug auf die beigefügten Zeichnungen im einzelnen beschrieben, in welchen

Fig. 1 einen topologischen Graphen eines Torus-Router-Netzwerks zeigt,

Fig. 2 ein Warteschlangen-Modell eines einzelnen Prozessors in einem Torus- Router zeigt, der mit einer Kommunikationsvorrichtung ausgestattet ist,

Fig. 3 den ersten Schritt des Zusammenfassens gemäß des Verfahrens der Er­ findung zeigt,

Fig. 4 einen zweiten Zusammenfassungsschritt zeigt,

Fig. 5 die Zielmaschinen-Konfiguration gemäß der Zusammenfassung von Fig. 4 darstellt,

Fig. 6 einen anderen zweiten Zusammenfassungsschritt darstellt,

Fig. 7 die Zielmaschinen-Konfiguration entsprechend der Zusammenfassung der Fig. 6 zeigt, und

Fig. 8 einen Leistungsverhaltensvergleich mit Programmcode, der für ver­ schiedene Zielmaschinen ansteigender Größe erzeugt wurde.

Das erste Beispiel betrifft das Quellcode-Compilierverfahren zum Erzeugen von maschinenlesbaren Codes aus Quellcodes an dem Beispiel eines Torus-Router- Netzwerkes.

Fig. 1 zeigt einen topologischen Graphen des Torus-Router-Netzwerks, welches das SUT darstellt. Dieses Modell, das hier als ein Beispiel verwendet wird, ist ein Beispiel eines Kommunikationsnetzwerkes, welches häufig in massiv-parallelen Maschinen verwendet wird, wo es die Aufgabe hat, Rechenanforderungen und Ergebnisse zwischen den Prozessoren auszutauschen.

Die Knoten des Torus repräsentieren Prozessoren, auf welchen Anwendungs­ software läuft, welche Botschaftspakete senden und empfangen und welche mit einem Torus-Router ausgestattet sind. Der Torus-Router garantiert hierbei, daß die Pakete, welche von sowohl dem Prozessor als auch dem Kommunikations­ netzwerk kommen können, zu dem richtigen Zielprozessor hin geroutet werden. Jeder Prozessor in der parallelen Maschine ist mit einer Kommunikations­ vorrichtung ausgestattet, welche zwei Eingangs- und zwei Ausgangsverbindungen mit dem Kommunikationsnetzwerk hat (siehe auch Fig. 2, die ein Warteschlangen-Modell einer Kommunikationsvorrichtung zeigt). Unter Ver­ wendung dieser vier Verbindungen sind die Prozessoren der parallelen Maschine in einem Raster mit Ende-zu-Anfang-Rückläufen verbunden, welches das Torus- Netzwerk bildet. Die Kommunikationsvorrichtungen sind in der Lage, Pakete, welche noch nicht an ihrem Ziel angekommen sind, in der richtigen Richtung (Dimension) in dem Torus-Netzwerk zu routen.

Bei dem in diesem Netzwerk angewendeten Routing reist ein Paket in einer Richtung so lange, bis die entsprechende Koordinate mit derjenigen des Ziels übereinstimmt, und hiernach fährt es in der nächsten Dimension fort.

Das Modell des SUT ist in der feinstkörnigen Form beschrieben, welche für die Art der Analyse relevant ist, für welche das Simulationssystem bestimmt ist. Die Operationen des Empfangens, Speicherns, Widerrufens, Lesens, Routens und Sendens eines Pakets, die in jeder Richtung und bei Ankunft eines Pakets am Ziel durchzuführen sind, werden durch ein Paar Einzelwarteschlangen-Server und einer nicht-verschwindenden Verzögerung (in den Demultiplexern, die auch das Routen durchführen, pro Dimension und pro Knoten modelliert).

Jede Kommunikationsvorrichtung wird durch ein Warteschlangen-Netzwerk modelliert, welches acht elementare Prozesse aufweist, wobei das Verhalten eines jeden Prozesses aus den üblichen Blöcken in dieser Modellbeschreibung (Warteschlangen, Server, Quellen, Senken, . . .) besteht, siehe Fig. 2.

Die elementaren Interaktionen zwischen den Prozessen stellen Netzwerk-Pakete dar, die ausgetauscht werden, entweder innerhalb der Kommunikations­ vorrichtung (z. B. vom internen Speicher zu dem Routing-Prozessor) oder zwi­ schen zwei Prozessoren. Die Modellbeschreibung gemäß Fig. 2 ist, in maschi­ nenlesbarer Quellcodeform, die Basis, auf welcher das Verfahren gemäß der Erfindung angewendet wird.

Gemäß der Erfindung wird die Modellbeschreibung in Ausgangs-Quellcodes gebracht, die dazu bestimmt sind, compiliert zu werden oder auf dem Ziel- Hardwaresystem, das mehrere Verarbeitungssubsysteme aufweist, ausgeführt zu werden.

Im ersten Schritt werden die elementaren Prozesse gemäß Fig. 2 in Submodelle (A₁, . . ., A_N) zusammengefaßt, welche die verarbeitenden Knoten (Prozessor und Kommunikationsvorrichtung) des SUT darstellen. Das gesamte Modell kann nun als eine Torus-Topologie dargestellt werden, die N = 3 × 12 = 36 derartige Knoten aufweist. Die elementaren Interaktionen zwischen den elementaren Prozessen stellen einzelne Pakete dar, die zwischen Teilen der Kommunikationsvorrichtung oder zwischen den Kommunikationsvorrichtungen ausgetauscht werden. Aufgrund der gröberen Granularität des resultierenden Modells weist eine zusammengefaßte Interaktion zwischen den resultierenden Aggregaten mehrere Pakete auf, welche zwischen Verarbeitungsknoten ausgetauscht werden.

Im zweiten Schritt werden die im ersten Schritt erhaltenen Aggregate weiter zu noch weniger (aber größeren) Aggregaten in ähnlicher Weise wie zuvor zu­ sammengefaßt, aber nunmehr auf Aggregate und nicht auf elementare Prozesse angewendet.

Die Aggregate gemäß Fig. 3 werden in eine Anzahl von NN = 4 Aggregate (Submodelle) zusammengefaßt gemäß der Anzahl und dem Typ von Subsystemen des Zielsystems, siehe Fig. 4. Der Aggregationsprozeß hängt ab von der Art der einzelnen Subsysteme, deren Anzahl von CPUs, deren Typen, d. h. von der Granularität der Subsysteme. In dem Fall der Fig. 3 ist das Zielsystem ein Netzwerk mit vier identischen Rechnern, siehe Fig. 4. Jeder der Aggregate A_ii umfaßt neun Aggregate der ersten Iteration, a_ii = 9, wobei jeder Aggregat ein Segment des Torus darstellt (siehe Fig. 3). Die zusammengefaßten Interaktionen umfassen Pakete, die zwischen einem Segment und einem anderen Segment versendet werden. Die Aggregat-Interaktionen (ausgetauscht über die Eingänge und Ausgänge der jeweiligen Aggregate) umfassen die Interaktionen mit Prozessen, die in anderen dieser Aggregate zusammengefaßt sind, jedoch ersetzt jede derartige Interaktion eine Anzahl von Aggregat-Interaktionen aI zu und von dem zusammengefaßten Aggregat des vorhergehenden Iterationsschritts.

Der zweite Schritt kann rekursiv wiederholt werden für einige oder alle Aggre­ gate. Das Ziel ist, Aggregate herzustellen (die eine Anzahl von Prozessen des ursprünglichen SUT darstellen), welche gut zu dem Ziel-Subsystem passen, auf dem sie ausgeführt werden sollen.

Da das erfindungsgemäße Verfahren nicht auf homogene Zielsysteme beschränkt ist, ist es möglich, Aggregation mit unterschiedlicher Tiefe (d. h. unterschiedliche Anzahl von Rekursionen) für unterschiedliche Aggregate durchzuführen. Dies ist im besonderen Maße eine interessante Möglichkeit z. B. dann, wenn eines der Hardware-Subsysteme bereits eine parallele Maschine ist, während andere Maschinen Rechner mit einer einzigen CPU sind. In diesem Fall ist der Aggregationsprozeß für die parallele Maschine beendet, bevor die Aggregation der Prozesse/Aggregate für die Maschine mit einer CPU beendet wird, da die parallele Maschine einen gewissen Grad von Parallelismus verwalten kann.

Es sei darauf hingewiesen, daß die theoretische Maximalzahl von Rekursionen erreicht ist, wenn nur noch ein einziger Aggregat übrigbleibt. Dann würde dieser Aggregat das gesamte Modell des SUT enthalten. Dies entspricht einer Be­ schreibung des SUT für nur eine einzige Verarbeitungseinheit, ist somit eine vollständig sequentielle Beschreibung.

Andererseits ist es möglich, daß einige der elementaren Prozesse nicht mit an­ deren zusammengefaßt werden. Im Beispiel der Fig. 6 werden die oberen neun Aggregate nicht miteinander verschmolzen. Dies ist vorteilhaft, wenn die Ziel- Hardware streng heterogen ist. Beispielsweise kann das nichtaggregierte Sub­ modell auf einer feinkörnigen Parallelmaschine ausgeführt werden, während die aggregierten Untermodelle auf Einzelprozessor-Maschinen ausgeführt werden, siehe Fig. 7, wo die parallele Maschine im Netzwerk oben dargestellt ist.

Im letzten Schritt werden die verbleibenden Aggregate in maschinenlesbare Codes transformiert. Diese maschinenlesbaren Codes stellen noch immer eine Modellbeschreibung in einer Quellcodesprache dar, nun aber spezifisch für das Ziel-Subsystem. Es sei darauf hingewiesen, daß die Ausgangs-Quellcodes auch Simulator-Ausführungscodes enthalten.

Somit ist das Ergebnis des zweiten Schritts gemäß der Erfindung eine (trans­ formierte) Quellcodebeschreibung des SUT-Modells. Es sei darauf hingewiesen, daß die Aggregationsprozedur das Modell selbst nicht verändert.

Die Anwendung des erfindungsgemäßen Verfahrens schafft die Möglichkeit, die Granularität der Software (durch Aggregation der Prozesse) und auch die Granularität der Ziel-Hardware (durch Hinzufügen zusätzlicher Verarbeitungs­ einheiten) zu trimmen.

Vorteilhafterweise kann die Aggregation in einer derartigen Weise durchgeführt werden, daß die Granularität der Software mit Bezug auf die Ziel-Hardware optimiert wird.

Einer der hauptsächlichen Vorteile ist, daß der Prozeß des Erzeugens des Modells von dem Prozeß des Herstellens ausführbarer Programme getrennt wird. Somit ist, wenn die Zielsystem-Konfiguration sich ändert, überhaupt keine Änderung auf Modellbeschreibungsniveau notwendig. Lediglich die Aggregationsschritte werden von neuem durchgeführt, um die Simulation hinsichtlich der neuen Hardware-Konfiguration zu optimieren.

Die maschinenausführbaren Codes werden aus den Ausgangs-Quellcodes durch einen Programmcode-Compilierungsschritt erzeugt. Dies wird erreicht durch Compilieren der Ausgangs-Quellcodes der jeweiligen Aggregate zu ausführbaren Programmen für die jeweiligen Ziel-Subsysteme.

Es ist auch möglich, die Quellcodebeschreibung, wie sie durch Anwenden des erfindungsgemäßen Verfahrens erhalten wird, (oder einiger Teile davon) auf einer Interpreter-Plattform (z. B. virtuelle Java-Maschine) auszuführen. In diesem Fall besteht keine Notwendigkeit für den jeweiligen Programmcode-Compilierschritt.

Wenn das Modellierwerkzeug keine genügend feinkörnige Beschreibung des SUT liefert, wird ein Schritt des Auflösens der gelieferten Modellbeschreibung in eine Beschreibung, die elementare Prozesse enthält, noch vor dem ersten Aggregationsschritt durchgeführt. Der Auflösungsschritt zerlegt die Modellbe­ schreibung unter Verwendung von Information aus dem Modellierwerkzeug, wobei die Information üblicherweise aus der Datenbank dieses Werkzeugs verfügbar ist.

Auf der Basis einer und derselben Modellbeschreibung wurde das Codeerzeu­ gungsverfahren gemäß Anspruch 1 verwendet zum Erzeugen von ausführbaren Codes zum Simulieren des Modells für mehrere unterschiedliche Zielsysteme. Die Zielsysteme umfassen einen bis 8 Personal Computer, die durch ein lokales Netzwerk verbunden sind; jeder Computer hat eine CPU. Das Modell stellt ein Torus-Netzwerk von 128 × 4 Prozessoren dar. Fig. 8 zeigt einen Vergleich des Leistungsverhaltens mit Programmcode erzeugt für die unterschiedlichen Zielsysteme. Das Diagramm zeigt die Simulationsausführungszeit über der Anzahl von Verarbeitungseinheiten des Zielsystems. Während die Eingangs-SUT- Beschreibung konstantgehalten ist, müssen lediglich die ausführbaren Codes der unterschiedlichen Zielsysteme geändert werden unter Verwendung verschiedener Aggregationen gemäß dem Erzeugungsverfahren. Dies stellt einen großen Vorteil bei der Entwicklung von Simulationssoftware dar.

In einem zweiten Beispiel wird das erfindungsgemäße Verfahren wie oben beschrieben angewendet, um Zielsystem-spezifischen Quellcode (und sodann einen ausführbaren Simulationsprogrammcode) einmal für die ganze Simulation (statisches adaptives System) zu erzeugen. Des weiteren unterstützt die vorliegende Erfindung auch die Vorgehensweise einer Anpassung des Simula­ tionssystems zur Laufzeit der Simulationsausführung (dynamisches adaptives System). Dies basiert auf der Überlegung, daß während der Laufzeit einer konkreten Simulation die Last, d. h. das Aufkommen von Rechenleistung oder Datenkommunikation einzelner Verarbeitungseinheiten über die Zeit variieren kann, so daß das ursprünglich compilierte Programm weniger effizient wird. In diesem Fall kann die Software oder sowohl die Software als auch die Hardware geändert werden, um diese der gegenwärtigen Granularität des Problems anzu­ passen. Auf der Basis des Programms, wie es durch das erfindungsgemäße Verfahren erzeugt wird, ist dies möglich, ohne die ursprüngliche Modell­ quellcode-Beschreibung zu ändern.

Die Software-Anpassung wird durch Neucompilieren von Teilen oder der gesamten Modellcode-Beschreibung durchgeführt, die durch den ersten Schritt erhalten wurde mit unterschiedlicher Aggregation des zu simulierenden Modells gemäß dem zweiten Schritt. Vorteilhafterweise kann das Neucompilieren auf einem separaten Computersystem durchgeführt werden, so daß die laufende Simulation für die Zeit des Neucompilierens nicht unterbrochen werden muß. Der neucompilierte ausführbare Code kann in die jeweiligen Verarbeitungseinheiten zu beliebiger Zeit geladen werden.

Die Hardware-Konfiguration kann entweder manuell (d. h. durch Hinzufügen zusätzlicher Ressourcen zu dem Netzwerk) oder automatisch geändert werden. Eine Möglichkeit, die Ziel-Hardware automatisch zu ändern, ist gegeben durch die Verwendung wiederkonfigurierbarer programmierbarer Zellen (z. B. Feld­ programmierbarer Gate-Arrays (FPFAs). In diesem Fall ist das Simulationssystem geeignet, Systemlast-Parameter wie z. B. das Rechenaufkommen und die Kommunikationshäufigkeit der Verarbeitungseinheiten des Zielsystems zu überwachen. Wenn das Leistungsverhalten des Simulationsprogramms abfällt (oder wenn zusätzliche Hardware-Ressourcen verfügbar werden), kann die Si­ mulation "eingefroren" werden, die Hardware kann automatisch modifiziert werden (entsprechend der neuen Granularität des Problems) durch Neupro­ grammieren der Funktionszellen. Zu diesem Zweck sind die pogrammierbaren Zellen mit Programmiermitteln ausgestattet (z. B. mit einer entsprechenden Ladelogik). Dann wird durch Wiederanwenden des erfindungsgemäßen Ver­ fahrens das Simulationsprogramm an die neue Zielsystem-Konfiguration ange­ paßt. Da, wie oben beschrieben, das zu simulierende Modell überhaupt nicht geändert wird, kann die Simulationsausführung in demjenigen Zustand fortgesetzt werden, in dem es vor der Rekonfigurierung war.

Dies führt zu einer kürzeren Gesamtrechenzeit für die Simulation und zu einer verbesserten Verwendung der verfügbaren Hardware-Ressourcen.

Das erfindungsgemäße Verfahren kann mit Parallelrechen-Topologie jeglicher Art verwendet werden, seien es Multiprozessor-Konfigurationen oder erteilte Systeme, beispielsweise homogene oder inhomogene Netzwerke, oder Kombi­ nationen dieser Systeme. Selbstverständlich kann dieselbe Simulationsquelle verwendet werden für verschiedene Ebenen der Simulation, beispielsweise Simulation des SUT in makroskopischem, mesoskopischem oder mikroskopi­ schem Maßstab.

Dateneingaben für das zu simulierende System können durch Zufallsprozesse oder von gemessenen Prozessen aus dem entsprechenden realen System erzeugt werden. In letzterem Fall können die Ergebnisse der Simulation zum Steuern des künftigen Verhaltens des realen Systems verwendet werden, z. B. durch Beeinflussung von Parametern des realen Systems auf Basis der Simulationsergebnisse.

Das erfindungsgemäße Quellcodeerzeugungsverfahren kann im Rahmen eines Softwareentwicklungs-Computersystems zum Erzeugen von Quellcodes für die Simulation eines beliebigen realen Systems angewendet werden, wie z. B. für ein Telekommunikationsnetz, Straßenverkehr auf einem Stadtplan zum Steuern des städtischen Verkehrs oder zum Steuern von Produktionsstätten.

Claims (19)

1. Verfahren zum automatischen Erzeugen von maschinenlesbaren Aus­ gangs-Quellcodes aus maschinenlesbarem Eingangs-Quellcode, wobei der Eingangs-Quellcode ein Modell eines zu simulierenden Systems (SUT) - insbesondere eines Kommunikationsnetzwerkes - darstellt,
wobei die Ausgangs-Quellcodes dazu bestimmt sind, compiliert zu werden oder auf einem Ziel-Hardwaresystem, das mehrere Verarbeitungs­ untersysteme aufweist, ausgeführt zu werden,
wobei das Modell das System (SUT) darstellt als eine Anzahl von ele­ mentaren Prozessen (P₁, . . ., P_n), wobei jeder elementare Prozeß (P_i) elementare Interaktionen (eI_ij, . . ., eI_ik) mit einer Anzahl von anderen (P_j, . . ., P_k) der elementaren Prozesse (P₁, . . ., P_n) auszutauschen in der Lage ist,
wobei das Verfahren die folgenden Schritte aufweist:

• A) Zusammenfassen der Anzahl elementarer Prozesse (P₁, . . ., P_n) in eine vorbestimmte Anzahl (N) disjuncter Aggregate (A₁, . . ., A_N) gemäß einer vorbestimmten Granularität mit Bezug auf die Ziel- Verarbeitungssubsysteme, wobei jeder Aggregat (A₁)
  • a) eine Anzahl p_i von Prozessen (P_a, . . ., P_b) der Anzahl elementarer Prozesse (P₁, . . ., P_n) aufweist,
  • b) Aggregat-Interaktionen (aI_ij) mit einer Anzahl der Anzahl von Aggregaten (A₁, . . ., A_N) hat, wobei jede Aggregat- Interaktion (aI_ij) elementare Interaktionen (eI_ac, . . ., eI_ad; eI_bc, . . ., eI_bd) der elementaren Prozesse (P_a, . . ., P_b) umfaßt, welche in dem jeweiligen Aggregat (A_i) zusammengefaßt sind, mit den elementaren Prozessen (P_c, . . ., P_d) eines anderen Aggregats (A_j),
• B) Zusammenfassen der Anzahl von Aggregaten (A₁, . . ., A_N), die im vorangegangenen Schritt erhalten wurden, in eine vorbestimmte Anzahl disjunkter Aggregate mit Bezug auf die Anzahl von Ziel- Subsystemen, wobei jeder Aggregat (A_ii)
  • a) eine Anzahl a_i der Anzahl von Aggregaten (A₁, . . ., A_N) aufweist,
  • b) Aggregat-Interaktionen (aI_ij) mit einer Anzahl der Anzahl von Aggregraten (A₁, . . ., A_N) aufweist, wobei jede Aggregat-Interaktion (aI_ij) Aggregat-Interaktionen (aI_ac, . . ., aI_ad; aI_bc, . . ., aI_bd) derjenigen Aggregate (A_a, . . ., A_b) aufweist, die in dem jeweiligen Aggregat (A_ii) zusam­ mengefaßt sind, mit anderen Aggregaten (A_c, . . ., A_d) eines anderen Aggregats (A_jj),
• C) rekursives Wiederholen des Schritts B) für einen oder mehrere der Aggregate (A_i), bis jeder resultierende Aggregat (A_ii) eine vorbestimmte Granularität aufweist,
• D) Transformieren der resultierenden Aggregate (A_ii) in Ausgangs- Quellcodes.

2. Verfahren gemäß Anspruch 1, dadurch gekennzeichnet, daß die Inter­ aktionen zwischen Prozessen oder Aggregaten in Form von Zeitintervallen definiert sind, welche die elementaren Interaktionen hinsichtlich der Zeit begrenzen.

3. Verfahren gemäß Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Ausgangs-Quellcodes zu Hardwarespezifischen ausführbaren Codes compiliert werden.

4. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch ge­ kennzeichnet, daß mindestens eine Anzahl p_i oder a_i gleich 1 ist.

5. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch ge­ kennzeichnet, daß die Zusammenfassungsschritte derart durchgeführt werden, daß die Granularität der ausführbaren Programmcodes mit Bezug auf die vorbestimmte Ziel-Hardware optimiert wird.

6. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch ge­ kennzeichnet, daß die Wahl der zusammenzufassenden Prozesse zu einem Aggregat gemäß vorbestimmten Optimierungsalgorithmen, wie z. B. simulated annealing oder genetischen Algorithmen, durchgeführt wird.

7. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch ge­ kennzeichnet, daß die ausführbaren Codes Simulationsalgorithmen ent­ halten, die geeignet sind, für jede Eingabe der jeweiligen Aggregate ein Ausgabeintervall zu berechnen, vorzugsweise das letztmögliche Aus­ gabeintervall.

8. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch ge­ kennzeichnet, daß die Simulationsalgorithmen gemäß vorbestimmten Eigenschaften der jeweiligen Aggregate und der Ziel-Hardware ausgewählt werden.

9. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch ge­ kennzeichnet, daß die Ziel-Hardware aus einem heterogenen Compu­ ternetzwerk besteht.

10. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch ge­ kennzeichnet, daß die Ziel-Hardware eine Anzahl von Multi-Prozessor- Systemen aufweist.

11. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch ge­ kennzeichnet, daß die Ziel-Hardware eine Anzahl statisch oder dynamisch rekonfigurierbarer Gate-Arrays aufweist.

12. Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch ge­ kennzeichnet, daß mehrere Aggregate (A_i) einer Verarbeitungseinheit zugeordnet werden.

13. Compiler, der das Verfahren gemäß einem der vorhergehenden Ansprüche durchführt.

14. Compiler gemäß Anspruch 13, dadurch gekennzeichnet, daß er Mittel zum Eingeben der Anzahl und zum Spezifizieren der Typen von Verar­ beitungeinheiten und Typen von Simulationsalgorithmen aufweist.

15. Programm zum Durchführen einer Simulation eines Modells eines Sy­ stems (SUT) - insbesondere eine Kommunikationsnetzwerkes - auf einem Ziel-Hardwaresystem mit mehreren Verarbeitungssubsystemen, dadurch gekennzeichnet, daß das Programm Ausgangscodes aufweist, die unter Verwendung des Verfahrens gemäß einem der vorhergehenden Ansprüche erzeugt wurden.

16. Programm gemäß Anspruch 15, dadurch gekennzeichnet, daß die Ziel- Hardware eine Anzahl statisch oder dynamisch rekonfigurierbarer Gate- Arrays aufweist.

17. Verfahren gemäß Anspruch 15 oder 16, dadurch gekennzeichnet, daß während der Laufzeit Teile der Ziel-Hardware geändert werden können, wobei für die Teile ein neuer spezifischer ausführbarer Code gemäß dem Verfahren eines der Ansprüche 1 bis 14 erzeugt wird.

18. Hardware-Konfiguration zum Durchführen einer Simulation eines Systems (SUT), aufweisend:
Eine Anzahl von Verarbeitungseinheiten,
Speichermittel,
ein Netzwerk zum Verbinden der Verarbeitungseinheiten und der Spei­ chermittel,
dadurch gekennzeichnet, daß es zum Ausführen des Programms gemäß einem der Ansprüche 15 bis 17 geeignet ist.

19. Hardware-Konfiguration gemäß Anspruch 18, weiterhin statistisch oder dynamisch rekonfigurierbare logische Mittel zum Rekonfigurieren einer Anzahl der Verarbeitungseinheiten aufweisend.