Hallo,
Ich möchte fragen welche Systeme es gibt um einen FPGA im Bedarfsfall in
der Schaltung upzudaten.
Da wir vorhaben eine CPU mit genügend Speicher zu integrieren währe es
super wenn das FPGA die Daten von der Cpu erhält. Damit währe auch ein
Update kein Problem da es mit CPU ja eben problemlos ist.
Geht das, also kann der FPGA damit leben aus der CPU seine Daten zu
bekommen. Es könnte ja zu leichten Verzögerungen kommen durch Interrups
u.s.w. im Gegensatz zum Quad Flash.
Oder kann man das Quad Flash beschreiben und in der Zeit das FPGA
Tristate Schalten?
Es geht um einen Spartan 6, Cpu wahrscheinlich ein ARM Derivat mit
Linux.
Es geht, wenn dein System es verkraftet, dass erst die CPU und das
Betriebsystem läuft, danach erst das FPGA. Es ginge z.B. nicht so
einfach, wenn das FPGA ein PCI Device wäre. Denn das muss gleich ganz zu
Beginn schon aktiv sein. Wenn dein FPGA aber unkritisch jederzeit
initialisiert und angesprochen werden kann, dann suchst du dir den
passenden Config-Modus heraus und Initialisierung das FPGA mit dem uC.
Der FPGA kann nach der CPU starten, das ist machbar. Finde mich im
Moment noch nicht ganz zu recht bei der vielen Doku.
Die Frage war natürlich auch wie das geht und obs ein Beispiel gibt.
Kann man die Xilinx IP Cores eigendlich auch in der Hardware testen wie
bei Al tera?
Moin,
auf diverser Hardware lade ich das FPGA jeweils per Slave-Serial von der
Host-CPU aus per SPI. Muss man sich nur einen (einfachen) Kerneltreiber
für basteln. Aber man muss sich sein System wirklich GENAU durchdenken,
dass man sich nicht selbst (oder den Kunden) mit einem fehlerhaften
Firmware-Update aussperrt.
Lieber im Zweifelsfall noch ein CPLD spendieren, welches das "harte"
Routing erledigt.
Was seit Spartan6 gehen soll, aber mir noch ein Rätsel ist, ist die
partielle Rekonfiguration. Da soll man wohl über die
ICAP_SPARTAN6-primitive die SelectSlave-Logik gezielt ansteuern können.
Wie das mit dem Multiplexing im Detail geht, ist mir noch nicht klar.
Theoretisch aber eine schöne Lösung, weil man immer einen Bootloader im
Flash als Fallback-Szenario hat und die restliche Funktion nachladen
kann.
Was man aber immer auch "von Hand" geht:
- FPGA lädt Default-Konfig aus einem SPI-Flash (Master Serial)
- kleiner Multiplexer, dass Host-CPU über einen Select-Pin auf das
SPI-Flash zugreifen kann
- ein paar I/O pins um das FPGA zu resetten (damit es nicht während dem
CPU-Zugriff versucht zu booten)
Allerdings muss man damit ziemlich aufpassen, da gibt's einige kleine
dreckige Treiberdetails unter Linux. Und man kann sich damit auch
aussperren, wenn das System ohne nichtinitialisiertes FPGA nicht booten
kann.
Andere Variante, bei der man sich aber den eigenen Ast absägen kann:
Einen kleinen Softcore ins FPGA mit reinbacken, der sein eigenes SPI
programmiert. Geht da aber was schief, kann man die Geschichte nur per
JTAG wiederbeleben.
Grüsse,
- Strubi
Ich habe mitlerweile Erfahrung mit Bootloadern, hat lange gedauert bis
es auch unter wiedrigen Umständen lief (stecker ziehen und so),
allerdings nur mit CPU Systemen.
Hab jetzt gelesen das der Spartan 6 das auch kann.
Erst die Booltloaderkonfig laden mit der dann im >Flash an zweiter
Adresse das eigendliche Image geflasht wird, dann gibt es da wohl eine
Reset der dann die zeite Startadresse nimmt. Soweit die Theorie.
Wenn man dierekt aus der CPU laden kann hat sich das ja im Prinzip
erledigt. So der Plan (?!)
Bernd schrieb:> Soweit die Theorie.
Geht auch in der Praxis. Das zweite image, dass der S6 im multi boot
Modue verarbeiten kann, erleichtert die Sache insofern, als dass man das
nicht per Hand triggern muss, wie zuvor mit PLDs oder MCUs.
Hallo!
Schau dir mal das "Spartan 6 Config User Guide" (ug380) von Xilinx an.
Dort ist auf Seite 28 der Schaltplan für den "Slave Serial Mode"
abgebildet.
Vielleicht wäre das ja was für dich...
Gruß,
Thomas
Hi!
Ich habe ein Verständnisproblem:
Strubi schrieb:> auf diverser Hardware lade ich das FPGA jeweils per Slave-Serial von der> Host-CPU aus per SPI.
Das verstehe ich so: "Normalerweise" lädt sich der FPGA seine
Konfiguration aus einem EEPROM / Flash. Die CPU simuliert nun dieses
EEPROM / Flash in dem es die Daten per SPI ausgibt.
Strubi schrieb:> Muss man sich nur einen (einfachen) Kerneltreiber für basteln.
Wozu braucht man hier einen Kerneltreiber? Meiner Meinung nach reicht
es, wenn in einem Teil im Flash der CPU die FPGA Konfiguration abgelegt
ist. Die CPU gibt beim Booten einfach diesen Teil des Flashs aus.
Gruß
Der schrieb:> Das verstehe ich so: "Normalerweise" lädt sich der FPGA seine> Konfiguration aus einem EEPROM / Flash. Die CPU simuliert nun dieses> EEPROM / Flash in dem es die Daten per SPI ausgibt.
Nicht ganz.
Der/das FPGA wird in einen Mode gesetzt, wo es auf Daten und Taktimpulse
von einem externen Master (eben die CPU) wartet, verhält sich also
passiv.
Da wird kein EEPROM / Flash simuliert, wo das FPGA aktiv taktet und der
Speicher mit Daten antwortet.
Gruß,
Thomas
Salute,
> Strubi schrieb:>> auf diverser Hardware lade ich das FPGA jeweils per Slave-Serial von der>> Host-CPU aus per SPI.> Das verstehe ich so: "Normalerweise" lädt sich der FPGA seine> Konfiguration aus einem EEPROM / Flash. Die CPU simuliert nun dieses> EEPROM / Flash in dem es die Daten per SPI ausgibt.>
Antwort gabs schon :-) s.o.
> Strubi schrieb:>> Muss man sich nur einen (einfachen) Kerneltreiber für basteln.> Wozu braucht man hier einen Kerneltreiber? Meiner Meinung nach reicht> es, wenn in einem Teil im Flash der CPU die FPGA Konfiguration abgelegt> ist. Die CPU gibt beim Booten einfach diesen Teil des Flashs aus.>
Das "einfach" ist bei Linux eben nicht der Fall, normalerweise darf der
User nicht einfach Pins toggeln. Deswegen ein Treiber, der das FPGA
unter /dev/fpga0 oder ähnlich zugänglich macht, d.h. z.B. ein "cat
firmware.bin >/dev/fpga0" programmiert dann die Kiste.
Alles klar?
Frankenfurter schrieb:> Geht auch in der Praxis. Das zweite image, dass der S6 im multi boot> Modue verarbeiten kann, erleichtert die Sache insofern, als dass man das> nicht per Hand triggern muss, wie zuvor mit PLDs oder MCUs.
Machst Du das über die ICAP_SPARTAN6?
Bisher haben mir viele erzählt, dass das so geht, aber halt immer mit
dem "in der Theorie"-Disclaimer. Damals hatten nicht mal die
Xilinx-Leute was am Laufen..(ist aber schon ne Weile her). Mir schien
auch alles big X-typisch gezielt schlecht dokumentiert zu sein. Würde
mich gerne eines besseren belehren lassen.
Ganz konkret würde ich gerne in Zukunft von SPI nur noch ein bootstrap
laden, welches über einen Mini-Softcore das zweite "grosse"
Firmwareimage nachlädt, und zwar während das System bootet. Dabei dürfen
manche Pins nicht tristaten.
Falls dabei ein Glitch in der Versorgung auftritt, darf das System nicht
fehlerhaft konfiguriert bleiben, sondern muss sich per Watchdog wieder
komplett neuinitialisieren können.
Hat das schon jemand hinbekommen? (Und zwar wirklich praktisch!)
Grüsse,
- Strubi
