Das Steuerwerk

Jeder RISC-V-Befehl ist 32 Bit lang. Die Felder des Befehls liegen unabhängig vom Befehlsformat immer an denselben Positionen:

Diese Regelmäßigkeit ist ein großer Vorteil: Die Registerdatei kann rs1 und rs2 schon lesen, während das Steuerwerk den Befehl noch dekodiert - auch wenn sich später herausstellt, dass eines der Register gar nicht gebraucht wird.

Das Steuerwerk schaut vor allem auf die unteren 7 Bit, den Opcode. Für unsere minimale Teilmenge sind das:

Die Felder funct3 und funct7 unterscheiden Befehle mit gleichem Opcode, also zum Beispiel add von sub. Wir brauchen sie später für die ALU-Steuerung.

Das folgende Bild zeigt unsere komplette Single-Cycle-CPU. Es erweitert den Datenpfad aus dem letzten Beitrag um das Steuerwerk, die ALU-Steuerung, den Immediate-Generator und drei Multiplexer. Die Steuersignale sind blau gezeichnet: Sie verlassen das Steuerwerk rechts und sind an ihren Zielen als kurze Stummel mit demselben Namen eingezeichnet, damit das Bild übersichtlich bleibt.

Befehlsspeicher und Datenspeicher sind hier zwei getrennte Speicher. Das ist notwendig, weil wir innerhalb eines einzigen Takts einen Befehl lesen und auf den Datenspeicher zugreifen müssen.

Jetzt können wir für jeden Befehl festlegen, welchen Wert jedes Steuersignal haben muss. Diese Tabelle ist das Herzstück des Steuerwerks:

Das X steht für „don’t care“ (egal): Bei sw und beq spielt der Wert von MemToReg keine Rolle, weil RegWrite = 0 ist und ohnehin nichts in die Registerdatei geschrieben wird. Solche Don’t-Cares geben uns Freiheit, die Logik kleiner zu machen.

Gehen wir die Zeilen durch:

Die ALU aus Teil 1 wird über die Signale Ainvert, Binvert und Operation gesteuert. Zusammen sind das 4 Steuerbits. Für unsere Befehle brauchen wir:

Die ALU-Steuerung erzeugt diese 4 Bit aus dem 2 Bit breiten ALUOp des Hauptsteuerwerks und, bei R-Typ-Befehlen, aus funct7 (davon zählt nur Bit 30 des Befehls) und funct3:

Warum zwei Stufen? Das Hauptsteuerwerk muss nur grob entscheiden („Adressberechnung“, „Vergleich“ oder „schau auf funct“), die Feindekodierung übernimmt die ALU-Steuerung. Beide Blöcke bleiben klein, und jeder hat nur wenige Eingänge. Dieses Prinzip der mehrstufigen Dekodierung hält die Logik klein und schnell.

Manche Befehle enthalten eine Konstante (Immediate). Der Immediate-Generator holt sie aus den Befehlsbits heraus und erweitert sie auf 32 Bit. Je nach Format liegen die Bits an unterschiedlichen Stellen:

Das sieht zunächst etwas wirr aus, hat aber einen Grund: Wo immer es geht, liegt ein Bit der Konstante in allen Formaten an derselben Stelle. Und das Vorzeichenbit ist immer inst[31]. So kann die Vorzeichenerweiterung sofort beginnen, noch bevor das Format überhaupt bekannt ist.

Bei Verzweigungen ist das niederwertigste Bit imm[0] immer 0, weil Sprungziele immer an einer geraden Byteadresse liegen. Es wird deshalb gar nicht erst im Befehl gespeichert - das verdoppelt die Reichweite des Sprungs.

Die Vorzeichenerweiterung füllt die oberen Bits mit Kopien des Vorzeichenbits. So bleibt ein negativer Offset wie -8 auch nach der Erweiterung negativ (das Zweierkomplement lässt grüßen).

Bei einer Verzweigung berechnet die ALU rs1 - rs2. Ihr Zero-Ausgang ist 1, wenn das Ergebnis 0 ist - also wenn beide Register gleich sind. Gleichzeitig berechnet der zweite Addierer das Sprungziel PC + Offset. Der Multiplexer vor dem PC wird gesteuert durch:

\[PCSrc = Branch \cdot Zero\]

Nur wenn der Befehl eine Verzweigung ist und die Register gleich sind, wird das Sprungziel in den PC übernommen. In allen anderen Fällen geht der PC einfach zu PC + 4 weiter.

Verfolgen wir den Befehl lw x5, 8(x6) durch das Bild oben:

All das passiert innerhalb eines Takts, als reine kombinatorische Logik. Erst mit der nächsten steigenden Taktflanke werden die neuen Werte übernommen: Die Registerdatei schreibt x5, und der PC übernimmt PC + 4. Das ist genau das Verhalten der D-Flipflops aus dem Beitrag über Taktgeber und Register.

Unser Beispielprogramm aus dem RISC-V-Beitrag verwendet zwei Befehle, die unsere minimale CPU noch nicht ausführen kann: addi und bne. Erweitern wir die CPU - daran sieht man schön, wie das Steuerwerk mit dem Befehlssatz wächst.

Mit diesen Erweiterungen kann unsere CPU jetzt das Beispielprogramm ausführen. Das Programm liegt ab Adresse 0x00:

Die Steuersignale für die verwendeten Befehle:

Und so läuft das Programm Takt für Takt ab:

Nach 33 Takten ist das Zählen beendet, und die CPU kreist in der Endlosschleife an Adresse 0x18. In Takt 6 zum Beispiel berechnet die ALU 1 - 10 = -9, also ist Zero = 0. Da bei bne inst[12] = 1 ist, gilt Zero ⊕ inst[12] = 1, und mit Branch = 1 ergibt sich PCSrc = 1: Der PC springt zurück auf 0x14 + (-8) = 0x0C.

Wer das live sehen möchte, lädt das Programm in den Simulator Ripes und wählt den Single-Cycle-Prozessor: Dort kann man zusehen, wie die Steuersignale von Befehl zu Befehl umschalten.

Unsere CPU funktioniert - schnell ist sie aber nicht. Die Taktperiode muss lang genug für den langsamsten Befehl sein. Mit typischen Beispielwerten (wie sie Patterson und Hennessy verwenden) ergibt sich:

Die Taktperiode beträgt also 800 ps, bestimmt durch lw - obwohl ein beq schon nach 500 ps fertig wäre. Jeder Befehl „wartet“ auf den langsamsten.

Hier endet die Reihe vorerst - aber genau hier fängt Rechnerarchitektur eigentlich erst an. Die wichtigsten nächsten Schritte, die man in der Literatur findet:

Wer die CPU selbst bauen möchte, für den sind eine Hardwarebeschreibungssprache und ein FPGA der nächste Schritt. Der Autor hat dazu einige Beiträge zum Einstieg in FPGAs geschrieben.

Vom ersten Logikgatter bis zur CPU, die ein Programm ausführt: Das war der Weg dieser Reihe. In Teil 1 haben wir die kombinatorischen Bausteine kennengelernt - Gatter, boolesche Algebra, Addierer und die ALU. In Teil 2 kam das Gedächtnis hinzu - Flipflops, Register, Speicher und Automaten -, und am Ende wurde all das zu einer funktionierenden RISC-V-CPU zusammengesetzt.

Zum Weiterlesen:

(Erstellt mit Claude AI)