CPU Design mit VHDL 7.5 ECTS

• Modul: CPU Design mit VHDL: 7.5ECTS, SS24
• Prüfungsform: Mündlich
• Prüfer: Philipp Holzinger, Beisitzer: Thomas Schlögl
• Note: 1.0
• Vorbereitung:
  • Alle Vorlesungen zusammengefasst, ggf. einzelne Punkte nochmal in den (leider teilweise unvollständigen) Vorlesungsaufzeichnungen nachgeschaut
  • Single-Cycle-CPU per Hand gezeichnet
  • Die Übungsaufgaben sollte man bearbeitet haben (und nicht nur den Gruppenpartner machen lassen), in der Prüfung muss man syntaktisch korrekten VHDL Code auf Papier schreiben
  • Falls man die 7.5ECTS Variante belegt, sollte man sich idealerweise zu dem Zusatzthema (letzte Übungsaufgabe) sehr gut auskennen

Die Prüfung war ein entspanntes Gespräch, wenn man etwas mehr Zeit bei einem Themenblock verbracht hat, war das nicht schlimm. Wenn man zu ausführlich war, hat Philipp einem dann freundlich gesagt dass man XYZ jetzt nicht hinzeichnen/aufschreiben braucht. Auch wenn man Sachen auf anhieb nicht wusste und man dann (ggf. mit etwas Hilfestellung) selbst auf die richtige Lösung gekommen ist, war das nicht schlimm.

* Wie sieht denn eine CPU aus, welche Komponenten hat die so?

Single-Cycle CPU aufgemalt und Komponenten einzeln erklärt. Zu ein paar Sachen kamen Zwischenfragen:

* Du erwähntest das Instruction Format. Was ist das denn und wo unterscheiden sich MIPS und RISC-V

Erklärt was ein Instruction Format ist, unterschied MIPS/R-V: RD und RT an anderer Stelle

* Wie viele Register benötigt man denn in einer R-Type Instruction?

3 Stück: zwei Operanden und ein Ergebnis

* Wie setzen wir denn Sprünge um?

Unterschied zwischen jumps/branches erklärt, und wie man branches in der Zeichnung implementieren kann

* Okay, jetzt haben wir da eine schöne Zeichnung. Wie bekommen wir die denn auf einen FPGA?

Mit einer Hardware Description Language. VHDL/Verilog und HLS erwähnt.

* Und wie funktioniert das denn?

VHDL Designflow im Detail erklärt mit Synthese, Implementierung (Translation, Map, Place&Route). Am Ende dann Bitstream auf den FPGA laden.

* Jetzt lade ich das auf den PFGA und stelle fest - nichts funktioniert. Warum das?

Weil wir vergessen haben, das zu simulieren. Dann kurz die verschiedenen Simulationsarten (Funktional/Post-X) erklärt.

* Okay, dann machen wir das doch mal. Schreibe mir doch mal eine ALU, welche die Befehle „XOR“, „Sub“ und „Shift“ unterstützt.

Simple ALU programmiert, mit Multiplexer am Ende. Code ist dem fleißigen Leser zur Übung in Eigenarbeit überlassen. Dabei die wichtigen Bestandteile (Libraries, Entity, Architecture) erklärt, warum die existieren (Modellierungs-/Verhaltensbeschreibung). Bei der Datenflussbeschreibung/Kombinatorischen Prozess muss man drauf achten, dass alle Fälle abgedeckt sind, sonst entsteht ein Latch.

* Zu welcher Hardware würde dein VHDL Code denn werden?

RTL-Zeichnung davon hingemalt, mit MUX am Ende.

* Was ist denn jetzt das Problem an dieser ALU?

Hier folgt eine Diskussion, weil mehrere Sachen nicht ganz Optimal sind. Zuerst habe ich mit hohem HW-Aufwand argumentiert, dass man besser eine 1-Bit ALU-Zelle nehmen könnte mit klugem Encoding. Darauf wollte Philipp aber nicht hinaus, also habe ich die Probleme am MUX erklärt und die Probleme an dessen Skalierbarkeit

* Denk mal mehr an den Energieverbrauch.

