Guten Tag,
ich hätte eine vielleicht etwas dumme Frage bezüglich des Accumulators
und der ALU in CPUs.
Ich plane zur Zeit einen sehr einfachen 8-Bit-Computer aus Logikgattern
zu entwerfen und zu bauen und habe mich auch schon umfassend darüber
informiert. Ich habe angefangen eine einfache ALU (ADD, SUB, NOT, OR,
AND, XOR) zu designen und diese auch schon auf dem Breadboard getestet,
was prima funktioniert hat. Der nächste Schritt wäre einen Accumulator
zu entwerfen, hier stecke ich allerdings zur Zeit etwas fest und damit
komme ich zu meinem Problem:
Der Ausgang des Accumulators ist einer der beiden Eingänge der ALU, der
Ausgang der ALU wiederum der Dateneingang des Accumulators. Wenn ich
jetzt aber das Ergebnis der ALU in den Accumulator speichere, ändert
sich damit wiederum der Ausgang und damit auch der Ausgang der ALU, was
wiederum das Register überschreibt und somit wieder ein anderes Ergebnis
an der ALU erscheint, das würde ja dann immer so weiter gehen.
Soweit ich weiß werden für Register taktflankengesteuerte D-Flip-Flops
verwendet, ist hierbei die steigende Taktflanke so kurz, dass die ALU
keine Chance hat noch mal etwas zu ändern, werden gar andere Flip-Flops
verwendet (wie z.B. Master-Slave-Flip-Flops) oder habe ich wieder mal
einen ganz dummen Denkfehler?
Und noch eine weitere Frage:
Wenn taktflankengesteurte D-Flip-Flops verwendet werden, wie wird dann
garantiert, dass die Daten bereits stabil anliegen, wenn die Takflanke
steigt?
Ich bedanke mich schon mal im Voraus,
Benedikt
Benedikt S. schrieb:> Guten Tag,>> ich hätte eine vielleicht etwas dumme Frage bezüglich des Accumulators> und der ALU in CPUs.> Ich plane zur Zeit einen sehr einfachen 8-Bit-Computer aus Logikgattern> zu entwerfen und zu bauen und habe mich auch schon umfassend darüber> informiert.
Hmm, Hardcore Retro? Warum nicht ein FPGA? Löten mag ja schön ein, aber
hmm?
> Der Ausgang des Accumulators ist einer der beiden Eingänge der ALU, der> Ausgang der ALU wiederum der Dateneingang des Accumulators.
Normal. Irgendwo muss das Ergebnis ja gespeichert werden.
> jetzt aber das Ergebnis der ALU in den Accumulator speichere, ändert> sich damit wiederum der Ausgang und damit auch der Ausgang der ALU, was> wiederum das Register überschreibt und somit wieder ein anderes Ergebnis> an der ALU erscheint, das würde ja dann immer so weiter gehen.
Nö. Synchrone Logik funktioniert anders.
> Soweit ich weiß werden für Register taktflankengesteuerte D-Flip-Flops> verwendet, ist hierbei die steigende Taktflanke so kurz,
Naja, das Prinzip ist etwas anders. Ein Register (FlipFlop)
speichert mit einer Taktflanke die Eingangsdaten, die kurz vorher
anlagen. Die Daten am Eingang dürfen sich sehr kurz nach der Taktflanke
wieder ändern, das hat einen Einfluß auf das gespeicherte Ergebnis.
> dass die ALU> keine Chance hat noch mal etwas zu ändern, werden gar andere Flip-Flops> verwendet (wie z.B. Master-Slave-Flip-Flops) oder habe ich wieder mal> einen ganz dummen Denkfehler?
Die Alu ist nur kombinatorische Logik. Eingangsdaten aus Registern
laufen da durch, werden "verwurstet" und hinten steht nach X
Nanosekunden ein Ergebnis an. Das kann man dann kurz darauf mit der
nächsten Taktflanke wieder in einem Register speichern. Das ist ganz
normal. Macht jedes D-FlipFlop so.
Extremfall. Ein T-FlipFlop (Toggle FlipFlop). Ein D-FlipFlop, dessen
invertierter Ausgang direkt an den Eingang geht. Das funktioniert
problemlos, denn es dauert ein paar ns, bis die Daten vom Eingang am
Ausgang anliegen. Und wenn das passiert, ist die Speicherung schon
abgeschlossen.
> Und noch eine weitere Frage:> Wenn taktflankengesteurte D-Flip-Flops verwendet werden, wie wird dann> garantiert, dass die Daten bereits stabil anliegen, wenn die Takflanke> steigt?
Das musst du machen, indem die Logik zwischen den Registern weniger
Durchlaufzeit als die Periodendauer hat.
Benedikt S. schrieb:> Und noch eine weitere Frage:> Wenn taktflankengesteurte D-Flip-Flops verwendet werden, wie wird dann> garantiert, dass die Daten bereits stabil anliegen, wenn die Takflanke> steigt?
Dafür muss nur die Taktfrequenz niedrig genug sein. Wenn die
Taktfrequenz z. B. 1/300stel Hz ist, dann kannst du selber in diesen 5
Minuten die ALU spielen und den Wert z. B. mit Schaltern an den
Akku-Flipflops anlegen.
Benedikt S. schrieb:> ist hierbei die steigende Taktflanke so kurz, dass die ALU keine Chance> hat noch mal etwas zu ändern
Die Flipflops haben eine Setup-Zeit und eine Hold-Zeit am Eingang, und
sie haben ein Clock-to-Output-Delay. Diese Zeiten beziehen sich auf die
aktive Taktflanke. Die Daten am Eingang müssen für tsu vor der
Taktflanke und für th nach der Taktflanke stabil sein. Und der Ausgang
ändert sich um tco nach der Taktflanke.
Also muss eigentlich nur tco größer als th sein, dann kann niemals das
von dir befürchtete "Stolpern" passieren.
Und in der Praxis kommt zur tco ja noch die Kombinatorik der ALU und die
Laufzeit durch die Verdrahtung hinzu.
Ich würde es auch über ein FPGA machen.
Und warum nicht erst einmal mit VHDL die Logik simulieren? Selbst wenn
man später 74XX Logikgatter nimmt. So kann man im Vorfeld schon sehen,
ob ein Signal wirklich dort ankommt, wo man es erwartet.
12345 schrieb:> Register aus taktflankengesteuertes Master-Slave-FlipFlop ist das, was> du suchst.
Der innere Aufbau ist eher von akademischem Interesse. Jedes
handelsübliche D-FlipFlop erfüllt hier seinen Zweck.
Typisch dimensioniert man ein D-FF so, daß die Datenhaltezeit 0 ist,
d.h. der Eingang darf sich gleichzeitig mit der übernehmenden Flanke
ändern. Da sich der Ausgang aber rein kausal erst nach der Flanke ändern
kann, ist man immer auf der sicheren Seite. Sonst würde ja nie ein
Schieberegister funktionieren können.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten