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