Erstmal vorweg: Ich bin absoluter Anfänger was Computer-Hardware betrifft. Ich hab eine grundlegende Ahnung von boolescher Algebra und hab theoretisch auch was über Flip-Flops, D-Latches etc. gelernt, aber das war's auch schon und mein Wissen ist ein wenig eingerostet. Kürzlich bin ich in einer Diskussion auf FPGAs gestoßen und das Konzept hat mich fasziniert. Nicht nur, weil sie ermöglichen, jede beliebige Schaltung als Software zu implementieren, sondern auch, weil sie ermöglichen, diese Schaltungen dynamisch zu implementieren. Wenn ich das Recht verstehe, wäre es theoretisch möglich, das FPGA je nach Verwendungszweck zu modifizieren. Ja, theoretisch. Praktisch gibt es da allerdings einige Probleme, auf die ich noch keine expliziten Antworten gefunden habe. Erstmal: Wie viel "kostet" es, das FPGA umzuprogrammieren? Wie oft muss eine bestimmte Schaltung genutzt werden, damit sie diese umprogrammierung wert ist? Beispiel: Ich habe ein Programm. Dieses Programm sei nun zu "lang", um in einem Rutsch auf dem FPGA implementiert zu werden. Ist es nun effizient, das Programm aufzuteilen und nach der Ausführung des ersten Teils den zweiten zu laden? Oder lohnt es sich erst, die Schaltung zu laden, wenn ich sie X mal nutze? Noch ein wichtiger Aspekt: Kann ich das FPGA nur als ganzes programmieren, oder kann ich auch nur einzelne Bereiche beeinflussen? Könnte ich das FPGA quasi in autonome FPGAs aufteilen, die verschiedene Tasks erfüllen und unabhängig voneinander veränderbar sind? Ist es weiterhin für das FPGA möglich, sich selbst umzuprogrammieren? Noch ein Problem: Es scheint, dass die Software zum erstellen von "binaries" für FPGAs proprietär ist. Ist es somit unmöglich, einen Open Source "Compiler" für ein bestimmtes FPGA target zu schreiben? Müsste sämtlicher Code, bevor er distributed werden kann, mit einem proprietären Programm verarbeitet werden? Diese Fragen stelle ich deshalb: Wenn oben genannte Dinge möglich sind, so wäre es ja möglich, eine Art Betriebssystem zu entwerfen, welches, mithilfe eines aufwendigen "Managers", Code effizient ausführen kann, indem es "Schaltungsstrecken" je nach Bedarf modifiziert und so Programme effizient und synchron ausführt. Zumindest scheint mir das das Potential einer derartigen Technologie zu sein, wenn es auch scheint, dass FPGAs meist nur als "statische" Schaltungen betrachtet werden, die man eben erstellen kann, ohne gleich an der Hardware rumzubasteln.
Von den Spezialwünschen (zb sich selbst programmierendes FPGA, eine Hälfte der Schaltung ausführen, dann die andere) sehe ich nicht, wie die allgemein implementierbar sein sollen. Vom Zusammenschalten von fixer Logik und programmierbarer Logik, die je nach Aufgabenlage umkonfiguriert wird, habe ich schon gehört, das Problem das mir dabei aber genannt wurde war, dass das Neukonfigurieren so lange braucht, dass der Geschwindigkeitsvorteil durch die angepasste Schaltung beim Neukonfigurieren schon wieder verloren geht.
> Ist es nun effizient, das Programm aufzuteilen und nach der Ausführung > des ersten Teils den zweiten zu laden? Kauf ein FPGA, das groß genug ist ;-) Die (teilweise) Rekonfiguration von FPGAs ist nicht so trivial, wie z.B. das Laden und Starten eines Programms. Es hat schon bei Transputern nicht so richtig funktioniert, parallele Prozesse zu beschreiben und automatisch aufzuteilen... > Müsste sämtlicher Code, bevor er distributed werden kann, mit einem > proprietären Programm verarbeitet werden? Er müsste nicht, er muss. Der Synthesizer ist nicht proprietär, die nachfolgenden Designschritte Translate, P&R schon, und zudem vom Ziel-FPGA und dessen Derivaten (Ausstattung, Pinout,...) abhängig. > Ist es somit unmöglich, einen Open Source "Compiler" für ein bestimmtes > FPGA target zu schreiben? Diesen Schuh wird sich niemand antun (wollen). Und falls doch: bis die Konfigurationsdaten aufgeschlüsselt sind und ein P&R von dritter Seite existiert, ist das FPGA veraltet. Und wehe, der FPGA-Hersteller dreht irgend ein Bit rum... > Wenn oben genannte Dinge möglich sind, so wäre es ja möglich... Ah, der Konjunkitv, ich liebe ihn ;-) > ... eine Art Betriebssystem zu entwerfen, welches, mithilfe eines > aufwendigen "Managers", Code effizient ausführen kann, indem es > "Schaltungsstrecken" je nach Bedarf modifiziert und so Programme > effizient und synchron ausführt. Der Vorteil eines FPGAs ist m.E. derzeit genau der, dass es kein (fehlerbehaftetes und undurchschaubares) Betriebssystem gibt, das zur Selbstverwaltung die meisten Ressourcen verschlingt. > Zumindest scheint mir das das Potential einer derartigen Technologie > zu sein... Hat eigentlich jemand nochmal was von Fuzzy-Logic gehört?
Ah, OK. Ich nehme an, ich hatte ein falsches Bild von FPGAs(erklärt auch, warum ich zu dem, was ich sagte, keine expliziten Erklärungen fand, schlichtweg, weil's nicht geht). Es ist also effizienter, häufig genutzte Schaltungen einmalig auf das FPGA zu laden. Somit müssen alle Arbeitsschritte, die ich für einen bestimmten Task brauche, bereits auf dem FPGA enthalten sein. Ich könnte höchstens zwischen verschiedenen Tasks das FPGA neu laden - Die Binaries müssten allerdings schon vorher fertig sein, können also nicht "Just in Time" zusammengesetzt werden.
> Ich könnte höchstens zwischen verschiedenen Tasks das FPGA neu laden - Ja, das ginge, allerdings dauert es eine gewisse Zeit... Man kann FPGAs auch teilweise rekonfigurieren, aber da muß man schon sehr genau über das verwendete FPGA Bescheid wissen. > Die Binaries müssten allerdings schon vorher fertig sein, können also > nicht "Just in Time" zusammengesetzt werden. Richtig, in den Konfigurationsdaten sind ganz elementare Verbindungen beschrieben, die nicht einfach irgendwo hingeladen und dort "ausgeführt" werden können (im Gegensatz z.B. zu einem Programm im Speicher eines Computers).
> Wenn ich das Recht verstehe, wäre es theoretisch möglich, das FPGA je nach > Verwendungszweck zu modifizieren. Ist es auch. Das Thema ist aktuelles Forschungsgebiet. > Erstmal: Wie viel "kostet" es, das FPGA umzuprogrammieren? Größenordnungsmäßig 1 Sekunde (Spartan-3 1000). > Ist es nun effizient, das Programm aufzuteilen und nach der Ausführung > des ersten Teils den zweiten zu laden? Oder lohnt es sich erst, die Schaltung zu > laden, wenn ich sie X mal nutze? Dazu musst du die entsprechenden Parameter kennen: Kann man das Programm überhaupt aufteilen? In wie große Brocken? Passen diese in den FPGA? Wie lange dauert die Ausführung der Teile? usw. > Noch ein wichtiger Aspekt: Kann ich das FPGA nur als ganzes > programmieren, oder kann ich auch nur einzelne Bereiche beeinflussen? > Könnte ich das FPGA quasi in autonome FPGAs aufteilen, die verschiedene > Tasks erfüllen und unabhängig voneinander veränderbar sind? Bei Bestimmten Modellen der Firma Xilinx: ja. Das ist aber in der Praxis nicht ganz ohne. Bei der Konkurrenz (Altera) hält man diese Teilprogrammierung soweit ich weiß für eine schlechte Idee. Kann aber sein dass das veraltetes Wissen ist. Ansonsten bleibt dir selbstverständlich noch die Möglichkeit, eine Schaltung aus mehreren FPGAs aufzubauen. > Ist es weiterhin für das FPGA möglich, sich selbst umzuprogrammieren? Viele FPGAs können grundsätzlich sich selbst (ganz) programmieren, also wird da wohl auch Teilprogrammierung gehen. Soll heißen, bei den meisten FPGAs ist ein fester Sub-schaltkreis eingebaut, der die Programmierung aus einem externen Speicher ziehen kann. Kommt auch etwas auf die Wahl des Konfigurationsspeichers an. Ob bei Teilprogrammierbaren FPGAs ein Teil den anderen umprogrammieren kann weiß ich leider nicht. Falls in der Praxis Probleme auftauchen, ist dieser Punkt aber nebensächlich. In vielen Schaltungen werden einfache externe Steuerchips zum Programmieren von FPGAs verwendet - damit kann man im Zweifel alle Probleme erschlagen. (Diese Steuerchips werden oft mit CPLDs, dem "kleinen Bruder" des FPGA, realisiert) > Noch ein Problem: Es scheint, dass die Software zum erstellen von > "binaries" für FPGAs proprietär ist. Ist es somit unmöglich, einen Open > Source "Compiler" für ein bestimmtes FPGA target zu schreiben? Müsste > sämtlicher Code, bevor er distributed werden kann, mit einem > proprietären Programm verarbeitet werden? Kurze Antwort: ja.
>> Erstmal: Wie viel "kostet" es, das FPGA umzuprogrammieren? >Größenordnungsmäßig 1 Sekunde (Spartan-3 1000). Dies gilt nur für das komplette FPGA, und hängt auch von der Programmierschnittstelle ab. Die Xilinx Virtex haben einen interernen Programmierport mit dem sich das FPGA selbst neu programmieren kann. Um Teile des FPGAs auszutauschen werden hier nur wenige ms benötigt. Es gibt zb. ein Projekt, bei dem für eine Bildbearbeitung von Videodaten zwischen zwei Frames neu konfiguriert wird (Austausch von Filtern, bzw. Teilen davon). Leider ist partielle dynamische Rekonfiguration ein ziemliches Gefrickel, deswegen wird sowas bevorzugt in Studien- und Diplomarbeiten gemacht. Ein spannendes Thema ist es auf jeden Fall.
Einer von Xilinx hat zur partiellen Rekonfiguration gemeint, dass das eine Lösung für ein noch zu findendes Problem wäre. Und das war ~1998 rum. Wesentlich weitergekommen ist man inzwischen auch nicht :-)
Naja, ist zwar ein interessanter Ansatz, aber eben ein sehr akademischer. Da müsste sich ja schon die Struktur der Datenverarbeitung grundlegend ändern. Wenn man beispielsweise "nur" die Filter ändern will, tauscht man den Inhalt des BlockRams für die Koeffizienten und ggf. ein paar Konfig-Bits irgendwo aus. Ich hab da auch immer noch von konstruierten akademischen Problemen gelesen, eine sinnvolle Anwendung einer partiellen Rekonfiguration wüsste ich jetzt auch nicht.
Xilinx würde die "partial reconfiguration" durchaus mehr pushen, 'scheut' sich andererseits jedoch, die dazu benötigte "manpower" (vor allem bei der Erstellung/Verbesserung der notwendigen software-tools) zu investieren: es hat sich bisher kein "Großkunde" (>10 Mio Umsatz/Jahr) gefunden, der a) eine Anwendung für das feature hat b) bereit ist, ein Kundenprojekt auf Software (-> Xilinx) aufzubauen, die den Forschungsstatus noch nicht verlassen hat c) das dahinter liegende (ressourcen-) Problem nicht irgendwie anders in den Griff bekam Also das typische Henne-Ei-Problem Gruß
http://www12.informatik.uni-erlangen.de/research/?PHPSESSID=v42hpqk00ftbmn35vuu2lku6m3 die beschäftigen sich u.a. mit partieller dynamischer Rekonfigurierbarkeit ;)
> ... informatik.uni ...
Genau auf dieser Ebene bewegt sich die ganze Geschichte: es muß erst mal
eine anständige und allgemein anerkannte Theorie zur Thematik entwickelt
werden, dann kann die Entwicklung des Themas an sich beginnen...
Geht schon konkreter: An der TUM (in Kooperation mit BMW) wird an der Sache ganz konkret geforscht. Es geht dabei um Software-defined-Radio (SDR) Applikationen. Wegen sich oft ändernder Standards ist Rekonfigurierbarkeit ohnehin gewünscht, aber es wird noch einen Schritt weitergegangen. Nach und nach werden die einzelnen Stufen des Empfängers/Senders in den FPGA getauscht, also in etwa: - Filtermodul in den FPGA laden - einkommende Daten Filtern -> in den RAM - Tausche Filter gegen FFT-Modul - lese gefilterte Daten aus RAM, berechne FFT, schreibe wieder in RAM - Tausche FFT gegen Demodulatormodul - ...usw. mit Mixer, Viterbi-Dekoder, Deinterleaver, Energy-Disperser etc. In einer praktischen Applikation (DAB-Receiver) wurde ermittelt, dass eine Tauschrate von ca. 50Hz optimal ist. Der Resourcenbedarf ist geringer (!) als bei einer herkömmlichen Implementierung. Genau nachlesen kann man das ganze hier: http://www.lis.ei.tum.de/fileadmin/downloads/publications/WSR08_DPR_for_SDR.pdf
Die Uni Karlsruhe forscht auch an solchen Dingen (ich hoffe ich gebe das einigermaßen korrekt wieder, habe da nicht einen kompletten Überblick): Es werden Hot-Spots in Anwendungen durch Special Instructions (also dafür optimierte HW-Blöcke) eines ASIP (Application Specific Instruction Set Processor) implementiert. Diese Special Instructions (hier Moleküle genannt) werden wiederum aus einzelnen Hardware Blöcken (Atomen) zusammengesetzt. Hierbei können dynamisch zur Laufzeit neue Moleküle erzeugt werden indem die entsprechenden Bereiche des rekonfigurierbaren FPGA (Virtex-II / Virtex-IV) neu konfiguriert werden (Atome) - und zwar zur Laufzeit. Dazu muss man aber noch Modelle entwickeln um entscheiden zu können ob sich eine solche Rekonfiguration (kostet Zeit und Power etc. ) überhaupt lohnt, und entsprechend überlegt werden ob man auf Speed oder Low-Power ... optimiert. Hier gibts ne Homepage dazu: http://ces.univ-karlsruhe.de/RISPP/ Dazu gibts einige Papers, und das ganze wird eben auch auf FPGA implementiert, es sind aber denke ich noch nicht alle Blöcke fertig, sondern es wird da parallel an diversen Baustellen (Modellbildung, dyn. Rekonfiguration, auf Software-Ebene...) gewerkelt. Naja, vielleicht interessiert das ja jemanden hier, ist halt alles noch sehr Grundlagenforschung. Auch hakts manchmal eben noch an den Tools von Xilinx (vor Allem PlanAhead), sodass man manchmal direkt mit Xilinx kommunizieren muss um Lösungen zu finden (zum Beispiel Constraints, die nicht offiziell dokumentiert sind). Gruß, Micha.
Ich hab im Rahmen meiner Diplomarbeit mit partieller dyn. Rekonfiguration gearbeitet. Damals mit Virtex 1, Virtex 2 und Virtex 4. Virtex 1 war nur spaltenweise, den V4 konnte man dann schon in kleineren Teilen rekonfigurieren zur Laufzeit. Aber der Aufwand ist enorm. Man muss über Region constraints die Ranges festlegen, damit sich die Module nicht überschneiden. Außerdem musste man spezielle Bus-Macros zwischen den Modulen einfügen, die der Übergabe von Signalen zwischen den Modulen dienen. Man muss den VHDL-Code schon im vorraus mit Block auf die Rekonfiguration schreiben, oder man baut sich eigene Tools, die das design partitionieren. Nur wird es da schwierig, sinnvolle Trennstellen zu finden und man darf dann auch nicht die benötigten Ressourcen außer acht lassen. Außerdem kamen dann noch einige weitere Einschränklungen dazu, wie zB. dass ein dynamisches Modul nicht über der mittlersten Spalte des V2 liegen durfte, die man sich erstmal so nicht erklären konnte. Und man muss natürlich alle Module im vorraus komplett durch den Designflow laufen lassen, das kann schonmal ne Weile dauern ;-) Das ganze ist jetzt knapp 2,5 Jahre her, kann sein, dass sich da was getan hat. Als ich letztens den FAE nach dem Thema gefragt habe, konnte er mir keine Auskunft geben ;-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.