Hallo Leute,
bisher habe ich den XCF16PVOG48C (Xilinx Prom mit 16MBit) für einen
Virtex 5 (XC5VLX30T-1FFG665C)FPGA verwendet. Nur leider hat Xilinx diese
Baustein abgekündigt. Wir konnten noch einige kaufen jedoch muss ich den
Baustein auf meinem Board eretzen.
Mit hoher Wahrscheinlichkeit wird es ein SPI-Flash werden. Was verwendet
Ihr denn für einen Speicher?
Kann mir vielleicht einer einen Flash für den Virtex 5 empfehlen.
1:1 ersetzen wird je nach Board schwierig, der SPI Flash wird ja anders
angeschlossen und der Boot Mode muss auch umgestellt werden. Master
Serial != SPI.
Virtex 5 muss ja noch mit ISE/Impact bemuttelt werden, das wird schon
lange nicht mehr aktualisiert. Du müsstest also gucken, welche Flashes
von Impact 14.7 unterstützt werden. Booten müsste aber mit allen gehen,
die 0x03 oder 0x0B zum Lesen nutzen und 24 Bit Adressierung haben. Ich
meine mich zu erinnern dass man am V5 über Pins auch das Read Command
einstellen konnte.
Für aktuelle Flashes kann man versuchen, Impact zum Ignorieren der Flash
ID zu überreden, da gabs ein Flag, SKIP_ID_CHECK oder so...
Edit: Ach ist ja der parallele Boot Flash. Hm. Mouser sagt sie können
noch ein paar hundert liefern auf Bestellung...
Wir kaufen noch einige Flash Bausteine ein. Aber da das Board noch
einige Jahre benutz werden soll muss ich es umarbeiten und den PROM
durch einen SPI-Flash austauschen.
Ich habe gerade ein gutes Dokument von Xilinx (XAPP951) gefunden das
dies gut für den Virtex 5 erklärt.
Das mit der 24Bit Adressierung ist ein guter Hinweis und mit dem 0x03
und 0x0B habe ich auch gerade gelesen. Die muss mann über die Variant
Select Pins auswählen. Den Mode muss ich auf SPI-Master (M0=1; M1=0;
M2=0;) setzen.
Dann werde ich mal nach Bausteinen suchen die ich dann verwenden kann.
Bisher habe ich das XCS3PROG benutzt. Weiß vielleicht jemand ob ich das
weiterhin benutzen kann?
Michael schrieb:> Bisher habe ich das XCS3PROG benutzt. Weiß vielleicht jemand ob ich das> weiterhin benutzen kann?
Fuer SPI-Flashes benoetigt das ein Loader-Bitfile, damit die
SPI-Kommandos erst ueber's BSCAN-Interface getunnelt werden koennen. Das
muss man vermutlich aus dem Source fuer seine Plattform bauen
(allenfalls portieren). Dazu kommen ab und an auch kleine Anpassungen
fuer allenfalls nicht erkannte Flash-Vendor-Codes.
Momentan bin ich noch leicht überfordert mit den ganzen Information die
ich gaerade gelesen habe. Ich weiß schon mal wie ich den Flash am FPAG
anschließen muss. Jedoch weiß ich noch nicht so genau wie ich das File
in den Flash bekomme. Ich habe gelesen das es eine direct SPI Flash
programming gibt. Hier muss ich die Pins des FPGA in den TriState
schicken damit das externe Programming Tool den SPI-Flash beschreiben
kann.
Diese Lösung würde für mich schon mal nicht in Frage kommen da kein
Update im Feld möglich ist.
Ich kann mich noch daran erinnern das man mit den IMPACT einen Boundary
Scan durchführen kann. Dann finden man den FPGA der über eine
JTAG-Interface angeschlossen ist. Dann kann man der Kette einen
unbekannten SPI-Flash hinzufügen und dann die Firmware auf den SPI-Flash
hochladen. Das JTAG-Interface kann dann ein FTDIFT2232H zur Verfügung
stellen. Der FPGA stellt dann das SPI-Interface zum Flash her.
Michael schrieb:> Jedoch weiß ich noch nicht so genau wie ich das File> in den Flash bekomme.
Du hast schon das richtige gefunden. Es gibt direct programming (Klemme,
Steckverbinder o.ä.) aber das wird schon seit Ewigkeiten nicht mehr von
Impat und den Programmern unterstützt. Möglichkeit über Impact wäre
indirect Programming, dazu lädt Impact zuerst ein Bit File ins FPGA, was
zwischen JTAG und SPI vermittelt, dann wird der Flash programmiert. Das
kann erst mal nur damals bekannte Flash Chips, aber das kann man umgehen
mit dem SKIP_IP_CHECK.
Falls dein System ohnehin einen Kommunikationsschnittstelle hat, kannst
du den Flash aber auch über das System programmieren, auf die SPI Boot
Pins hat du nach dem Booten Zugriff aus dem System. So machen wir das
überall. Dann muss man lediglich beim allerersten Mal per JTAG das
Design rein laden und danach geht alles über die im Design integrierte
SPI Logik und die Anwender Software.
XC3SPROG kann auch indirect programming für einige FPGAs und für einige
Flash Chips.
Michael schrieb:> Jedoch weiß ich noch nicht so genau wie ich das File> in den Flash bekomme.
Wenn du das Treiber-Bit-File ($(BSCAN_SPIDRV)) fuer die indirekte
Programmerung hast, so:
1
xc3sprog -b $(BSCAN_SPIDRV) -s a -f deine_firmware.bit
Wenn deine Firmware eine Soft-CPU hat, ist es relativ simpel, aus dem
System heraus zu programmieren, wie supachris schreibt. Da liegt auch in
der Opensource einiges an Code. Mit Hilfe der ICAP-Primitive kann man
das Ganze auch recht narrensicher gestalten ('Goldener Bootloader' als
doppelter Boden, wenn man sich mal die Firmware zerschiesst).
Ich habe meinen Boards allerdings (weil's kaum mehr kostet) jeweils
gleich den FTDI 2232H mit draufgekloppt, um UART/FIFO und JTAG fuers
Neuflashen in petto zu haben. Wird von xc3sprog tadellos unterstuetzt,
ist somit effektiv in der Produktion zu handhaben.
Mein Plan ist auch einen FT2232H zu benutzen und die JTAG Leitungen an
den FPGA anzuschließen und dan XCSPROG zu verwenden. Schon mal vielen
Dank für die ganzen Hinweise.
Ich bin noch am Überlegen ob ich ein JTAG Moodule von Digilent drauf
löte. Da hat man immer die Möglichkeit über Impact ein Backup zu haben.
https://store.digilentinc.com/boards-and-components/programmers/jtag-modules/
Ich werde die Eindrücke auf mich wirken lassen und dann eine
Entscheidung treffen.
Ich könnte noch einen XMEGA an UART Port vom FT2232H anschließen. Der
würde dann per UART die Firmware erhalten und direct per SPI die Daten
in den Flash schreiben. Dabei muss man die PROG_B Leitung durch den
XMEGA auf '0' ziehen. Dann sind alle SPI Pins im TriState.
Muss ich direkt ddas Bitfile "Firmware.bit" das ich in den FPGA lade in
den FLash schreiben oder muss ich die Datei vorher noch in das Intel
Format wandeln wie z.B. beim MCS-File das in den PROM kommt.
Michael schrieb:> Ich bin noch am Überlegen ob ich ein JTAG Moodule von Digilent drauf> löte. Da hat man immer die Möglichkeit über Impact ein Backup zu haben.
Das wäre die einfache Lösung, wo man nicht groß nachdenken muß.
Wenn man den FTDI2232H direkt auf das Board setzt, braucht man noch den
passenden EEPROM-Inhalt, damit der Chip von Impact und Konsorten erkannt
wird.
Für xc3sprog reicht vmtl. die richtige USB-ID.
> Ich könnte noch einen XMEGA an UART Port vom FT2232H anschließen. Der> würde dann per UART die Firmware erhalten und direct per SPI die Daten> in den Flash schreiben. Dabei muss man die PROG_B Leitung durch den> XMEGA auf '0' ziehen. Dann sind alle SPI Pins im TriState.
Ist Dein FPGA schon voll und hat keine Soft-CPU?
Das was der XMEGA machen soll, kann auch gut eine interne CPU mit
übernehmen.
Duke
Michael schrieb:> Ich könnte noch einen XMEGA an UART Port vom FT2232H anschließen. Der> würde dann per UART die Firmware erhalten und direct per SPI die Daten> in den Flash schreiben. Dabei muss man die PROG_B Leitung durch den> XMEGA auf '0' ziehen. Dann sind alle SPI Pins im TriState.>
Das riecht nach mehr Aufwand und Aerger, wenn der XMega mal haengen
sollte.
Auf jeden Fall ist das weniger 'failsafe' als komplett in-system. Aber
wenn du die Firmware nicht modifizieren darfst, ist das wohl der einzig
Gangbare.
> Muss ich direkt ddas Bitfile "Firmware.bit" das ich in den FPGA lade in> den FLash schreiben oder muss ich die Datei vorher noch in das Intel> Format wandeln wie z.B. beim MCS-File das in den PROM kommt.
Wie es oben steht, das rohe Bit-File kommt wie es ist ins Flash,
zumindest per xcs3prog, was Adept macht, weiss ich nicht mehr.
Impact tut wunderbar mit anderen FT2232H-Adaptern, wenn sie die
ML605-Identitaet haben. Stichworte 'ML605 JTAG', oder Einstiegspunkt:
https://gist.github.com/rikka0w0/24b58b54473227502fa0334bbe75c3c1
Danke für den Hinweis mit den ML605.
Ich habe selber mal vor mehr als 10 Jahren den EEPROM Inhalt von den
Digilent Modulen ausgelesen. Mit den FTPROG bekommt man den gesamten
Inhalt vom EEPROM zurück. Aber von FTDI Chip gibt es funktionien mit den
man einfach den EEPRO Inhalt auslesen kann. Mich hatte es damals
interessiert wie die es gelöst haben.
Kennt vielleicht noch jemand einen Flash der gut verfügbar ist und so
zwischen 16 und 32MBit besitz.
Duke Scarring schrieb:>> Ich könnte noch einen XMEGA an UART Port vom FT2232H anschließen. Der>> würde dann per UART die Firmware erhalten und direct per SPI die Daten>> in den Flash schreiben. Dabei muss man die PROG_B Leitung durch den>> XMEGA auf '0' ziehen. Dann sind alle SPI Pins im TriState.> Ist Dein FPGA schon voll und hat keine Soft-CPU?> Das was der XMEGA machen soll, kann auch gut eine interne CPU mit> übernehmen.
Oder gleich der FT2232H im MPSSE Modus mit dem SPI. So einen Flash zu
proggen ist ja kein Hexenwerk: https://flashrom.org/FT2232SPI_Programmer
oder https://github.com/adafruit/ftdiflash
Das ist auch ein interessanter Hinweis an den ich nicht gedacht habe.
Ich habe schon häufig mit einem xmega den Flash Speicher überschrieben.
Vielen Dank für die tollen Hinweise, das hat mir sehr geholfen. Jetzt
muss ich nur noch die Lösungen durchdenken.
Ich habe mich jetzt für diesen Flash Baustein (W25Q32JVSSIQTR)
entschieden. Der Flash Baustein ist 32MBit groß und ist sehr gut
verfügbar. Ich verwenden diesen Baustein bereits in anderen Projekten
somit schlage ich gleich 2 Fliegen mit einer Klappe.
https://www.mouser.de/datasheet/2/949/w25q32jv_revg_03272018_plus-1489806.pdf
Der Baustein unterstützt das Kommando 0x03 für read und 0x0B für fast
read. Außerdem hat es einen 24Bit Adressbus. Der Baustein unterstützt
den SPI-Standard mit 1 Datenleitung als auch Dual und Quad SPI.
Falls du das Layout ändern muss, mach am besten so ein Multi-Footprint
drauf für SO8(W) und So16W Flash. Denn die Verfügbarkeit kann sich
täglich ändern, wir haben da leidvolle Erfahrung und machen jetzt immer
das Footprint für diese 3 Gehäuse drauf.