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 / blobdiff