Alternative Rechnerarchitekturen (Teil 4)

Die s-Unit des >S<puter-Konzepts sowie der Übersetzungsalgorithmus PDSP lassen sich aus dem Konzept des superskalaren Mikroprozessors herauslösen und einzeln beziehungsweise in neuer Zusammensetzung benutzen. Hieraus ergibt sich eine interessante Mischung aus Programmier- und Ausführungsmodell. Das optimale Modell besteht – nach dem aktuellen Kenntnisstand – darin, dass die Programmkodierung einem sequenziellen Modell folgt, die Ausführung jedoch an die aktuellen Randbedingungen (auch zur Laufzeit) angepasst werden kann. Genau dies wird von dem UCB-/UCM-Modell (Universal Configurable Block/Machine) unterstützt.

Diesen Artikel und eine ganze Reihe weiterer Grundlagenthemen zu Prozessoren finden Sie auch in unserem tecCHANNEL-Compact "Prozessor-Technologie". Die Ausgabe können Sie in unserem Online-Shop versandkostenfrei bestellen. Ausführliche Infos zum Inhalt des tecCHANNEL-Compact "Prozessor-Technologie" finden Sie hier.

Ausführungsphasen dieses Modells

Die ausführenden Blöcke (UCB) benötigen im Prinzip eine Konfiguration, die den Datenweg innerhalb des Blocks für eine Zeitspanne festlegt. Mehr noch als das, eigentlich ist ein Konfigurationsfluss notwendig, da man nicht davon ausgehen kann, dass im allgemeinen Fall eine einzige Konfiguration etwa eine komplette Schleife beinhaltet.

Dieser Konfigurationsfluss lässt sich aus dem Instruktionsfluss gewinnen, dies ist aus der >S<puter-Architektur bekannt. Damit ergeben sich drei (grobe) Ausführungsphasen, die nicht mit dem Phasen-Pipelining einer RISC-Architektur verwechselt werden dürfen (Bild 1, a)).

Im Fall einer Übersetzung zur Compile-Zeit – dies wird als Post-Assembler-Lauf bezeichnet, unterliegt jedoch den gleichen Regeln wie die Übersetzung zur Laufzeit – verringert sich die Anzahl der Grobphasen auf zwei (Bild 1, b)). Unabhängig davon, wann diese Übersetzung stattfindet, gilt jedoch, dass das Programmiermodell mit dem des zu Grunde liegenden Mikroprozessors übereinstimmt. Die bekannten Compiler einschließlich aller Optimierungen können weiterhin benutzt werden. Die nicht starr ausgeführte Kopplung zwischen Fetch/Übersetzung (wie sie definitiv bei Mikroprozessoren der Fall ist) ermöglicht den wichtigen Schritt, die Konfiguration so lange auszuführen, wie sie benötigt wird: Dies ist wie in Teil 1 beschrieben das Kriterium für Reconfigurable Computing.

Universal Configurable Blocks

Ein Universal Configurable Block (UCB) (Bild 2) besteht wie die s-Unit des >S<puter aus Operatoreinheiten und konfigurierbaren Datenpfaden.

Gegenüber dem >S<puter wurden nur wenige Teile ergänzt:

• Arithmetic Unit (AU, Type A): Die AU enthält eine oder wenige, dann konfigurierbare Verknüpfungen. Das ist etwa die Möglichkeit, zwei Integerzahlen zu addieren. Wenn die Eingänge entsprechend beschaltet sind, liefert die AU ein Ergebnis an ihrem Ausgang, das innerhalb des Schaltnetzes weiterverwendet werden kann. 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, wie bei der Multiplikation, kann die Breite des Ausgangsbusses abweichen, um die Berechnungen zu ermöglichen.

• Compare Unit (CoU, Type B): Für die bedingte Ausführung einer Verknüpfung werden Condition-Code-Bits durch einen konfigurierbaren Vergleich in der CoU erzeugt. Der Vergleich lässt sich mit drei Konfigurationsbits auf >, >=, <, <=, !=, ==, TRUE oder FALSE einstellen. Kennzeichen der CoU sind zwei Eingangsbusse, ein Ausgangsbit sowie die Konfigurierbarkeit.

• Multiplexer (Mul_C, Type C): Multiplexer vom Typ C belegen die Eingänge der AUs und der CoUs mit jeweils zwei Eingangswerten (in der vollen Verarbeitungsbreite). Hierfür benötigen sie eine Anzahl von Konfigurierungsbits, die sich aus der Anzahl von Eingängen und den zwei Ausgängen ergeben. Kennzeichen für Mul_C-Einheiten sind zwei Ausgangsbusse.

