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.
@ 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
Klingt aber ziemlich interessant. Wär toll, wenn ein paar Infos in diesem Thread aufkommen würden.
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!
> 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.
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.
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
> - 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.
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.
> 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...
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 ?
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.
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?
@ 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
@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?????
@ 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
> 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)
@ 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
@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?
@ 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.
>... ü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.
... und dabei ununterbrochen und sicher weiterlaeuft, muss noch hinzugefügt werden.
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.
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.
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.
@ 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!
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)
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
>wenn ein einfacher Designflow für partielle >Rekonfiguration möglich ist. Den möchte ich jetzt endlich mal dargestellt sehen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.