Forum: FPGA, VHDL & Co. Vorteile Xilinx Platform Flash ggü. Standard-EEPROM


von stalk (Gast)


Lesenswert?

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

von Falk B. (falk)


Lesenswert?

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.

von Lattice User (Gast)


Lesenswert?

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

von stalk (Gast)


Lesenswert?

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

von Klaus F. (kfalser)


Lesenswert?

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.

von stalk (Gast)


Lesenswert?

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

von Lattice User (Gast)


Lesenswert?

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.

von Lattice User (Gast)


Lesenswert?

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.

von Christian R. (supachris)


Lesenswert?

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.

von Klaus F. (kfalser)


Lesenswert?

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.

von Christian R. (supachris)


Lesenswert?

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

von Lattice User (Gast)


Lesenswert?

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

von Klaus F. (kfalser)


Lesenswert?

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
von Lattice User (Gast)


Lesenswert?

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