From b7ad6f1d94b4548548d241071f9bee9eb788dc80 Mon Sep 17 00:00:00 2001 From: Bernhard Urban Date: Fri, 16 Apr 2010 13:43:53 +0200 Subject: [PATCH] review: bbcode und kleinere anpassnungen bitte textwidth=80 verwende, sonst schauts in myTI scheisse aus... --- doc/review/designspec.txt | 162 +++++++++++++++++++++----------------- doc/review/hwmodspec.txt | 56 ++++++++----- spec/TODO | 1 + 3 files changed, 127 insertions(+), 92 deletions(-) diff --git a/doc/review/designspec.txt b/doc/review/designspec.txt index 413cc8a..a306310 100644 --- a/doc/review/designspec.txt +++ b/doc/review/designspec.txt @@ -1,92 +1,111 @@ 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 @@ -96,6 +115,7 @@ 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 diff --git a/doc/review/hwmodspec.txt b/doc/review/hwmodspec.txt index fac7ac2..0e2217d 100644 --- a/doc/review/hwmodspec.txt +++ b/doc/review/hwmodspec.txt @@ -1,10 +1,11 @@ 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 @@ -13,29 +14,31 @@ 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 @@ -43,9 +46,20 @@ Note: 2 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 diff --git a/spec/TODO b/spec/TODO index 596a500..3a6ec90 100644 --- a/spec/TODO +++ b/spec/TODO @@ -1,3 +1,4 @@ - sys_{clk,res} low/high-aktiv? - signale einheitlicher benennen - buttonmodul (mit debouncing) fuer reset und rs232 dump +- am liebsten haette ich (das gilt auch fuer unsere spezifikation) moore-state-machines. -- 2.25.1