Super-Chips Was mit einer Mrd. Transistoren anfangen?

Was könnte man mit mehr als einer Milliarde Transistoren anfangen? Diese Frage kommt unwillkürlich in den Sinn, wenn man solche Super-Chips betrachtet. Die Standardantwort lautet beispielsweise,

Anbieter zum Thema

Schulz-Electronic GmbH

MicroConsult Microelectronics Consulting & Training GmbH

Was könnte man mit mehr als einer Milliarde Transistoren anfangen? Diese Frage kommt unwillkürlich in den Sinn, wenn man solche Super-Chips betrachtet. Die Standardantwort lautet beispielsweise, „das werden wir schon sehen“ oder „es gibt immer Applikationen, die so viele Transistoren wirklich brauchen“ oder „wir arbeiten an diesem Thema“. Doch Hand aufs Herz: Haben Sie sich einmal überlegt, was wirklich nützlich wäre in einem Chip und welche Eigenschaften Sie schon seit langem vermissen?

Diese Frage soll mit einem Blick auf Mikroprozessoren und Mikrocontroller beantwortet werden. Der einfachste Weg zu einer Milliarde Transistoren bestünde darin, die Anzahl der Mikroprozessorkerne zu vervielfachen. Zusammen mit gemeinsamem Cache und anderen Kontrolleinheiten lässt sich auf diese Weise eine nahezu beliebige Anzahl an Transistoren unterbringen. Doch ist dies eine praxisgerechte Lösung? Ließen sich die drängensten Probleme besser durch neue Funktionen in der Hardware lösen? Schließlich hört man immer häufiger, dass Mikroprozessoren und -controller gar nicht so gut für die unzähligen Applikationen im Bereich eingebetteter Systeme geeignet wären. Warum eigentlich nicht?

Auf dem Wunschzettel der Industrie, die eingebettete Systeme herstellt oder nutzt, steht Zuverlässigkeit ganz oben – auch der Konsument, der mit seinem High-Tech-Automobil am Straßenrand liegen geblieben ist, wird dies vehement fordern. Diese Zuverlässigkeit, die eigentlich ein Konglomerat von vielen Unterthemen wie deterministisches Echtzeitverhalten, Fehlertoleranz, Verfügbarkeit usw. ist, häufig auf den Entwicklungsprozess abgebildet. Das ist richtig, denn was im Entwicklungsprozess falsch läuft, kann zur Laufzeit nicht wieder ausgeglichen werden.

Der Preis der Flexibilität

Allerdings kann man im Entwicklungsprozess nicht alles richtig machen, z.B. Laufzeitfehler durch Höhenstrahlung verhindern. Nachdem dieses Thema jahrzehntelang eher akademischer Natur war, hat es nun aufgrund der Strukturverkleinerungen die Praxis erreicht – hier helfen nur fehlertolerante Maßnahmen seitens der Hardware. Doch wie lässt sich die Zuverlässigkeit durch eine neue bzw. erweiterte Hardwarearchitektur deutlich verbessern?

Hinsichtlich Space/Time-Mapping besteht die Frage der Ausführungsdimension von Programmen. Programmierbare Systeme sind halbfertige Systeme, deren endgültige Funktionalität erst durch die Programmanweisungen erreicht wird. Diese Flexibilität ermöglicht Fehlerverbesserungen und Programmupdates bis zur letzten Sekunde.

Dies hat seinen Preis, und der ist erheblich. Mehrere Studien [1 – 3] haben sich mit der Frage beschäftigt, welches Transistorbudget eigentlich für die Universalität der Maschinen notwendig ist, bezogen auf die verschiedenen Formen der Programmierbarkeit. Blume et. al. [1, 2] beispielsweise haben verschiedene Kommunikationsalgorithmen in unterschiedliche Plattformen implementiert und Siliziumfläche, Geschwindigkeit und Energieumsatz gemessen. Das Ergebnis ist in Bild 1 dargestellt.