Achso, ja die ganzen Units laufen ja alle immer, weil das rein kombinatorische Logik ist. Immer wenn sich ein Signal verändert, propagiert sich das durch alle Recheneinheiten der ALU, obwohl man das ggf. gar nicht will. Besser: DEMUX verwenden am Anfang oder enable für die functional units.

* Und wie schnell kann ich denn meinen Clock machen?

Hängt vom kritischen Pfad ab.

* Und wo ist der denn?

Kommt drauf an *diskussion wie adder und shifter aufgebaut sind*.

* [Bezogen auf Kritischen Pfad von ALU] Wie kann ich das denn besser machen?

Pipelining. Man baut in die ALU ein paar zusätzliche Register ein (da wo es halt Sinn macht) und verkürzt so den kritischen Pfad.

* Wie lange sollen denn die kritischen Pfade dann sein?

Ungefähr gleichlang, da die Pipeline durch den längsten kritischen Pfad gebottlenecked wird.

* Okay, betrachten wir nochmal deine CPU. Kann ich denn jetzt da 100 Pipelinestufen einfügen?

Nein, das sind viel zu viele. *Es folgt eine Erklärung, wann und wo es sinvoll ist, Pipeline-Stufen einzufügen*.

* Welche Probleme können denn zusätzlich bei Pipelining auftreten?

Interrupts, Hazards.

* Welche Arten von Hazards gibt es denn?

Struktur-, Daten- und Steuerungshazards

* Erklär doch mal Datenhazards. Wann und wie können die Auftreten?

Erklärt.

* Wie lösen wir das denn?

Entweder in Software (Compiler fügt NOPs ein) - blöd weil langsam und überhaupt nicht portabel. Etwas besser: in Hardware mit Hazard-Detection Unit, welche Bubbles einfügt - Immer noch blöd, weil langsam. Am besten: Forwarding.

* Wie kann ich denn Forwarding in die CPU mit einbauen?

Forwarding-Unit erklärt.

* Was ist denn Interlocking?

Wenn wir was vom Memory Lesen, steht es ja nicht in einem Register der nächsten Pipeline-Stufe. Da bringt uns Forwarding nichts mehr, wir müssen also in den saueren Apfel beißen und mit einer Hazard-Detection-Unit eine Bubble einfügen.

* Wir haben jetzt also unsere Pipeline. Die ist jetzt mit einem Bus-System über mehrere Caches zum Hauptspeicher verbunden. Wie wird das denn umgesetzt?

Pipeline muss stallen und „druck auf den Memory ausüben“ - Backpressure. Das geht, indem man z.B. ein Busprotokoll wie AXI verwendet und dort das VALID-Bit setzt.

* Wie funktioniert denn AXI?

Es gibt Channels, über die werden Daten übertragen, wenn ein AXI-Handshake erfolgt.

* Wie heißen die und wie viele gibt es?

5 Stück: Read-Addr, Read-Data, Write-Addr, Write-Data, Write Response

* Du hast den AXI-Handshake erwähnt. Worauf muss man da denn aufpassen?

Es darf keinen kombinatorischen Pfad zwischen XX_VALID und XX_READY geben, ansonsten kann es zu deadlocks kommen.

* Das ist richtig. Es kann aber noch zu einem viel schlimmeren Problem kommen.

Hier wusste ich erst mal nicht, worauf er hinaus wollte. Nach etwas vor- und zurück, hat er mich dann ein XOR-Gatter malen lassen, und den Ausgang mit dem Eingang verbinden lassen. Dann wusste ich worauf er hinauswollte: Kombinatorische Schleifen.

* Was ist denn das Problem an einer kombinatorischen Schleife?

Man muss hier sehr vorsichtig sein, dass man genau das erzeugt, was man will. Eigentlich will man diese gar nicht haben, weil die Hardware durch zu schnelle Signaländerung heiß läuft und beschädigt werden kann, daher Synthetisieren es die meisten Tools nicht einmal.

* Und wo genau kann das jetzt beim AXI-Handshake passieren?

Wenn es halt einen kombinatorischen Pfad von Ready nach Valid gibt.

* Exakt.

Und damit war die Prüfung vorbei.