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


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).

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


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


Verbesserungsvorschlag fuer die Schnittstellenbeschreibung:
* eine Spalte zu welchen Module (oder externes Geraet, z.B. PS/2) die Signale fuehren.


Note: 3

4. Gesamtbeurteilung: Vergeben Sie eine Gesamtnote (1-5) und geben Sie Ihren Kollegen ein kurzes
   Feedback über die Qualität ihres Spezifikations-Dokumentes!

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