Dabei ist zu beachten, dass es sich hierbei um eine doppelt-logarithmische Darstellung handelt. Der Flexibilität, gemessen im reziproken Zeitaufwand für Änderungen, steht als Kostenfaktor das Produkt aus „Verlustleistung × Siliziumfläche × Rechenzeit“ gegenüber. Während bei der Flexibilität eine Variabilität von 3 Größenordnungen zu sehen ist, sind es bei den Kosten immerhin 8 Zehnerpotenzen. Dies ist der Preis der Flexibilität.

Neue Möglichkeiten mit Space/Time-Mapping

Der Vergleich von programmierbaren Architekturen wie z.B. Von-Neumann-Prozessoren (General Purpose-CPU – GP-CPU), Digitaler Signalprozessoren (DSP) und Applikationsspezifischer Instruktionssatzprozessoren (ASIP) mit FPGAs (Field-Programmable Gate Arrays) ergibt immerhin noch den Faktor 10 in der Flexibilität und 10000 beim Kostenprodukt. Dieser Vergleich hat jedoch eine weitere Dimension: FPGAs rechnen „in der Fläche“ (Computing in Space) und benötigen dazu wenig Zeit, im Idealfall einen Ausführungstakt, Mikroprozessoren rechnen „in der Zeit“ und benötigen dazu weniger Fläche, die insbesondere mit wachsenden Applikationen kaum zunimmt. Viele Anwendungen würden von beiden Ausführungsmodellen profitieren, und zwar durchaus alternativ, also für manche Ausführungen schnell und insbesondere echtzeitfähig, für manche Ressourcen-schonend.

Benötigt wird eine Architektur, die beide Modelle unterstützen kann, also umschaltbar ist. Dieses Merkmal wird Space/Time-Mapping genannt. Die Möglichkeiten einer solchen Architektur wären enorm: Man denke sich nur eine Hardware, deren Ausführungsmodus ein- und desselben Programms (oder Programmteils) zwischen mikroprozessorähnlich (also zeitsequenziell) oder FPGA-ähnlich (also in der Fläche) umschaltbar wäre. Echtzeitbetriebssysteme könnten so dringende Aufgaben erheblich beschleunigen, zudem wäre das Design (und vor allem auch der Nachweis) von echtzeitfähigen Systemen erheblich vereinfacht.

Flexibel reagierende Hardware

Dies mag unrealistisch klingen, doch existieren hierzu Vorschläge. In [4] wird beispielsweise eine FPGA-ähnliche, allerdings auf arithmetischen Operationen basierende Architektur vorgeschlagen (so genanntes FPFA, Field-Programmable Function Array, hier als Sub-ALU-Array aufgebaut) (siehe Bild 2). Mithilfe von Übersetzungsalgorithmen, die Instruktionsfolgen für einen Mikroprozessor in eine Folge von Konfigurationen umsetzen und auch in Hardware ablaufen können, lässt sich tatsächlich ein erster Schritt in diese Richtung gehen.

Space/Time-Mapping ist dann sinnvoll, wenn die vorhandene Hardware sehr flexibel auf unterschiedliche Betriebssituationen reagieren soll: Sie könnte beispielsweise in einer Normalbetriebsart arbeiten wie ein Mikroprozessor – vielleicht mit Beschleunigung einiger rechenintensiver Bereiche wie bei konfigurierbaren Prozessoren – und bei Alarmsituationen Instruktionen ausschließlich in Hardware abarbeiten, die spezifisch konfiguriert ist, um auf solche Situationen so schnell wie möglich zu reagieren. Dies beansprucht einen Großteil der vorhandenen Ressourcen auf Kosten der anderen Aufgaben im System. Aber bitte keine Illusionen: Jeder neue Freiheitsgrad in der Programmierbarkeit, und dies ist ein neuer Freiheitsgrad, bedeutet, dass die System- und Softwareentwickler und die Toolhersteller hier neue Herausforderungen finden.

