Abbildung 1: Komponenten des aktiven Routingknotens.
Die Anbindung von rekonfigurierbaren Einheiten kann dabei durch eine lose Kopplung über einen Systembus, aber auch über eine direkte Kopplung an den Prozessorbus stattfinden. Eine lose Kopplung wurde mit Hilfe des am Fachgebiet Schaltungstechnik entworfenen Raptor Prototyping-Systems evaluiert (s. Abb. 2). Das Raptor-System verfügt über alle wichtigen Komponenten, um komplexe Schaltungs- und Systementwürfe zu realisieren. Hierzu kann das Raptor-System über den PCI-Bus betriebssystem- und rechnerunabhängig mit einem Hostrechner gekoppelt werden. Zur Kommunikation der verschiedenen Systemkomponenten auf dem Prototypen-Board wurde ein unabhängiges Multi-Master-Bussystem implementiert, das über einen eigenen Arbiter und eine eigene Speicherverwaltung verfügt. Die rekonfigurierbare Logik kann auf zwei unabhängig konfigurierbaren Xilinx FPGAs implementiert werden, wobei die Funktionalität von bis zu 500.000 Transistoren emuliert werden kann. Der Vorteil dieser Realisierung liegt in der Universalität des Ansatzes. Die Anbindung von Erweiterungskarten über den PCI-Bus wird von allen gängigen Systemen im PC-Bereich und von vielen Systemen im eingebetteten Bereich unterstützt. Als Nachteil ist jedoch die durch den PCI-Bus bedingte hohe Latenz beim Zugriff auf die Prototypen-Karte zu nennen. Die Ausführungsdauer der Erweiterungen auf der Prototypenkarte muß eine gewisse Zeit überschreiten, um die Latenzen beim Zugriff über den PCI-Bus zu rechtfertigen und zu einer Geschwindigkeitserhöhung des Gesamtsystems zu führen.
Abbildung 2: Die Raptor Prototyping-Umgebung.
Um diese Nachteile zu umgehen, wurde eine zweite Prototypenentwicklung vorgenommen, die eine direkte Kopplung zwischen dem Prozessor und der rekonfigurierbaren Hardware ermöglicht (s. Abb.3). Grundlage dieser Umgebung ist eine Platine mit zwei Xilinx FPGAs, die im Gegensatz zu dem Raptor-Board auch als Stand-Alone Version lauffähig ist und über eine größere Anzahl an Verbindungsleitungen zwischen den FPGAs verfügen. Kernkomponente dieses Designs ist ein auf einem FPGA abgebildeter Prozessorkern, der über einen AMBA AHB-Bus an externe Einheiten angebunden ist. Die applikationsspezifische, rekonfigurierbare Einheit kann über den zweiten FPGA direkt an den Prozessor angebunden werden. Weiterhin besteht die Möglichkeit, über eine spezielle Co-Prozessor-Schnittstelle den Befehlssatz des Prozessors um feingranulare Befehle zu erweitern.
Abbildung 3: Prototypenumgebung zur direkten Kopplung von Prozessor und Rekonfigurierbarer Hardware.
Ein untersuchtes Teilgebiet in diesem Zusammenhang ist die Unterstützung von lokalitätsabhängigen Aufgaben innerhalb des Routingknotens durch rekonfigurierbare Logik. Ein Beispiel hierfür ist in Abb. 4 gegeben. Je nach Lage des aktiven Routingknotens innerhalb des gelevelten Netzwerkes werden der rekonfigurierbaren Einheit unterschiedliche Aufgabenstellungen zugeordnet. So kann z.B. ein Knoten an dem Zugang zu einem lokalen Netzwerk den Prozessor um protokollspezifische Aufgabenstellungen entlasten. Sind Sicherheitsaspekte für die Anbindung an die externen Einheiten von Bedeutung, kann in einer weiteren Schicht eine Kryptographie-Einheit eingeführt werden. In Zusammenarbeit mit dem Teilprojekt B1 haben wir untersucht, wie die Komprimierung von Daten durch eine rekonfigurierbare Einheit unterstützt werden kann. Dabei wurden verschiedene Varianten untersucht, die sich durch den Anteil der von dem Prozessor ausgelagerten Funktionalität unterscheiden. Als ein Ergebnis konnte festgestellt werden, daß bereits mit heute erhältlichen feldprogrammierbaren Bausteinen mehrere MByte Daten pro Sekunde effizient komprimiert werden können.
Abbildung 4: Prototypenumgebung zur direkten Kopplung von Prozessor und Rekonfigurierbarer Hardware.
Im Rahmen dieses Projektes wurden analytische Modelle entwickelt und durch umfangreiche Simulationen validiert, die den Flächen und Energieverbrauch von verschiedenen Verbinungsstrukturen abschätzen. Dabei wurden neben Bussen, Multiplexern und geswitchten Verbindungen auch hierarchischen Strukturen untersucht. Im Gegensatz zu anderen Arbeiten beziehen sich unsere Untersuchungen auf Standardzellenentwürfe. Mit Hilfe unserer analytischen Modelle können auf einem hohen Abstraktionsniveau Abschätzungen über den zu erwartenden Energie- und Flächenverbrauch der Verbindungsstruktur einer Schaltung gemacht werden. Eingabeparameter sind die Anzahl der Module, ihre ungefähre Größe und die Breite der Schnittstelle zu der Verbindungsstruktur. Die analytischen Modelle sind durch Simulationen mit einer 0,6 µm Standardzellenbibliothek verifiziert worden.
Abbildung 5: Aufbau der diskreten Prototypen-Umgebung.
Parallel zum Aufbau der diskreten Umgebung wurde bereits mit der Integration des aktiven Routingknotens auf einem hochintegrierten Baustein begonnen. Dabei konnten bereits in diesem Antragszeitraum mehrere Module des aktiven Routingknotens in der Hardwarebeschreibungssprache VHDL implementiert und getestet werden. Die Grundlage der Evaluierung der erzielten Forschungsergebnisse und der Implementierung des aktiven Routingknotens bildet ein zum Motorola M-Core kompatibler Prozessorkern (siehe Abb. 6). Bei dem Prozessorkern handelt es sich um einen 32 Bit RISC Prozessor, der ähnlich wie die ARM-Architektur für den Einsatz in eingebetteten Systemen ausgelegt ist. Sein Befehlssatz ermöglicht aufgrund seiner nur 16 Bit breiten Befehlsworte und seiner konsequenten Load-Store Architektur eine hohe Programmdichte, einen geringen Flächenverbrauch und u.a. dadurch bedingt eine hohe Energieeffizienz. Auf Basis der VHDL-Beschreibung ist es möglich, die Anbindung des Kontrollers an die umgebende Peripherie zu manipulieren und somit verschiedene Architekturprinzipien miteinander zu vergleichen (s. auch Kooperation mit B1). Darüberhinaus ist es auch möglich, den Befehlssatz des Prozessorkerns zu manipulieren und auf die hier vorgestellte Problematik hin zu optimieren. Gemeinsam mit dem Entwurf der Medienzugangsschicht eines Ethernetkontrollers nach dem IEEE 802.3µ-Standard kann bereits zum jetzigen Zeitpunkt eine Teilfunktionalität des aktiven Routingknotens auf einem applikationsspezifischen Baustein integriert werden. Das erfolgreiche Zusammenspiel der beiden Komponenten konnte mit Hilfe der von uns entwickelten Prototypen-Boards nachgewiesen werden.
Abbildung 6: Aufbau des M-Core Prozessor-Kerns.
Als eine weitere Komponente des aktiven Routingknotens haben wir
einen serielle Transceiver entwickelt, der als analoge Komponente im
Full-Custom Verfahren entworfen wurde. Der Transceiver wurde im Rahmen
des Europractice-Programms in einer 0,6 µm Technologie gefertigt. Der
Baustein hat eine maximale Übertragungsrate von 900 MBit/s bei einer
Versorgungsspannung von 3,3 Volt und einer Stromaufnahme von 90 mA.
Der eigentliche Kern des Transceivers hat eine Fläche von nur 410 x
200 µm für den Receiver und von 320 x 530 µm für den Transmitter . Auf
jedem der hochintegrierten Bausteine sind zu Testzwecken zwei
Transceiver integriert, die gemeinsam mit den Anschlußpads eine Fläche
von 10 mm2 einnehmen. Durch seine kompakten Ausmaße und
seinen geringen Stromverbrauch ist er optimal für eine spätere
Integration in den aktiven Routingknoten geeignet.
Die für den Test des Transceivers entworfene Platine (s. Abb. 7) kann
in die am Fachgebiet Schaltungstechnik entwickelte Prototypen-Umgebung
Presto eingebungen werden. Somit ist auch möglich, die Testplatine
in den diskreten Prototypen des aktiven Routingknotens zu verwenden.
Abbildung 7: Transceiver-Baustein auf einer Test-Platine.
Grundlage der Realisierung des Softwaresystems war die Verwendung des pSOS-Betriebssystems für eingebettete Systeme. Die Verwendung eines eingebetteten Betriebssystems auf dem Prototypenboard ermöglichte es uns, bereits zu einem frühen Zeitpunkt in dieser Antragsphase mit der Implementierung von Basisfunktionalitäten zu beginnen. Weiterhin ist es möglich, auf Basis des Betriebssystems die in diesem Teilprojekt für den Prototypen implementierten Algorithmen mit wenig Aufwand auf die hochintegrierte Version des aktiven Routingknotens zu portieren. In diesem Zusammenhang ist nur die Anpassung der Treibermodule notwendig.
Bei der Implementierung wurde ein mehrschichtiges Konzept verfolgt. Auf der untersten Ebene wurden verschiedene Treiber für eigene Hardwarekomponenten entwickelt und ein SCSI-Treiber für unsere Umgebung portiert. Auf dieser Treiberebene aufsetzend wurde die Basisfunktionalität des Datenservers implementiert. Diese umfasst einige der bereits in unserer Simulationsumgebung untersuchten Algorithmen zur Datenplazierung, zum Scheduling und zum Wegefinden.
Die Anbindung an externe Server erfolgt im Rahmen der Zusammenarbeit mit dem Lehrstuhl von Herrn Y. Birk am Technion in Haifa (Israel. Dort wurde eine Schnittstelle in den Linux-Kernel integriert, die Anfragen an die SCSI-Schnittstelle des Rechners auf das lokale Netzwerk und somit an unseren Datenserver umleiten kann. Mit Hilfe dieser Schnittstelle ist es möglich, direkt Blockanfragen an unseren Datenserver zu versenden. Weiterhin haben wir auf unserem Datenserver einen HTTP-Server integriert. Dieser ermöglicht es dem Betreiber des Systems, eine benutzerfreundliche Konfiguration des Datenservers durchzuführen. Desweiteren dient der HTTP-Server als Benutzer- und Monitoringschnittstelle. Auf der Datenserverebene haben wir eine Streamingsoftware aufgesetzt, die es erlaubt, den Datenserver auch als Videoserver zu verwenden. Durch die Verwedung des RTSP-Protokolls ist es möglich, den Videoserver an gängige Abspieleinheiten auf PCs und Unix-Rechnern anzubinden. Die Auswahl und die Steuerung der Videosoftware erfolgt wiederum über den HTTP-Server.
