1. Korrektheit: Enthält die Spezifikation inhaltiche Fehler, widersprüchliche Aussagen oder werden
falsche Annahmen getroffen? Vergeben Sie eine Note (1-5) und begründen Sie!
-Viele kleinere Unstimmigkeiten (vor allem bei der Schnittstellenbeschreibung), aber das hat wohl den
-Grund, dass es noch nicht die finale Abgabe ist (ein paar Einzelheiten werden weiter unten erwaehnt).
-
-> bernhard: Die Verwendung eines Stackes scheint das ganze Design etwas kompliziert zu machen, oder
-> find das nur ich?
-
-> alex: grundsaetzlich hast du recht und ich bin der meinung kman kann einen operanden- bzw.
-> operatorenstack durch operanden register (3) und operatorenregister (2) ersetzen. Aber wenn man
-> einen RPN-taschenrechner machen weurde braucht man einen stack und man haette damit beliebige
-> tiefe erreicht. jedoch braucht man noch immer einen operatorenstack dafuer.
-
-Note: X
+Viele kleinere Unstimmigkeiten (vor allem bei der Schnittstellenbeschreibung),
+aber das hat wohl den Grund, dass es noch nicht die finale Abgabe ist (ein paar
+Einzelheiten werden weiter unten erwaehnt).
+Note: 2
2. Vollständigkeit: Enthält das Spezifikations-Dokument alle wesentlichen Requirements/Module des
Designs? Vergeben Sie eine Note (1-5) und begründen Sie!
-> 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:
+
+TODO: hab ich dein beispiel richtig verstanden (und angepasst?)
+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]
-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.
-
-Note: 2
+Note: 3
3. Verständlichkeit: Ist das Dokument klar und verständlich geschrieben? Besitzt das Dokument eine
ordentliche Struktur? Vergeben Sie eine Note (1-5) und begründen Sie!
Grundssaetzlich ja, aber das Zusammenspiel einiger Komponenten ist teilweise unklar:
-* im Modul "MulDiv" gibt es die Signale "quotient", mehrere "operand_out_*", "divisor" und
- "dividend" (in dieser Reihenfolge). Das ist am ersten Blick sehr verwirrend, am zweiten Blick
- (naemlich auf die anderen Module) wird erst klar dass diese Signale unterschiedliche Wege nehmen.
- Ausserdem: Warum die Division und Multiplikation nochmal extra in ein Modul packen?
-
-* Die Verwendung des Stacks geht leider nur sehr schwamming hervor (wie oben schon angesprochen).
-
-* Wieviele Stacks sind nun tatsaechlich in Verwendung? ein ASCII-Stack, ein Operanden-Stack und ein
- Operator-Stack? Haben die das selbe Interface? Wie speichern die Daten, sind doch eigentlich ganz
- unterschiedliche Datenstrukturen zu speichern?
-* Was haben signale wie "div_busy", "divisor", etc. im Modul "Encoder" zu suchen?
-
-
-> alexander: divisor dividend sind output signale?
-> und wenns muldiv heisst wieso isses dann immer nur ein operand und operator?
-> (vermutlich irgendwie stack basiert aber wie greift der auf den stack zu.)
-
-> bernhard: ja ist verwirrend am ersten blick. das scheint aber das interface zum "Divider" zu sein.
-> meiner Meinung nach sind das zu viele Module und wuerde
+[list]
+[*]
+im Modul "MulDiv" gibt es die Signale "quotient", mehrere "operand_out_*",
+"divisor" und "dividend" (in dieser Reihenfolge). Das ist am ersten Blick sehr
+verwirrend, am zweiten Blick (naemlich auf die anderen Module) wird erst klar
+dass diese Signale unterschiedliche Wege nehmen. Ausserdem: Warum die Division
+und Multiplikation nochmal extra in ein Modul packen?
+[/*]
+[*]
+Die Verwendung des Stacks geht leider nur sehr schwamming hervor (wie oben
+schon angesprochen).
+[/*]
+[*]
+Wieviele Stacks sind nun tatsaechlich in Verwendung? ein ASCII-Stack, ein
+Operanden-Stack und ein Operator-Stack? Haben die das selbe Interface? Wie
+speichern die Daten, sind doch eigentlich ganz unterschiedliche Datenstrukturen
+zu speichern?
+[/*]
+[*]
+Was haben signale wie "div_busy", "divisor", etc. im Modul "Encoder" zu suchen?
+[/*]
+[/list]
Verbesserungsvorschlag fuer die Schnittstellenbeschreibung:
-* eine Spalte zu welchen Module (oder externes Geraet, z.B. PS/2) die Signale fuehren.
+[list]
+[*]
+eine Spalte zu welchen Module (oder externes Geraet, z.B. PS/2) die Signale
+fuehren.
+[/*]
+[/list]
Note: 3
Man erkennt grundsaetzlich eine Aufteilung in Komponenten, jedoch happerts im Detail: Die
Zusammenhaenge der Module werden einem durch das Lesen der Spezifikation nicht ganz klar.
+
Der Stack selbst gehoert auch noch detailierter beschrieben
-Note: 2
+Note: 2-3
projects / hwmod.git / blobdiff