-> alexander: Mir persoenlich fehlen die Zustandsmaschinen. Ich wuerde vorschlagen hier
-> entweder Grafen oder Tabellen zu nehmen.
-
-> bernhard: Statemaschinen sind doch eh in der Detailed Design Description? ich find das passt...
-> naehere Stackbeschreibung fehlt halt imho.
-
-> alexander: am liebsten haette ich (das gilt auch fuer unsere spezifikation) moore-state-machines.
-> das heisst jeder Zustand hat Kanten, die input und output definieren. wenn man in "wenig" signalen
-> die wichtig sind, zeigen kann das so eine zustandsmaschine glaubhaft funktionieren kann hat man
-> viel gewonnen. ich haette mir von mir schon solche state machines erwartet in meiner
-> spezifikation.
-
-> Beispiel fuer rs232 eine kante hat signale: req char(n) / ack counter_overflow tx
-> states wareen dann: startbit ,char(0), char(1), char(2) ... (char n-1) stopbit1, stopbit2, done
-> belieber state -> startbit: 0 XX ... XX / 0 0 X // das ist bloed zum modellieren
-> startbit -> char (0): 0 XX ... XX / 0 1 0
-> char (k) -> char (k+1): 0 XX ... XX / 0 1 char(n)
-> char (n-1) -> stopbit 1: 0 XX ... XX / 0 1 1
-> stopbit1 -> stopbit2: 0 XX ... XX / 0 1 1
-> stopbit2 -> done: 1 XX ... XX / 1 1 1
-
-> und im selben state wird geblieben bei X XX ... XX / X 0 X
-
-Die Interfaces sind grundsaetzlich vorhanden und tabellarisch fest gehalten, jedoch wird nicht
-spezifiziert wie diese Werte zu verwenden sind. Zum Beispiel der Stack hat ein Signal "enable", aber
-ist das nun High- oder Low-Aktiv?
-
-Ist das Poppen des Stacks destruktiv? Wenn ja wie wird die Ausgabe dann produziert? Beim ASCII-Stack
-bin ich mir nicht sicher ob das so gemeint ist und ob das auch gut ist. Beim Operanden-Stack ist
-dieses Verhalten jedoch gewuenscht.
-
-Die Grafik koennte man entweder weglassen oder ueberarbeiten (kann auch eine gute Handzeichnung
-sein, solange klar ist was passiert).
+[list]
+[*]
+Statemaschinen sind zwar vorhanden, aber es fehlt an Details die man mit
+Moore-State-Maschinen gut darstellen kann. D.h. jeder Zustand hat Kanten, die
+Input und Output definieren. Wenn man in "wenign" Signalen, die wichtig sind,
+zeigen kann, dass so eine Statemaschine glaubhaft funktionieren kann, hat man
+viel gewonnen:
+
+Beispiel fuer RS232:
+[list]
+[*]eine Kante hat Signale:
+[list]
+[*]input: req, char(N)[/*]
+[*]output: ack, counter_overflow, tx[/*]
+[/list]
+[/*]
+[*]die States waeren dann: startbit ,char(0), char(1), char(2), ... ,char(n-1),
+stopbit1, stopbit2, done[/*]
+[*]die Uebergaenge
+[list]
+[*]belieber state -> startbit: 0 XX ... XX / 0 0 X[/*]
+[*]startbit -> char (0): 0 XX ... XX / 0 1 0[/*]
+[*]char (k) -> char (k+1): 0 XX ... XX / 0 1 char(k)[/*]
+[*]char (n-1) -> stopbit 1: 0 XX ... XX / 0 1 1[/*]
+[*]stopbit1 -> stopbit2: 0 XX ... XX / 0 1 1[/*]
+[*]stopbit2 -> done: 1 XX ... XX / 1 1 1[/*]
+[/list]
+[/*]
+[/list]
+[/*]
+[*]
+Die Interfaces sind grundsaetzlich vorhanden und tabellarisch fest gehalten,
+jedoch wird nicht spezifiziert wie diese Werte zu verwenden sind. Zum Beispiel
+der Stack hat ein Signal "enable", aber ist das nun High- oder Low-Aktiv?
+[/*]
+[*]
+Ist das Poppen des Stacks destruktiv? Wenn ja wie wird die Ausgabe dann
+produziert? Beim ASCII-Stack bin ich mir nicht sicher ob das so gemeint ist und
+ob das auch gut ist. Beim Operanden-Stack ist dieses Verhalten jedoch
+gewuenscht.
+[/*]
+[*]
+Wichtig ist ausserdem nicht nur wer aller Zugriff auf den Stack hat sondern
+auch ob ein Zugriff auf den Stack gleichzeitig geschehen darf. Der Zugriff
+selbst auf den Stack wird auch nur sehr oberflaechig beschrieben und geht nicht
+wirklick hervor wie der tatsaechlich funktioniert.
+[/*]
+[*]
+Die Grafik koennte man entweder weglassen oder ueberarbeiten (kann auch eine
+gute Handzeichnung sein, solange klar ist was passiert).
+[/*]
+[*]
+Testfaelle fehlen komplett.
+[/*]
+[/list]