From: Alex Date: Thu, 15 Apr 2010 16:54:44 +0000 (+0200) Subject: weitere kommentare im review X-Git-Tag: review_abgabe~5 X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=commitdiff_plain;h=aa654ae7a0985af07c32b9b422dd0ef55c894959;p=hwmod.git weitere kommentare im review --- diff --git a/doc/review/designspec.txt b/doc/review/designspec.txt index c785b10..413cc8a 100644 --- 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 7c9eb37..fac7ac2 100644 --- 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,