Eine weitere und derzeit naheliegendere Methode für erhöhte Zuverlässigkeit ist die Fehlerfolgenvermeidung. Eine der wesentlichen Fehlerquellen innerhalb von Programmen sind schreibende und lesende Zugriffe auf Speicherbereiche, die vom Programm nicht vorgesehen und damit verboten sind. Gerade schreibende Zugriffe können verheerend wirken, da sie still ablaufen und erst wesentlich später zu schweren Fehler führen können, sobald der überschriebene Teil genutzt wird.

Davor sollte der Entwicklungsprozess sowie eine Memory Protection Unit schützen. Doch beides bietet keinen ausreichenden Schutz: Im Entwicklungsprozess sind bei weitem nicht alle Speicherzugriffe derart kontrollierbar (Trivialbeispiel siehe Listing), dass garantiert keine Fehlzugriffe erfolgen. Zudem können Programmteile durch äußeren Einfluss (EMV, Höhenstrahlung) negativ verändert werden. Die Memory Protection Unit hingegen kann nur auf Prozessebene unterscheiden, d.h. nur zwei Prozesse besitzen strikt voneinander getrennte Speicherbereiche.

Dabei wäre es durchaus möglich, einen Schutz im Programm selbst einzubauen [5]. Eine Softwarelösung bringt eine oft inakzeptable Geschwindigkeitseinbuße von etwa Faktor 5 bis 10 mit sich, während die Hardwarelösung für ca. 2 bis 5% erhöhter Laufzeit und Codegröße erhältlich wäre. Durch die Struktur des neuen Adressenformats im PERM/DPE (Protection Enhanced RISC Machine with Data Protection Enhancement) (siehe Bild 3) wird pro Datenladevorgang nicht nur die Registeradresse (bei RISC sind die Speicheradressen fast ausschließlich in Registern gespeichert), sondern auch die vom Linker festgelegte Basisadresse und die obere Grenze sowie weitere Kontrollinformationen geladen. Während des Ladevorgangs kann die CPU kontrollieren, ob die von ihr im Register gespeicherte Adresse wirklich gültig ist. Damit lässt sich zusammen mit einigen Zusatzoperationen ein Speicherschutz auf Variablenebene und nicht mehr auf Prozessebene verwirklichen.

Als Nebeneffekt kann man sehr leicht eine Datenbereichsüberwachung integrieren: Gerade sicherheitstechnische Applikationen verlangen oft, dass spezielle Variabeln immer in bestimmten Bereichen bleiben. Der Nachweis hierfür ist sehr schwierig, aber mit Hardwareunterstützung leicht möglich.

Eine Milliarde Transistoren nur in Geschwindigkeit zu übersetzen, wäre Verschwendung. Damit ließen sich zahlreiche Funktionen verwirklichen, zudem eine Hardware wertvoll ist, die bei Randbedingungen Unterstützung bietet. Sie macht Systeme verlässlicher und ermöglicht gezieltes Design.

Literatur:

[1] Blume, H., Hübert, H., Feldkämper, H.T., Noll, T.G., Model-based Exploration of the Design Space for Heterogeneous Systems on Chip. Proceedings of the Workshop Heterogeneous reconfigurable Systems on Chip (SoC), Hamburg, April 2002.

[2] Blume, H., Feldkämper, H.T., von Sydow, T., Noll, T.G., Auf die Mischung kommt es an. Elektronik 53(19) S. 54–64 und Elektronik 53(20) S. 62–67.

[3] André Dehon, Reconfigurable Architectures for General-Purpose Computing. Massachusetts Institute of Technology, A.I. Technical Report No. 1586, 1996.

[4] Christian Siemers, Volker Winterstein, The Universal Configurable Block/Machine – An Approach for a Configurable SoC-Architecture. The Journal of Supercomputing 26, pp.309-331 (2003).

[5] Christian Siemers, Detlef Jantz, The PERM Architecture Approach: Supporting Embedded Systems Development. In: Zdenek Bradac, Frantisek Zezulka, Michal Polansky, Vaclav Jirsik (eds.), Proceedings of IFAC Workshop on Programmable Devices and Embedded Systems PDeS 2006, pp. 291-297.

*Prof. Dr. Christian Siemers lehrt an der Fachhochschule Nordhausen und der TU Clausthal

(ID:187089)