www.mikrocontroller.net

Forum: FPGA, VHDL & Co. FPGA reprogrammiert sich selbst


Autor: Jonathan Swift (psihodelia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich überlege mir folgenes Design:
Ein FPGA ständig reprogrammiert sich selbst.
Natürlich hat solche FPGA auch solche Gebiete die man nicht 
reprogrammieren darf, z.B. ein UART und Logic mit Funktionen für das 
Brennen.

Meine Frage ist: ist es möglich nur ein kleines Teil des FPGAs zu 
reprogrammieren? Mich interessiert insbesonders Xilinx Spartan 3.

Danke in Voraus.

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich glaube das geht nur mit den virtex. spartan geht nicht.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jonathan Swift (psihodelia)

>ich überlege mir folgenes Design:
>Ein FPGA ständig reprogrammiert sich selbst.

Und wozu?

>Natürlich hat solche FPGA auch solche Gebiete die man nicht
>reprogrammieren darf, z.B. ein UART und Logic mit Funktionen für das
>Brennen.

>Meine Frage ist: ist es möglich nur ein kleines Teil des FPGAs zu
>reprogrammieren? Mich interessiert insbesonders Xilinx Spartan 3.

Ja, nennt sich Partial Reconfiguration und ist nicht ganz trivial.

MFG
Falk

Autor: Johannes T. (johnsn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klingt aber ziemlich interessant. Wär toll, wenn ein paar Infos in 
diesem Thread aufkommen würden.

Autor: Cheffe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich halte die Reprogramierbarkeit für ein rein akademisches Thema. Mir 
ist kein industrielles Umfeld bekannt, wo das gemacht wird. Technisch 
ist das zwar kein Problem, aber wie sieht es mit den Themen Validierung 
aus? Welche Systeme eignen sich schon dafür, dynamisch programmiert zu 
werden ?

Die großen Massenbrachen Medizintechnik und Automitve scheiden komplett 
aus. Die haben sowieo ein Problem mit allem "Soften". Kann mir auch kaum 
vorstellen, daß man für ein MedProdukt, daß sich im Betrieb 
umconfiguriert, eine Zulassung (von der FDA) bekommt. Wer will das 
Risiko tragen? Schon jetzt wird alles statisch gemacht und gesichert, um 
ja keine Risiken zu kriegen -koste es auch etwas Speicherplatz im FPGA.

Rekonfigurierende Systeme sind Elfenbein!

Autor: Jonathan Swift (psihodelia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Rekonfigurierende Systeme sind Elfenbein!

Rekonfigurierbare Systeme eignen sich zum Fault-Tolerant Design, z.B. 
fuer ein Mars-Roboter. Es ist oft auch erwuenscht dass ein Roboter 
adaptiert sich zu seiner Umgebung, wo auch verschiedene 
Evolutionsalgorithmen sich lohnen.

Autor: Marcel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Evolutionärfunktionen lassen sich auch mit statischen 
Rechen-Funktionen und autodaptiver Software realisieren, die besser 
simulier- und testbar sind. Gerade für solche Satelitenprojekte muss 
alles haarklein vorgedacht und vorgetestet werden.

Meist sind dei reprogrammierbaren Systeme immer ein Argument, Hardware 
besser auszunutzen. Aber dort, wo es möglich wäre (Astro, Einzel- und 
Sonderanfertigungen) ist die STückzahl so gering, daß FPGA-Kosten kein 
Thema sind. Da zählt Entwicklungsgeschwindigkeit.

Autor: Valerij Matrose (fpga-dev)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zitat: "Ich halte die Reprogramierbarkeit für ein rein akademisches 
Thema."

Ich muss hier Cheffe zu 100% zustimmen. Dieses Thema wurde äußerst gerne 
dazu benutzt, um eine (internationale) Veröffentlichung zu "generieren". 
Es gab in der Vergangenheit immer wieder Forschungsthemen, die keine 
einzige praktische Anwendung hervorgebracht haben, jedoch immer gut 
genug waren um die Unwissenden zu begeistern.

Die Idee ist an sich selbst von verlockender Schönheit, aber sobald man 
versucht etwas "praxistaugliches" zu implementieren, ist von der 
Schönheit nichts mehr zu erkennen:

- Die Rekonfiguration ist langsam,
- Der zu rekonfigurierende Bereich muss vorher festgelegt werden und ist 
dann genau so groß wie der größte austauschbare Schaltungsteil. Es kommt 
aufgrund der Herstellervorgben wie der Bereich auszusehen hat, zu 
schlechter Ausnutzung der FPGA-Fläche. Die letzte (deutschsprachige) 
Veröffentlichung, die mir bekannt ist, hat den treffenden Titel "Eine 
Studie zur dynamischen Rekonfiguration von Hardware: "Pain oder Gain"" 
von Philipp Reinkemeier & Co. Ist für jeden der sich für das Thema 
interessiert wirklich lesenswert!
- Den Schmerz der Designverifikation sollte man sich wirklich ersparen, 
indem einfach mehrere komplette Bitstreams für unterschiedliche 
Anwendungsfälle erzeugt werden und der FPGA jedesmal komplett 
rekonfiguriert wird. Bei Spartan 3 sind die Bitstream sehr einfach zu 
managen. Da kann der FPGA selbst entscheiden, wann er und mit welchem 
Bitstream konfiguriert wird.
-Mangelhafte Unterstützung seitens der FPGA-Hersteller.

Mein Fazit: lasst in der Praxis die Hände weg davon oder nutzt das Thema 
um zu promovieren ;)

Gruß,

fpga-dev

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> - Die Rekonfiguration ist langsam
koennte sich loesen lassen, indem der FPGA eine zweite Ebene an 
Konfigurationsspeicher besitzt, der im Bedarf parallel geladen werden 
kann.

> Der zu rekonfigurierende Bereich muss vorher festgelegt werden und ist
> dann genau so groß wie der größte austauschbare Schaltungsteil. Es kommt
> aufgrund der Herstellervorgben wie der Bereich auszusehen hat, zu
> schlechter Ausnutzung der FPGA-Fläche.
Da hat sich einiges getan, beim V4 kann man Bereiche bis auf die Groesse 
von wenigen Slices dyn rekonfigurieren, man koennte also das Design 
feingranularer partitionieren und rekonfiguerieren. Dummerweise steigt 
dadurch dann wieder der Rek.aufwand, weil man oefter rek. muss

Ich stimme aber zu, dass sich das Ganze fuer ein Projekt ausserhalb des 
akad. Rahmens kaum eignet wegen der Kosten und Entwicklungszeit. Dafuer 
eignen sich andere dy. rek. Strukturen besser, wie zB. XPP von Pact.

Autor: Jonathan Swift (psihodelia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Valerij Matrose (fpga-dev)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
T.M. wrote:
>> - Die Rekonfiguration ist langsam
> koennte sich loesen lassen, indem der FPGA eine zweite Ebene an
> Konfigurationsspeicher besitzt, der im Bedarf parallel geladen werden
> kann.

Und wie soll das technisch realisiert werden? Auf dem FPGA-Die? Das
führt dann automatisch zur größeren Flächenbedarf und zwangsläufig zu
höheren Kosten. Dann kann man ja gleich einen größeren FPGA nehmen und
sich die Rokonfiguration sparen. Die Hersteller werden niemals
Strukturen auf dem FPGA integrieren, die nur möglicherweise und dann in
wenigen Designs sinnvoll sind. Das heutzutage (fast) jeder FPGA einen
RAM-Block hat, kommt daher, daß diese im fast jedem Design benötigt
werden.

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und wie soll das technisch realisiert werden?

Ich hab nicht gesagt, dass es unbedingt sinnvoll waere sowas zu tun... 
Es waere nur eine Moeglichkeit, um die Realisierung solcher Systeme zu 
vereinfachen. Aber wie gesagt, dafuer eignen sich andere Architekturen 
bei weitem besser...

Autor: FPGA-Guru (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für die Rekonfigurationsfähigkeit benötit man nicht zwangsweise eigene 
Chipstrukturen. Eine an das Problem sich selbst adaptierende Schaltung 
(Umsetzen von Signalpfaden, Änderung von Parametern und 
Ablaufstrukturen) ist allein durch Multiplexerpfade und Schaltlogik 
möglich. Dies wird auch bereits in diversen Schaltungen realsiert - nur 
kommt kaum einer auf die Idee, hier von einer selbstkonfigurierenden 
Schaltung zu sprechen.

Den Austausch ganzer Schaltungsteile halte ich kaum für zweckmäßig, den 
jede erdenkliche Funktion, die eine Schaltung annehmen kann, muss 
strukturell und funktionell untersucht und validiert werden. Wie will 
man dies leisten ?

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist nicht ganz klar, was exakt du vor hast, und was du unter 
Rekonfiguration verstehst.
Wenn du während der Laufzeit einzelne Bereiche des FPGA 
"umprogrammieren" willst, ohne einen neunen Bootvorgang anzustossen, 
dann dürfte das Extrem kompliziert werden.

Willst du aber z.B. über einen im FPGA implementierten UART ein neues 
Konfigfile in das FPGA spielen, dann geht das recht einfach.
Der UART ist ja während der FPGA läuft, im den RAM-Zellen des FPGA. 
Somit kannst du ihn nutzen um das Boot-Device (Flash) im Hintergrund zu 
programmieren.
Wenn das Bootdevice fertig programmiert ist, dann Reset ausführen und 
das umkonfigurierte System läuft wieder.

Autor: ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe eine Anwendung im industrielles Umfeld die bisher aus aus zwei 
Spartan3-FPGA's besteht. Das erste hat einen festen Inhalt und 
realisiert eine Netzwerkverbindung. Das zweite ist viel größer und wird 
je nach Anwendung über das Netzwerk konfiguriert. Ist es möglich das mit 
nur einem Spartan3-FPGA zu lösen?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ ralf (Gast)

>je nach Anwendung über das Netzwerk konfiguriert. Ist es möglich das mit
>nur einem Spartan3-FPGA zu lösen?

Schwierig. Und gerade im industriellen Umfeld würde ich die Finger davon 
lassen. Und wesentlich billiger wird es dadurch auch nicht. Du brauchst 
ein FPGA das beide Inhalte (Netzwerkanbindung + variablen Teil) 
gleichzeitig fassen kann. Und grosse FPGAs sind ab einem bestimmten 
Punkt überproportional teuer (weil die Ausbeute bei grossen ICs stark 
sinkt). Lass es wie es ist.

MFG
Falk

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ralf:

Sollte problemlos möglich sein.
Ein einfacher MAC-Controller nimmt nicht viel Platz im FPGA weg. Würde 
wahrscheinlich in deinem großen FPGA kaum in´s Gewicht fallen.

Ich hab genau sowas bei mir angedacht und bis jetzt spricht gar nix 
dagegen. Allerdings geh ich auf Lattice XP-Bausteine, die haben das 
Flash bereits on Chip und unterstützen explizit das Programmieren im 
"Hintergrund" via JTAG, Serial oder Parallel.

@Falk:
Warum würdest du gerade im industriellen Umfeld die Finger davon lassen?
wegen erweiterter Temp-bereich? EMV? Verfügbarkeit?????

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Schlumpf (Gast)

>Sollte problemlos möglich sein.

Wenn das mal kein Irrtum ist.

>Ein einfacher MAC-Controller nimmt nicht viel Platz im FPGA weg. Würde
>wahrscheinlich in deinem großen FPGA kaum in´s Gewicht fallen.

Sicher, aber . . .

>Warum würdest du gerade im industriellen Umfeld die Finger davon lassen?
>wegen erweiterter Temp-bereich? EMV? Verfügbarkeit?????

EMV und Temperatur sind nicht meine Bedenken, wohl aber

a) Designflow für partielle Rekonfiguration ist AFAIK im Moment noch 
reichlich problematisch/unausgereift
b) Ausfallsicherheit/Verfügbarkeit/Verifikation der partiellen 
Konfigurationen.

MfG
Falk

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn das mal kein Irrtum ist.

ist es nicht!

> Sicher, aber . . .
?

> a) Designflow für partielle Rekonfiguration...

Hat ralf was von partieller Konfiguration gesagt??? NATÜRLICH ist nebst 
dem  veränderten Desing der gute alte MAC-Controller im neuen Desing 
wieder vorhanden.
z.B. altes Design: MAC + Funktion A
neues Design: MAC + Funktion B

wird jeweils natürlich komplett neu geschrieben und Neustart über Reset.

(ich erspar mir an dieser Stelle den Kommentar, der mir auf der Zunge 
liegt)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Schlumpf (Gast)

>> Wenn das mal kein Irrtum ist.

>ist es nicht!

Na wenn DU das sagst.

>Hat ralf was von partieller Konfiguration gesagt??? NATÜRLICH ist nebst
>dem  veränderten Desing der gute alte MAC-Controller im neuen Desing
>wieder vorhanden.
>z.B. altes Design: MAC + Funktion A
>neues Design: MAC + Funktion B

Wenn diese Münchhausenstrategie mal nicht daneben geht. Was machst du, 
wenn das Konfigurieren des neuen Bitstroms fehlschlägt?

MFG
Falk

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk: genauuu das sag ich: Das funzt!

Im Gegensatz von Münchhausen muss ich mich nicht selber am Schopf aus 
der Sch... ziehen, sondern nur nen FPGA neu beschreiben, was deutlich 
einfacher ist.

Und wegen dem Fehlschlagen während der Konfiguration gibt es eine 
mindestens genauso simple Lösung. Man muss ja nicht on-the-fly 
schreiben, wenn die Daten über´s Ethernet reinknallen, sondern kann sie 
auf dem Prozessor zwischenspeichern... Na, dämmert´s?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Schlumpf (Gast)

>Und wegen dem Fehlschlagen während der Konfiguration gibt es eine
>mindestens genauso simple Lösung. Man muss ja nicht on-the-fly
>schreiben, wenn die Daten über´s Ethernet reinknallen, sondern kann sie
>auf dem Prozessor zwischenspeichern... Na, dämmert´s?

Auf welchem Prozessor? Davon war bisher keine Rede.

MFG
Falk

P.S. Mir ist schon klar, dass man eine Failsafe Konfiguration irgendwo 
bereithalten kann. Das benötigt dann aber mehr oder weniger 
Zusatzhardware (Flash/Watchdog/kleiner uC), die prüft, ob das FPGA den 
neuen Datenstrom fehlerfrei schluckt und ggf. handelt.

Autor: FPGA-Guru (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>... über einen im FPGA implementierten UART ein neues Konfigfile in das
> FPGA spielen ... ihn nutzen, um das Boot-Device (Flash) im Hintergrund
> zu programmieren.

Wo ist denn da der grundsätzliche Unterschied zu einer Flash-Config oder 
einer AS zu einem Proz? Das FPGA das FLash bespielt, hat nichts zu 
dagen!

>Wenn das Bootdevice fertig programmiert ist, dann Reset ausführen

Eben! Komplett neuer Systemstart!

Unter Reconfiguration verstehe ich, daß der FPGA anhand der aktuellen 
Situation des Prozesses, seine Schaltungsteile anpasst, um benötigte 
Funktionen zu laden, um Spciecher zu sparen, oder seine Teile 
anzupassen.

Autor: FPGA-Guru (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... und dabei ununterbrochen und sicher weiterlaeuft, muss noch 
hinzugefügt werden.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Rede.

Autor: FPGA-Guru (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein Punkt: Lasse ich vergangene Projekte Revue passieren, so fallen 
überhaupt nur 20% der Zeit auf die eigentliche Entwicklung. Vieles davon 
ist Test und Sicherheitsuntersuchung. Diese für ein reprogrammable 
System zu leisten, dürfte einen erheblichen Mehraufwand bedeuten, als 
für ein "normales" gleicher Funktion. An "Selbstlern-Elektronik" wage 
ich garnicht zu denken.

Schon heute ist es ja doch so, daß man als Entwickler im FPGA-Bereich 
(und auch embedded) kaum das Machbare ins System bekommt, weil es kaum 
testbar ist und es einfach nicht abgesegnet wird. Z.T.kriegt man ja 
nicht mal überhaupt ein FPGA ins System, weil der Kunde oder die Branche 
es nicht akzeptiert.

Autor: Jonathan Swift (psihodelia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die schlechte Qualität von heutige FPGA-Design Software Tools ist eine 
gerade Konsequenz von ihre proprietare Natur. Man braucht Open Source 
VHDL Compilers und Synthesis Tools um eine neue technologische 
Paradigmshift zu erreichen.

Autor: Berater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Selbst mit verbesserten Tools umgeht man nicht das Problem, daß der 
Kunde es nicht will, weil er es nicht für sicher hält. Wenn, dann müsste 
man schon eine enorme Reihe an Dauertestversuchen mit etlichen 
Reprogrammierungen laufen lassen- gfs auch in einem künstlich 
beschleunigten System, um eine gesicherte Riskioberwertung durchführen 
zu können.

Solange ein FPGA-Update eine Softwareänderung / wesentliche 
Hardwareänderung darstellt und wichtige Funktionen betroffen sind, 
müssen bei mediznischen Geräten z.T. neue klinische Studien anberaumt 
werden. Da die keiner bezahlen kann, bleibt es bei rudimentären 
Sparfunktionen.

Innovation ist nicht.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jonathan Swift (psihodelia)

>Die schlechte Qualität von heutige FPGA-Design Software Tools ist eine
>gerade Konsequenz von ihre proprietare Natur. Man braucht Open Source
>VHDL Compilers und Synthesis Tools um eine neue technologische
>Paradigmshift zu erreichen.

BINGO! Du bist Laberconsultant of the week!

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dass es zwei Arten der Reconfiguration gibt, das hab ich viel weiter 
oben erwähnt.
Die eine, von der ihr ausgegangen seid, hab ich oben auch als sehr 
fragwürdig dargestellt. Sprich: Die Partielle Konfiguration zur Laufzeit 
halte ich auch für kaum umsetzbar.
Die zweite, bei der das gesamte FPGA umkonfiguriert wird, stellt 
allerdings kein Problem dar.

Ich hab lediglich erwähnt, dass es dabei nicht zwingend notwendig ist, 
dass für die Zeit des Umprogrammierens das gesamte FPGA "stillgelegt" 
werden muss.
Das heisst, dass das die modifizierten Daten in´s Flash geladen werden, 
während das FPGA weiterläuft. Daher ist es auch möglich, dass das FPGA 
Aufgaben erfüllen kann, die für den Programmiervorgang AN SICH notwendig 
sind. (z.B. ein JTAG Interface emulieren)
Nach erfolgreicher Programmierung erfolgt der Reset. (der nicht zwingend 
für das gesamte System ausgeführt werden muss)

Da Ralf schrieb, dass "je nach Anwendung" über´s Netz neu konfiguriert 
wird, daher sollte ein Reset des FPGAs nach einem Wechsel der Anwendung 
ja kein Problem sein. (Wenn Zeit ist, ne andere ANWENDUNG über´s Netz zu 
übertragen, dann ist meines Erachtens auch Zeit, den FPGA neu zu laden, 
da diese Zeit ja wohl kaum in´s Gewicht fällt)

Nen uC hab ich mal vorausgesetzt, da sicher in den meisten industriellen 
Anwendungen nicht einfach ein FPGA stand-alone alles macht.
Ganz unabhäng davon wäre das Verfahren prinzipiell aber auch ohne uC 
möglich. Allerding mit der Einschränkung, dass, wenn dann beim 
Programmieren was schief geht, das Teil ein Fall für den Service ist. 
(wie Falk richtig erkannte)

Autor: ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antworten. In dem System ist nur ein kleiner µC mit 
32kByte internem Speicher. Ein zusätzlicher Zwischenspeicher und die 
kurzzeitige Netzwerkunterbrechung heben den Vorteil leider auf. Der 
Vorteil bleibt nur wenn ein einfacher Designflow für partielle 
Rekonfiguration möglich ist.

Gruß,

Ralf

Autor: Silvan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>wenn ein einfacher Designflow für partielle
>Rekonfiguration möglich ist.

Den möchte ich jetzt endlich mal dargestellt sehen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.