Von Prof. Dr. Christian Siemers
Fortsetzung von ComputerPartner-Ausgabe 12/05, Seite 34
Die UCB-Klasse der rekonfigurierbaren Architekturen eignet sich - zumindest aus Operati-onssicht - gut als weiterführende Architektur für Mikro-prozessoren. Dies erläutern wir anhand des (auch an der Technischen Universität Clausthal entwickelten) UCB-/UCM-Konzepts. Es beinhaltet blockorientierte Strukturen (UCB: Universal Configurable Block) mit übergeordneten Maschinen (UCM: Universal Configurable Machine) zur Verwaltung der Blöcke, Scheduling et cetera.
Wir beginnen mit dem >S<puter, der aus der Varia- tion des Instruction Scheduling der superskalaren Prozessoren stammt und aus dem schließlich auch die UCBs weiterentwickelt wurden.
Einführung in das >S<puter-Prinzip
Bild 1 zeigt den Aufbau eines superskalaren Prozessors bei bewusster Weglassung der Floa-ting-Point-Einheit. Die im Fol-genden dargestellten Eigenschaf-ten der ausführenden Einheit für den Integerteil des Rechners lassen sich jedoch auf die Floating-Point-Unit 1:1 übertragen.
Innerhalb des Prozessors werden das Integer Register File, die Functional Units und die Re-order-and-Commit-Unit zu einer neuen Einheit (in Bild 1 grau unterlegt), der s-Paradigmen-Unit oder abgekürzt s-Unit, zusammengefasst. Diese Architektur wird im s-Paradigmen-Modell wie in Bild 2 (Seite 28) variiert.
Das s-Paradigmen-Modell kennt vier Klassen von Maschi- nenbefehlen:
w Branch- und Jump-Befehle zur Kontrollflusssteuerung
w Load-/Store-Instruktionen zum Datentransfer zwischen Registern und Speicherbereich
w Arithmetische und logische Kommandos zur Berechnung
w Sonstige Befehle wie No Operation, Wait, Stop et cetera, die im weitesten Sinne auch der Kontrollflusssteuerung dienen
Während die Befehlsklassen zur Kontrollflusssteuerung so belassen und entsprechend dem Standard in superskalaren Rech-nern ausgeführt werden, nehmen die Load-/Store- und die arithmetisch/logischen Befehle eine neue Stellung ein.
Load-/Store-Befehle werden entweder mit Hilfe einer oder mehrerer Load-/Store-Pipeline(s) zum Datentransfer zwischen dem Integer Register File und dem Datenspeicher (Cache, Haupt-speicher) eingesetzt und dann wie bisher bearbeitet. Oder sie werden zu den arithme-tisch/logischen Befehlen hinzugefügt und in das nun beschriebene Kernstück des s-Paradigmen-Modells integriert. Die Entschei-dung hierüber obliegt dem System-Designer der CPU. Move-Befehle hingegen, die einen Datentransfer zwischen den Re-gistern des Prozessors bewirken, gehören grundsätzlich zu diesem Modell.
Die arithmetisch/logischen Be-fehle (und die hinzugefügten Load-/Store-Befehle) werden ihrer Programmiersequenz zufolge in eine Struktur von aufeinander folgenden Hardware-Verknüp-fungen übersetzt. Zu diesem Zweck bietet die Functional Unit im >S<puter eine programmierbare Struktur und fest verdrahtete arithmetisch/logische Verknüp-fungen (sowie gegebenenfalls Zugriffsfunktionen wie Load-/ Store-Pipelines). Diese lassen sich durch die Struktur miteinander verknüpfen und werden in der Reihenfolge der Strukturierung bearbeitet. Bild 3 (Seite 29) erläutert diese Funktionalität.
Teileinheiten der Functional Unit I
Die Teileinheiten der Functional Unit und das Register File (Bild 3 Seite 29) sind durch eine Vielzahl von Datenverbindungen und Multi-plexern verbunden.
Die Datenverbindungen sind dabei als Busse mit der jeweiligen internen Datenbusbreite ausgeführt (zum Beispiel mit 32 Bit). Eine Ausnahme bilden die Condition Codes, die als Bitlei-tungen implementiert sind. Innerhalb der Functional Unit existieren fünf Typen von Teilein-heiten:
w Arithmetic Unit (AU, Type A): Diese Einheit darf man nicht mit der herkömmlichen Arithmeti-cal-Logical-Unit (ALU) verwechseln. Die AU enthält eine oder wenige, dann konfigurierbare Verknüpfungen, beispielsweise um zwei Integerzahlen zu addieren. Sie liefert ein Ergebnis an ihrem Ausgang, wenn die Eingänge entsprechend beschaltet sind. Dieses Ergebnis kann innerhalb des Schaltnetzes weiterverwendet werden.
Die AU ist gekennzeichnet durch zwei Eingangsbusse und einen Ausgangsbus, gegebenenfalls durch eine Konfigurationsmöglichkeit (Auswahl der Verknüpfung, im Extremfall entsprechend einer ALU) und durch Konditionalbits. In einigen Fällen, beispielsweise bei der Multiplikation, kann die Breite des Ausgangsbusses abweichen, um die Berechnungen möglich zu machen.
w Compare Unit (CoU, Type B): Für die bedingte Ausführung einer Verknüpfung werden Condi-tion-Code-Bits durch einen konfigurierbaren Vergleich in der Compare Unit erzeugt. Der Ver-gleich lässt sich bei Verwendung von drei Konfigurationsbits auf >, >=, <, <=, !=, ==, TRUE oder FALSE einstellen. Kennzeichen der Compare Unit sind zwei Eingangsbusse und ein Aus-gangsbit sowie die Konfigurier-barkeit.
w Multiplexer (Mul_C, Type C): Multiplexer vom Typ C belegen die Eingänge der AUs und der CoUs mit jeweils zwei Eingangs-werten (in der vollen Verarbei-tungsbreite). Hierfür benötigen sie eine Anzahl von Konfigurier-ungsbits, die sich aus der Anzahl von Eingängen und den zwei Ausgängen ergeben. Kennzeichen für Mul_C-Einheiten sind zwei Ausgangsbusse.
w Multiplexer (Mul_D, Type D): Für die Belegung der Register mit den Ergebniswerten wird lediglich ein Ausgangsbus und damit auch nur die Hälfte der Konfigu-rationsbits benötigt. Ein Mul_D unterscheidet sich daher vom Mul_C durch die Anzahl seiner Ausgangsleitungen.
w Demultiplexer (Demul, Type E): Die Ergebnisse der Vergleiche (CoU) müssen an entsprechende AUs weitergeleitet werden. Im Gegensatz zu den Multiplexern, die eine Quellenauswahl vornehmen, liegt hier eine Zielauswahl vor.
Die Verbindungen zwischen den Teileinheiten können komplett oder teilweise ausgeführt sein, abhängig von der Anzahl der zur Verfügung stehenden Konfi-gurationsbits in der Gesamtheit. In einer Beispielarchitektur auf den nächsten Seiten wird eine vollständige Verbindbarkeit gezeigt und die Zahl der notwendigen Bits daraus berechnet.
Teileinheiten der Functional Unit II
Der Sinn der strukturierbaren Functional Unit, der s-Paradig-men-Unit, liegt nun darin, die Struktur entsprechend den Ma-schinenbefehlen in einem (Basis-, Super- oder Hyper-)Block eines Programms anzupassen.
Die Programmierung erfolgt im s-Paradigmenmodell durch das Laden von Konfigurationsbits für die Teileinheiten. Diese werden im Programmable Structure Buffer zwischengespeichert und bei Bearbeitung des Blocks in die s-Unit geladen. Die Einheit ist dadurch entsprechend strukturiert und kann den Block bearbeiten. Die Bearbeitung bezieht sich dabei lediglich auf die arithmetischen und logischen Verknüp-fungen zwischen Registerinhal-ten, gegebenenfalls auch mit Speicherinhalten (falls eine entsprechende Load-/Store-Pipeline zur Verfügung steht). Alle anderen Kommandos, insbesondere Load/Store und Kontrollflussbe-fehle laufen wie bisher üblich ab.
Die Generierung der Konfigu-rationsbits kann im Assembler erfolgen (Compile-time-basierte Generierung). Es ist auch möglich, sie in der CPU zur Laufzeit erzeugen zu lassen (Runtime-basierte Generierung), etwa durch einen funktionell erweiterten Programmable Struc-ture Buffer.
Realisie-rung eines >S<puters
Die Struktur der s-Unit mit fest verdrahteten AUs sowie CoUs und konfigurierbaren Wegen zwischen diesen Teileinheiten legt zunächst fest, dass die Multiplexer das programmierbare Element sind. Die feste Verdrahtung insbesondere der AUs hält die Anzahl der zu ladenden Bits gering.
In einer weiteren Stufe der Flexibilisierung könnten auch die AUs programmierbar sein. Auf einfachen Strukturen wie NAND-Gattern oder disjunktiven Normalformen (DNF) aufbauend wäre eine nahezu beliebige Funktionalität bereits in einer AU integrierbar.
Arithmetic Units beinhalten beispielsweise folgende Funktion-alitäten:
w Arithmetische Verknüpfungen: Addition, Subtraktion, Multipli-kation, Division
w Logische Verknüpfungen wie AND, OR, XOR, NOT, (Zweier) Komplement
w Shift-Funktionen wie arithmetische oder logische Shifts nach rechts/links
w Bedingte Datentransfers, abhängig von den Eingangsbits (2-Wege-Multiplexer; im Unter-schied zu Mul_C- und Mul_D-Typen zur Laufzeit umschaltbar)
Die Basis für die Program-mierung der Struktur, also der beiden Multiplexer-Typen, besteht in RAM-Zellen. Damit ist eine sehr schnelle Konfigurierung gewährleistet, während andere Technologien wie EEPROM längere Zeit benötigen und eher für den Einsatz von program-mierbaren AUs denkbar wären. Mit n Bit lassen sich 2n Wege schalten. Für einen Mul_C bei 32 Eingän-gen wären somit 2 x 5 Bit und für einen Mul_D fünf Bit zur Kon- figurierung not-wendig.
Register der Modellarchitektur
In der Modellarchitektur implementieren wir folgende Teilein-heiten und Register:
w Vier Addierer (AU), bei denen durch ein Condition-Code- Bit die Addition durchgeführt (TRUE) oder das erste Wort unverändert durchgelassen wird.
w Ein Multiplizierer (AU) und ein Dividierer (AU).
w Eine logische Einheit mit AND, OR, XOR und Zweier-Komplementbildung, konfigurierbar durch zwei Bit (AU).
w Eine Shift-Funktionseinheit (AU), die mit Hilfe von zwei Bit auf links/rechts und arithme-tisch/logisch konfiguriert wird.
w Zwei dynamische Pfad-Multi-plexer, die durch ein Bit im Steuereingang einen der beiden Eingangsbusse am Ausgang anliegen lassen (AU). Diese Multiple-xer dürfen nicht mit dem Multi-plexer Typ C oder D verwechselt werden, da die hier vorgeschlagene Teileinheit die Auswahl dynamisch schaltet.
w Sechs Vergleichseinheiten mit je einem Bitausgang, konfigurierbar über drei Bit auf acht Ver-gleichsarten (CoU).
w Zwölf logische Register R0 bis R11, die in einem Pool von beispielsweise 24 physikalischen Registern per Register Renaming identifiziert werden.
w Vier Konstantenregister C0 bis C3, in denen die im Instruk-tionscode kodierten Konstanten während der Bearbeitung eines Blocks gespeichert werden.
Dies ergibt 32 zu verbindende Teile innerhalb der s-Unit. Bei vollständiger Verbindbarkeit wären die Multiplexer mit fünf beziehungsweise 2 x 5 Bit zu konfigurieren. Zur Verbindung aller Einheiten benötigen wir zehn Multiplexer Typ C, 12 vom Typ D und sechs Demultiplexer vom Typ E. Die Konditionierung durch Vergleichsoperationen soll sich dabei nur auf AUs beziehen. Daher benötigen die Demulti-plexer nur 3 Bit zur Konfigura-tion. Damit ergibt sich eine Gesamtzahl der Konfigurations-bits (für Multiplexer und konfigurierbare AUs) von 200. Diese Zahl soll lediglich die Komple-xität der Konfiguration zeigen. Für die Zahl der real benötigten AUs und CoUs sind umfangreiche Simulationen notwendig. Dem Modell fehlt außerdem eine Behandlung von Flags, die durch gesonderte AUs mit Auswerte- eigenschaften möglich wäre. Um einen Überlauf bei arithmetischen Operationen zu verhindern/erkennen, sind ausreichend dimensionierte Datenbusse und Auswerteeinheiten notwendig, die wir aus Übersichtsgründen weglassen.