doc/review/designspec.txt

   1 1. Korrektheit: Enthält die Spezifikation inhaltiche Fehler, widersprüchliche Aussagen oder werden
   2    falsche Annahmen getroffen? Vergeben Sie eine Note (1-5) und begründen Sie!
   3
   4 Viele kleinere Unstimmigkeiten (vor allem bei der Schnittstellenbeschreibung), aber das hat wohl den
   5 Grund, dass es noch nicht die finale Abgabe ist (ein paar Einzelheiten werden weiter unten erwaehnt).
   6
   7 > bernhard: Die Verwendung eines Stackes scheint das ganze Design etwas kompliziert zu machen, oder
   8 > find das nur ich?
   9
  10 > alex: grundsaetzlich hast du recht und ich bin der meinung kman kann einen operanden- bzw.
  11 > operatorenstack durch operanden register (3) und operatorenregister (2) ersetzen. Aber wenn man
  12 > einen RPN-taschenrechner machen weurde braucht man einen stack und man haette damit beliebige
  13 > tiefe erreicht. jedoch braucht man noch immer einen operatorenstack dafuer.
  14
  15 Note: X
  16
  17
  18 2. Vollständigkeit: Enthält das Spezifikations-Dokument alle wesentlichen Requirements/Module des
  19    Designs? Vergeben Sie eine Note (1-5) und begründen Sie!
  20
  21 > alexander: Mir persoenlich fehlen die Zustandsmaschinen. Ich wuerde vorschlagen hier
  22 > entweder Grafen oder Tabellen zu nehmen.
  23
  24 > bernhard: Statemaschinen sind doch eh in der Detailed Design Description? ich find das passt...
  25 > naehere Stackbeschreibung fehlt halt imho.
  26
  27 > alexander: am liebsten haette ich (das gilt auch fuer unsere spezifikation) moore-state-machines.
  28 > das heisst jeder Zustand hat Kanten, die input und output definieren. wenn man in "wenig" signalen
  29 > die wichtig sind, zeigen kann das so eine zustandsmaschine glaubhaft funktionieren kann hat man
  30 > viel gewonnen. ich haette mir von mir schon solche state machines erwartet in meiner
  31 > spezifikation.
  32
  33 > Beispiel fuer rs232 eine kante hat signale: req char(n) / ack counter_overflow tx
  34 > states wareen dann: startbit ,char(0), char(1), char(2) ... (char n-1)  stopbit1, stopbit2, done
  35 > belieber state -> startbit: 0 XX ... XX / 0 0 X // das ist bloed zum modellieren
  36 > startbit -> char (0): 0 XX ... XX / 0 1 0
  37 > char (k) -> char (k+1): 0 XX ... XX / 0 1 char(n)
  38 > char (n-1) -> stopbit 1: 0 XX ... XX / 0 1 1
  39 > stopbit1 -> stopbit2: 0 XX ... XX / 0 1 1
  40 > stopbit2 -> done: 1 XX ... XX / 1 1 1
  41
  42 > und im selben state wird geblieben bei X XX ... XX / X 0 X
  43
  44 Die Interfaces sind grundsaetzlich vorhanden und tabellarisch fest gehalten, jedoch wird nicht
  45 spezifiziert wie diese Werte zu verwenden sind. Zum Beispiel der Stack hat ein Signal "enable", aber
  46 ist das nun High- oder Low-Aktiv?
  47
  48 Ist das Poppen des Stacks destruktiv? Wenn ja wie wird die Ausgabe dann produziert? Beim ASCII-Stack
  49 bin ich mir nicht sicher ob das so gemeint ist und ob das auch gut ist. Beim Operanden-Stack ist
  50 dieses Verhalten jedoch gewuenscht.
  51
  52 Die Grafik koennte man entweder weglassen oder ueberarbeiten (kann auch eine gute Handzeichnung
  53 sein, solange klar ist was passiert).
  54
  55 Wichtig ist ausserdem nicht nur wer aller Zugriff auf den Stack hat sondern auch ob ein Zugriff auf
  56 den Stack gleichzeitig geschehen darf. Der Zugriff selbst auf den Stack wird auch nur sehr
  57 oberflaechig beschrieben und geht nicht wirklick hervor wie der tatsaechlich funktioniert.
  58
  59 Note: 2
  60
  61
  62 3. Verständlichkeit: Ist das Dokument klar und verständlich geschrieben? Besitzt das Dokument eine
  63    ordentliche Struktur? Vergeben Sie eine Note (1-5) und begründen Sie!
  64
  65 Grundssaetzlich ja, aber das Zusammenspiel einiger Komponenten ist teilweise unklar:
  66 * im Modul "MulDiv" gibt es die Signale "quotient", mehrere "operand_out_*", "divisor" und
  67   "dividend" (in dieser Reihenfolge). Das ist am ersten Blick sehr verwirrend, am zweiten Blick
  68   (naemlich auf die anderen Module) wird erst klar dass diese Signale unterschiedliche Wege nehmen.
  69   Ausserdem: Warum die Division und Multiplikation nochmal extra in ein Modul packen?
  70
  71 * Die Verwendung des Stacks geht leider nur sehr schwamming hervor (wie oben schon angesprochen).
  72
  73 * Wieviele Stacks sind nun tatsaechlich in Verwendung? ein ASCII-Stack, ein Operanden-Stack und ein
  74   Operator-Stack? Haben die das selbe Interface? Wie speichern die Daten, sind doch eigentlich ganz
  75   unterschiedliche Datenstrukturen zu speichern?
  76
  77 * Was haben signale wie "div_busy", "divisor", etc. im Modul "Encoder" zu suchen?
  78
  79
  80 > alexander: divisor dividend sind output signale?
  81 > und wenns muldiv heisst wieso isses dann immer nur ein operand und operator?
  82 > (vermutlich irgendwie stack basiert aber wie greift der auf den stack zu.)
  83
  84 > bernhard: ja ist verwirrend am ersten blick. das scheint aber das interface zum "Divider" zu sein.
  85 > meiner Meinung nach sind das zu viele Module und wuerde
  86
  87
  88 Verbesserungsvorschlag fuer die Schnittstellenbeschreibung:
  89 * eine Spalte zu welchen Module (oder externes Geraet, z.B. PS/2) die Signale fuehren.
  90
  91
  92 Note: 3
  93
  94 4. Gesamtbeurteilung: Vergeben Sie eine Gesamtnote (1-5) und geben Sie Ihren Kollegen ein kurzes
  95    Feedback über die Qualität ihres Spezifikations-Dokumentes!
  96
  97 Man erkennt grundsaetzlich eine Aufteilung in Komponenten, jedoch happerts im Detail: Die
  98 Zusammenhaenge der Module werden einem durch das Lesen der Spezifikation nicht ganz klar.
  99 Der Stack selbst gehoert auch noch detailierter beschrieben
 100
 101 Note: 2