• 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 Konfigurationsbits benötigt. Ein Mul_D unterscheidet sich daher vom Mul_C durch die Anzahl seiner Ausgangsleitungen.

• 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.

• Compare Unit 2 (CoU2, type F): Diese (optionale) Einheit erzeugt ein (konfigurierbares) Ready-Signal, das die Steuereinheiten wie der Hyperblock-Sequencer (siehe nächsten Abschnitt) auswerten.

• Zusätzliche Hardware zur Synchronisierung des Takts mit in- und externen Steuersignalen.

• Privates RAM (Scratchpad oder Local RAM) zur Unterstützung von datenintensiven Algorithmen. Insbesondere Algorithmen der Signalverarbeitung oder Interpolationen basieren auf Datenfeldern, die wichtige Parameter enthalten, meist aber die Größe von Registern überschreiten.

Procedural-driven Structural Programming

Der Übersetzungsalgorithmus, der zur Erzeugung einer Konfiguration aus einem Instruktionsfluss notwendig ist, entspricht demjenigen für rRISC und >S<puter (Teil 3) und wird Procedural Driven Structural Programming (PDSP) genannt. In speziellen Fällen werden zusätzlich Datenabhängigkeiten erkannt und aufgelöst, wie in Bild 3 dargestellt.

Im Beispiel wird der Inhalt von r1 (Variable a) mit der Konstanten 0 verglichen und davon abhängig der Inhalt in r2 (Variable b) kopiert oder nicht. Dies ist eine klare Datenabhängigkeit (RAW), die aber bei der Übersetzung in die Konfiguration aufgelöst wird und „lediglich“ eine Verlängerung der Bearbeitungszeit nach sich zieht. Die Übersetzung von Verzweigungsbefehlen ist speziell zu berücksichtigen. Alle Branches, die aus Verzweigungen stammen, lassen sich prinzipiell in bedingte Befehle (Bild 10.27) übersetzen. Das gilt nicht für Rückwärtssprünge, deren Herkunft in den Schleifen liegt. Schleifen lassen sich zwar entrollen, dies liefert im allgemeinen Fall aber nur eine Verringerung der Anzahl der Sprünge.

Konsequenterweise müssen die UCBs (oder die übergeordnete Maschine) Verzweigungen behandeln können. Eine solche Verzweigung bedeutet gegebenenfalls den Wechsel einer Konfiguration.

Multicontext-UCB

Die allgemeine Lösung zur Verwaltung von mehreren, sequenziell auszuführenden Konfigurationen sowie von Verzweigungen lautet Multicontext-UCB. Dieser besteht aus einem ausführenden UCB sowie mehreren Speicherebenen, die ausführbare Konfigurationen enthalten können. Der Kontext-Switch von einer Konfiguration zu einer anderen kann durch paralleles Laden im Rahmen eines Takts erfolgen, sofern die Konfigurationen vorgeladen sind.

Die Konfigurationssequenz sowie die Verzweigungen verwaltet der Konfigurationsmanager. Diese neue Einheit gehört insoweit zum UCB, wie dieser über mehrere Speicherebenen verfügt. Ansonsten ordnet man sie der nachfolgend beschriebenen höheren Maschine zu.

Universal Configurable Machine

Ein UCB muss mit fertigen Konfigurationen versehen werden. Diese Übersetzung obliegt dem PDSP-Algorithmus. Allerdings treten eine Reihe von weiteren Aufgaben auf, die allesamt in der höheren Maschine, mit UCM (Universal Configurable Machine) bezeichnet, vereinigt sind:

• Während der PDSP-Algorithmus einen Instruktionsblock übersetzt, muss die Fetch-Einheit den Kontrollfluss innerhalb des Programms (beziehungsweise Threads) weiter verfolgen. Diese Aufgabe zählt zur UCM.

• Bei mehreren UCB-Blöcken müssen diese mit verschiedenen Aufgaben versorgt und gegebenenfalls synchronisiert werden.

Bild 5 gibt einen Überblick zur Mikroarchitektur der UCMs. Hier sind mehrere Blöcke mit Signalisierungen und Kommunikationspfaden vorgesehen. Diese UCM-Architektur lässt sich durch vier Parameter, (b,h,s,c) beschreiben: b ist die Anzahl der UCBs, h der Hardware Scheduler, s der Instruktionsblock-Sequencer und c die Beschreibung der internen Kommunikation.

Die Fähigkeit einer UCM zur sequenziellen Ausführung von UCB-Konfigurationen (Hyperblocks) ist durch den Parameter s beschrieben. Bei s = 1 ist der Sequencer vorhanden, bei s = 0 nicht. Die Fähigkeit zur sequenziellen Bearbeitung bedeutet, dass die UCM wie ein Mikroprozessor arbeiten kann.

