Spartan 3A über FTDI USB IC flashen

Also zunächst mal lassen sich die per SPI angeschlossenen Flashes über 
Impact mit indirekter Programmierung über den JTAG Anschluss 
beschreiben. Dazu lädt impact einen kleinen Core in den FPGA, der die 
Übersetzung zwischen JTAG und SPI macht.
Außerdem kann man den auch per SPI Direct Programming mit dem USB 
Platform Cable von Xilinx direkt beschreiben. Die zugehörigen 
Schaltungen findest du im Configuration User Guide.
Über den FT2232H gehts natürlich auch, musst dir aber dann selbst eine 
Softare schreiben, die entweder SPI für die direkte Progarmmierung oder 
aber JTAG für die indirekte Programmierung macht.
Der Charme der SPI-Flash Lösung ist neben dem Preis, dass du den Flash 
aus der FPGA Firmware heraus direkt beschreiben kannst. Es muss also im 
Idealfall nur einmal das Bitfile per JTAG drauf und dann kannst du 
Firmware-Update über dein Design machen. Die Pins sind nach der 
Konfiguration des FPGA normale I/Os, also der Flash steht dir dann 
komplett zur Verfügung. Wenn das Gerät sowieso ein 
Kommunikationsinterface hat, ist das sehr sinnvoll.

Es wäre zu überlegen, ob man nicht gleich einen etwas größeren Flash (4 
oder 8 MBit) nimmt. Dann kann man ein Multi-Boot-System bauen, also 
mehrere Konfigurationen des FPGAs ablegen. Und man kann Daten darauf 
speichern im freien Bereich.

Allerdings würde ich Dir dann empfehlen auf den STM-Speicher zu 
wechseln. Das laden des Designs nach dem Power-Up erfolgt im Continuous 
Read des Flash ab Adresse 0. Da gibt es zwischen den Atmel und STM-Typen 
keinen Unterschied. Allerdings sind die Atmel im Default im 264 Byte 
Page Mode. Daher ist die Adressierung im SPI-Protokoll anders aufgebaut. 
9-Bit für die Auswahl der Bytes und dann erst die Bits für die Auswahl 
der Pages. Das hat zur Folge, dass Impact mit der indirekten 
Programmierung (hier wird ein Continious Write aus dem FPGA heraus 
gemacht) die Adressierung fasch aufbaut und Die Daten an einer anderen 
Adresse ablegt. Das muss dann auch beim Starten eines zweiten Boots bei 
der Adressgenerierung beachtet werden.

Bei Xilinx findet man dazu aber leider nichts (zumindest noch vor 2 
Jahren). Das habe ich mir mühselig erkämpfen müssen in dem ich den 
Bitstream des SPI mit dem Oszi analysiert habe bevor ich auf das Problem 
gestoßen bin.

Johann schrieb:
> Muß man da einen eigenen Bootloader schreiben?

Gibts bereits von mir. Siehe Anhang.

Für den Atmel-PROM habe ich zur Adressgenerierung folgende Kommentar in 
mein VHDL mit eingebaut.

1

-- Adressberechnung für die Startadresse des PROMs bei AT45DBxx:

2

-- Bei der Bitstream-Generierung wird das Startbyte angegeben. Das ist z.B.  0x010000 (64k-Byte-Adresse).

3

-- Der FPGA schickt als erstes zu dem Konfigurationsprom den Befehl 0xE8. Dies bedeutet "Continuous Array Read".

4

-- Gefolgt von 3 Byte Startadresse. Dieser wird aber nicht als Byte-Adresse vom PROM interpretiert, sondern wie folgt:

5

--

6

--         Bits    7    6    5    4    3    2    1    0

7

-- Adressbyte 1:   x    x    x    x   PA10 PA9  PA8  PA7

8

-- Adressbyte 2:  PA6  PA5  PA4  PA3  PA2  PA1  PA0  BA8

9

-- Adressbyte 3:  BA7  BA6  BA5  BA4  BA3  BA2  BA1  BA0

10

--

11

-- PA ist dabei die Page-Adresse á 264 Bytes und BA die Byte-Adresse innerhalb dieser Page. Um also von dieser Page

12

-- Starten zu können, muss man die Adresse auf dieses Format umrechnen: 

13

-- PA = ganzzahliger Anteil von 0x010000/264

14

-- BA = rest von 0x010000/264 multipliziert mit 264

15

-- => PA = 248 (11-Bit-Binär 00011111000)

16

-- => BA = 64  ( 9-Bit-Binär   001000000)

17

-- => Startadresse an picoboot: 00011111000001000000 = 0x01F040

Wenn du nur den FPGA konfigurieren willst, und keinen µC da drin 
implementiert ist, brauchst du keinen Bootloader. Zunächst mal holt sich 
der FPGA selbst das BitFile aus dem Flash, wenn die 3 Mode Pins 
entsprechend gesetzt sind. Die MultiBoot Spezialitäten sind im Config 
User Guide beschrieben. Sollte man vielleicht als Anfänger nicht gleich 
alles auf einmal implementieren.