Hallo, sind euch irgendwelche Vorteile der Xilinx Platform Flash Chips gegenüber Standard-EEPROMs bekannt, wenn man NUR die Konfiguration im FPGA Master Mode in Betracht zieht (Spartan 6), und der PROM-Inhalt mit einem Platform Cable upgedated (kein zusätzlicher uC) wird? Die Konfigurationsdauer ist in meinem Fall eher nebensächlich. Ich konnte nach Einlesen in den UG380 und UG161 und auch zB Low Cost FPGA Konfiguration keinen Vorteil ausmachen, der den viel höheren Preis eines Xilinx PF Chips bei dieser Anwendung rechtfertigt. Habe ich irgendetwas nicht bedacht? MfG
AFAIF ist der Xilinx Plattform Flash ein hochwertiger NOR-Flash mit hoer Datensicherheit, während die einfachen EEPROMs halt billige NAND-Flash Typen sind. Für Anwendung ohne extorbitante Sicherheits- und Verfügbarkeitsanforderungen reichen die normalen EEPROMs.
Falk Brunner schrieb: > AFAIF ist der Xilinx Plattform Flash ein hochwertiger NOR-Flash mit hoer > Datensicherheit, während die einfachen EEPROMs halt billige NAND-Flash > Typen sind. Auch die Standard seriellen SPI-Flashes sind NOR-Flashes. NAND geht hier nicht, da NAND grundsätzlich eine Fehlerkorrektur braucht. http://www.spansion.com/Products/memory/Serial-Flash/Pages/Serial-NOR-Flash.aspx
Danke für euren Input. Bin nun doch am Überlegen, ob ich ein Feature einbaue, um die Konfiguration über Ethernet empfangen zu können, da mein Design sowieso einen Microblaze und eine Ethernet-Schnittstelle enthält. Hier würde sich bei Verwendung eines Platform Flash die Xilinx Application Note XAPP 975 anbieten. Ich hätte mir das so vorgestellt: die Anwendung am Microblaze erkennt in Ethernet-Frames einen "Konfigurations-Identifier", der den Start der Konfigurationsdaten kennzeichnet. Diese werden danach übertragen und im RAM abgelegt, für die richtige Kodierung gibt es bei der XAPP 975 in den Design Files bereits ein fertiges Script (XBINUTIL). Nach Ende der Übertragung kriegt die in XAPP 975, Fig.1 bezeichnete "User Application" ein Signal und gibt die Daten Byte für Byte dem PFP Module weiter, das den Platform Flash updated. Wenn das PFP Module fertig ist ein "Kaltstart" vom FPGA, und der programmiert sich neu. Wäre dankbar für jede Anregung von Leuten mit mehr Erfahrung bzgl. "Firmware-Update over Ethernet" ;) MfG
Ein Nachteil von Standard Flashes kann die Langzeit-Verfügbarkeit sein. Dazu haben wir negative Erfahrung gemacht. Die Hersteller von Standard Flashes kündigen die Bauteile ab, wenn kein Bedarf mehr besteht, egal ob es das FPGA noch gibt. Der Nachfolge-Baustein ist dann möglicherweise nicht mehr Pin- oder SW- kompatibel und erfordert eine Anpassung von Leiterplatte und/oder SW. Bei Plattform Flashes wird sich der FPGA Hersteller bemühen, die selbe Lebensdauer für FPGA und Flash anzubieten. Xilinx selbst empfiehlt die SPI Flashes in ihrer APP-Note für preissensitive Massenproduktion mit kurzer Produktzykluszeit.
Danke Klaus, das hab ich im Xilinx UG380 gelesen. Habe oben nicht erwähnt, dass das für mich auch nicht ausschlaggebend ist. Falls sich bei meinen Recherchen herausstellt dass das Konzept mit dem Flash Update über Ethernet-Frames mit dem Xilinx Platform Flash besser zu implementieren ist, wäre das der Knackpunkt für meine Entscheidung. Wie in meinem letzten Beitrag schon erwähnt, wäre ich dankbar für jede Anregung zu diesem Thema :) MfG
Klaus Falser schrieb: > Ein Nachteil von Standard Flashes kann die Langzeit-Verfügbarkeit sein. > Dazu haben wir negative Erfahrung gemacht. Würde ich gerne genaueres Wissen. > Die Hersteller von Standard Flashes kündigen die Bauteile ab, wenn kein > Bedarf mehr besteht, egal ob es das FPGA noch gibt. > Der Nachfolge-Baustein ist dann möglicherweise nicht mehr Pin- oder SW- > kompatibel und erfordert eine Anpassung von Leiterplatte und/oder SW. Im SO-8 Gehäuse ist Pinkompatibilität kein Problem (ist vielleicht sogar JEDEC Standard). Der standard Lesebefehl (0x03, bzw 0x0B für Fastread) muss auch von allen implementiert werden, SPI Bootflashes werden ja nicht nur bei FPGAs verwendet, sondern auch bei SoCs als Option. Problematisch ist nur das Schreiben auf das Flash, da hat man versäumt einen mandatory Befehl vorzuschreiben. > Bei Plattform Flashes wird sich der FPGA Hersteller bemühen, die selbe > Lebensdauer für FPGA und Flash anzubieten. Hat ausser Xilinx ein anderer Hersteller eigene Flashes? Lattice hat keine. > > Xilinx selbst empfiehlt die SPI Flashes in ihrer APP-Note für > preissensitive Massenproduktion mit kurzer Produktzykluszeit.
stalk schrieb: > Danke Klaus, das hab ich im Xilinx UG380 gelesen. > Habe oben nicht erwähnt, dass das für mich auch nicht ausschlaggebend > ist. > > Falls sich bei meinen Recherchen herausstellt dass das Konzept > mit dem Flash Update über Ethernet-Frames mit dem Xilinx Platform Flash > besser zu implementieren ist, wäre das der Knackpunkt für meine > Entscheidung. > Wie in meinem letzten Beitrag schon erwähnt, wäre ich dankbar für jede > Anregung zu diesem Thema :) > Wichtig ist dabei die Dualboot-Fähigkeit damit eine abgebrochener Updatevorgang nicht zu einem toten Board führt.
Spartan 6 kann problemlos Multiboot mit Fallback bei SPI Flash. Der einzige Vorteil am Platform Flash ist dass man den gegen Auslesen schützen kann Für Online Update ist der PF aber ungeeighnet.
Lattice User schrieb: > Klaus Falser schrieb: >> Ein Nachteil von Standard Flashes kann die Langzeit-Verfügbarkeit sein. >> Dazu haben wir negative Erfahrung gemacht. > > Würde ich gerne genaueres Wissen. Da ist vielleicht ein bischen Pech dabei, Atmel hat die Flash Sparte an Adesto verkauft. Wir haben den AT45BD642D-CNU verwendet, dazu gibts nicht genau kompatibles.
Wir haben da ein ähnliches Problem und mussten uns noch 500 AT45DB081D auf Halde legen. Für das bekloppte Pinout gibts ja kein second source. Leider gabs damals auch keinen anderen 2,5V Flash für den S3e. Heute nehmen wir nur noch Flash mit Standard Pinout, und am liebsten M25Pxx
Klaus Falser schrieb: > Da ist vielleicht ein bischen Pech dabei, Atmel hat die Flash Sparte an > Adesto verkauft. > Wir haben den AT45BD642D-CNU verwendet, dazu gibts nicht genau > kompatibles. Ahh, den hätten wir auch fast eingesetzt. Dessen Features sind allerdings auch eher für Dataflash als für Bootflash Anwendungen gedacht, was sich auch im Preis niederschlägt und unser Einkäufer schaut auf jeden Cent. Die Standardisierung bei SPI Flashes verbessert sich auch immer mehr, inzwischen gibt es auslesbare Parametertabellen, Pageprogramming ...
Lattice User schrieb: > Die Standardisierung bei SPI Flashes verbessert sich auch immer mehr, > inzwischen gibt es auslesbare Parametertabellen, Pageprogramming ... Das setzt aber voraus, dass Impact dies unterstützt, weil die erste Programmierung des Flashs eines Boards über Impact erfolgen muss. Später, wenn man einen Bootloader drauf hat der die ganzen Varianten beherrscht, kann man das Flash natürlich flexibel programmieren. Und dann gibt es auch die "Konfigurations-Firmware/Hardware" des FPGA, welche in der Konfigurationphase das SPI Flash Byte für Byte seriell lesen können muss.
:
Bearbeitet durch User
Klaus Falser schrieb: > Lattice User schrieb: >> Die Standardisierung bei SPI Flashes verbessert sich auch immer mehr, >> inzwischen gibt es auslesbare Parametertabellen, Pageprogramming ... > > Das setzt aber voraus, dass Impact dies unterstützt, weil die erste > Programmierung des Flashs eines Boards über Impact erfolgen muss. Xilinx wird auf Dauer nicht daran vorbeikommen das zu unterstützen. Momentan haben sie ja das Problem, dass jeder Flash nur über seine ID identifiziert wird, und die Parameter Impact bekannt sein müssen. Das gilt natürlich für alle Hersteller. > Später, wenn man einen Bootloader drauf hat der die ganzen Varianten > beherrscht, kann man das Flash natürlich flexibel programmieren. > Und dann gibt es auch die "Konfigurations-Firmware/Hardware" des FPGA, > welche in der Konfigurationphase das SPI Flash Byte für Byte seriell > lesen können muss. Der Lesebefehl (0x03) ist schon sehr lange standardisiert.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.