Trotz der offensichtlichen Einschränkung für s = 0 sind UCMs mit dieser Eigenschaft durchaus sinnvoll, insbesondere in kleineren Applikationen. Hier wird das Programm in dem Multicontext-UCB selbst gespeichert. Bei kleineren Applikationen geht man davon aus, dass lediglich eine kleine Anzahl von Rekonfigurationen überhaupt notwendig ist. Konsequenterweise besteht die kleinste UCM, eine (1, 0, 0,-)-UCM aus einem UCB mit Multicontext-Konfigurationsspeicher, einer PDSP-Übersetzungseinheit und einem Bootloader für den Start.

Der Parameter h ist interessanter. h = 1 beschreibt die Fähigkeit der UCM, UCBs zu schedulen, ihnen also exklusive oder sequenziell fortschreitende Aufgaben zuzuordnen. Dies ist eine sehr wichtige Funktion, die in den Bereich der Betriebssysteme fällt: Das Scheduling von Ressourcen bedeutet, dass die UCM auf besondere Aufgaben – Interrupt Service beispielsweise – vorbereitet sein kann.

Der Parameter c wurde zur Klassifizierung hinzugefügt, weil die Intra-Chip-Kommunikation gerade für Multiblock-Anwendungen mit zur Laufzeit veränderlichen Zuordnungen sehr wichtig ist. Dieser Parameter beschreibt Funktionalitäten: Die vordefinierte Funktion „lc“ (loosely coupled) beschreibt dabei jene Kopplung, in der Statusleitungen zwischen verschiedenen UCBs verfügbar sind, ein Datentransfer jedoch via Hauptspeicher ablaufen muss.

Im Gegensatz dazu beschreibt „tc“ (tightly coupled) die Kopplung benachbarter UCBs via Shared-Register. Eng gekoppelte Systeme können gerade bei hohem Datenkommunikationsaufkommen sehr effektiv arbeiten. Mit „-“ ist keine Kommunikation verfügbar, „x“ beschreibt eine nicht explizit definierte Kopplung.

Konsequenzen für verschiedene UCM-Typen

Universal Configurable Machines mit b > 1 (Multi-UCB) sind sowohl zur Erhöhung der Performance als auch zur Verbesserung (beziehungsweise Herstellung) von Echtzeitfähigkeit sowie für zuverlässige Systeme zu nutzen. Die Performance lässt sich dabei auf verschiedene Weisen unterstützen: Ein möglicher Weg besteht darin, dass verschiedene UCBs verschiedene Threads beziehungsweise Prozesse ablaufen lassen können. Dies entspricht mehr dem CMP-Ansatz (Chip-Integrated Multiprocessing) für Mikroprozessorarchitekturen [1], während für SMT-Ansätze (Simultaneous Multithreading) [1] mehr Unterstützung innerhalb der UCBs notwendig sein wird.

Eine andere Möglichkeit zur Performance-Verbesserung ist, gänzlich andere, für bestimmte Einsatzgebiete sehr gut geeignete Architekturen auf die UCM abzubilden. Dies kann für den Xputer (Abschnitt 10.4) sehr einfach geschehen, dieser entspricht einer (b, 0, 0, tc)-UCM. Für datenintensive Applikationen, etwa aus dem Bereich der Bildverarbeitung, erhält man hier verglichen mit mikroprozessorbasierten Lösungen große Beschleunigungsfaktoren bis zu 100 und mehr. Echtzeitapplikationen werden durch das Space-/Time-Mapping, die fundamentale Eigenschaft dieses Ansatzes, unterstützt. Hierdurch erhöht sich die Event-Dichte E, die die Reaktionsfähigkeit des Systems beschreibt, um Faktoren von zirka 100 bei Nutzung von (b, 1, 1, tc)-UCMs.

Ausblick

Die von PACT vorgestellte XPP-Architektur (XPP = eXtreme Processing Platform) ist ebenfalls als Coprozessor konzipiert. Mit einem RISC-Prozessorkern, der auch auf dem Chip integriert sein kann, wird hieraus ein vollständiger Prozessor mit enormen Rechenkapazitäten. Das soll Thema des nächsten Artikelteils sein.

Diesen Artikel und eine ganze Reihe weiterer Grundlagenthemen zu Prozessoren finden Sie auch in unserem tecCHANNEL-Compact "Prozessor-Technologie". Die Ausgabe können Sie in unserem Online-Shop versandkostenfrei bestellen. Ausführliche Infos zum Inhalt des tecCHANNEL-Compact "Prozessor-Technologie" finden Sie hier. (mec)

Literatur

[1] Šilc, J.; Robic, B.; Ungerer, T.: Processor Architecture – Berlin, Heidelberg, New York: Springer, 1999