Hallo liebe Freunde, gibt es FPGAs (oder CPLDs), die sich zur Laufzeit teilweise rekonfigurieren lassen, bzw. sich selbst rekonfigurieren können? Gruß, Thomas
Ja gibt es. Die Xilinx Virtex 4, 5 und 6 können partielle Rekonfiguration. Wird auch immer besser von ISE unterstützt. Aber trotzdem ein sehr akademisches Thema seit Jahren. Da muss man schon jede Menge beachten... Selbst komplett rekonfugieren geht mit allen FPGAs, die einen durch das eigentliche Design beschreibbaren Konfig-Speicher haben. Das kann auch ein Spartan 3 mit SPI-Flash sein. Dazu musst du ein neues Prom-File in den Flash packen und ein Config auslösen. Bei einigen geht das über ein internes, spezielles Modul, beim Spartan 3e aber beispielsweise nur über einen speziellen Pin am FPGA. Wir haben den PROG_B daher an einen I/O angeschlossen und können so per Kommando ein Rekonfigurieren auslösen.
Wow, danke für die prompte Antwort! Virtex währe absolut überdimensioniert. Aber wenn ich das richtig verstanden habe könnte ich sowas machen: - An einen LVDS Bus sind etliche FPGAs angeschlossen. - Jedes der FPGAs bekommt einen SPI-Flash. - PROG_B kommt an einen FPGA I/O - Ein Minimalprogramm kann: -- Daten über LVDS empfangen -- In den Flash speichern -- Eine Rekonfiguration auslösen. - Dieses Programm kommt initial in alle Flashs. - Jetzt kann ich alle FPGAs gleichzeitig über LVDS rekonfigurieren. - Das neue Programm hat die oben beschriebene Funktion als Teilmenge. - Diesen Vorgang kann ich jetzt beliebig oft wiederholen. Problem: Wenn bei der Übertragung etwas schief geht, dann müssen alle Flashs wieder einzeln neu geflasht werden. Dieses Problem umgehe ich im Moment mit einem kleinen CPLD zwischen FPGA und LVDS. Dadurch spare ich auch den Flash. Aber es gibt ja auch FPGAs mit internem Flash, daher der Gedanke. Über den LVDS sollen übrigens auch andere Daten ausgetauscht werden. Ist im Moment sowieso alles nur Konzeptphase... P.S. Was sagt man eigentlich bei FPGAs anstatt Programm bei uCs?
Hm, naja, wäre es dann nicht einfacher, irgendwo hin einen µC zu setzen, der die FPGAs über Slave Serial konfiguriert? Oder gibts außer dem LVDS-Bus keine extra Leitungen? Schief gehen darf natürlich nix, aber auch da gibts Möglichkeiten. Extendes Spartan 3A und Spartan 6 können verschiedene Files aus einem Flash laden, sogar mit Watchdog und Fallback, falls was nicht klappt. Somit könnte der "Bootloader" immer drin bleiben. Wie man das nennt? Hmm....eigentlich den BitStream, aber auch gerne mal Design, Firmware, Configfile....
Es handelt sich hier um bis zu 50 FPGAs, die alle auf einem eigenen Board sitzen und alle dem selben Code ausführen sollen. Dieser Code soll jederzeit beliebig austauschbar sein. Mehrere Konfigurationen auf dem Flash würden das Problem also nicht lösen. Ich denke die Lösung mit dem CPLD zwischen LVDS und FPGA ist schon nicht schlecht. Dann habe ich wenigstens eine Firmware, wo keiner dran rumfummelt, also kann auch keiner was kaputt machen...
Was genau macht das CPLD jetzt? Irgendwie ist mir das nicht klar. Konfiguriert das den FPGA? Oder wie? Und wo genau ist jetzt das Problem?
Im übrigen: So etwas geht nicht nur mit FPGAs von Xilinx. Andere Anbieter stehen dem nicht nach. Das ist Stand der Technik seit gut 3 Jahren. Der Sinn mehrer Konfigurationen im FLASH liegt in der Betriebsicherheit. Die Frage ist nämlich, wo das FPGA die neuen Konfigurationsdaten zwischespeichern soll. Wenn genügent RAM im FPGA oder außerhalb vorhanden ist, dann kann man die kompletten Konfigurationsdaten empfangen, prüfen, und erst dann ins FLASH programmieren. Wenn eine Zwischenspeicherung aber nicht möglich ist, dann muss man das FLASH sofort programmieren, und wenn jetzt einer über das Netzkabel stolpert ist eine ungültige Konfiguration im FLASH. Also schreibt man zwei Konfigurationen ins FLASH, lädt nach Power-up das "factory image", dieses prüft die zweite Konfiguration im FLASH und veranlasst das die Rekonfiguration.
> Wie man das nennt? "Multi Boot" heißt das Zauberwort bei Xilinx. Dafür wird kein zweiter Flash benötigt. Ich hatte mal einen ganz ähnlichen Fall, da wurden beliebig viele Module mit einem FPGA hintereinander gesteckt und seriell in einer Kette mit einem LVDS-Signal Verbunden (Ring-Struktur). Zum Einsatz kamen dabei FPGAs der Serie Spartan 3A. Beim Power-Up wird automatisch immer das 1. Image (feststehendes Bootimage) vom Config-Flash geladen. Per Kommando über den Seriellen Bus wurden die FPGAs aufgefordert ihr 2. Image (anderer Speicherberich im Flash) zu laden. Sollte das Schief gehen oder nicht vorhanden sein, dann wird automatisch wieder das 1. geladen. Über den Ring wurde dann geprüft welches Image (Versionsnummer) aktiv ist. Gegebenenfalls kann, falls ein Update des 2. Image nicht geklappt hat, dieses wiederholt werden. Oder aber falls es nicht aktuell ist, ein neues eingespielt werden. PS: Harald war schneller!!!
Im Normalfall leitet das CPLD den Datenstrom vom LVDS einfach an den FPGA weiter. Senden tut auf dem LVDS nur der Master (ein Echtzeitrechner). Dieser kann auch die FPGAs konfigurieren. Dazu sendet er einen bestimmten Befehl über LVDS. Dieser wird von den CPLDs registriert, woraufhin sie vom State "Weiterleiten" in den State "Konfigurieren" wechseln. Nun werden die FPGAs von den CPLDs mit den Daten vom LVDS neu konfigurieren. Dieser Vorgang kann beliebig oft wiederholt werden. Da die CPLDs eine fest einprogrammierte Firmware haben kann der Benutzer auch nichts kaputt machen. Ein Problem gibt es nicht, meine Frage hast du ja bereits beantwortet. Deine Meinung interessiert mich natürlich trotzdem, ist ja bisher auch nur ein Konzept.
Wenn man nicht gerade eine unidirektionale Kommunikation hat, kann man auch erst mal alles ins Flash schreiben und dann ein Verify machen. Klappt zuverlässig. Multiboot ist natürlich etwas feiner, kann unser 3e leider nicht. "Wie man das nennt?" War übrigens auf seine Frage nach der Bezeichnung des FPGA- "Programms" bezogen.
Danke Harald & Matthias, sehr interessant. Das Problem dabei ist, dass der Benutzer vollen Zugang zum FPGA hat. Er müsste das also ständig in seine Designs mit einbauen. Wenn er da mal Murks baut, dann muss man das Board ausbauen und neu flashen. Ich denke, da ist die Lösung mit CPLD sicherer, oder wie seht ihr das? Das ganze muss komfortabel und idiotensicher sein ;)
> Wenn man nicht gerade eine unidirektionale Kommunikation hat, kann man > auch erst mal alles ins Flash schreiben und dann ein Verify machen. Wenn im FPGA kein µC implementiert ist, dann ist ein Verify schon etwas aufwendiger. Normalerweise geht beim Update auch nichts schief, so dass die indirekte Prüfung über eine Versionsnummer in meinem Fall völlig ausreichend war. Was ich allerdings an dem Multiboot schätze ist, dass wenn es doch mal schief geht, kann man es wiederholen. In meinem Fall werden die Module beim Kunden über Fernwartung upgedatet und sind zudem noch so verbaut, dass man ohne größere Maßnahmen nicht dran kommt (IP-Wasserdicht mit vielen Schrauben und Dichtungen) um per JTAG-Adapter ein neues Image einspielen zu können.
Achso, na wenn das mit dem CPLD zuverlässig klappt ist doch eine gute Idee. Vor allem, wenn das FPGA eh nur flüchtig seine Config bekommt. Klar, Multiboot hat unbetreitbare Vorteile. Aber wir sind zunächst gezwungen, den S3E zu benutzen. Image in SPI Flash schieben und komplett auslesen für ein Verify klappt allerdings auch problemlos. Reboot wird erst ausgelöst, wenn das Image korrekt drin ist. Natürlich fehlt dann der Watchdog, falls das Image an sich schon defekt ist oder Designfehler aufweist, aber in der nächsten Versions werden das wohl dann Spartan 6 (falls es die dann endlich mal gibt), dann ist das vom Tisch. Zum Glück sind die Geräte halbwegs zugänglich.
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.