-
Hintergrund
der Erfindung
-
Die
Erfindung betrifft die Simulation von digitalen Systemen. Insbesondere,
aber nicht ausschließlich betrifft
die Erfindung simulierende komplexe logische Netzwerke, wie sie
in elektronischen Rechnern anzutreffen sind.
-
Herkömmliche
Simulatoren verwenden eine Warteschlange zum zeitlichen Planen von Änderungen am
Status des simulierten Systems. Wann immer festgestellt wird, dass
der Status geändert
werden soll, wird eine Aufzeichnung, die den neuen Statuswert enthält, der
entsprechenden Position der Warteschlange hinzugefügt. Im Betrieb
wird die Warteschlange sequentiell abgetastet, um den Durchlauf
der Zeit zu simulieren und, wenn jede Aufzeichnung abgetastet ist,
werden die neuen Zustandswerte, die durch diese Aufzeichnung gegeben
sind, gesetzt.
-
Die
VHDL-Simulationssprache [ANSI/IEEE Standard 1076] verwendet Signale,
um Änderungen
des Zustands um das Simulationsmodell herum fortzupflanzen. Signale
werden als nicht aufgelöste
und aufgelöste Signale
klassifiziert. Nicht aufgelöste
Signale sind solche, die nur eine Antriebsquelle haben, während aufgelöste Signale
mehr als eine Antriebsquelle haben. Ein Auflösungs-Prozess wird verwendet,
um aufgelöste
Signale zu handhaben, damit die Werte aus den unterschiedlichen
Quellen aufgelöst
werden.
-
Nicht
aufgelöste
Signale können
entweder auf Ereignis basierende oder auf Delta basierende Signale sein.
Auf Ereignis basierende Signale können explizite Zeitverzögerungen
haben, die ihnen zugeordnet sind. Andererseits repräsentieren
Signale auf Delta-Basis Änderungen,
die als augenblicklich stattfindend angenommen werden; d. h. dass
ihnen keine expliziten Zeitverzögerungen
zugeordnet sind. Auf Delta-Basis beruhende Signale werden verwendet,
um eine Unabhängigkeit
der Reihenfolge für
gleichlaufende Prozesse sicher zu stellen und zu gewährleisten,
dass Änderungen
an dem Signalwert nur dann stattfinden, wenn alle gleichlaufenden
bzw. parallelen Prozesse ihre Ausführung für die jeweilige Zeiteinheit
abgeschlossen haben. Im Falle eines auf Ereignis basierenden Signal
wird eine Aufzeichnung der Warteschlange zu der entsprechenden Zeitposition
hinzugefügt,
wobei die Zeitverzögerung
für dieses
Signal berücksichtigt
wird. Im Falle eines Delta-Basis-Signals
wird eine Aufzeichnung an der Position in der Warteschlange hinzugefügt, die
der laufenden Simulationszeit entspricht.
-
Konventionalle
VHDL-Simulatoren verwenden ein zentralisiertes Kernel-Programm,
um die Arbeitsweise des Simulations-Modells zu steuern. Ein derartiges
Kernel-Programm macht ein feststehenden Datenformat erforderlich,
mit dem alle Datentypen, die bei der Simulation verwendet werden,
konform sein müssen, um Änderungen
des Zustands des Modells zu repräsentieren,
und es benötigt
einen Bereich von verallgemeinerten Routinen zur Handhabung aller
dieser Änderungen.
-
Ein
Problem besteht dabei darin, dass dann, wenn das simulierte Netzwerk
groß und
komplex ist, die Simulation sehr langsam verlaufen kann und damit
sehr viel Zeit für
den Durchlauf benötigt.
Auch stellt die Komplexität
des Kernel-Programms ein Problem dar, falls es erforderlich ist,
einen hohen Leistungspegel aufrecht zu erhalten, während das
Kernel-Programm in der Lage sein muss, sich mit jeder Datentype – gleich
welcher Form – zu
befassen. Jede Einstellung an dem Kernel-Programm wird in bezug
auf Leistung kritisch, und manche Datentypen können nicht hinzuaddiert werden,
weil die Gefahr besteht, Simulationsleistung zu verlieren.
-
Aufgabe
der Erfindung ist, eine Möglichkeit
zu schaffen, die Leistung eines Simulationssystems zu verbessern,
um die Geschwindigkeit für
die Durchführung
der Simulation zu erhöhen.
-
Kurzbeschreibung
der Erfindung
-
Gemäss der Erfindung
weist ein Simulator zum Simulieren eines digitalen Systems ein Simulations-Modell
eines digitalen Systems zur Verwendung in einem elektronischen Computer,
eine Ereignis – Warteschlange
zum zeitlichen Planen von Änderungen
bezüglich
des Zustandes des Simulations-Modells zu bestimmten Zeiten und eine
getrennte Delta – Warteschlange
zum zeitlichen Planen von Änderungen
bezüglich des
Zustands des Simulations-Modells auf, die alle augenblicklich stattfinden
sollen.
-
Es
wird gezeigt, dass die Verwendung von getrennten Ereignis- und Delta-Warteschlangen
auf diese Weise die Möglichkeit
schafft, eine Reihe von Optimierungen vorzunehmen, die bei einem
herkömmlichen
Simulator mit einer einzigen Warteschlange sowohl für Ereignisse
als auch für
Deltas nicht möglich
wäre.
-
Vorzugsweise
umfasst das Simulations-Modell eine Anzahl von austauschbaren Teilen,
von denen jedes seine eigenen Zustands-Informationen enthält, und
für das
Managen der eigenen Zustands-Informationen verantwortlich ist. Die
Ereignis-Warteschlange und die Delta-Warteschlange enthalten Hinweise
auf die Teile des Modells, für
die Änderungen
des Zustands geplant sind, ohne dass die tatsächlichen Werte dieser Änderungen
des Zustands darin enthalten sind.
-
Nachstehend
wird gezeigt, dass dies eine Anzahl von weiteren Optimierungen ermöglicht,
die bei einem herkömmlichen
Simulator mit einem zentralisierten Kernel nicht möglich wären.
-
Kurzbeschreibung der Zeichnungen
-
1 zeigt
ein schematisches Blockschaltbild eines Rechnersystems, in dem ein
Simulator nach der Erfindung enthalten ist.
-
2 zeigt
ein schematisches Schaltbild eines Simulations-Modells.
-
3 stellt
ein Flussschaltbild eines hochkarätigen Modells dar, das in dem
Simulator verwendet wird.
-
4 stellt ein Flussschaltbild einer Pop_Deltas
() Funktion dar.
-
5 stellt
ein Flussschaltbild einer Pop_Events () Funktion dar.
-
6 stellt
ein Flussschaltbild einer Entry () Funktion dar.
-
7 stellt
ein Flussschaltbild einer Send_Event () Funktion dar.
-
8 stellt
ein Flussschaltbild einer Fire_Event () Funktion dar.
-
9 zeigt
ein schematisches Schaltbild eines Teils des Simulators.
-
Beschreibung
einer Ausführungsform
der Erfindung
-
Ein
Simulator nach der Erfindung wird nachstehend anhand eines Ausführungsbeispieles
in Verbindung mit den Zeichnungen beschrieben.
-
Gesamtübersicht
des Simulators
-
Nach 1 weist
der Simulator einen Allzweck-Rechner 10 auf, der eine Anzahl
von Software-Komponenten einschließlich eines Simulations-Modells 11,
eines Top-Level-Modells 12,
einer Ereignis-Warteschlange 13 und einer Delta-Warteschlange 14 umfasst.
-
Das
Simulations-Modell 11 simuliert ein spezifisches logisches
Netzwerk. Das Top-Level-Modell 12 ergibt
einen Rahmen zum Betreiben des Simulations-Modells und ist von der
gleichen Gattung wie eine Reihe von Simulations-Modellen.
-
Die
Ereignis- und Delta-Warteschlangen 13, 14 werden
zum zeitlichen Ablaufplanen von Änderungen in
den Zustand des Modells verwendet. Die Ereignis-Warteschlange plant
zeitlich Änderungen,
die zu bestimmten Zeiten stattfinden sollen, während die Delta-Warteschlange Änderungen
zeitlich plant, von denen angenommen wird, dass sie gleichzeitig
stattfinden.
-
Der
Simulator verwendet zwei Ausführungsformen
von simulierter Zeit: Die Ereignis-Zeit und die Delta-Zeit. Die Ereignis-Zeit
wird in Zeiteinheiten, z. B. Nanosekunden gemessen. Die Delta-Zeit
stellt einfach eine ganze Zahl dar, die schrittweise jedesmal weiter
geschaltet wird, wenn die Delta-Warteschlange verarbeitet wird,
d. h. jedes Mal dann, wenn eine pop_Deltas () Funktion (siehe unten)
ausgeführt
wird.
-
Simulations-Modell
-
2 zeigt
eine vereinfachte Ausführungsform
eines Simulations-Modells 11. Das Modell umfasst eine Anzahl
von Prozess-Objekten P1–P6
und Signal-Objekten S1–S7,
von denen jedes einen veränderbaren Teil
des Simulations-Modells darstellt. Jedes Objekt hat einen Zustand,
der durch eine oder mehrere Datenstrukturen repräsentiert wird, und ein Verhalten,
das durch eine Reihe von Funktionen repräsentiert wird, wie nachstehend
beschrieben. Jedes dieser Objekte wird als ein Augenblick einer
verallgemeinerten Klasse kreiert. Es wird unterstellt, dass im allgemeinen
Simulations-Modelle
wesentlich komplexer sind als die in dieser Zeichnung dargestellten,
und dass sie wesentlich mehr Objekte einschließen.
-
Die
Prozess-Objekte stellen spezifische funktionelle Teile des simulierten
logischen Netzwerkes, z. B. VHDL-Prozesse, dar. Die Signal-Objekte
stellen Signale zwischen diesen Teilen dar. Ein Prozess-Objekt kann den
Status eines oder mehrerer Signal-Objekte ändern. In 2 beispielsweise ändert das
Prozess-Objekt P1 den Status des Signal-Objekts S1. Ein Prozess-Objekt
kann seinerseits von einem oder mehreren Signal-Objekten abhängig (oder
von ihm angetrieben) sein: In 2 beispielsweise
wird P2 durch S1 angetrieben. Es ist für ein Prozess-Objekt auch möglich, ein
weiteres Prozess-Objekt direkt ohne Zwischenschaltung eines Signal-Objektes
anzurufen.
-
Allgemein
treiben viele der Signal-Objekte keine Prozess-Objekte an. Diese
Signal-Objekte dienen
lediglich als Status-Halter zur Speicherung von Status-Werten, anstatt
dass sie ein Prozess-Objekt mit einem anderen koppeln. In diesem
Beispiel treibt S2, S6 und S7 keine Prozess-Objekte an.
-
Ein
Simulations-Modell kann auch andere Arten von Objekten, zusätzlich zu
Prozess-Objekten
und Signal-Objekten enthalten. Beispielsweise kann das Modell ein
kombiniertes Prozess-Signal-Objekt einschließen, das sowohl einen Prozess
als auch ein Signal repräsentiert.
Dieses kann verwendet werden, um beispielsweise eine Zustands-Maschine
oder einen getakteten Prozess zu simulieren.
-
Gespaltene
Prozesse
-
Jedes
Signal-Objekt kann direkt nur ein Prozess-Objekt maximal antreiben.
Wenn von dem Modell verlangt wird, dass ein bestimmtes Signal mehr
als einen Prozess antreibt, wird ein gespaltener Prozess zwischen das
Signal-Objekt und die abhängigen
Prozess-Objekte
eingeführt.
In 2 beispielsweise ermöglicht der gespaltene Prozess
SP1, dass das Signal-Objekt S3 drei unabhängige Prozess-Objekte, nämlich P1,
P3 und P4 antreibt. Diese Beschränkung
verbessert die Effizienz des Modells, da sie die Notwendigkeit für einen
komplexen Code zur Handhabung des Antreibens einer Anzahl von Prozessen
vermeidet. Auch reduziert sie die Anzahl von Warteschlangen-Vorgängen, da
sie bedeutet, dass nur ein einziger Warteschlangen-Vorgang erforderlich
ist, anstatt einer für
jedes der abhängigen
Prozess-Objekte.
-
Ein
gespaltener Prozess kann einfach eine Folge von Anrufen zu den Entry
()-Funktionen eines
jeden der abhängigen
Prozess-Objekte enthalten. Beispielsweise kann der gespaltene Prozess
SP1 in 2 aus Anrufen zu den Entry ()-Funktionen von P1,
P3 und P4 bestehen: Ein gespaltener Prozess kann auch bestimmte
Verarbeitungsvorgänge
durchführen.
Beispielsweise kann ein gespaltener Prozess den Wert eines bestimmten
Signales, z. B. eines Taktsignales, testen und unterschiedliche
Funktionen aufrufen, je nach dem, ob dieses Signal echt oder falsch
ist.
-
Prozess-Objekte
-
Ein
typisches Prozess-Objekt P hat einen Zustand, der durch eine oder
mehrere Daten-Strukturen
repräsentiert
ist. Diese Daten-Strukturen können
interne Status-Daten, z. B. die Variablen des Prozesses darstellen.
-
Ein
typisches Prozess-Objekt weist auch zwei Funktion auf:
| Init
(): | Eine
Initialisier-Funktion. |
| Entry
(): | Eine
Eintritts-Funktion. |
-
Signal-Objekte
-
Ein
typisches Signal-Objekt S weist die folgenden Zustandsdaten auf:
| Old_State: | Der
alte Status des Signal-Objektes. |
| New_State: | Der
neue Status des Signal-Objektes. |
| Altered: | Ein
Kennzeichen, das angibt, ob der Status des Signal-Objektes sich
geändert
hat oder nicht. |
| proc_ptr: | Ein
Hinweiszeichen auf das Prozess-Objekt (falls gegeben), das durch
dieses Signalobjekt angetrieben ist. |
-
Zum
Beispiel zeigt in 2 das proc_ptr von S1 Punkten
auf P2. Wenn das Signal-Objekt
kein Prozess-Objekt antreibt, ist dieses Hinweiszeichen Null.
-
Last_delta_time:
Der letzte Delta-Zeitwert, für
den eine Änderung
in dieses Signal-Objekt
auf der Delta-Warteschlange disponiert worden ist.
-
Last_event_time:
Der letzte Ereignis-Zeitwert, für
den eine Änderung
in dieses Signal-Objekt
auf der Ereignis-Warteschlange disponiert worden ist.
-
Zusätzlich enthält ein typisches
Signal-Objekt die folgenden Funktionen:
-
init
(): Initialisiert den alten Zustand des Signal-Objekts, entweder
auf einen Benutzer spezifizierten Wert oder auf einen Vorgabe-Wert.
Die init ()-Funktion initialisiert auch die verschiedenen Kennzeichen
im Signal-Objekt, und die letzten Delta- und Ereignis-Zeiten.
-
change_state
(): Setzt den alten Statuswert des Signal-Objektes auf den neuen
Statuswert.
-
send_event
(): Disponiert eine Änderung
in den Zustand des Signal-Objektes, indem eine Aufzeichnung an der
Delta-Warteschlange oder der Ereignis-Warteschlange platziert wird
(je nach dem, ob das Signal-Objekt auf Delta-Basis oder Ereignis-Basis
steht).
-
fire_event
(): Ruft die Eintritts ()-Funktion des abhängigen Prozesses auf, der mit
proc_ptr spezifiziert ist.
-
Resolved
signals (d. h. Signale mit mehr als einer Antriebs-Quelle) werden
durch Signal-Objekte ähnlich
denen für
nicht aufgelöste
Signale repräsentiert.
Die fire_event ()-Funktion jedoch ist im Falle eines aufgelösten Signals
komplizierter, da es erforderlich ist, Anrufe nach rückwärts wie
auch nach vorwärts
durchzuführen,
um sicher zu stellen, dass alle Prozess-Objekte, die auf Änderungen
des aufgelösten
Signals ansprechen, angerufen werden.
-
Ereignis-Warteschlange
-
Die
Ereignis-Warteschlange 13 weist eine verkettete Liste von
Aufzeichnungen auf, deren jede eine disponierte Änderung des Zustands eines
bestimmten Signal-Objektes repräsentiert.
Jede Ereignis-Aufzeichnung enthält
die folgenden Felder:
-
Reference:
Eine Hinweis-Adresse auf ein Signal-Objekt.
-
Event_Zeit:
Die Ereignis-Zeit, bei der das betreffende Signal-Objekt auf eine Änderung
eines Zustandes disponiert ist. Die Aufzeichnungen in der Ereignis-Warteschlange
werden in der Reihenfolge zunehmenden Ereignis_Zeitwertes aufrecht
erhalten.
-
Next:
Eine Hinweis-Adresse zur nächsten
Aufzeichnung in der Ereignis-Warteschlange.
Wenn dies die letzte Aufzeichnung in der Warteschlange ist, ist
die Hinweis-Adresse Null.
-
Der
Ereignis-Warteschlange sind zwei Funktionen zugeordnet:
-
push_event
(reference, event_time): Addiert eine neue Ereignis-Aufzeichnung
an einer entsprechenden Position in die Ereignis-Warteschlange entsprechend
dem Wert der Ereignis-Zeit. Die Parameter (Referenz, Ereignis-Zeit)
bestimmen die Referenz- und Ereignis-Zeitfelder der neuen Ereignis-Aufzeichnung.
-
pop_events
(): Verarbeitet Aufzeichnungen auf der Ereignis-Warteschlange.
-
Delta-Warteschlange
-
Die
Delta-Warteschlange weist eine verkettete Liste von Aufzeichnungen
auf, deren jede eine disponierte Änderung des Status eines bestimmten
Signal-Objektes repräsentiert.
Die Änderungen,
die an der Delta-Warteschlange disponiert sind, werden so angesehen,
dass sie sofort auftreten, d. h., dass sie keine ihnen zugeordneten
expliziten Zeitverzögerungen
haben.
-
Jede
Aufzeichnung in der Delta-Warteschlange enthält die folgenden Felder:
-
Reference:
Eine Hinweis-Adresse auf ein Signal-Objekt.
-
Next:
Eine Hinweis-Adresse auf die nächste
Aufzeichnung in der Delta-Warteschlange. Wenn dies die letzte Aufzeichnung
in der Warteschlange ist, ist die Hinweis-Adresse gleich Null.
-
Der
Detal-Warteschlange sind zwei Funktionen zugeordnet:
-
push_delta
(reference): Addiert eine neue Delta-Aufzeichnung zu der Delta-Warteschlange. Der
Parameter bestimmt das Referenz-Feld der neuen Delta-Aufzeichnung. Die
neue Aufzeichnung wird stets dem Ende der Delta-Warteschlange hinzuaddiert.
-
pop_deltas
(): Bearbeitet Aufzeichnungen an der Delta-Warteschlange.
-
Hierzu
wird bemerkt, dass die Ereignis- und Delta-Warteschlangen nicht
die aktuellen Werte der Änderungen
des Zustands enthalten; stattdessen halten sie einfach Referenzen
auf das Signal-Objekt, dessen Zustand auf die Änderung disponiert ist. Es
ist die Ansprechbarkeit der Signal-Objekte, um ihre eigenen Zustandsänderungen
in der effektivsten Weise zu handhaben.
-
Top-Level-Modell
-
Nachstehend
wird das Top-Level-Modell 12 in Verbindung mit 3 beschrieben.
-
(Schritt 301)
Das Top-Level-Modell lädt
zuerst das Simulations-Modell und ruft die init ()-Funktion eines jeden
Prozesses in dem Modell auf, so dass die gewünschten Datenstrukturen für jeden
Prozess vorbereitet werden.
-
(Schritt 302)
Das Top-Level-Modell wählt
dann die optimale Form der Ereignis- und Delta-Warteschlangen für das Modell
und konfiguriert jede Warteschlange in diese optimale Form.
-
Die
Auswahl der Form der Ereignis-Warteschlange basiert auf einer Information,
die während
der Initialisierung erzielt worden ist. Diese Information enthält die Anzahl
von auf Event basierenden Signalen in dem Modell, und die geringste
Zeitverzögerungs-Einheit,
die im Modell verwendet wird, sowie den Bereich von Zeitverzögerungen.
Die folgenden Optionen stehen für
die Form der Ereignis-Warteschlange
zur Verfügung:
- – Kein-Ereignis-Warteschlange:
Dies wird gewählt,
wenn das Modell keine auf Ereignis basierenden Signal-Objekte enthält. In diesem
Fall ist deshalb kein Ereignis-Warteschlangen-Aufwand vorhanden.
- – Einzel-Ereignis-Warteschlange:
Dies wird gewählt,
wenn das Modell nur auf Ereignis basierendes Signal-Objekt enthält und dieses
Signal-Objekt nur eine Status-Änderung
gleichzeitig hält.
Dies ist die schnellste Form der Warteschlange, da kein Einsetzungsvorgang
erforderlich ist.
- – Mehrfach-Ereignis-Warteschlange:
Diese Option wird gewählt,
wenn das Modell mehr als ein auf Ereignis basierendes Signal-Objekt
enthält,
oder ein einzelnes, auf Ereignis basierendes Signal-Effekt enthält, das mehr
als eine Zustandsänderung
enthalten kann und wenn der Bereich der Zeitverzögerungen verhältnismäßig klein
ist.
- – Mehrfach-Ereignis,
Viel-Zeit-Basis-Bereich-Warteschlange: Dies stellt die langsamste
Form der Warteschlange dar, sie ist jedoch in der Lage, einen verhältnismäßig großen Bereich
von Zeitverzögerungen
zu handhaben.
-
(Schritt 303)
Ein Anfangs-Satz von Delta-Aufzeichnungen wird an der Delta-Warteschlange eingesesetzt.
-
(Schritt 304)
Diese Anfangs-Delta-Aufzeichnungen werden dann schnell an die Delta-Warteschlange abgegeben,
damit eine Anfangs-Einstellung der Signal-Werte erreicht wird. Dazu
wird eine pop_initialisation_deltas ()-Funktion verwendet.
-
(Schritt 305)
Jedes Prozess-Objekt wird initialisiert, indem die Eintritts ()-Funktion
aufgerufen wird. Dies kann zu weiteren Deltas führen, die erzeugt werden und
die bei der nächsten
Delta-Zeit in die Delta-Warteschlange eingesetzt werden.
-
(Schritt 306)
Die laufende Ereignis-Zeit und die laufende Delta-Zeit werden beide
auf Null zurückgesetzt.
-
(Schritte 307–309)
Das Top-Level-Modell tritt dann in eine Haupt-Warteschlange ein,
in der die pop_events ()-Funktion und die pop_deltas ()-Funktion
aufgerufen werden. Diese Warteschlange wird fortgesetzt, bis entweder
die Ereignis-Warteschlange
leer ist oder bis die Simulations-Zeit eine spezifizierte Simulations-Endzeit erreicht
hat.
-
Pop_Deltas ()
-
Die
pop_deltas ()-Funktion wird nachstehend in Verbindung mit 4 beschrieben.
-
(Schritt 401)
Wenn die Delta-Warteschlange leer ist, wird die Funktion zurückgeführt. Andernfalls
geht sie auf Schritt 402 über.
-
(Schritt 402)
Ein Warteschlangen-Aufzeichnungs-Hinweiszeichen wird auf die erste
Aufzeichnung in der Delta-Warteschlange gesetzt.
-
(Schritte 403–405)
Es wird eine Schleife durchlaufen, in der jede Aufzeichnung in der
Delta-Warteschlange nacheinander ausgewählt wird. Für jede dieser Aufzeichnungen
wird die Change_State () Funktion des Signal-Objektes, auf die durch
diese Aufzeichnung verwiesen wird, aufgerufen. Die Change_State
() Funktion aktualisiert den Status des Bezugs-Signal-Objektes durch
Einstellung des Old_State-Wertes
gleich dem New_State-Wert. Diese Schleife wird wiederholt, bis das
Aufzeichnungs-Hinweiszeichen Null wird, wodurch angezeigt wird,
dass die letzte Aufzeichnung in der Delta-Warteschlange erreicht
worden ist.
-
(Schritt 406)
Das Aufzeichnungs-Hinweiszeichen der Warteschlange wird auf die
erste Aufzeichnung in der Delta-Warteschlange rückgesetzt.
-
(Schritte 407–409)
Es wird eine Schleife ausgeführt,
in der jede Aufzeichnung in der Delta-Warteschlange der Reihe nach
ausgewählt
wird. Die ausgewählte
Aufzeichnung wird aus der Delta-Warteschlange entfernt und die Fire-Event
(Funktion des Signal-Objektes,
auf die durch diese Aufzeichnung Bezug genommen wird), wird aufgerufen.
Diese Schleife wird wiederholt, bis alle laufenden Aufzeichnungen
in der Delta-Warteschlange
entfernt worden sind.
-
Die
fire_event () Funktion kann dazu führen, dass weitere Delta-Aufzeichnungen
vorgenommen und dem Ende der Delta-Warteschlange hinzuaddiert werden.
Diese neuen Delta-Aufzeichnungen werden während dieses Durchlaufes der
pop_deltas ()-Funktion
nicht verarbeitet; sie werden bei der nächsten Delta-Zeit verarbeitet
(z. B. während
des nächsten
Durchlaufes der pop_deltas ()-Funktion).
-
Die
pop_initialisation_deltas ()-Funktion ist ähnlich der pop_deltas-Funktion
mit der Ausnahme, dass die Schritte 406–409 weg gelassen
werden. Somit wird in diesem Fall die fire_event-Funktion () nicht
aufgerufen, und damit erfolgt kein Fortschreiten von Signalen.
-
Pop_events ()
-
Die
pop_events ()-Funktion wird nachstehend in Verbindung mit 5 beschrieben.
-
(Schritt 501)
Wenn die Ereignis-Warteschlange leer ist, kehrt die Funktion zurück. Andernfalls
geht sie auf Schritt 502 über.
-
(Schritt 502)
Eine Prüfung
wird durchgeführt,
um zu bestimmen, ob der Ereignis-Zeit-Wert der ersten Aufzeichnung auf der
Ereignis-Warteschlange nach der (d. h. größer als die) spezifizierten
Simulations-Endzeit ist. Ist dies der Fall, kehrt die Funktion zurück.
-
(Schritt 503)
Eine Warteschlangen-Aufzeichnungs-Hinweisadresse wird auf eine Stelle
auf der ersten Aufzeichnung in der Ereignis-Warteschlange eingestellt
und die laufende Ereignis-Zeit wird gleich dem Ereignis-Zeitwert
dieser Aufzeichnung eingestellt.
-
(Schritte 504–506)
Es wird eine Schleife durchlaufen, in der jede Aufzeichnung auf
der Ereignis-Warteschlange nacheinander ausgewählt wird. Für jede dieser Aufzeichnungen
wird die change-state ()-Funktion des Signal-Objektes, die auf die
Aufzeichnung bezogen ist, aufgerufen. Die change-state ()-Funktion
aktualisiert den Status des bezogenen Signal-Objektes dadurch, dass
der alte Zustandswert gleich dem neuen Zustandswert eingestellt
wird. Diese Warteschlange wird wiederholt, bis der Ereignis-Zeitwert
der ausgewählten Aufzeichnung
größer ist
als die laufende Ereignis-Zeit.
-
(Schritt 507)
Das Warteschlangen-Aufzeichnungs-Hinweiszeichen wird dann in die
erste Aufzeichnung in der Ereignis-Warteschlange rückgesetzt.
-
(Schritte 508–510)
Es wird eine Schleife ausgeführt,
bei der jede Aufzeichnung in der Ereignis-Warteschlange nacheinander
ausgewählt
wird. Die ausgewählte
Aufzeichnung wird aus der Ereignis-Warteschlange entfernt und die
fire_event ()-Funktion
des Signal-Objektes, die auf diese Aufzeichnung bezogen ist, aufgerufen.
Diese Schleife wird wiederholt durchlaufen, bis der event time – Wert der
ausgewählten
Aufzeichnung größer ist
als die laufende Ereignis-Zeit.
-
Eintritts ()-Funktion
-
Jedes
Prozess-Objekt hat seine eigene Eintritts-Funktion, die für dieses
Prozess-Objekt spezifisch ist. 6 zeigt
die Eintritts-Funktion eines typischen Prozess-Objekts.
-
(Schritt 601)
Die Funktion liest die Werte des alten Zustandes von beliebigen
Eingangs-Signal-Objekten, führt
Nutzer-definierte Verarbeitungsvorgänge durch und aktualisiert
den Wert des neuen Zustandes von beliebigen Abgabe-Signal-Objekten.
Beispielsweise liest in 2 das Prozess-Objekt P2 den
Wert des alten Zustands von S1 und aktualisiert den Wert des neuen
Zustands von S2. Das Aktualisieren des Wertes des neuen Zustandes
setzt das geänderte
Kennzeichen des Signal-Objektes auf Echt.
-
Es
ist zu erwähnen,
dass der alte Zustand des Ausgangs-Signal-Objektes in dieser Stufe
nicht aktualisiert wird. Damit benutzen die anderen Prozess-Objekte,
die bei der gleichen Delta-Zeit (oder Ereignis-Zeit) gezündet werden,
den gleichen Wert des alten Zustandes. Die Werte des alten Zustandes
werden solange nicht aktualisiert, bis der nächste Durchlauf der pop_deltas
()- oder pop_events ()-Funktion in der vorbeschriebenen Weise erfolgt.
-
(Schritt 602)
Nach Beendigung aller Nutzer-definierten Verarbeitungsvorgänge ruft
die Eintritts-Funktion die Sende-Ereignis-Funktion eines jeden Signal-Objektes
auf, dessen Zustand er möglicherweise
während
des Verarbeitens aktualisiert hat.
-
Sende_Ereignis ()
-
7 zeigt
die Sende-Ereignis ()-Funktion eines typischen Signal-Objekts. Es
wird in der nachfolgenden Beschreibung angenommen, dass das Signal-Objekt
Ereignis-basiert ist.
-
(Schritt 701)
Die Funktion prüft
zunächst,
ob das geänderte
Kennzeichen des Signal-Objekts
echt ist. Ist dies der Fall, geht die Funktion auf Schritt 702 über, andernfalls
kehrt sie zurück.
-
(Schritt 702)
Der Schritt des geänderten
Kennzeichens für
das Signal-Objekt wird auf Falsch rückgesetzt.
-
(Schritt 703)
Die Funktion prüft
dann, ob der Wert des neuen Zustands des Signal-Objekts gleich dem Wert des alten Zustands
ist. Ist dies der Fall, kehrt die Funktion zurück.
-
(Schritt 704)
Die Funktion prüft
dann, ob eine Änderung
auf das Signal-Objekt bereits auf der Ereignis-Warteschlange für die exakt
gleiche Zeit wie die Änderung,
die gerade verarbeitet wird, disponiert wird. Dieser Schritt schließt das Prüfen mit
ein, ob die Ereignis-Zeit (d. h. die Ereignis-Zeit, bei der das
Signal disponiert worden ist, eine Änderung vorzunehmen) größer ist
als der Wert der letzten Ereignis-Zeit für dieses Signal-Objekt. Ist
dies nicht der Fall, ist eine Änderung
bereits disponiert worden und es wird keine weitere Aktion durch diese
Funktion vorgenommen.
-
(Schritt 705)
Geht man davon aus, dass alle vorstehend genannten Prüfungen einwandfrei
verlaufen, wird der Wert der letzten Ereignis-Zeit für das Signal-Objekt
gleich der Ereignis-Zeit gesetzt. Die Änderung wird dann disponiert,
indem push_event (this event_time) aufgerufen wird, wobei „this" ein Hinweiszeichen
für dieses
Signal-Objekt darstellt.
Dies fügt
eine neue Aufzeichnung der entsprechenden Position in der Ereignis-Warteschlange
hinzu.
-
Es
zeigt sich, dass die vorbeschriebenen Tests sicher stellen, dass
ein Signal nur in die Warteschlange eingeführt wird, wenn ihre Werte sich
geändert
haben und wenn eine Änderung
für dieses
Signal nicht bereits in die Warteschlange eingeführt worden ist. Dies reduziert
die Anzahl von Warteschlangen-Vorgängen und hilft damit, die Laufgeschwindigkeit
des Modells zu erhöhen.
-
Wie
angegeben, geht die vorstehende Beschreibung nach 7 davon
aus, dass das Signal-Objekt Ereignis-bezogen ist. Wenn es Delta-bezogen
ist, werden die Schritte 704 und 705 durch den
Schritt 704a wie folgt ersetzt.
-
(Schritt 704a)
Die Änderung
wird disponiert, indem push_delta (this) aufgerufen wird, wobei „this" ein Hinweiszeichen
auf dieses Signal-Objekt repräsentiert.
Dies fügt
eine neue Aufzeichnung dem Ende der Delta-Warteschlange hinzu.
-
Fire_event ()
-
8 zeigt
die fire_event ()-Funktion eines typischen Signal-Objekts.
-
(Schritt 801)
Die Funktion prüft
zuerst, ob das proc_ptr für
das Signal-Objekt Null ist. Ist proc_ptr Null, bedeutet dies, dass
das Signal-Objekt keine abhängigen
Prozess-Objekte
aufweist, so dass keine weitere Aktion durch diese Funktion veranlasst
wird.
-
(Schritt 802)
Unterstellt man, dass proc_ptr von Null verschieden ist, wird die
Eintritts-Funktion des abhängigen
Prozesses, auf die durch proc_ptr verwiesen wird, aufgerufen.
-
Betriebsweise
-
Die
Betriebsweise des Simulators wird in Verbindung mit 9 beschrieben;
diese 9 zeigt Prozess-Objekte P1, P2, Signal-Objekt
S1 und die Ereignis-Warteschlange. Es wird davon ausgegangen, dass
S1 Ereignis-bezogen ist.
-
Wenn
die Eintritts-Funktion von P1 läuft,
aktualisiert sie den Wert des neuen Zustandes des Ausgangssignals
S1. Sie ruft dann die send_event ()-Funktion von S1 auf, nachdem
sie eine andere Nutzer-definierte Verarbeitung vorgenommen hat.
-
Die
send_event ()-Funktion ruft die push_event ()-Funktion der Ereignis-Warteschlange
auf, die bewirkt, dass eine Ereignis-Aufzeichnung der Ereignis-Warteschlange
für eine
spezifizierte Ereignis-Zeit hinzugefügt wird.
-
Wenn
die spezifizierte Ereignis-Zeit erreicht ist, entfernt die pop_events
()-Funktion diese Aufzeichnung aus der Ereignis-Warteschlange und
ruft die change-Status-Funktion von S1 auf. Dies bewirkt, dass der alte
Zustand von S1 gleich dem neuen Zustand gesetzt wird. Pop_events
ruft dann die fire_event ()-Funktion von S1 auf. Diese ruft die
Eintritts-Funktion des abhängigen
Prozess-Objektes P2 auf.
-
Zusammenfassend
ergibt sich, dass erreicht wird, dass ein Signal von P1 nach P2
mit einer spezifizierten Verzögerung
kommuniziert wird.
-
Erörterung
-
Ein
entscheidendes Merkmal der vorbeschriebenen Simulations-Technik
besteht in der Verwendung von getrennten Ereignis- und Delta-Warteschlangen.
Die beiden unterschiedlichen Formen der Zeit, Delta-Zeit und Ereignis-Zeit,
haben unterschiedliche Formen der Warteschlangen-Aktion wie auch
unterschiedliche Optimierungen, so dass die Verwendung von getrennten
Ereignis- und Delta-Warteschlangen
es wesentlich leichter macht, die Warteschlangen-Aktionen zu optimieren.
Beispielsweise kann die Form der Ereignis-Warteschlange in der oben
beschriebenen Weise optimiert werden.
-
Ein
anderes wichtiges Merkmal der Simulations-Technik besteht darin,
dass jeder veränderbare
Teil des Simulations-Modells als ein getrenntes Objekt implementiert
wird, und jedes Objekt auf die Handhabung der eigenen Zustandsänderungen
ansprechen kann. Daraus ergibt sich, dass der Status eines jeden
Teils in einem optimalen Format gehalten werden kann, anstatt dass
er mit einem Standard-Format benutzt wird, wie dies bei herkömmlichen
Simulatoren auf Kernel-Basis erforderlich ist. Darüber hinaus
können
die Routinen, die zur Änderung
des Status eines Modellteils benötigt
werden, speziell für
diesen Teil ausgelegt werden, anstatt dass sie auf einer verallgemeinerten
Routine in einem Kernel abgestellt sind. Dies ermöglicht,
dass eine große Anzahl
von diskreten Optimierungen den individuellen Modellteilen aufgegeben
werden können,
so dass die Geschwindigkeit der Simulation erhöht wird.
-
Da
jedes Teil der Modell-Steuerungen seinen eigenen Status hat, brauchen
die Warteschlangen nicht die tatsächlichen Werte der Änderungen
des Status festzuhalten; stattdessen können sie einfach Referenzen zu
den Modellteilen halten, deren Zustände so disponiert sind, dass
sie sich ändern.
Dies vereinfacht die Warteschlangen-Aktionen erheblich, da Werte
nicht in einen und aus einem Speicher kopiert werden brauchen, und
es können
komplexe Datenstrukturen durch ihre eigenen Teile anstatt durch
verallgemeinerte Warteschlangen-Routinen behandelt werden. Dies
führt zu
weiteren Verbesserungen in der Effizienz.
-
Einige mögliche Modifikationen
-
An
dem vorbeschriebenen System können
zahlreiche Modifikationen vorgenommen werden, ohne dass vom Wesen
der Erfindung abgewichen wird. Beispielsweise können die Warteschlangen auf
Zeitsteuer-Regelkreisen basieren, wie in der US-Patentschrift 5157
620 beschrieben, statt dass sie als verkettete Listen konstruiert
sind.