Hallo Zusammen, ich bin ein bisschen verwirrt. Scheinbar sind sämtliche XILINX PROMs als End-of-Life gekennzeichnet. Selbst die für neuere FPGAs wie den Spartan7. Bisher war ich der Überzeugung dass damit die alten Spartan6 aus dem Produktportfolio von XILINX verschwinden sollen. Aber die 7er-Reihe verwendet ja die gleichen PROMs. Ich benutze derzeit für ein Spartan6-Projekt ein SPI-Flash. Die Programmierzeit ist hier jedoch wesentlich länger als beim PROM. Daher würde ich am liebsten für den Spartan7 ein PROM verwenden, das nicht abgekündigt ist. Ist dass nicht mehr zeitgemäß oder gibt es bessere Alternativen zum speichern der Konfigurationsdatei? Ich dachte die Verwendung eines PROMs ist der "Musterweg".
Moin, Sören B. schrieb: > oder gibt es > bessere Alternativen zum speichern der Konfigurationsdatei? evtl. koennte es da langsam interessant werden, statt dem Flash/PROM zum Konfigurieren einen ganzen µController mit ausreichend Flash (und HW-SPI Interface, damit's FPGA hurtig konfiguriert werden kann) herzunehmen. Muesst' man halt mal gucken, ob was preislich und grad verfuegbar und vom Programmieraufwand her geht... Gruss WK
Man kann die SPI Flashes ja auch direkt programmieren mit dem FT2232 zum Beispiel. Über indirekt ist das lahm, richtig. Wir sind glücklich dass es überall mit SPI Flash geht, denn wir haben eh ein PC Interface und die lassen sich dann über das Design einfach direkt und sau schnell updaten. Ich denke da wirst du auf SPI umsteigen müssen.
Vor bzw. mit der EOL-Meldung gibt es üblicherweise einen last-order-Termin. Bis dahin sollte man sich die benötigten Mengen für die nächsten xx Jahre bestellt haben. Ich habe noch nie verstanden, warum Xilinx teure und schwer beschaffbare Sonderlocken-PROMs anbietet. Welche Programmierzeit ist Dir denn wichtig? Die Zeit bis das Design (einmalig) in den Speicher geschrieben wird oder die Zeit, die das FPGA nach dem Einschalten braucht, um die Konfiguration aus dem Speicher rauszuholen?
Vielen Dank schon mal für die nützlichen Tipps! Was mich am SPI-Flash stört ist ausschließlich die Zeit die ich während der Codeentwicklung zum beschreiben des PROMs benötige. Die normale Bootup-Zeit des Systems ist mir egal. Da sich der FPGA beim Startup mit einem PIC synchronisiert, muss das System nach dem beschreiben des PROMs neu gestartet werden. Ich kann also zum testen nicht einfach nur den FPGA schnell flüchtig beschreiben. Das PROM lässt sich flink in ca 10 sec beschreiben. Das SPI-Flash benötigt 3 min. Das nervt beim Entwickeln. Die Idee über einen FTDI-Chip zu programmieren finde ich interessant. Allerdings muss man dann wahrscheinlich jedes mal das bit-file konvertieren und aus der XILINX-Umgebung raus. Das kostet dann wahrscheinlich alles auch wieder Zeit. Welche Schritte werden dabei denn zusätzlich benötigt? Gibt es einen fertigen bitfile-Konverter dafür?
Sören B. schrieb: > Was mich am SPI-Flash stört ist ausschließlich die Zeit die ich während > der Codeentwicklung zum beschreiben des PROMs benötige. Die normale > Bootup-Zeit des Systems ist mir egal. Ok. Der übliche Weg einen SPI-Flash, der am FPGA hängt zu beschreiben geht über ein spezielles FPGA-Design, welches einen JTAG-zu-SPI-Konverter darstellt. Dort läßt sich ggf. Zeit herausholen, wenn man die JTAG-Taktrate hochschraubt und den SPI-Flash im x2 oder x4-Modus beschreibt. Andererseits habe ich auch schon mit größeren FPGA-Systemen gearbeitet, wo trotz Xilinx-PROMs nur das Programmieren der PROMs ca. eine Stunde gedauert hat. Da muß man dann seinen Workflow anpassen (mehr simulieren statt synthetisieren). Duke
Sören B. schrieb: > Die Idee über einen FTDI-Chip zu programmieren finde ich interessant. > Welche Schritte werden dabei denn > zusätzlich benötigt? Gibt es einen fertigen bitfile-Konverter dafür? WIMRE nimmt xc3sprog direkt das Bitfile und macht die Konvertierung automatisch. Duke
Duke Scarring schrieb: > Der übliche Weg einen SPI-Flash, der am FPGA hängt zu beschreiben geht > über ein spezielles FPGA-Design, welches einen JTAG-zu-SPI-Konverter > darstellt. > Dort läßt sich ggf. Zeit herausholen, wenn man die JTAG-Taktrate > hochschraubt und den SPI-Flash im x2 oder x4-Modus beschreibt. Soweit ich weiß macht ja impact dieses Design, wenn man ein SPI-FLASH flasht. So hab ich es bisher gemacht. Entsprechend hat es ja 3 min. gedauert. Der Spartan 6 kann soweit ich weiß nur ein SPI-FLASH im Quad-Mode lesen und nur im einfachen Mode schreiben. Ein Kollege benutzt ein ZYNC-Evalboard. Das Arbeitet mit einem USB-JTAG-Konverter, der über den FPGA das SPI-FLASH beschreibt. Hier geht es komischer Weise deutlich schneller. Wir wissen aber nicht genau warum. In verdacht steht: 1. Flashen wurde in VIVADO besser/schneller umgesetzt als in ISE. 2. SPI-FLASH kann nicht nur im QUAD-Mode gelesen sondern auch beschrieben werden 3. Die Hardware vom ZYNC läßt eine schnellere Programmierung zu als der Spartan 6 Weiß jemand ob was davon zutrifft?
Duke Scarring schrieb: > Andererseits habe ich auch schon mit größeren FPGA-Systemen gearbeitet, > wo trotz Xilinx-PROMs nur das Programmieren der PROMs ca. eine Stunde > gedauert hat. > Da muß man dann seinen Workflow anpassen (mehr simulieren statt > synthetisieren). Eine Stunde ist echt lang! Da sind 3 min. tatsächlich eine Genugtuung. Mehr simulieren statt synthetisieren habe ich mir auch mal vorgenommen. Aber Testbench erstellen ist immer so mühselig.
Duke Scarring schrieb: > Sören B. schrieb: >> Die Idee über einen FTDI-Chip zu programmieren finde ich interessant. >> Welche Schritte werden dabei denn >> zusätzlich benötigt? Gibt es einen fertigen bitfile-Konverter dafür? > WIMRE nimmt xc3sprog direkt das Bitfile und macht die Konvertierung > automatisch. > > Duke Okay, nachdem ich nach dem Tool WIMRE gesucht habe und herausgefunden habe, dass ich alt geworden bin, habe ich mir den xc3sprog angeschaut:) Wenn ich das richtig verstanden habe, simuliert der eine JTAG-Schnittstelle. Somit ersetzt der doch lediglich das XILINX Platformcable. Programmiert wird der SPI-Flash doch weiterhin über den FPGA. Dauert das dann nicht wieder 3 min.? Ich dachte du beschreibst direkt über den FTDI-Chip den SPI-Flash z.B. über Dasy-Chain.
Du kannst bei VIVADO einfach beim "Generate Bit file" den Haken "Bin File" setzen dann purzelt das bin für den Flash gleich mit raus. Ja, indirekt ist langsam, das stimmt, im Quad Modus aber relativ flott. SPI Flash direkt mit FT2232 geht z.B. so: https://flashrom.org/FT2232SPI_Programmer Das kann man dann z.B. mit so einer Chip Klemme drauf.
Sören B. schrieb: > Wenn ich das richtig verstanden habe, simuliert der eine > JTAG-Schnittstelle. Somit ersetzt der doch lediglich das XILINX > Platformcable. Programmiert wird der SPI-Flash doch weiterhin über den > FPGA. Ja. > Dauert das dann nicht wieder 3 min.? Ausprobieren. Das letzte Mal, als ich das probiert habe ging es sehr flott. Man konnte xc3sprog auch noch einen Parameter für die JTAG-Taktfrequenz mitgeben. Die generelle Programmierzeit hängt von mehreren Faktoren ab: - Größe der bit bzw. bin-Datei - SPI-Geschwindigkeit und SPI-Mode - JTAG-Geschwindigkeit - Programmiersoftware (impact/vivado/xc3sprog) Ich habe bei mir eine Ethernetanbindung am FPGA und programmiere den SPI-Flash über TFTP. Das geht dann auch sehr flott. Duke
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.