Effizientes Codesign und Prototyping auf Java-Basis

<BODY> <H1>www.duv24.net : Effizientes Codesign und Prototyping auf Java-Basis</H1> <P> <BR> [<A href="/">www.duv24.net</A>] [<A href="../index.html">back</A>] </P> <TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0> <TR> <TD VALIGN=top> <TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0> <TR> <TD VALIGN=TOP CLASS=detailBereichRedaktion>Bereich > Redaktion > <B><FONT color="#CC3300">Fachbeiträge</FONT></B></TD> <TD ALIGN=right VALIGN=bottom CLASS=detailDatum>18.11.2000</TD> </TR> </TABLE> </TD> <TD VALIGN=top> </TD> <TD VALIGN=top> </TD> </TR> <TR> <TD VALIGN=top CLASS=detailFirma ID=topSpace>Infineon Technologies AG:</TD> <TD VALIGN=top> </TD> <TD VALIGN=top> </TD> </TR> <TR> <TD VALIGN=top CLASS=detailTitel>Effizientes Codesign und Prototyping auf Java-Basis</TD> <TD VALIGN=top> </TD> <TD VALIGN=top> </TD> </TR> <TR> <TD VALIGN=top CLASS=detailSubtitel>Neue Entwicklungsumgebung ermöglicht das Design von dynamisch rekonfigurierbaren Systemen</TD> <TD VALIGN=top> </TD> <TD VALIGN=top> </TD> </TR> <TR> <TD VALIGN=top> <TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0> <TR> <TD VALIGN=top CLASS=detailContent>Erschienen in DESIGN&VERIFICATION 0/2000, S. 75<BR><BR>Weitere Autoren:<BR>Prof. Dr. KLAUS BUCHENRIEDER, Infineon Technologies AG<BR>Dr.-Ing. JOSEF FLEISCHMANN, Siemens AG<BR><BR><BR>Vorwort<BR><BR>Die wachsende Funktionalität und Komplexität zwingt Design-Teams vermehrt dazu, Hardware/Software-Codesign-Konzepte zu verwenden, um mit den steigenden Anforderungen schritt zu halten. Diese neuen Methoden müssen die Entwicklung von Systemen unterstützen, die zwar zum Großteil in Software implementiert, aber auch durch rekonfigurierbare Hardware-Komponenten erweitert werden. Hier wird eine Methode beschrieben, die eine Antwort auf diese Anforderungen liefert. JaCoP (Java-based Codesign and Prototyping) ist eine portable Java-basierte Codesign-Umgebung, welche Spezifikation, Co-Synthese und Prototyping von ASPPs unterstützt.<BR><BR><BR><BR>Im Allgemeinen ist die Unterstützung für den Entwurf und die Programmierung dynamisch konfigurierbarer Hardware/Software-Systeme noch nicht ausreichend. Da diese Systeme jedoch immer mehr an Bedeutung gewinnen und rekonfigurierbare Komponenten zu integralen Bestandteilen innovativer eingebetteter Systeme werden, hat Infineon zusammen mit der Technischen Universität München eine Entwicklungsumgebung für eingebettete Systeme entwickelt, die dynamisch rekonfigurierbare Elemente enthalten, entwickelt. Als Spezifikationssprache für alle Systemkomponenten und als Implementierungssprache für die Systemsoftware wird Java verwendet. Java ermöglicht durch seine Plattformunabhängigkeit, dass Anwendungen nur einmal geschrieben werden, um dann auf vielen Plattformen zu laufen (write once – run everywhere). Diese Unabhängigkeit wird durch die sogenannte Java Virtual Machine (JVM) erreicht. Diese Virtual Machine arbeitet den Java-Bytecode, also kompilierten Java-Quellcode ab. Durch die Objektorientierung von Java lassen sich komplexe Systeme, die mehrere parallele Threads enthalten, strukturiert entwickeln und rasch prototypisch realisieren. <BR>Ein Problem stellen jedoch Echtzeitsysteme dar, da Java nicht direkt zur Spezifikation oder Realisierung von Anwendungen mit harten Echtzeitbedingungen ausgelegt ist. Java bietet aber bei Verwendung speziell entwickelter Klassenbibliotheken die Möglichkeit, zeitkritische Funktionen in einer festgelegten Zeit abzuschließen. Sogenannte Realtime-Erweiterungen gestatten den Einsatz von Java für die meisten Anwendungen, die nur ‚weichen‘ Echtzeitbedingungen genügen müssen. <BR><BR>Spezifikation und Synthese<BR><BR>Der Designablauf des JaCoP-Codesign-Systems kann wie folgt zusammengefasst werden (Abb. 1). Am Anfang des Prozesses steht initiale Beschreibung in Java. Diese Spezifikation wird mit typischen Eingabedaten ausgeführt, so dass ein Ausführungsprofil erstellt werden kann (profiling). Dieses Profil wird analysiert und unterstützt somit den Designer bei der Auswahl, welche Teile der Applikation in Software und welche in Hardware abgearbeitet werden sollen. Die kleinste Einheit dieser zu verschiebenden Teile sind Funktionen, in Java ‚Methoden‘ genannt. Funktionen, die in Hardware ablaufen sollen, werden in eine Hardwarebeschreibungssprache, hier VHDL, konvertiert und mit Hilfe von High-level- und Logiksynthesewerkzeugen (Hardware-Synthese) synthetisiert. Vorgefertigte Hardwarekomponenten werden in einer Datenbank als parametrisierbare VHDL-Module gespeichert. Aus allen Funktionen wird mittels eines Java-Compilers Bytecode erzeugt, unabhängig davon, ob sie in Software oder Hardware ausgeführt werden. Der Bytecode aller Methoden der ursprünglichen Spezifikation wird in einem Software-Pool gespeichert. Alle Kandidaten die für eine Implementierung in rekonfigurierbarer Hardware in Frage kommen, werden in einem Hardware-Pool gespeichert. Dabei werden sowohl die FPGA-Konfigurationsdaten als auch die Interface-Informationen gespeichert. Das Laufzeitsystem bildet die Schnittstelle zur Entwicklungsplattform. Außerdem liefert es Profiling-Daten an den Benutzer zurück. Somit kann die Partitionierung der partiell in der Hardware und partiell in der Software ablaufenden Applikation kontinuierlich verbessert werden.<BR><BR>Zielsystem<BR><BR>Zielsysteme der JaCoP-Entwurfsumgebung sind Mikrocontroller mit eingebettetem FPGA. Das FPGA kann hierbei sowohl statisch als auch dynamisch programmierbar sein. Weiterhin kann der Mikrocontroller noch beliebig viele andere nicht-programmierbare Peripherals besitzen. Derartige Systeme werden allgemein als ASSPs (Application Specific Standard Products) bezeichnet. Die programmierbare Logik kann beispielsweise auch sogenannte Softperipherals, also konfigurierbare Erweiterungsblöcke, implementieren.<BR>In Abbildung 2 ist ein Prototyp eines solchen Systems zu sehen, für das die JaCoP-Umgebung konzipiert ist: Ein 16-bit-Microcontroller von Infineon wird über entsprechende Adress- und Datenleitungen mit einer FPGA-Plattform verbunden. Auf dem Mikrocontroller läuft eine Java Virtual Machine, die den Bytecode, also die Software-Methoden interpretiert. Auf der FPGA-Plattform werden die Hardware-Methoden abgearbeitet.<BR>Entwicklungsplattform von JaCoP ist ein Linux-PC mit einer ‚XC6200DS‘-PCI-Karte. Die Karte besteht aus einem PCI-Interface, einem dynamisch rekonfigurierbaren FPGA ‚XC6216‘, sowie zwei MBytes statischem Speicher. Ein herausragendes Merkmal des dynamisch rekonfigurierbaren FPGAs (DPGAs) ist dessen Prozessorinterface, mit dem jedes Register der Hardware direkt über einen Adress- und Datenbus angesprochen werden kann. Dadurch wird der Datentransfer zwischen Prozessor und DPGA sehr komfortabel. Der Hardware-Wrapper kann somit zur Laufzeit jedes DPGARegister schreiben oder lesen.<BR><BR>Laufzeitsystem<BR><BR>Die Interaktionen zwischen Hardware- und Software-Komponenten bei der Ausführung des Systemprototypen sowie der Rekonfigurationsprozess werden vom Laufzeitsystem (Abb. 3) gesteuert. Das Laufzeitsystem plant die Ausführung der Methoden. Software-Methoden werden auf der Virtual Machine des Linux-PCs ausgeführt, während Hardware-Methoden auf einer rekonfigurierbaren DPGA-Hardwareerweiterung ausgeführt werden. Die Planung der Ausführung (scheduling) hängt von dem dynamischen Verhalten der Applikation und von der vom Designer gewählten Partitionierungstabelle ab. Im Gegensatz zu herkömmlichen FPGA-basierten Prototypingsystemen ist die Ausführung hier ein sehr dynamischer Prozess. Die Ausführung wird vom Softwareanteil bestimmt, der auf einer Virtual Machine läuft. Immer wenn der Kontrollfluss eine Hardwaremethode erreicht, bestimmt das Laufzeitsystem, ob das entsprechende Konfigurationsfile schon auf das DPGA geladen ist. Falls nicht, wird es ein freies DPGA aussuchen und die benötigte Funktionalität laden. Falls nur eine partielle Rekonfiguration notwendig ist, so wird nur diese durchgeführt.<BR>Es gibt prinzipiell zwei alternative Ansätze für die Realisierung des Laufzeitsystems: Im ersten Ansatz wird die Virtuelle Maschine erweitert, während alternativ dazu die Hardware/Software Schnittstelle auch über native Methoden realisiert werden kann.<BR><BR>Ergebnisse<BR><BR>Um den Overhead, der durch die Kommunikation zwischen Prozessor und FPGA entsteht, zu minimieren, wurden einige Optimierungen entwickelt, die im Wesentlichen den Rekonfigurationsvorgang des FPGAs betreffen. Ungefähr 78% der Zeit wird in der Virtual Machine und den Devicetreibern für das Ansprechen der Hardware benötigt. Die Ausführung eines Designs auf der DPGA-Karte inklusive der Kommunikation über den PCI-Bus beträgt etwa 22% der Zeit. Daraus folgt, dass ein Geschwindigkeitsvorteil einer Hardware/Software-Implementierung hauptsächlich dann erzielt wird, wenn die in Hardware ausgelagerte Funktion eine signifikante Komplexität hat. Bei zu geringer Komplexität wird der Kommunikationsoverhead zu groß. <BR><BR>Beispiel:<BR><BR>Am Beispiel eines Algorithmus für Fehlererkennung und -korrektur wird im folgenden die Leistungsfähigkeit untersucht: Hamming-Codierer werden normalerweise in Zusammenhang mit anderen Codierern für die Erkennung von Einzelbitfehlern und deren Korrektur genutzt. Der Codierer als auch der Decodierer wurden auf der DPGA-Karte implementiert. Durch die speziellen Operationen auf Bitebene wird ein deutlicher Geschwindigkeitsvorteil der Hardware/Software-Implementierung gegenüber der reinen Software-Implementierung erreicht. Die entsprechenden Performance-Zahlen zeigt Abb. 4. Die erste Säulengruppe zeigt die Ausführungszeit für eine De- und eine Kodierung mit dem modifizieten JaCoP-Interpreter (JVM1). Die zweite Säulengruppe benutzt die gleiche Virtuelle Maschine (JVM1), allerdings läuft die Kommunikation über das in JaCoP integrierte native Interface. Man erkennt hier einen Geschwindigkeitsnachteil der zweiten Implementierung. Allerdings kann wegen der Unabhängigkeit der benutzten Virtual Machine eine optimierte Virtuelle Maschine (JVM2) eingesetzt werden. Dies ist in der dritten Säulengruppe gezeigt. Sowohl die reine Softwarelösung als auch die Hardware/Software-Lösung sind nun erheblich schneller. Das Verhältnis der Geschwindigkeiten dieser Lösungen, also die erzielbare Beschleunigung bleibt nahezu gleich.<BR><BR>Perspektiven<BR><BR>Der Aufbau der JaCoP-Entwicklungsplattform mit der ‚XC6200DS‘-PCI-Karte ermöglicht bemerkenswerte Ergebnisse. Dies ist insbesondere auf die dynamisch rekonfigurierbare Logik zurückzuführen. Dadurch lassen sich während der Laufzeit neue Funktionen als Schaltungsteile realisieren und als in Hardware realisierter Algorithmus nutzen. Der entscheidende Vorteil ergibt sich durch daten- oder programmabhängige dynamische Veränderungen der Unterstützungshardware. Trotz der Möglichkeit immer neue Funktionen während des Betriebs nachladen zu können, reicht die Zahl der verfügbaren Gatter auf einer XC6200DS-Karte oft nicht aus, um eine hinreichend komplexe Funktion, z.B. MPEG-Decoder auszulagern. Die Zerlegung in mehrere funktionale Teilstücke, die nacheinander geladen werden, ist nicht sinnvoll, da die Performanz der Anordnung durch viele zusätzliche Kopiervorgänge für Variablen, Werte und Konfigurierungsstrings stark sinkt. Abhilfe schafft hier entweder die Verteilung der Berechnung auf mehrere rekonfigurierbare Einheiten in einem oder mehreren Rechnern oder der Einsatz von größeren FPGAs. Hierzu bietet sich z.B. der Single-Board-Emulator ‚RC-1000PP‘ der Firma Embedded Solutions. mit 150.000 Gatteräquivalenten an, auf dessen Speicherblöcke das ‚XC4150‘-FPGA direkt und der Host-PC über ein schnelles PCI-Interface vollständig zugreifen kann. Der Speicher auf dem RC-1000PP umfasst vier Speicherbänke zu je 2 MByte, die sowohl für Daten als auch für Teststimuli genutzt werden kann. <BR>Zur Optimierung von Hardware- und Softwareteilen sowie zur Beobachtung von Signalen führt man Verbindungen zu externen Sensoren oder einem ‚HP16702A‘-Logikanalysator am zweckmäßigsten über den 50 Pin ‚AUX-IO‘-Port der Emulatorkarte. Dieser Port kann auch zum Debugging des Systemverbunds bestehend aus Software und Hardware genutzt werden. <BR>Die Möglichkeit, den Status der ausgelagerten Funktion genau beobachten zu können ist von besonderem Interesse. Denn durch die Zusammenarbeit mit Prozessoren die On-chip-Debugging unterstützen, wie beispielsweise dem Infineon Tricore mit Level 2 OCDS, kann nun auch in der Hardware/Software Tradeoff-Analyse die Performance der ausgelagerten Algorithmen mit bestimmt werden. Somit lassen sich sehr leistungsfähige eingebettete Systeme entwerfen und in realen Umgebungen validieren.<BR><BR></TD> </TR> <TR> <TD CLASS=detailQuelle> </TD> </TR> </TABLE> </TD> <TD WIDTH=28 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=1 HEIGHT=1 ALT=""></TD> <TD WIDTH=174 VALIGN=top></TD> </TR> <TR> <TD VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=393 HEIGHT=1 ALT=""></TD> <TD WIDTH=28 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=28 HEIGHT=1 ALT=""></TD> <TD WIDTH=174 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=174 HEIGHT=1 ALT=""></TD> </TR> </TABLE> <P><I>Diese Seite wurde am 25.09.2004, 13:11 Uhr aktualisiert</I></P> </BODY>