Forum: FPGA, VHDL & Co. Ersatz für XCF16PVOG48C


von Michael (Gast)


Lesenswert?

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.

von Christian R. (supachris)


Lesenswert?

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

: Bearbeitet durch User
von Michael (Gast)


Lesenswert?

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?

von Martin S. (strubi)


Lesenswert?

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.

von Michael (Gast)


Lesenswert?

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.

von Christian R. (supachris)


Lesenswert?

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.

von Martin S. (strubi)


Lesenswert?

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.

von Michael (Gast)


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von Martin S. (strubi)


Lesenswert?

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

von Michael (Gast)


Lesenswert?

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.

von Christian R. (supachris)


Lesenswert?

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

von Michael (Gast)


Lesenswert?

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.

von Michael (Gast)


Lesenswert?

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.

von Christian R. (supachris)


Lesenswert?

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.

von Michael (Gast)


Lesenswert?

Danke für den Hinweis. Ja ich kenne das Thema nur zu gut. Danke für den 
Hinweis

Bitte 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
Noch kein Account? Hier anmelden.