weitere kommentare im review

diff --git a/doc/review/designspec.txt b/doc/review/designspec.txt
index c785b10cb9384a3a321fad01db1d279fb32a6447..413cc8aec696f2dcee9bab38dc10f839620cbbf4 100644 (file)
--- a/doc/review/designspec.txt
+++ b/doc/review/designspec.txt
@@ -7,6 +7,11 @@ Grund, dass es noch nicht die finale Abgabe ist (ein paar Einzelheiten werden we
 > 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
 
 
@@ -19,6 +24,23 @@ Note: X
 > 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?

diff --git a/doc/review/hwmodspec.txt b/doc/review/hwmodspec.txt
index 7c9eb37aeeea7e481ee132ac7ee81c1b27c523cc..fac7ac2269e187d0af0880f2849c32c3481885a5 100644 (file)
--- a/doc/review/hwmodspec.txt
+++ b/doc/review/hwmodspec.txt
@@ -21,6 +21,10 @@ schlicht und ergreifend nicht eingegangen wird.
 > 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,