Spartan6 Firmware mit Microcontroller updaten

Gast #3232133
Lesenswert?

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!
Gast #3232410
Lesenswert?

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
#3232468
Lesenswert?

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.
Gast #3232524
Lesenswert?

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)
Gast #3233211
Lesenswert?

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
#3233330
Lesenswert?

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.
Gast #3243724
Lesenswert?

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
#3244002
Lesenswert?

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

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren