Hallo Freunde, wir fangen gerade ein neues Projekt an, in dem es einen Spartan6, ein Flash für dessen Firmware und einen Microcontroller geben wird, über den die Firmware des Spartan6 geupdated werden können soll. Ich hab mir folgendes überlegt: 1. Lösung: - Xilinx Platform Flash XCFxxP parallel an Spartan6 - Spartan6 konfiguriert sich selbst aus dem XCFxxP - µC kann XCFxxP über JTAG beschreiben - Update: PC -> µC -> JTAG -> XCFxxP - Firmware-Format: .xsvf Vorteil: FPGA-Config schnell (parallel) Nachteil: hoher Aufwand im µC (XSVF-Player) 2. Lösung - Standard SPI-Flash am µC - µC liest Bitfile aus Flash und konfiguriert Spartan6 seriell - Update: PC -> µC -> SPI -> Flash - Firmware-Format: .bit Vorteil: einfach zu implementieren Nachteil: FPGA-Config langsam (seriell) Habt Ihr bessere Vorschläge oder Ideen? Am liebsten wäre mir eine fertige Lösung, die man einkaufen könnte und möglichst wenig selbst entwickeln muß. Danke!
Bronco schrieb: > Nachteil: FPGA-Config langsam (seriell) Wie groß ist denn Euer Spartan6? Wie schnell muss den Euer Design beim power-up starten? Duke
lass doch den µC direkt mit dem SPI-Flasch reden und den FPGA ebenfalls. Wenn du den FPGA im RESET hällst, kann der µC exklusiv auf den Flash zugreifen... wenn du dann den FPGA loslaufen lässt, bootet der "schnell" aus dem SPI Flash von selber...
Duke Scarring schrieb: > Wie groß ist denn Euer Spartan6? Wie schnell muss den Euer Design beim > power-up starten? Tendenziell werden es 16 oder gar 32MBit, und die Startup-Zeit sollte deutlich unter 10s liegen.
Bronco schrieb: > Tendenziell werden es 16 oder gar 32MBit, und die Startup-Zeit sollte > deutlich unter 10s liegen. Das könnte selbst mit Quad-SPI etwas knapp werden. Aber versuchen würde ich es. Mit Quad-SPI auf dem Trenz TE0600 füllt man das FPGA mit ca. 1 MBit/Sekunde (geschätzt). Duke
Duke Scarring schrieb: > Mit Quad-SPI auf dem Trenz TE0600 füllt man das FPGA mit ca. 1 > MBit/Sekunde (geschätzt). Hä? Das ist aber dann falsch einestellt. Der Spartan 6 erlaubt bis 26MHz CCLK, kann man bei BitGen einstellen. Selbst unsere S6-100 laden in etwa einer Sekunde aus einem normalen Single Bit SPI Flash. Das ist die günstigste und flexibelste Variante. Dann noch MultiBoot mit Fallback dran und man kann den Flash auch durch das FPGA Design hindurch selbst updaten. Ledigleich bei PCI (Express) Anwendungen wäre SPI Boot zu langsam. Bei 26MHz CCLK und 33MBit Bitfile Größe kann man sich ja leicht ausrechnen, dass es nur eine reichliche Sekunde dauert.
kann ich nur zustimmen: selbst der größten Spartan6 läßt sich - wenn man will - via SPI in 250ms konfigurieren: UG380 Seite 43: Beispiel Winbond im x4 mode Seite 54: USERCCLK Input Dual-purpose External configuration clock source for all master configuration modes => Unabhängigkeit vom FPGA-internen Taktgenerator der +-50% haben kann => schließ hier z.B. 64 MHz an + sag' bitgen, dass er diesen Takt zum Konfigurieren nehmen und durch 2 teilen soll (Achtung: /2 notwendig, um ein Silizium-bug zu umgehen) => 32 MHz Konfig-Clock (<40 MHz für etwas 'Luft' s.u.) DS162 Seite 55: FMCCK serial mode (Master Serial/SPI) All devices 40 MHz (nur nicht -1L !!) => 32 MHz x 4 bit => 128 Mb/s => 32 Mb in 250 ms Viel Erfolg P.S. Achte auf das Datenblatt des SPI - aber eigentlich können die alle 32MHz mit den vom Spartan6 geforderten Setup/hold P.P.S. Update wie oben bereits von Hannes (!) beschrieben direkt vom uC oder via JTAG-Kabel mit standard Xilinx software via "indirect programming" (Achtung: nicht alle Flashes unterstützt)
Christian R. schrieb: > Hä? Das ist aber dann falsch einestellt. Der Spartan 6 erlaubt bis 26MHz > CCLK, kann man bei BitGen einstellen Hmm. Wenn ich die ConfigRate höher als 2 setze funktioniert zwar die Konfiguration per JTAG, aber die Konfiguration aus dem Flash schlägt fehl. Ein Teil meines Designs läft (die Error-LED blink), aber meine Soft-CPU startet nicht. Muß ich noch andere Optionen beachten? Hier sind meine bitgen-Optionen:
1 | -w |
2 | -g INIT_9K:Yes |
3 | -g DebugBitstream:No |
4 | -g Binary:no |
5 | -g CRC:Enable |
6 | -g Reset_on_err:Yes |
7 | -g ConfigRate:2 |
8 | -g ProgPin:PullUp |
9 | -g TckPin:PullUp |
10 | -g TdiPin:PullUp |
11 | -g TdoPin:PullUp |
12 | -g TmsPin:PullUp |
13 | -g UnusedPin:PullDown |
14 | -g UserID:0xFFFFFFFF |
15 | -g ExtMasterCclk_en:No |
16 | -g SPI_buswidth:4 |
17 | -g TIMER_CFG:0xFFFF |
18 | -g multipin_wakeup:No |
19 | -g StartUpClk:CClk |
20 | -g DONE_cycle:4 |
21 | -g GTS_cycle:5 |
22 | -g GWE_cycle:6 |
23 | -g LCK_cycle:NoWait |
24 | -g Security:None |
25 | -g DonePipe:No |
26 | -g DriveDone:No |
27 | -g en_sw_gsr:No |
28 | -g drive_awake:No |
29 | -g sw_clk:Startupclk |
30 | -g sw_gwe_cycle:5 |
31 | -g sw_gts_cycle:4 |
Duke
Christian R. schrieb: > Selbst unsere S6-100 laden in etwa > einer Sekunde aus einem normalen Single Bit SPI Flash. Das ist die > günstigste und flexibelste Variante. Das klingt vielversprechend. Wie bekommt Ihr denn das Bitfile ins Flash?
Bronco schrieb: > Wie bekommt Ihr denn das Bitfile ins Flash? Bei der Erstinbetriebnahme mit indirekter Programmierung über Impact. Danach durch das FPGA selber, da das eh an einen PC angeschlossen ist. Duke Scarring schrieb: > Hmm. Wenn ich die ConfigRate höher als 2 setze funktioniert zwar die > Konfiguration per JTAG, aber die Konfiguration aus dem Flash schlägt > fehl. Ein Teil meines Designs läft (die Error-LED blink), aber meine > Soft-CPU startet nicht. Muß ich noch andere Optionen beachten? Hm, also wenn DONE auf High geht, hat der Spartan alles was er selber braucht aus dem Flash geladen. Der Rest ist dann Problem deines Designs.
Nachtrag: Duke Scarring schrieb: > Hmm. Wenn ich die ConfigRate höher als 2 setze funktioniert zwar die > Konfiguration per JTAG, aber die Konfiguration aus dem Flash schlägt > fehl. Ein Teil meines Designs läft (die Error-LED blink), aber meine > Soft-CPU startet nicht. Muß ich noch andere Optionen beachten? Ich hab mich nochmal hingesetzt und Fehler gesucht. Meine Soft-CPU holt ihre Opcodes aus dem BRAM. Bei höherer ConfigRate ist offenbar die Zeit zwischen DCM-Konfiguration und dem Start der CPU zu kurz. Und dort ist der Ausgangstakt der DCM noch nicht stabil, so das korrupte Daten aus dem BRAM gelesen werden. Die Lösung war es, die CPU erst zu starten, nachdem locked auf '1' gegangen ist. Jetzt funktioniert auch
1 | -g ConfigRate:26 |
bei mir. Nach was zur Beachtung: Der Takt für die SPI-Clock wird intern generiert (Master mode) und kann lt. Datenblatt (DS162) um bis zu +/- 50% vom eingestellten Wert abweichen (F_MCCKTOL). Das kann dann u.U. für den SPI-Flash zu schnell werden. Duke
Man kann ja BitGen auch gleich sagen, dass die Konfig solange verzögert wird, bis alle konfigurierten DCM/PLL auf Locked gehen. Dann hast du das Problem nicht.
Nur so als Idee: Wenn man Slave Parallel zur Konfiguration nimmt, kann man danach die Pins auch gleich als Datenpins für CPU-FPGA-Kommunikation nehmen. Wenns nicht High-Speed sein muss, kann man mit nur drei weiteren Pins (ALE, RD, WR) einen IO-Bus mit 256 Addressen aufziehen. Praktisch, wenn die CPU auch so ein Memory-Mapped-Interface hat (wie zB die grossen AVRs). Ich hab so ein Setup, wo ein S3E vom AVR aus einer SD-Karte so geladen wird. Danach dient der AVR über den IO-Bus als "IO-Extender" (ADC, GPIOs, auch die SOC-UART läuft vom Microblaze unbemerkt nativ auf dem AVR, sodass AVR-Bootloader und MB bequem zu beobachten sind).
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.