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.
Gast
#6586703
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.
Ein Bild sagt mehr als 1000 Worte. https://www.mikrocontroller.net/articles/Flipflop#Zeitverhalten_von_FlipFlops_in_synchronen_Logikschaltungen
Gast
#6586809
Register aus taktflankengesteuertes Master-Slave-FlipFlop ist das, was du suchst.
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.