Forum: FPGA, VHDL & Co. FPGA Metaprogramming?


von Christian B. (cib)


Lesenswert?

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 Matthias (Gast)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> 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?

von Christian B. (cib)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> 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).

von Morin (Gast)


Lesenswert?

> 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.

von Rince (Gast)


Lesenswert?

>> 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.

von Georg A. (Gast)


Lesenswert?

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 :-)

von Christian R. (supachris)


Lesenswert?

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.

von Gast (Gast)


Lesenswert?

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ß

von D. I. (Gast)


Lesenswert?

http://www12.informatik.uni-erlangen.de/research/?PHPSESSID=v42hpqk00ftbmn35vuu2lku6m3

die beschäftigen sich u.a. mit partieller dynamischer 
Rekonfigurierbarkeit ;)

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> ... 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...

von Ras F. (rasfunk)


Lesenswert?

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

von Micha (Gast)


Lesenswert?

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.

von TM (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.