Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock Internet-on-a-Chip:...
-
Upload
elsie-gess -
Category
Documents
-
view
104 -
download
1
Transcript of Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock Internet-on-a-Chip:...
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Internet-on-a-Chip: The Network is the Computer
Linux-basierte Middlewarefür Networks-on-Chip
Ronald HechtUniversität Rostock, Deutschland
GRK-WorkshopSchwarzenhof, November2005
2Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Überblick
Trends und Motivation
Network-on-Chip (NoC) Anwendungsschicht Entwurfsparadigmen
Rekonfigurierbare Hardware Architekturen Virtuelle Hardware
Linux Erweiterungen Zusammenfassung
3Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Mobile Alleskönner
Mobiltelefon Messaging Web und e-mail Multimedia Spiele!
4Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
System-on-Chip (SoC)
Mix aus Hardware und Software
Viele Systemkomponenten Datenströme
Von Neumann Architektur Flaschenhals
Systembus Speicher
Feste Hardware Große Chipfläche
System-on-Chip Bus
Prozessor
Cache
RF
3DGrafik
Bluetooth
Crypto
Audio
Video
SpeicherMemory
Controller
I/O
5Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Ziele
Kosten Time-to-Market Stromverbrauch Performance Effizienz
Programmierbarkeit Multifunktionalität
Skalierbarkeit Dezentralisierung Datenstromorientierte Kommunikation
6Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Network-on-Chip (NoC)
Skalierbare on-Chip Kommunikation
„Route Packets not Wires“ Dezentralisierung Abstraktion durch
Schichtenmodell
Application Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
7Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Physical und Data Link Layer
Verbindung zwischen benachbarten Routern Verbindung zwischen Router und Ressource
Leitungen, Takt und Fehlerkorrektur
Application Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
8Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Network Layer
Verbindung zwischen entfernten Routern
Schnelles, deterministisches Routing durch das Netz Geographische Adressierung
Application Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
1,1
3,0
9Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Transport Layer
Punkt-zu-Punkt Verbindung zwischen Ressourcen/Prozessen
Verbindungslose und Verbindungsorientierte Dienste Logische Adressierung und Portnummern
15:2
22:2
Application Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
10Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Application Layer
Verbindung zwischen Anwendungen
Anwendungsprotokoll Audio, Video, Crypto, Networking ...
CPU
Crypto
Application Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
11Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Entwurfsparadigmen für NoC-Anwendungen
NoC als Ersatz für SoC-Bus Sockets, Netzwerk-Programmierung Message Passing Remote Procedure Call Verteilte Objektsysteme
Abstraktion
12Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
NoC als Ersatz für SoC-Bus
Dezentralisierung durch Topologie Programmierung wie bisher (Adressen und Daten) Noch immer von Neumann Speicher ist Flaschenhals Nicht Datenstrom orientiert
3D Memory I/O
Video CPU RF
Audio Crypto Bluetooth
13Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
NoC Sockets
Client-Server Architektur Lokaler Speicher Message Passing Datenstromorientierte Kommunikation Dezentralisierung der Datenströme Bessere Lastverteilung im Netzwerk
CPU(Client)
cache
crypto(Server)
local memmem
NoC
connect()send(msg)recv(msg)close()
listen()accept()recv(msg)close()
ClientSocket
ServerSocket
14Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Remote Procedure Call
Auch in Hardware realisierbar Verfeinerung von Schnittstellen Gleichberechtigung von Hardware und Software Verteilung der Rechenlast
NoC
Clientstub
Serverstub
CryptoCore
Message
setKey(key)encrypt(plain)decrypt(cipher)
15Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Objektorientierter Ansatz
„Everything is an Object“ IP Cores sind Objekte IP Cores haben Schnittstellen
Einsatz von UML Einfache Partitionierung in Hardware und Software
+setKey()+encrypt()+decrypt()
«Schnittstelle»ICrypto
+setKey()+encrypt()+decrypt()
-key-someData
CryptoCoresetKey(key)encrypt(plain)decrypt(cipher)
CryptoCore
16Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Remote Method Invocation (RMI)
IP Cores kommunizieren über Nachrichten miteinander Automation durch Interface Description Language (IDL)
Nachrichtenformat Proxy Skeleton
NoC
Proxy Skeleton
CryptoCore
Message
myCore->setKey(key)myCore->encrypt(plain)myCore->decrypt(cipher)
GleicheSchnittstelle
17Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Hardware/Software Entwurf
Grafischer System-Entwurf Komponenten-basiert Manuelle Partitionierung
IDL Compiler Automatische Generierung
der HW/SW-Schnittstelle
Abbildung auf NoC
UML
C++, IDL
HW/SW Partitionierung
C++SystemC
VHDL
Proxy SkeletonMessages
Prozessor(en)
Network-on-Chip
IP Cores
18Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Verteiltes Objektsystem
IP Cores sind im NoC verteilt Verteilte Objekte, Entfernte Referenzen
Verwendung der Module wird durch Middleware vereinfacht
Client Application
Proxy
Naming Service
Application Protocol
IP Core LookupService
Remote References
NoC Transport Layer
Hardware
IP Core
Skeleton
Application Protocol
Software
19Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Code Beispiel AES Crypto Core
// Referenz auf AESCore deklarieren
AESCoreRef myAESCore;
// Explizites Binden mit AESCore
// Lokalisieren des AESCore im NoC
myAESCore = AESCore::getInstance();
// Remote Method Invocation
myAESCore->setKey(aKey);
aCypher = myAESCore->encrypt(aMessage);
// Explizites Trennen vom AESCore
myAESCore->releaseInstance();
20Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Linux-Integration
Debian Linux – Kernel 2.6.9
Kernel
User Space
HAL
NoC Transport Layer
NoC Object System
Application
NoC Device Driver
TUN/TAP
SystemC NoC Model
BSD Socket APIsocket()
21Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
NoC Device
22Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
NoC – Zusammenfassung
Dezentralisierung und Verteilung Kommunikation Rechenlast
Abstraktion der Kommunikation Objektorientierung UML-Entwurf von Hardware und Software Automation durch IDL
Vereinfachung Keine Treiber, sondern Anwendungsprotokolle
23Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Hardware oder Software ?
Hardware Parallele Verarbeitung – Datenfluss-Dominiert Hohe Effizienz Fest verdrahtet, Für eine Anwendung
zugeschnitten Hohe Kosten, Kompliziert, Hohes Risiko
Software Sequentielle Verarbeitung – Kontrollfluss-Dominiert Niedrige Effizienz Programmierbar Multifunktional Niedrige Kosten, Geringes Risiko
24Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Rekonfigurierbare Hardware
Field Programmable Gate Arrays (FPGA) Programmierbare Hardware Logik und Verbindungen konfigurierbar Virtueller ASIC
Prozessor
FPGA
ASIC
Effizienz
Flex
ibili
tät
25Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Vorteile
Hoher Abstraktionsgrad Schneller Entwurfszyklus Geringes Risiko
Hardware-Updates „Bananaware“ Time-to-Market
26Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Aktuelle FPGAs
Mix aus Logik und Leitungen Speicher Prozessoren und Hardmacros
Pow
erPC
Pow
erPC
GigaBitTransceiver
I/O
RAMMultiplier
Logic
ConfigurableLogic Block
SwitchMatrix
27Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
FPGAs der Zukunft (Ausblick)
Festverdrahtetes NoC Hardmacros im NoC integriert Tiles mit Logik und Speicher I/Os über dem gesamten Chip verteilt
Reconfig
CPU ReconfigEthernet
MAC
CPU
GigaBit Transc
GigaBit Transc
GigaBit Transc
Reconfig
Reconfig Reconfig
ReconfigGigaBit Transc
GigaBit Transc
GigaBit Transc
Ethernet MAC
28Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Partielle dynamische Rekonfiguration
Rekonfiguration der Tiles zur Laufzeit Einspielen von Updates Virtuelle Hardware
Mehrfachnutzung von Chipfläche Hardware-Swapping
Fragestellungen Physikalische Verbindungen Logische Verbindung Relokation Sichern des Zustands
29Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Betriebsystem für Virtuelle Hardware
Verwaltung der rekonfigurierbaren Chipfläche Selbstrekonfiguration Virtualisierung, Vereinfachung
CPU
Betriebssystem für virtuelle Hardware
VerwaltungTiles + NoC
Dynamische Rekonfiguration
Middleware
30Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
NoC und Dynamische Rekonfiguration
Feste physikalische Schnittstellen zwischen Tile und NoC
Logische Punkt-zu-Punkt Verbindung zwischen Prozessen
Tile 2,0 Tile 3,0
Physikalische Adresse
IP Core 5Prozessor 0 LogischeAdresse
Prozess 12
Prozess 13
Prozess 32
Prozess 1
Prozess 2Port
0:12 (2,0) – 5:1 (3,0)
31Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Relokation
Zur Realisierung von IP Core-Swapping Zwischen Tiles Zwischen Tiles und Software
CPU
AES Core
AES Core
3DCore
32Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Accelerators und Decelerators
Accelerator Hardware-Implementierung Wird in Tile geladen Schnell
Decelerator Software-Implementierung (Emulator) Läuft auf Prozessor Wenn kein Tile (mehr) vorhanden Wenn Beschleunigung nicht nötig ist
Reconfig
CPU
33Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Sichern des Zustands
Objektorientierter Ansatz „Serialisieren“ von IP Cores
Verpacken der Attribute
Nur zwischen atomaren Operationen erlaubt
Nicht alle Speicherele-mente des IP Cores
Erweiterung der IP Core Schnittstelle
+setKey()+encrypt()+decrypt()
«Schnittstelle»ICrypto
+setKey()+encrypt()+decrypt()+start()+stop()+reset()
AESCore
+start()+stop()+reset()
«Schnittstelle»IReloc
34Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Verteiltes Objektsystem
Erweiterung um Allokation und Deallokation IP Core Loader startet
Decelerators Accelerators
Client Application
Proxy
Naming Service
Application Protocol
IP Core LookupService
NoC Transport Layer
FPGA
IP CoreAccelerator
Skeleton
Application Protocol
Software
IP Core Loader
IP CoreDecelerator
Skeleton
Application Protocol
35Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Codebeispiel – Dynamische Rekonfiguration
AESCoreRef myAESCore;
// Explizites Binden mit AESCore
// Initialisieren des Decelerators
// Eventuelles Laden des Accelerators
myAESCore = AESCore::getInstance();
// Remote Method Invocation
myAESCore->setKey(aKey);
aCypher = myAESCore->encrypt(aMessage);
// Explizites Trennen vom AESCore
// Decelerator und Accelerator entfernen
myAESCore->releaseInstance();
36Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Implizites Binden
{
AESCoreRef myAESCore;
// Implizites Binden mit AESCore
// Decelerator und Accelerator laden
// Remote Method Invocation
myAESCore->setKey(aKey);
aCypher = myAESCore->encrypt(aMessage);
// Implizites Trennen vom AESCore
// Decelerator und Accelerator entfernen
}
37Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
IP Core Scheduler und Dispatcher
Faire Zuteilung der Chipfläche Scheduler nutzt
Priorität IP Core-Auslastung Netzauslastung
Trifft Entscheidungen
Dispatcher führt sie aus Laden des Accelerators oder Decelerators Relocation NoC Konfiguration
38Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Linux Erweiterungen
Debian Linux – Kernel 2.6.9
Kernel
User Space
HAL
BSD Socket APIsocket()
NoC Transport Layer
Application + IP Cores
TUN/TAP
SystemC FPGA Model
NoC Object System
IP Core Loaderexec()
IP Core SchedulerIP Core Dispatcher
NoC Device Driver FPGA Device Driver
Char Device
39Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Erweiterung des /proc-Dateisystems
40Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Entwurfsprozess
Manuelle Partitionierung IDL-Compiler
Decelerator aus Software-Implementierung
Accelerator durch Verfeinerung der Implementierung
UML
C++, IDL
HW/SW Partitionierung
C++
DeceleratorsSoftware
SystemCVHDL
Accelerators
Prozessor(en)
Dynamisch Rekonfigurierbares System
IP Cores
41Ronald Hecht, November 2005
Institut für Angewandte Mikroelektronik und Datentechnik, Universität Rostock
Zusammenfassung
Überblick über NoC-Anwendungsschicht Dynamische Rekonfiguration von Hardware
Verteiltes Objektsystem Hohes Potential zur Automation Keine Treiber sondern Anwendungsprotokolle
Linux-Integration FPGA-Modell