So minimieren Sie die Mikrocode-Komplexität in einer selbstgebauten 8-Bit-CPU

tldr; Ich habe Ben Eaters 8-Bit-Breadboard-Computer gebaut und später erweitert. Nach dem ersten Build habe ich 16-Bit-Programmzähler und Speicheradressenregister integriert, den Befehlssatz neu gestaltet und es geschafft, auf 64 KB RAM zuzugreifen. In Zukunft habe ich 8-Bit-X- und Y-Register als Zählerregister hinzugefügt, vergleichbar mit X und Y des 6502/10. Mit diesen 2 zusätzlichen Registern wird die Microcode-Organisation und die notwendige ROM-Größe bereits unangenehm groß. Wie kann ich die Microcode-Organisation besser handhaben?

Details: Im aktuellen Design habe ich bereits 7 8-Bit-Register (A, B, ALU, Ausgang, Befehlsregister, X- und Y-Zähler). Außerdem habe ich 2 16-Bit-Register (Programmzähler, Speicheradressenregister) und ein 2-Bit-Flags-Register.

Aktuell verwende ich 3 ROMs für Microcode mit jeweils 11 Bit Adressbreite, also jeweils 2kB und 6kB zusammen. Die ROMs decodieren derzeit die Ausgabe für bereits 18 Steuersignale, um die Eingabe und Ausgabe der gesamten an den 8-Bit-Einzelbus angeschlossenen Hardware zu handhaben.

Die 11 Eingangsbits für die Decoder-ROMs bestehen aus 6 Bits von der Anweisung (was mir nur maximal 64 Anweisungen lässt), 2 Bits von Flags und 3 Bits von einem Anweisungs-Unterschrittzähler.

Das Design funktioniert wie ein Zauber, aber ich frage mich, wie ich den Mikrocode noch verwalten kann, wenn ich das Design noch weiter erweitere. Ich plane mehr Busse (Daten, Adresse, ALU getrennt), mehr Flags, mehr Register. Ich befürchte, dass die schiere Anzahl der notwendigen Eingabebits für die Befehls-ROMs ihre Größe ziemlich schnell sprengen wird. Andererseits wächst auch der Bedarf an Steuerleitungen recht schnell.

Mögliche Lösungen, die ich sehe: Mein aktuelles Design hat den Vorteil, dass alle Anweisungen superschnell sind und maximal zwischen 2 und 6 Zyklen benötigen. Ich könnte zum Beispiel Steuerleitungen loswerden, indem ich ihre Anzahl verringere und Schieberegister verwenden, um Steuersignale sequentiell zu bilden. Aber das kostete mich viele Zyklen pro ASM-Befehl und würde die Maschine dramatisch verlangsamen. Das Problem der Eingangssignale ist völlig ungelöst.

Ich habe keine formelle Ausbildung in diesem Bereich, verzeihen Sie daher bitte meine naive Frage. Ich würde gerne verstehen, wie Hardware-Ingenieure in den 70er und 80er Jahren diese Probleme in CPUs wie dem RCA 1802, dem MOS 6502 oder dem Z80 gelöst haben. Gibt es Begriffe, die ich nicht kenne? Wo kann ich mich darüber informieren? Kann hier jemand helfen?

Traditionell wurden diese CPUs komplett ohne Mikrocode entwickelt. Der Befehlsdecoder war eine fest verdrahtete Logik, und die ISA wurde sehr sorgfältig entworfen, um die beteiligte Logik zu minimieren. (z. B. Befehlsformate so anordnen, dass 3 Bits der Befehlsadresse direkt registriert werden) Das minimiert zumindest den Mikrocode! Microcode war eine Möglichkeit, die Komplexität des fest verdrahteten Decoders zu verwalten ... Die Erweiterung einer vorhandenen CPU führt zum Z80 (vom 8080) und x86 (vom 8086). Irgendwann ist es besser, mit einem sauberen Befehlssatz neu zu beginnen, aber das verliert die Abwärtskompatibilität.
Danke @user_1818839, Abwärtskompatibilität ist für mich kein Problem, aber ich würde kombinatorische Logik als Mikrocode-Ersatz ausschließen, da dies zu komplex wäre, wenn versucht würde, sie ausschließlich auf der Grundlage von 74xx-TTL-Chips zu implementieren. Ich generiere meinen Mikrocode programmgesteuert, aber ein Problem ist zum Beispiel, dass ich meine Mikrocode-ROM-Größe mit jeder neuen Eingabezeile verdopple - zum Beispiel einem neuen Flag. Und die meisten ROM-Seiten sind derzeit mit sehr wenigen Bytes gefüllt. Ich suche nach einem anderen Codierungsschema.
Diese Frage ist so wie sie ist zu weit gefasst. Aber im Allgemeinen haben Sie die grundlegende Mikrocode-Architektur, mit der Sie angegeben haben, überdehnt. Beispielsweise ist es akzeptabel, "Flag"-Eingänge direkt als Adressbits in das ROM einzuspeisen, wenn es nur eine unbedeutende Anzahl davon gibt, aber wenn Ihr System wächst, müssen Sie Ihre Architektur erweitern. Versuchen Sie, Ihre Flags in einen Multiplexer einzuspeisen, der von einigen Ausgangsbits aus dem ROM gesteuert wird, und dann haben Sie nur einen Ausgang vom Mux, der in die ROM-Adresse zurückgeführt wird.
Vielleicht finden Sie eine Kopie von "Bitslice Microprozessor Design" von Mick and Brick. Außerdem können interessante Designhinweise aus dem Blick auf die Schaltpläne alter Computer gewonnen werden. ZB pdp11 und ihre Festplattencontroller.

Antworten (1)

Vielleicht könnten Sie etwas Multiplexing/Konsolidierung verwenden. Vielleicht können Sie dieselben Zeilen für verschiedene Kontexte verwenden. Wenn Sie ein Repeat-Flag haben, ist es wahrscheinlich nicht nützlich für Register-zu-Register-ALU-Operationen, also könnten einige der Zeilen für solche Operationen etwas anderes tun. Ich vermute, dass Ihr Microcode-ROM bereits eine Reihe von Lücken aufweist, nur dass Sie sie nicht erreichen können.

So minimieren Sie die Mikrocode-Komplexität in einer selbstgebauten 8-Bit-CPU
AntwortenHierDatenschutz-Bestimmungen1y, 0v