Anwendungsbeispiel Kreaturen
4.3 Realisierung des Simulationssystem
4.3.3 Konzepte
4.3.3.5 Bussystem
state
state
succeededSimulation
position position position position
direction direction
direction
direction s’
s’
s’
s’
0000 1111
0000 1111
Creature
Creature Creature
Creature
W Visited RAM
R Obstacle
ROM
Obstacle ROM
&
&
W Visited RAM
R
&
m y
= n
m y
= n
m y
= n m y
= n state
state
L L
L
c i⇔+1
˙p i 6∈{p1,p2,...,pi,pi+2,...,p|I|,
˙p 1 ,˙p 2 ,...,˙pi,
˙p i,...,˙p+2|I|}
c i
⇔
˙p i 6∈{p1,p2,...,pi−1,pi+1,...,p|I|,
˙p 1 ,˙p 2 ,...,˙pi−1,
˙p i,...,˙p+1|I|}
c i⇔+2
˙p i6∈{p,p,...,p,p,...,p,+212i+1i+3|I|
˙p 1 ,˙p 2 ,...,˙pi+1,
˙p i,...,˙p+3|I|}
c i⇔+3
˙p i6∈{p,p,...,p,p,...,p,+312i+2i+4|I|
˙p 1 ,˙p 2 ,...,˙pi+2,
˙p i,...,˙p+4|I|}
1
16
=max 12
12
12
12 12
12
12
1 16 16
counter watchdog
8 12
≥1
≥1
≥1
≥1
[i+2]
[i+3]
[i+1]
Collision Obstacle Detection
1
pi+1 pi
Success Observer 1
pi+1˙ pi+1˙
=0 ...
...
1 pi˙
pi+2˙ pi+3˙ Detection
fori=⌈
i 2⌉·2−1
≥1 [i]
select
select
wi+2
≥1
...
...
...... ... .........
pi+2
pi+3
˙hi+3
˙hi+2
˙hi+1
˙hi
ci+3 ci+2 ci+1
pi+3 pi+2
pi+2˙
pi+3˙ pi+1˙ pi+1 pi
pi˙
mi+3 mi+2 mi+1
˙hi mi ci
˙hi+1
ci+1
˙hi+2
ci+2
˙hi+3
ci+3
wi ci
⊕
⊕
⊕
⊕
V
V L
Abbildung 4.15: Zusammenhänge der speicherbasierten Architektur
Konfiguration analog zur Statistik und dem Inhalt der Hindernisauswertung. Insgesamt ergeben sich somit
X·Y 4 096
·
2· |I|
2
+1
Speicherblöcke, wenn sich jeweils zwei Kreaturen einen Speicher teilen.
Auch die Durchführung mehrerer Simulationen gleichzeitig stellt kein Problem dar, wenn ausreichend viele Kreaturen verfügbar sind und diese nur auf einem abgegrenzten Gebiet agieren können. Dadurch ist – insbesondere bei kleineren Feldgrößen – der Spei-cher besser ausgenutzt, da dieser eine Minimalgröße von 4 096 Bytes hat und sich so eine quadratische Feldgröße von 64·64 Zellen ergibt.
4.3 Realisierung des Simulationssystem der Ein- und Ausgabedaten des Speichers verzögert sich das Ergebnis auf dem Bus um zwei Takte relativ zur Anfrage. Die aktive Kreatur kann jedoch das Token direkt an die benachbarte Kreatur weitergeben. Dadurch entsteht eine Art Pipeline zwischen Speicher-anfragen und Auswertung.
Die Abbildung 4.16 stellt das Prinzip des Bussystems schematisch dar. Dort ist das inkrementelle Verfahren V⊕ verwendet, da eine 1 die erreichte Position markiert. Die Position p dient während der Berechnungsphase ausschließlich zum Setzen der Statistik-daten für V. Der Speicher für Venthält im Übrigen initial alle Hindernisse H, so dass der Speicher eigentlich V∪Henthält. Sind dann alle Positionen im Speicher markiert, dies entsprichtV∪H=P, so ist die Simulation abgeschlossen.
Die Erkennung einer Kollision erfolgt mit den Daten auf dem Bus. Dazu „belau-schen“ die anderen Kreaturen die gesendeten Daten, betreiben also das so genannte bus snooping. Stimmt Position oder Zielposition mit ihrer eigenen Zielposition überein, so stellt dies einen Konflikt dar. Da die Kreatur mit erkanntem Konflikt zu einem früheren oder späteren Zeitpunkt ebenfalls die Daten auf dem Bus legt, um zumindest die Posi-tion in den Speicher V einzutragen, erkennt auch die andere betroffene Kreatur einen Konflikt.
1 16
watchdog address counter
&
& &
display address counter initial address counter initial
0000 1111
... ...
...
...
token generator
...
=0
=max
≥1
success psr
psr
˙ p hp˙
h
V
1
p
Abbildung 4.16: Prinzip eines Busses für Kreaturen
Da jedoch für einen solchen Bus mit zahlreichen, potentiellen Sendern ein Tri-State-Bus mit einer hochohmigen Ausgabemöglichkeit erforderlich ist, das ganze aber inner-halb eines FPGAs ohne externe Anbindung erfolgen soll, steht diese Tri-State-Technik leider nicht zur Verfügung. Ersatzweise laufen die einzelnen Positionen pi aller Kreatu-ren zu einem Oder-Gatter, das die Anfragen zusammenfasst und an den Speicher leitet.
Nur die Kreatur mit den Token darf ihre eigentliche Position senden, alle anderen müssen in diesem Fall die logik-neutrale Position 0 dem Bus übergeben.
Um zusätzlich die Verarbeitung zu verbessern, steht ein Register zur Zwischenspei-cherung des Oder-Gatterwertes zur Verfügung. Dieses erhalten dann die zahlreichen Kreaturen. Von Vorteil ist die dadurch etwas bessere Taktrate und der gesteigerte Wert für den Fan Out, der die maximal anschließbaren Gatter bzw. Logikelemente bezeichnet.
Alternativ zur lesenden Anbindung von p und ˙p jeder Kreatur ist es ausreichend, nur die Zielposition ˙p auszuwerten. Eine Kreatur, die eine Kollision erkennt, teilt dies der anfragenden Kreatur über eine eigens dafür geschaffene Leitung c mit, sobald die
Übereinstimmung der eigenen Position oder Zielposition mit dem Wert ˙p auf dem Bus vorliegt, die sie nicht selbst gesendet hat. Zu beachten ist dabei, dass der Wert ˙p um einen Takt verzögert eintrifft und das gleichartig zu bearbeitende Kollisionssignal c um einen weiteren Takt verzögert bei der anfragenden Kreatur erscheint. Dies ist gleichzeitig mit dem Ergebnis aus dem Hindernisspeicher.
Trotz der geringeren Anzahl benötigter Verbindungsleitungen sind lediglich etwa 31/2% weniger Logikelemente notwendig, die maximal mögliche Taktrate sinkt dabei aber teilweise um 14 %. Im konkreten Fall haben 64 Kreaturen auf einem 4 096 Zellen umfassenden Feld 10 903 bzw. 10 431 Logikelemente benötigt, die maximale Taktrate betrug dabei 68,19 MHz bzw. 58,50 MHz.
Daher ist in der Tabelle 4.3 nur die Variante ohne gesonderte Kollisionserkennungs-leitung aufgeführt, obwohl bei 124 Kreaturen diese mit 20 652 benötigten Logikelemen-ten nicht mehr auf den verwendeLogikelemen-ten Baustein passt, die andere Variante mit 19 897 Lo-gikelementen hingegen schon. Bei 128 Kreaturen versagen beide Konzepte unter Beibe-haltung der ausgewählten Hardware. Aufgrund der symmetrischen Anordnung der Krea-turen in einem Quadrat, um eine einfache, allgemeine Generierung zu ermöglichen, gibt es keine Zwischenwerte.
Das Verfahren der Datenauswertung für V (watchdog) wie im vorigen Abschnitt 4.3.3.4 für Abbildung 4.14e bleibt erhalten, ein Zähler durchläuft alle Adressen des Spei-chers. Haben alle ausgelesenen Bits den Wert 1, so ist die Simulation erfolgreich beendet.
Auch hier gibt es wieder die Möglichkeit, die Generation exakt zu bestimmen oder nur zeitnah das Resultat zu erhalten. Aufgrund der Wahl eines anderen Speichermodells ohne JTAG-Schnittstelle stehen optimal nur 16 Bit zur Verfügung, bei 32 Bit steigt der Res-sourcenverbrauch unnötig.
Die gleiche Anbindung an den Speicher (port) kann nun anstatt in der Berechnungs-phase auch der Initialisierung dienen. Um mehrere Versuche nacheinander mit unter-schiedlichen Kreaturkonfigurationen durchzuführen, ist ein Rücksetzen des SpeichersV notwendig. Hierfür müssen alle Adressen beschrieben werden. Um möglichst viele Spei-cherzellen je Takt zu erreichen, bietet sich die gleiche Bitbreite wie für das Auslesen zur Datenauswertung an.
Da an den Hindernisspeicher h bisher nur ein Eingang beschaltet ist, bietet es sich bei einem Dual-Port-Speicher mit möglicher ungleicher Bitbreite für den anderen Port an, die Daten für denV-Speicher in gleicher Bitbreite von 16 Bit auszulesen. Da jedoch die Speicher gepuffert sind, ergibt sich eine Verzögerung für die Eingangsregister desV -Speichers, der die Daten aus dem Ausgaberegister des h-Speichers entgegen nimmt. Dies führt zu einer notwendigen Pufferung des initialen Adresszählers für den V-Speicher ähnlich dem Verfahren einer Pipeline.
Das Zurücksetzen der Daten für die Kreaturen erfolgt über ein einfaches Signal, der Startzustand ist auf Null festgelegt, die anderen Werte Position und Richtung sind über Parameter zur Synthesezeit konfigurierbar, Dadurch ist kein weiterer Speicher speziell für die Kreaturen notwendig, die Simulation lässt sich ausreichend ohne Schwierigkeiten durchführen.
Die Ausgabe greift ebenfalls auf alle möglichen Positionen der Speicher zu, aller-dings jede Position für sich, da gleichzeitig immer nur ein Zeichen darstellbar ist und ein Mehr an Bits unnötig mehr Organisationsaufwand zur Folge hat. Dies entspricht für den h-Speicher dem normalen Simulationsbetrieb. Um gleichzeitig die bereits besuchten Positionen von den noch nicht besuchten unterschiedlich darstellen zu können, erfolgt das Auslesen desV-Speichers über die sonst verwendete Schreibadresse, die ein Bit
In-4.3 Realisierung des Simulationssystem formation bereitstellt. Damit liegt auf p und ˙p während der Ausgabe die gleiche Adresse an.
Um nun auch Auskunft über Existenz, Drehrichtung und Zustandswert der Kreaturen zu erhalten, gibt es einen weiteren Bus zusätzlich zu den Positionen, auf denen diese Daten von den Kreaturen gelegt werden. Auch hierbei darf nur jeweils eine Kreatur Daten unterschiedlich Null von sich geben, um einen Tri-State-Betrieb zu emulieren. Stimmt die Position einer Kreatur mit der Zielposition auf dem Bus überein, so darf diese ihre Daten preis geben. ˆp wurde ausgewählt, da in jedem Fall die Hindernisse dargestellt werden, die Statistik ist aber nicht erforderlich. Um bei einer Ressourcensparmaßnahme diesbezüglich nichts umstellen zu müssen, bietet sich ˆp gegenüber p an.
Für eine Koordinierung zwischen Ausgabe und Berechnung ist noch ein Steuerwerk notwendig, das zusätzlich auch bei aufeinander folgenden Berechnungen ohne Pause dar-auf achten muss, dass jeweils nur ein Token zwischen den Kreaturen unterwegs ist und auch die Verzögerungszeiten der Speicher berücksichtigt.