Simulation mit Automatenaufzählung

Als erstes ist die Kombination der Ergebnisse aus Kapitel 3 und 4 notwendig – getrennt oder zusammen sowohl für Hardware als auch für Software. Aber bereits vor dem ersten Einsatz gibt es verschiedene Möglichkeiten, mit den Berechnungsmöglichkeiten umzu-gehen.

5.1.1 Einschränkung

Prinzipiell kann jede Kreatur einen anderen Algorithmus annehmen. Jedoch ergeben sich dann bei zahlreichen Kreaturen auf einem Feld zu viele Möglichkeiten, die nicht in einer überschaubaren Zeit ausreichend simulierbar sind. Zum Beispiel benötigt die Aufzäh-lung mittels Hardware bei drei Zuständen bereits 9 931 Takte. Wenn alle Konstellationen zum Tragen kommen, benötigt allein die Aufzählung aller relevanten Automaten für die Simulation bei nur vier Kreaturen bereits 9 931⁴=9 726 843 482 307 121 Takte. Mit der angenommenen Taktfrequenz von 85,16 MHz entspricht dies einer Zeit von etwa 3,6 Jah-ren. Hinzu kommt noch die eigentliche Simulationsdurchführung als konstanter Faktor.

Seien es durchschnittlich eintausend Generationen, so ergibt sich bereits mit diesen ge-ringen Werten eine Laufzeit von 3 600 Jahren. Dieses Verfahren ist demnach auf diese Weise nicht praktikabel.

Daraus ergibt sich, dass mehrere Kreaturen die gleichen Algorithmen verwenden soll-ten, um die Anzahl der Möglichkeiten zu reduzieren. Für drei unterschiedliche Kreaturen beträgt die Aufzählungszeit nur noch fast 3,2 Stunden, für zwei unterschiedliche Krea-turen sind es sogar nur 1,2 Sekunden allein für die Aufzählung aller Algorithmen. Für Automaten mit mehr Zuständen ist eine Simulation bei zwei unterschiedlichen Kreatu-ren zeitlich interessant.

Eine Variante ist, der Hälfte der Kreaturen den gleichen Algorithmus zuzuweisen.

Um die Durchführung auf zwei verschiedene Algorithmen zu reduzieren, wenn die Krea-turen zu Beginn am Rand angeordnet sind, gibt es die drei symmetrischen Varianten, den

• auf einer Seite gegenüberliegende Kreaturen,

• den über Eck liegende Kreaturen, z. B. obere und linke Seite, sowie

• jeder zweiten Kreatur einer Seite

den gleichen Automaten zuzuweisen und somit die Kreaturen gleichzusetzen. Abbildung 5.1 präsentiert das Resultat für ein einfaches Feld ohne weitere Hindernisse. Die Simula-tion mit nur einer Art von Automat bleibt davon unberührt relevant.

s s s s

> <

> <

> <

> <

n n n n

s s s s e <

e <

e <

e <

^ ^ ^ ^

s v s v

> w e <

> w e <

^ n ^ n Abbildung 5.1: Anordnung für Kreaturen am Rand mit insgesamt zwei unterschiedlichen Automaten (gegenüberliegend, aneinander liegend, alternierend)

5.1.2 Hardwareentwurf

Es hat sich gezeigt, dass sowohl die Aufzählung von Automaten als auch die Simulati-onsdurchführung mit einer speziellen Hardwarearchitektur schneller vorangeht als soft-wareprogrammiert mit einem üblichen Rechner. Nun ist eine Kombination der Automa-tenaufzählung mit der Simulation dynamischer Objekte erforderlich. Dabei erfordern un-terschiedliche Automaten für dynamische Objekte eine mehrfache Aufzählung; bei zwei Typen ergeben sich zwei Automatenzähler. Kommen mehrere Automaten zum Einsatz, ist es irrelevant, ob sich die Automaten in ihrer Konfiguration, z. B. in der Zustandsan-zahl, entsprechen.

Für die Kombination ist eine Architektur mit vom Feld getrennten Kreaturen vorteil-haft, da hier ein direkter Zugriff auf die Automatentabelle der Kreatur möglich ist. Basie-ren alle KreatuBasie-ren auf dem gleichen Automaten, erhalten alle ihre Automatentabelle für Zustandsübergänge und Ausgabewerte aus gleicher Quelle. Der dahinter liegende Au-tomatenaufzähler generiert immer dann den nächsten Automaten, wenn die Simulation erfolgreich beendet oder vorzeitig abgebrochen ist. Hierbei entspricht die in Abbildung 3.22 dargestellte Druckausgabe der Weitergabe an die Kreaturen der Simulation.

