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!
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:
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).