Forum: FPGA, VHDL & Co. FPGA-Funktionssicherheit


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Hein (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ist jemandem bekannt, welche Tests mit einem neu produzierten FPGA 
gefahren werden, wenn sie aus der Fabrik kommen?

Ich nehme an, die Hersteller spielen zumindest ein image drauf und 
probieren die Funktionen durch. Es geht dabei sowohl im reine FPGAs, als 
auch um SoC-Bausteine.

Mit welcher Sicherheit kann man davon ausgehen, dass die Chips 100% 
funktionieren?

von Ruck-Zuck Fresse dick (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Hein schrieb:
> Mit welcher Sicherheit kann man davon ausgehen, dass die Chips 100%
> funktionieren?

Mit keiner, schau dir einfach mal die Eratasheets an, die die Hersteller 
im laufe der Produktzyklen rausballern, beispiel Block-RM probleme:

https://forums.xilinx.com/t5/Spartan-Family-FPGAs-Archived/Spartan-6-Block-RAM-errata/td-p/256208

von Fitzebutze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ruck-Zuck Fresse dick schrieb:
> Mit keiner, schau dir einfach mal die Eratasheets an, die die Hersteller
> im laufe der Produktzyklen rausballern, beispiel Block-RM probleme:

Ein Erratum betr. Designmangel/Anomalie hat so rein gar nichts mit einem 
Funktionstest zu tun.

@Hein: Du wirst darüber vermutlich keine Details von den Herstellern 
erhalten, aber typischerweise durchlaufen die Chips mehrere Tests:
- Wafer Probe (Funktionstest auf der Siliziumscheibe)
- Boundary-Scan-Tests der einzelnen Funktionszellen
- Finaler Burn-In nach Bonding/Packaging (Testofen)

Damit kann man dann so statistisch gesehen schon eine 100%ige 
Funktionsfähigkeit (minus Epsilon) des Silizium bei Temperatur X, 
Frequenz Y, Strahlung Z, usw. garantieren, für wie lange und bei welcher 
MTBF ist halt sehr variabel.
Die Testdauer ist hier ein Kostenfaktor, gerade Boundary-Scan ist nicht 
sonderlich schnell. Könnte mir schon vorstellen, dass es spezielle 
BIST-Images gibt dafür, die zumindest die Tests nach dem Packaging 
beschleunigen.
Und je nach Industrial oder MIL-Variante sind die Tests und Preise dann 
auch recht unterschiedlich.

von Kastration schafft Weltfrieden (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Hein schrieb:
> Ich nehme an, die Hersteller spielen zumindest ein image drauf und
> probieren die Funktionen durch.

Nein, das wird aus Kostengründen eher selten gemacht, die 
übergeordnetetn Testverfahren sind Prozessüberwachung (durch BIST u.ä.) 
und Stichproben zur Ermittlung Chargen-Qualität und ATPG (Automatic Test 
Pattern Generation).

> Mit welcher Sicherheit kann man davon ausgehen, dass die Chips 100%
> funktionieren?

Geh davon aus, daß die Chips nicht zu 100% funktionieren, das Dir das 
aber entweder nicht auffällt oder es einen Workaround gibt, der die 
defekten Bereiche "ausblendet". Dieser Workarounds kann dir offiiziel 
mitgeteilt werden (bspw. "benutzen sie die Blockrams an den Bereichen 
XxYy nicht in Mode z, die BRAM's in den anderen Bereichen sind OK" oder 
durch ein Softwareupdate der Toolchain "heimlich" eingespielt.

Es gibt aber auch Fälle insbesonders bei neuen Typen, wo der Hersteller 
eben schulterzuckend einräumt, das eben die PLL o.ä. im IC es in diesem 
Temperaturbereich nicht tut oder eben der IC doch 50% mehr Leistung 
verbrät und es dem Kunden nicht anderes übrigbleibt als die PCB's neu zu 
designen.

Während der Wafer-prozessierung wird der gesamte Wafer unabhängig der 
Chipdetails überwacht, ob die Prozessschritte (Belichtung, Etch, etc.) 
auch ordentlich ausgeführt werden. Dazu gibt es "Teststrukturen" auf dem 
Wafer (gern in den Bereichen wo abschliessend die Diamantsäge drüber 
geht) oder es werden spezielle Testwafer denen man ähnlich der 
Layer-kontrollmarken auf PCB's ansieht ob alles i.O. lief. Bspw kann man 
dank Dünnschichtinterferenz dem Wafer an der Farbe ansehen wie dick die 
(Passivierungsschicht) geraten ist, "dazwischen gemischt".
Ist der Wafer OK nach jedem geprüften Prozessschritt OK, geht man davon 
aus, das die Chips OK sind.
In den Chips befinden sich auch gerne BIST-Schaltungen die eine 
"Signatur" ermitteln und diese mit einer Referenz vergleichen
https://de.wikipedia.org/wiki/Signaturanalyse_(Digitaltechnik)
https://de.wikipedia.org/wiki/Built-in_self-test

Damit wird aber eher selten eine 100% Testabdeckung erreicht, was man 
aus Zeitgründen auch nicht unbedingt erreichen will. Bei Hundert 
Millionen Transistoren braucht es halt Ewigkeiten jeden einzelnen zu 
überprüfen, Zeit die man in der Ära der Massenproduktion ohnehin nicht 
hat. Eine Zeitlang hat man sich mit "cleverer" Testpatterngenerierung 
beholfen, Hat also überlegt, welche Herstellungsfehler auftreten könnten 
(bspw. stuck-at-Zero) und hat entsprechende Input-muster ermittelt bei 
denen der Fehler an den Ausgängen sichtbar wird.
https://en.wikipedia.org/wiki/Automatic_test_pattern_generation

Und eben Stichprobenermittlung, da wird eben nur einer von hundert und 
bei reiferen Produkten, einer von tausenden geprüft. Da kann es gut 
sein, das trotzdem die gesamte Charge madig ist (deshalb gibt ja 
beispielsweise Xilinx in den Erratas an, welche Foundry in welchen 
Produktionswochen betroffen sein könnte und bittet um Rücklieferung) 
oder das doch einzelne Blindgänger in dieser Charge hocken.

von Hein (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Auf den Seiten der Hersteller hatte ich schon nachgesehen. Allerdings 
scheinen das sehr subjektive Darstellungen. Nett wären unabhängige 
Quellen.

Irgendwelche sonstigen konkreten Links?

Hat irgendwer sich schon damit befasst FPGAs in der eigenen Fertigung zu 
prüfen?

Oder erfolgt das nur im Zusammenhang des Gesamtsystems?

von Bürovorsteher (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Hat irgendwer sich schon damit befasst FPGAs in der eigenen Fertigung zu
> prüfen?

Nein, das ist sinnlos, weil im FPGA allerseltens alle Bereiche benutzt 
werden. Warum sollte man das Teil aufwendig aussortieren, wenn die 
matschigen Stellen dann ohnehin nicht benutzt werden?

> Oder erfolgt das nur im Zusammenhang des Gesamtsystems?

Ja, bei der Geräteendprüfung. Bisher hatte ich fast keine Probleme; 1 x 
Lattice bei ca 20 k Stück. Mülleimer auf, Baugruppe rein.

von A. F. (artur-f) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Hein schrieb:
> Mit welcher Sicherheit kann man davon ausgehen, dass die Chips 100%
> funktionieren?

Die werden nur auf Waver Ebene getestet, die Bonding und Packaging 
Prozesse werden ebenfalls überwacht und evtl noch ein E-Test 
durchgeführt.

eine 100% Sicherheit hat man nie, jedoch kann ich empfehlen keine FPGA's 
von irgendwelchen Resalern aus China zu kaufen...

von Ruck-Zuck Fresse dick (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Fitzebutze schrieb:
> Ruck-Zuck Fresse dick schrieb:
Hein schrieb:
> Mit welcher Sicherheit kann man davon ausgehen, dass die Chips 100%
> funktionieren?
>> Mit keiner, schau dir einfach mal die Eratasheets an, die die Hersteller
>> im laufe der Produktzyklen rausballern, beispiel Block-RM probleme:
>
> Ein Erratum betr. Designmangel/Anomalie hat so rein gar nichts mit einem
> Funktionstest zu tun.

Ein erratum sagt sehr wohl aus, welche Funktionen der Hersteller nicht 
garantiert. Einfach mal in eins schauen:
https://www.xilinx.com/support/documentation/errata/en247.pdf


> Auf den Seiten der Hersteller hatte ich schon nachgesehen.
aber nur flüchtig, xilinx macht sehr wohl Angaben zur Reliability.

https://www.xilinx.com/support/documentation/user_guides/ug116.pdf

Wenn ich micht recht erinnere gibt es auch Reports für aktuelle 
gefundenen Probleme, für die man sich allerdings anmelden muss. Einfach 
mal den zuständigen FAE fragen

von Hein (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bürovorsteher schrieb:
> Nein, das ist sinnlos, weil im FPGA allerseltens alle Bereiche benutzt
> werden. Warum sollte man das Teil aufwendig aussortieren, wenn die
> matschigen Stellen dann ohnehin nicht benutzt werden?

... weil es vermieden werden soll, eine Baugruppe voll zu bestücken, 
wenn der FPGA nicht funktioniert. FPGA ist billig, Baugruppe teuer.


Ruck-Zuck Fresse dick schrieb:
> Einfach mal den zuständigen FAE fragen
die erzählen einem viel, wenn der Tag lang ist ...

von Ruck-Zuck Fresse dick (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Hein schrieb:
> Ruck-Zuck Fresse dick schrieb:
>> Einfach mal den zuständigen FAE fragen
> die erzählen einem viel, wenn der Tag lang ist ...

Mit dieser Einstellung solltest Du mal zum Psychologen und nicht in eine 
Entwicklungsabteilung gehen.

>Bürovorsteher schrieb:
>> Nein, das ist sinnlos, weil im FPGA allerseltens alle Bereiche benutzt
>> werden. Warum sollte man das Teil aufwendig aussortieren, wenn die
>> matschigen Stellen dann ohnehin nicht benutzt werden?

>... weil es vermieden werden soll, eine Baugruppe voll zu bestücken,
>wenn der FPGA nicht funktioniert. FPGA ist billig, Baugruppe teuer.

Der FPGA funktioniert aber genau dort, wo es die Baugruppe resp. deren 
Funktion als Baugruppe verlangt ... Wie schon geschrieben, es ist 
sinnlos Bauteile nach kriterien auszusortieren, die für die Funktion 
irrelevant sind. Oder geht es hier um den WAF? 
https://en.wikipedia.org/wiki/Wife_acceptance_factor , da ist natürlich 
jede Vernunft hinderlich.

von Bürovorsteher (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> ... weil es vermieden werden soll, eine Baugruppe voll zu bestücken,
> wenn der FPGA nicht funktioniert. FPGA ist billig, Baugruppe teuer.

Das vorherige Aussortieren ist wesentlich teurer (Zeit für eine 
komplette Prüfung, Erstellung der Testpattern, Kosten für den Prüfplatz 
- und wenn es nur ein DSO ist, Verschleiß an Testfassungen, 
Bauteilverluste duch das Handling z.B. verbogene Beine) als aller 
Jubeljahre mal eine komplette Baugruppe zu verschrotten.
Bei mir beläuft sich der Verlust durch defekte FPGA in über zehn Jahren 
auf weit unter 100 EUR bei einer Warenproduktion mit FPGA von ca. 2 Mio 
EUR.
Das sollte man in den meisten Fällen verschmerzen können.

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe keinen Durchsatz an FPGAs, kann daher auch nicht mit 
Stückzahlen argumentieren, aber bei mir gar es bisher nur zwei defekte 
FPGAs, und die hab ich selbst zersemmelt.

Ich könnte mir vorstellen, das bei der Produktion über JTAG ein Test 
gefahren wird um anschließend defekte Reihen oder Spalten per Fuse zu 
deaktivieren. Mit einer solchen Maßnahme dürfte man die Ausbeute 
drastisch steigern.
So ähnlich wird es doch bei den CPUs auch gemacht: Wenn was nicht geht, 
wird der Core deaktiviert und der Chip als Dualcore verkauft, oder mit 
kleinerem Cache...

Duke

von Blechbieger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Ich könnte mir vorstellen, das bei der Produktion über JTAG ein Test
> gefahren wird um anschließend defekte Reihen oder Spalten per Fuse zu
> deaktivieren. Mit einer solchen Maßnahme dürfte man die Ausbeute
> drastisch steigern.

Ich kann mir nicht vorstellen wie das gehen soll ohne dass das Timing 
völlig unvorhersehbar wird.

Ich gehe eher davon aus das der hohe Testaufwand einer der Gründe für 
die hohen Preise ist. Ein anderer sind natürlich die großen Dies und 
dadurch niedrige Ausbeute.

Von Xilinx gab es früher ab gewissen Stückzahlen die günstigeren 
Easypath Varianten. Das war im Prinzip der Ausschuss der nicht 
vollständig funktioniert aber für die Xilinx garantiert dass sie mit 
genau dem einen Bitstream des Kunden funktionieren.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hein schrieb:
> ... weil es vermieden werden soll, eine Baugruppe voll zu bestücken,
> wenn der FPGA nicht funktioniert. FPGA ist billig, Baugruppe teuer.

Das hängt sehr vom FPGA ab. Die derzeit teuersten Bausteine liegen bei 
ca. $80.000 pro Stück. Bei einer Baugruppe, auf der solche FPGAs ist 
natürlich auch nicht nur Vogelfutter für drei Euro drauf, aber die 
Kosten für das FPGA können schon deutlich höher sein als der Rest.

von Kastration schafft Weltfrieden (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Blechbieger schrieb:
> Von Xilinx gab es früher ab gewissen Stückzahlen die günstigeren
> Easypath Varianten. Das war im Prinzip der Ausschuss der nicht
> vollständig funktioniert aber für die Xilinx garantiert dass sie mit
> genau dem einen Bitstream des Kunden funktionieren.

Nope, xilinx garantierte für zwei Bitstreams: der für die eigentliche 
(productive) Anwendung und einen zweiten bspw für die Wartung, 
Board-diagnose.
Und der Rest war nicht zwangsläufig Ausschuss, der von den beiden 
Designs nicht genutzte Bereich wurde einfach nicht geprüft. Xilinx 
leitete aus den bistreams verkürzte Testpattern ab und sparte so 
Testkosten (-zeit, verschleiss) das ist nochmals eine weitere 
Effizienzsteigerung neben dem verbesserten yield.
Für die Erstellung dieser kundenspez. Testprocedure verlangt xilix aber 
auch so um die 10000 US$ und der preisnachlass, bewegte sich so um 
16.00$ statt 16.50$/stück, da lohnt sich das Ganze erst in 100k 
Stückzahlen und kostet die Möglichkeit Bugfixes und neue Features 
nachzuliefern.

von Hein (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Hein schrieb:
>> ... weil es vermieden werden soll, eine Baugruppe voll zu bestücken,
>> wenn der FPGA nicht funktioniert. FPGA ist billig, Baugruppe teuer.
>
> Das hängt sehr vom FPGA ab. Die derzeit teuersten Bausteine liegen bei
> ca. $80.000 pro Stück.

In diesem Falle wäre es ja kein Problem, bei welchen die Baugruppe durch 
das FPGA getestet werden müsste.

In dem von mir skizzierten Fall ist es aber in der Tat so, dass der FPGA 
dreistellig und der Rest fünfstellig ist. Leider ist der FPGA so 
ziemlich das erste Bauteil das montiert wird und kriegt durch den 
Lötprozess hintendrein nochmal kräftig was ab.

von Michael K. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Hein schrieb:
> Mit welcher Sicherheit kann man davon ausgehen, dass die Chips 100%
> funktionieren?

Mit welcher Sicherheit kannst Du sagen das Dein Code und Deine Schaltung 
in allen möglichen Betriebszuständen zu 100% funktionieren?
Was ist wenn das FPGA zu 100% funzt, der Spannungsregler aber nicht?

Ich habe schon viele 100 Fehlfunktionen, Defekte, dramatische Abbrände 
etc. gesehen.
Schnell war da oft die Rede von gefälschten Bauteilen, schlechten 
Chargen etc.
Hat man sich das genau angeschaut, stieß man eigentlich immer auf eine 
Schwäche im Design, die die betreffenden Bauteile oft weit über die max 
Ratings belastet hat.
Die Bauteile sind meist besser als im DS.

Sicherheitskritische Designs sind ohnehin 3fach redundant ausgelegt.
Wenn Dir also auf 100K Bauteile mal ein Defektes geliefert wird, ist das 
wohl zu verschmerzen.
Es gibt umfangreiche Unterlagen zur MTBF Berechnung, in denen viele 
Erfahrungswerte stehen.
Mich hat diese Papierorgie nie so richtig angesprochen weil ich das für 
realitätsfern halte, aber wenn Du da Bock drauf hast, nur zu.

von Besorgter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich hoffe der TO will kein Atomkraftwerk damit steuern ^^

Scherz bei Seite: Es gibt durchaus sehr teure FPGAs, welche dann auch 
für Weltraumanwendungen qualifiziert sind. Die kosten aber schnell mal 
100K das Stück. Dort werden genau definierte Tests gefahren + Screening 
und alles was dazu gehört. Jedes FF ist dann auch noch 3 Fach redundant 
ausgeführt und die Technologie besonders sicher gegen Einflüsse von 
ionisierenden Teilchen...

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Besorgter schrieb:
> Jedes FF ist dann auch noch 3 Fach redundant
> ausgeführt

Dazu interessieren mich Quellen, wie das gebaut und verwendet wird. Wie 
wird eine konträre Information wieder zusammengeführt? 
Mehrheitsentscheider hinter jedem FF?

Eigentlich baut man ja größere Schaltungszzweige redundant auf, sodass 
eine elementare Funktion aus der SPEC abgeschlossen behandelt wird 
(encapsulated requiremenent fullfillment)

von Besorgter (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Besorgter schrieb:
>> Jedes FF ist dann auch noch 3 Fach redundant
>> ausgeführt
>
> Dazu interessieren mich Quellen, wie das gebaut und verwendet wird. Wie
> wird eine konträre Information wieder zusammengeführt?
> Mehrheitsentscheider hinter jedem FF?
>
> Eigentlich baut man ja größere Schaltungszzweige redundant auf, sodass
> eine elementare Funktion aus der SPEC abgeschlossen behandelt wird
> (encapsulated requiremenent fullfillment)

Ja genau. Es wird hierbei ein Mehrheitsentscheid herangezogen. Das 
Schlüsselwort ist hierbei TMR (triple-module redundancy). Microsemi hat 
entsprechende FPGAs im Angebot. Der RTG4 wurde speziell für die 
Anwendung im All entwickelt.

von Christophz (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Eigentlich baut man ja größere Schaltungszzweige redundant auf, sodass
> eine elementare Funktion aus der SPEC abgeschlossen behandelt wird
> (encapsulated requiremenent fullfillment)

Das sind zwei Varianten um an das selbe Ziel zu kommen.

Entweder man nutzt einen FPGA mit TMR in jeder Logikzelle und baut 
klassisch ohne weitere Redundanz. Oder man nutzt einen günstigeren FPGA 
ohne TMR und baut die Redundanz selber ein und zahlt das durch die 
zusätzlich verbrauchten Logikzellen. Die zweite Variante ist üblicher 
wenn keine Strahlungstoleranz nötig ist, da hier übliche Industrie-FPGA 
eingesetzt werden können.

Synopsis verkauft auch ein Tool um eine vorhandene Beschreibung in eine 
TMR gesicherte Variante zu konvertieren.

Besorgter schrieb:
> Microsemi hat
> entsprechende FPGAs im Angebot. Der RTG4 wurde speziell für die
> Anwendung im All entwickelt.

Wenn es nicht gleich ein RTG4 big iron sein muss (der wirklich so um die 
100k kostet) gibt es noch die RTAX (TMR auf Zellebene) und RTPro (TMR 
durch Synthesetool) Serien.
Beachte: Die stehen alle unter ITAR mit entsprechendem Papierkram beim 
Im-/Export.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christophz schrieb:
> Synopsis verkauft auch ein Tool um eine vorhandene Beschreibung in eine
> TMR gesicherte Variante zu konvertieren.

Geht das komplett automatisch?

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
J. S. schrieb:
> Christophz schrieb:
>> Synopsis verkauft auch ein Tool um eine vorhandene Beschreibung in eine
>> TMR gesicherte Variante zu konvertieren.
>
> Geht das komplett automatisch?

Falsche Frage, richtige Frage: ?Taugt das was?

Ich bezweifle das, denn mit in ein Module wie ein FPGA eingebaute 
Redundanz macht man das Modul selbst nicht redundant, sondern nur 
Subsystem innerhalb des Modules. Es verbleibt mind. ein single Point of 
Failure bspw. die Stromversorgung.

https://de.wikipedia.org/wiki/Single_Point_of_Failure


Prominentes Beispiel: 
https://www.handelsblatt.com/politik/deutschland/g20-reise-die-bundeswehr-hat-wohl-keine-schuld-an-merkels-pannen-flug/23801934.html?ticket=ST-61840717-zeMOQGijG4XTMxHW5zwD-ap1

von Thomas U. (thomasu)


Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Es verbleibt mind. ein single Point of
> Failure bspw. die Stromversorgung.

Die Stromversorung hat nichts mit der funktionalen Sicherheit im FPGA zu 
tun und lässt sich grundsätzlich nicht gleich behandeln. Damit ist der 
Rotwangsche Einwurf wieder einmal von der gleichen Qualität wie sonst 
auch.

Selbstredend kann ein FPGA durch ausreichende Massnahmen bei der 
Versorgung unabhängig von der Schaltung gesichert werden. Praktisch je 
Spannung auf heutigen PCBs ist überwacht.

von Thomas U. (thomasu)


Bewertung
1 lesenswert
nicht lesenswert
Michael K. schrieb:
> Mit welcher Sicherheit kannst Du sagen das Dein Code und Deine Schaltung
> in allen möglichen Betriebszuständen zu 100% funktionieren?
> Was ist wenn das FPGA zu 100% funzt, der Spannungsregler aber nicht?

Solche Ausfälle sind leicht zu erkennen, zu protokollieren und 
nachzuweisen, um sie entsprechend zu behandeln / bekämpfen.

Bei der Funktionssicherheit geht es um das zufällig Nichtfunktionieren, 
infolg von (kleinen Spannungseinbrüchen gfs) aber  vor allem Störungen 
auf Informationsleitungen von Außen, Timingproblemen die nicht erkannt 
wurden und Temperaturschwankungen, die nicht ausreichend berücksichtigt 
wurden oder werden konnten.

Der FPGA kann sich theoretisch jederzeit irgendwo vertakten und 
verrechnen, besonders bei EMI und Strahlung, sobald irgendwelche 
Block-RAMs oder gar externe RAMs im Spiel sind und ECC nicht geholfen 
hat. Solche Fehler müssen rechentechnisch erkannt werden, daher werden 
solche Schaltungen entsprechend überwacht und ausgelegt. TMR ist dabei 
nur eine von mehreren Waffen.

von Hans (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Thomas U. schrieb:
> zufällig Nichtfunktionieren, > infolg von

Ich leihe dir zwei "e" für das zufällig-e- und infolg-e- aber ansonsten 
find ich den Beitrag intressant. Wie wahrscheinlich sind solche 
Strahlenfehler?

Welche sonstigen Einflussfaktoren gäbe es denn noch, die solche 
Redundanz erfordern würde?

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thomas U. schrieb:
> C. A. Rotwang schrieb:
>> Es verbleibt mind. ein single Point of
>> Failure bspw. die Stromversorgung.
>
> Die Stromversorung hat nichts mit der funktionalen Sicherheit im FPGA zu
> tun und lässt sich grundsätzlich nicht gleich behandeln.
Doch die Ermittlung der Single Point of Failures ist Bestandteil der 
Analyse im Rahmen der funktionalen Sicherheit. Deshalb beschreibt die 
ISO 26262 auch die Aufstellung der Single Point Fault Metric.

> Damit ist der
> Rotwangsche Einwurf wieder einmal von der gleichen Qualität wie sonst
> auch.

Tolle Argumentation, Bravo; Dir würde ich auf jeden Fall die 
Konstruktions eines Herzschrittmachers oder eines Augenlasers 
anvertrauen, Du weisst, worauf es ankommt ....

>Solche Ausfälle sind leicht zu erkennen, zu protokollieren und
>nachzuweisen, um sie entsprechend zu behandeln / bekämpfen.

Klar, wie erkennt man beispielsweise, das durch einen Spannungseinbruch 
verursacht durch Kriechströme an den V_AUX-Pins die 
SRAM-Konfigurationsbits kippen, die den Redundanz-Comperator auf "always 
on" umfallen lassen??
Und was nützt ein Protokolleintrag in dem in etwa steht "das Kind ist in 
den Brunnen gefallen" ???

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
>>> Synopsis verkauft auch ein Tool um eine vorhandene Beschreibung in eine
>>> TMR gesicherte Variante zu konvertieren.
>>
>> Geht das komplett automatisch?
>
> Falsche Frage, richtige Frage: ?Taugt das was?

Ja, eines unserer Designs ist auf dem Weg zum Mars.

Noch ein Nachtrag dazu: Ich habe inzwischen erfahren, dass auch Mentor 
zu seinen Synthesetools eine TMR Option anbietet.

Thomas U. schrieb:
> Die Stromversorung hat nichts mit der funktionalen Sicherheit im FPGA zu
> tun und lässt sich grundsätzlich nicht gleich behandeln. Damit ist der
> Rotwangsche Einwurf wieder einmal von der gleichen Qualität wie sonst
> auch.

Wenn die Stromversorgung komplett weg ist, hat es nichts mehr mit der 
Funktionalen Sicherheit im FPGA zu tun, weil der ja nix mehr tun kann.

Die Stromversorgung ist aber natürlich zentraler Bestandteil der 
Betrachtung der funktionalen Sicherheit des Gesammtsystems.

Also haben Thomas UND C. A. recht :-)


Ich lege aber nach:
Strahlung, Vibration, Alterungseffekte können die Spannungsregler bzw. 
Schaltregler beeinflussen und so zu erhöhtem Spannungsripple, Peaks oder 
Glitches führen.

Diese können einen direkten Einfluss auf die funktionale Sicherheit des 
FPGA haben, wenn z. B. die Stützkondensatoren zu knapp bemessen sind für 
den Worst-case (Worst-case Temperatur, Worst-case Toleranz, Worst-case 
Alter).
Im Security Bereich sieht man gut, was so alles schiefgeht, wenn 
plötzlich die Spannungsversorgung im blödsten Moment plötzlich kurz zu 
tief ist...
(Power-glitching, eine übliche Side-channel Attacke).

Thomas U. schrieb:
> Der FPGA kann sich theoretisch jederzeit irgendwo vertakten und
> verrechnen, besonders bei EMI und Strahlung, sobald irgendwelche
> Block-RAMs oder gar externe RAMs im Spiel sind und ECC nicht geholfen
> hat. Solche Fehler müssen rechentechnisch erkannt werden, daher werden
> solche Schaltungen entsprechend überwacht und ausgelegt. TMR ist dabei
> nur eine von mehreren Waffen.

Genau, egal ob Block-RAM oder extern, hat alles bei uns ECC drauf und 
die Statusbits werden gespeichert, damit darauf reagiert werden kann 
(Also irgendeine Art Safe-Mode).

C. A. Rotwang schrieb:
> Klar, wie erkennt man beispielsweise, das durch einen Spannungseinbruch
> verursacht durch Kriechströme an den V_AUX-Pins die
> SRAM-Konfigurationsbits kippen, die den Redundanz-Comperator auf "always
> on" umfallen lassen??

Das ist ein wichtiger Punkt, der gar nicht so einfach zum Lösen ist:

- Lösung 1: Keine SRAM FPGAs verwenden (Microsemi Antifuse oder Flash). 
Nachteile: Teuer, keine modernen Chips mit >10 Gbit/S Serdes, Embedded 
CPU, eher hoher Stromverbrauch da eher grössere Chipstrukturen.
- Lösung 2: Bitstream zurücklesen, vergleichen, reagieren (benötigt 
wieder eine dazugehörige Risiko- und Fehlerbetrachtung)
- Lösung 3: Je nach Design kann man den Bitstream schneller neu laden, 
als die möglichen auftretenden Fehler ihre Auswirkung zeigen. Ist ein 
Trick den ich bei Cubesats schon angetroffen hatte. Da wird einfach jede 
Minute der FPGA neu konfiguriert und davon ausgegangen, dass dazwischen 
nichts kaputt gehen kann und höchstens ein paar Messwerte (erkennbar) 
kaputt sind.

Es gibt wohl noch andere kreative Lösungen oder Kombinationen davon, die 
mir noch nicht geläufig sind.

C. A. Rotwang schrieb:
> Und was nützt ein Protokolleintrag in dem in etwa steht "das Kind ist in
> den Brunnen gefallen" ???

In der FMEA steht ja nicht nur drin, dass ein Protokolleintrag gemacht 
wird, sondern was zu tun ist, damit das Kind doch nicht reinfällt oder 
z. B. das automatisch ein Rettungsring dem Kind nachgeworfen wird. (Der 
oben erwähnte Safe-Mode)

von M. W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hans schrieb:
> Welche sonstigen Einflussfaktoren gäbe es denn noch, die solche
> Redundanz erfordern würde?

Miese Leiterbahnen und Lötverbindungen. Diese ändern die Signalform. 
Auch bei der Alterung. Was im Test in der FAB ging, geht oft nach Jahren 
nicht mehr.

von M. W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> Je nach Design kann man den Bitstream schneller neu laden,
> als die möglichen auftretenden Fehler ihre Auswirkung zeigen. Ist ein
> Trick den ich bei Cubesats schon angetroffen hatte. Da wird einfach jede
> Minute der FPGA neu konfiguriert und davon ausgegangen, dass dazwischen
> nichts kaputt gehen kann und höchstens ein paar Messwerte (erkennbar)
> kaputt sind.

Das erfordert aber dann sicher jeweils einer weiteren redundanten FPGA, 
der die komplette Funktion während der Ladepause übernimmt?

: Bearbeitet durch User
von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:
> Das erfordert aber dann sicher jeweils einer weiteren redundanten FPGA,
> der die komplette Funktion während der Ladepause übernimmt?

Kommt darauf an, ob der FPGA systemkritische Aufgaben erledigt (z. B. 
Lageregelung, Powermanagement), dann ist ein zweiter redundanter FPGA 
nötig. Das Umschalten dazwischen erfordert nochmals zusätzliche 
Komponenten, was die Analyse wieder komplexer macht. Diese Komponenten 
sollten möglichst simple und robust sein.

Das Cubesat Beispiel war mehr aus dem Bereich Bilddatenauswertung. Der 
FPGA ist nicht systemkritisch also nicht redundant aber 
missionskritisch. Der Mission ist es aber egal wenn sie z. B. 1 min 
falsche Bilddaten bekommt. Kommt natürlich auf die Mission drauf an (Das 
gehört zur FMEA, die Bewertung wie stark gewichtet ein Fehler ist, 
aufgrund seiner Auswirkungen).

von Thomas U. (thomasu)


Bewertung
0 lesenswert
nicht lesenswert
Hans schrieb:
> Thomas U. schrieb:
>> zufällig Nichtfunktionieren, > infolg von
>
> Ich leihe dir zwei "e" für das zufällig-e- und infolg-e- aber ansonsten
> find ich den Beitrag intressant. Wie wahrscheinlich sind solche
> Strahlenfehler?

Für Systeme, die in Stahlungsgefährdeten Bereichen eingesetzt werden, 
sehr hoch und sehr wahrscheilich. Ohne Behandlung sind Fehlfunktionen 
mehr oder weniger garantiert.

Für normale Anwendungen sind RAMs gegenüber der Strahlung aus dem 
Weltraum und dem Boden resisent genug. Das geht alles im Rauschen unter.

Etwas anderes wären Attacken a la NEMP. Daran arbeiten wir gerade.

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Thomas U. schrieb:
> Etwas anderes wären Attacken a la NEMP. Daran arbeiten wir gerade.

Könntest du uns dann ein paar Tage vorher warnen? ;-)

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thomas U. schrieb:
> Hans schrieb:
>> Thomas U. schrieb:
>>> zufällig Nichtfunktionieren, > infolg von
>>
>> Ich leihe dir zwei "e" für das zufällig-e- und infolg-e- aber ansonsten
>> find ich den Beitrag intressant. Wie wahrscheinlich sind solche
>> Strahlenfehler?
>
> Für Systeme, die in Stahlungsgefährdeten Bereichen eingesetzt werden,
> sehr hoch und sehr wahrscheilich. Ohne Behandlung sind Fehlfunktionen
> mehr oder weniger garantiert.
>
> Für normale Anwendungen sind RAMs gegenüber der Strahlung aus dem
> Weltraum und dem Boden resisent genug. Das geht alles im Rauschen unter.

Naja ist ne Frage was normal ist und welche Fehlerrate akzeptabel. 
Untersuchungen von google haben gezeigt, das RAM-Fehler eher häufig 
auftreten (0.1-1/Monat). Die Daten wurden anhand des ECC-RAMS in den 
google Server Farmen ermittelt. Eine solch hohe Fehlerrate ist schon bei 
der Fliegerrei inakzeptabel:
https://www.zdnet.de/41515463/studie-dram-fehler-sind-weit-haeufiger-als-bisher-bekannt/

Und wir sprechen hier von rechner in klimatisierten und überwachten 
Räumen.

Unterhaltungspause: ein Ausschnitt aus der Tschernobyl-TV-Serie 
bezüglich Strahlenfehler:
Youtube-Video "Chernobyl Episode 4 Scene | HBO | German Robot Joker"
Youtube-Video "Radioactive Robots of Chernobyl - Joker & More - Part 1"

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.