...

Simulation

...

succeeded

Enumeration succeeded

enum.

...

psr psr

m

ov ena ov ena

maton auto-enum.

maton

auto-Abbildung 5.2: Anbindung der Automatenaufzählung an die Simulation

Gibt es nun unterschiedliche Kreaturen, sind auch unterschiedliche Automatenauf-zähler erforderlich, die koordiniert ihre Aufzählung durchführen. Ein Automat symboli-siert eine Zählerstelle. Gibt es einen Überlauf, beginnt der Zähler also wieder von Vorne,

5.1 Simulation mit Automatenaufzählung so ist dieser Überlauf das Signal für den nächsten Zähler. Die Abbildung 5.2 stellt dies für zwei herausgegriffene Zähler dar. Dabei ist ein Überlauf mit „ov“ für overflow, das In-krementierungssignal mit „ena“ für enable bezeichnet. Der erste Zähler erhält sein Signal bei Abschluss einer Simulation. Das Verfahren ist beendet, wenn auch der höchststelligs-te Zähler einen Überlauf erzeugt.

Eine Simulation kann immer dann starten, wenn ein gültiger Automat an allen Zäh-lerständen vorhanden ist.

5.1.3 Softwareentsprechung

Ähnlich wie für den Hardwareentwurf lassen sich die Zähler implementieren. In einer objektorientierten Programmierumgebung sind auch mehrere verkettete Automaten kein Problem; ein Überlauf, z. B. über einen Funktionsrückgabewert mitgeteilt, hat das Inkre-mentieren des nächsten Automaten zur Folge. Eine Kreatur kann einen Automaten über ein Array auswählen.

5.1.4 Kombinierte Berechnung mit Hard- und Software

Eine andere Art der Kopplung von Aufzählung und Simulation bietet die Aufteilung zwi-schen Hardware und Software, so dass eine Komponente die Aufzählung durchführt, die andere die Simulation. Die Tabelle 3.7 zeigt einen deutlichen Vorteil für die Hardware, weswegen die Aufzählung dort geschehen sollte. Der Vorsprung der Hardware bezüglich der Simulation ist nicht ganz so herausragend, weshalb sich diese für die Umsetzung in Software eignet, insbesondere für große Felder mit viel Speicheraufwand. Nichtsdesto-minder ist die Anlieferung der Daten auch umgekehrt möglich.

Verbleibt die Frage, wie die Daten zwischen den Systemen ausgetauscht werden kön-nen. Die einfachste Variante ist, die existierende serielle Schnittstelle zu nutzen. Aller-dings ist diese mit 115 200 Baud bzw. 11 520 Byte/s nicht besonders schnell. Eine Netz-werkanbindung mit theoretisch bis zu 1 000 MByte/s bietet da weitaus mehr Transfer-volumen. Aber auch eine PCI-Schnittstelle zu einem Rechner bietet einen Geschwindig-keitsvorteil, wie die Untersuchung in [Pas07] gezeigt hat; Transferraten von 120 MByte/s sind möglich.

Aber auch ohne das Schema der aufgeteilten Berechnung ist die Übertragung der Da-ten von der Hardware hin zu einem Rechner notwendig, um so die Ergebnisse dauerhaft protokollieren zu können. Die genauen Details der Aufteilung sind projektabhängig und basieren im wesentlichen auf der zur Verfügung stehenden Hardwareplattform und den zu berechnenden Eigenschaften, insbesondere der Simulationsumgebung.

5.1.5 Vorfilter durch andere Experimente

Statt einer vollständigen Trennung zwischen Hardware und Software bezüglich Aufzäh-lung und Simulation vorzunehmen, könnte die Hardware auch AufzähAufzäh-lung und Voraus-wahl durch Simulation durchführen, die dann weniger gewordenen Automaten an einen Rechner übertragen, so dass dann die Software weitere Simulationen durchführen kann.

Dieser Filter ist recht effektiv und reduziert die Anzahl der auf dem Rechner zu simulie-renden Automaten deutlich, wie auch das Beispiel in Abbildung B.12 zeigt.

Alternativ könnten die vorgefilterten Automaten auch auf einer anderen Spezialhard-ware zur Ausführung kommen, deren einzelne Bausteine nicht mit der Aufzählung und

Auswertung belegt sind. Die Simulation erhält die Liste der Automaten aus einem vor-initialisiertem ROM oder wieder per Datenübertragung von einem Rechner mit ausrei-chender Speicherkapazität. In jedem Fall ist ein universeller, softwaregesteuerter Rechner notwendig.