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