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
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!
-Wofuer sind die verschiedenen Clocks im Design da? Ein Multiclockdesign ist nicht wuenschenswert,
-ausserdem zu komplex? Wir glauben man sollte das durch Kontrollsignale ersetzen, also z.B. ein
-Requestsignal geht hoch wenn alle Daten ins Register geladen wurden und bis zur Fertigstellung der
-Arbeit bleibt das ACK-Signal niedrig. Es koennte sein, dass es so gemeint ist, dann ist aber die
+Wofuer sind die verschiedenen Clocks im Design da? Ein Multiclockdesign ist
+nicht wuenschenswert, ausserdem zu komplex? Wir glauben man sollte das durch
+Kontrollsignale ersetzen, also z.B. ein Requestsignal geht hoch wenn alle Daten
+ins Register geladen wurden und bis zur Fertigstellung der Arbeit bleibt das
+ACK-Signal niedrig. Es koennte sein, dass es so gemeint ist, dann ist aber die
Bezeichnung '*_clk' sehr irrefuehrend gewaehlt.
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!
-Requirements jein: da auf die genaue art wie das alles funktioniert
-schlicht und ergreifend nicht eingegangen wird.
-
-> bernhard: also ich finde die schon recht detailiert. afaik sagen die Requirements nichts darueber
-> aus wie die komponenten zusammenhaengen, sondern nur wie sich das system gegenueber dem user
-> verhalten soll. (ich kann mich aber auch irren -- ich hasse dieses geschwafel ueber
-> spezifikationen ;))
-
> alex: ich denke das hier nicht nur die vollstaendigkeit der requirements gemeint ist sondern auch
> die vollstaendigkeit der module bzw. interfaces. also ist zu jedem interface mindestens ein modul
> definiert und umgekehrt. Natuerlich gehort auch dazu ob die Module einen vollstaendigen
> Taschenrechner erzeugen.
-Module: Ueberblicksmaessig wirkt es recht gut (abgesehen von den '*_clk'-Signalen, aber in der
-"Detailed Design Description" fehlen eben die Details. Ablaeufe werden zwar textuell kurz erklaert,
-aber sie werden nur sehr oberflaechig und abstrakt "angekratzt". Ausserdem fehlen grafische
-Darstellungen (z.B. State-Maschinen). Weiters waere eine Beschreibung wuenschenswert wie ihr die
-eigentliche Berechnung umsetzen wollt (z.B. mit Hilfe von Pseudocode).
+> bernhard: aso, ich dachte das bezieht sich auf die Requirements. dann passts.
+
+Requirements: passen.
+
+
+Module:
+Ueberblicksmaessig wirkt es recht gut (abgesehen von den
+'*_clk'-Signalen), aber in der "Detailed Design Description" fehlen eben die
+Details.
+Ablaeufe werden zwar textuell kurz erklaert, aber sie werden nur sehr
+oberflaechig und abstrakt "angekratzt". Ausserdem fehlen grafische
+Darstellungen (z.B. State-Maschinen). Weiters waere eine Beschreibung
+wuenschenswert wie ihr die eigentliche Berechnung umsetzen wollt (z.B. mit
+Hilfe von Pseudocode). Da muss einfach noch viel gemacht werden!
+
Testfaelle: Sind sehr gut!
-Note: 2
+Note: 3
3. Verständlichkeit: Ist das Dokument klar und verständlich geschrieben? Besitzt das Dokument eine
Ja, grundsaetzlich schon, bis auf die Schnittstellenbeschreibung.
Verbesserungsvorschlaege:
-* eine Spalte zu welchen Module (oder externes Geraet, z.B. PS/2) die Signale fuehren.
-* einheitlichere Beschriftung der Signale (z.B. in "Calculator State Maschine", wo fuehren die
- Signale "result_data" bzw. "result_clk" hin? Das ist am ersten Blick nicht klar ersichtlich)
+[list]
+[*]
+eine Spalte zu welchen Module (oder externes Geraet, z.B. PS/2) die Signale
+fuehren.
+[/*]
+[*]
+einheitlichere Beschriftung der Signale (z.B. in "Calculator State Maschine",
+wo fuehren die Signale "result_data" bzw. "result_clk" hin? Das ist am ersten
+Blick nicht klar ersichtlich)
+[/*]
+[*]
+und wie schon angesprochen: die divisieren '*_clk'-Signale verwirren.
+[/*]
+[/list]
Note: 2
projects / hwmod.git / commitdiff