Online Logiktest auf FPGAs: Wie wird die korrekte Funktion eines FPGAs im Feld sichergestellt?

[M. N. (bmbl2)]

Hallo,

heute hat mich eine Frage beschäftigt, auf die ich nicht wiklich eine 
Antwort gefunden habe.

Vornweg: Ich komme primär aus der Asic-Ecke und für mich sind FPGAs 
bisher entweder schöne Hobby-Projekte oder beruflich tolle Test-Vehikel. 
Aber eben keine "finalen" Produkte. Deshalb fehlt mir da der Blick, wie 
man gewisse Dinge macht, wenn man FPGAs produktiv einsetzt.

Konkret stellt sich mir die Frage, wie (oder ob überhaupt?) Die Logik im 
FPGA online, also im Feld, getestet wird.

Digitale Asic-Logik hat, allein schon aus der Notwendigkeit des 
Asic-Tests in der Produktion her, eingebaute Scan-Ketten, durch die 
effektiv wie durch ein Schieberegister alle FFs im Design zusammenhängen 
und man beliebige Testpatterns durch die Logik schieben kann.

Im kritischen Umfeld kann man sich diese Scan Ketten zu nutze machen und 
einen "online logic built-in self test" fahren. Sprich es sitzt irgendwo 
ein Testcontroller mit einem Pattern Generator, der beim Start oder 
zyklisch die Logik durchtesten kann. Im Automotive Bereich ist das bspw. 
in vielen Teilen Standard, dass die Chips beim Powerup erstmal ihre 
Logik durchklappern.

Wird soetwas auch bei FPGAs gemacht? Wie wird hier bei kritischen 
Projekten sichergestellt, dass die Config keine bitkipper hat, oder 
irgendwelche routing Elemente den Geist aufgeben? Kann man Die 
Konfiguration regelmäßig neu laden? Oder gibt es Prüfsummen-Geschützte 
Logikelemente?

Spontan fällt mir da nur der Weg ein, ein klassisches Lockstep-Design 
mit 2 oder mehr Kernen und Vergleichern zu bauen.

Gibt es hier auch Möglichkeiten, den Zustand des FPGAs und des darin 
enthaltenen Designs auf Konsistenz zu prüfen?

Vielen Dank

[Gustl B. (gustl_b)]

Es gibt natürlich auch bei FPGAs das JTAG Interface und Bitstreams haben 
Checksummen.

[A. F. (chefdesigner)]

Beim Lesen dieses openings stellen sich mir 2 Fragen:

1) Wie kann jemand ASICs bauen und in FPGAs testen, wenn er so wenig 
über diese Bausteine weiß?

2) Wie kann jemand ASICs bauen , wenn er nicht in der Lage ist, die 
einschlägige Literatur darüber zu lesen und muss hier fragen?

---

Nicht nur, dass FPGAs selbstredend über SCAN-PATH FFs verfügen, nein, 
die, die in den ASICs eingebaut werden sollen, werden sogar in den FPGAs 
getestet. Und zwar als funktionelle Logikzelle und nicht etwa über die 
SP-FFs. D.h. das komplette Schaltungsdesign wird im FPGA simuliert und 
zwar sowohl funktionell als auch als Implementierung. Heißt:

a) alles, was im ASIC einmal rennen soll, rennt so mit reduzierter 
Geschwindigkeit vorher auch im FPGA.

b) alles was der ASIC tut, was die umgebende Elektronik tut, was die 
Aktoren und Sensoren machen, wird in MATLAB abgebildet und läuft dann in 
einer Simulink-Simulation in einer FPGA-Farm - gfs auch mehrere 
gleichzeitig. Dabei schalten die FPGAs nicht genau das, was das ASIC 
später tut, sondern der Simulations-Code nutz den FPGA als 
Rechenenknecht.

Für all diese Dinge braucht es entsprechendes Wissen. Unsere 
ASIC-Entwickler haben das. Ich habe es ja sogar und ich mache nur PL.

Was in Sachen Sicherheit in FPGAs passiert:
a) Man kann Mehrfachkopien arbeiten lassen und überwachen
b) Man kann die richtige Konfiguration über eine SEM-IP überwachen 
lassen

Ich nehme an, dass ich diesen Text dann demnächst bei CHATGP und irgend 
einer Hausaufgabe eines angehenden bachelers wiederfinden kann, der hier 
nur trollt und piekt, damit andere seine Arbeit machen.

[M. N. (bmbl2)]

A. F. schrieb:
> Nicht nur, dass FPGAs selbstredend über SCAN-PATH FFs verfügen, nein,
> die, die in den ASICs eingebaut werden sollen, werden sogar in den FPGAs
> getestet. Und zwar als funktionelle Logikzelle und nicht etwa über die
> SP-FFs. D.h. das komplette Schaltungsdesign wird im FPGA simuliert und
> zwar sowohl funktionell als auch als Implementierung. Heißt:

Mir ging es hier darum, wie jemand ein produktives FPGA Design baut. 
Nicht das Testdesign eines Asics im FPGA.

A. F. schrieb:
> Ich nehme an, dass ich diesen Text dann demnächst bei CHATGP und irgend
> einer Hausaufgabe eines angehenden bachelers wiederfinden kann, der hier
> nur trollt und piekt, damit andere seine Arbeit machen.

A. F. schrieb:
> 1) Wie kann jemand ASICs bauen und in FPGAs testen, wenn er so wenig
> über diese Bausteine weiß?

Ganz einfach. Für mich ist die Zuverlässigkeit eines FPGAs vollkommen 
egal. Wenn der im Labor mal komische Sachen machen würde, lade ich den 
Bitstream einfach neu. Deswegen kenne ich mich da auch nicht aus und 
habe einfach mal nachgefragt und darauf gehofft, dass jemand, der da 
eben fit ist, mir da die Möglichkeiten aufzeigt, die es da gibt. da wo 
ich herkomme ist Fragen zumindest keine Todsünde.

Ich finde diese Unterstellungen hier im Forum immer nicht so prickelnd. 
Erstens kennst du mich nicht und weißt nicht, woran ich arbeite, musst 
aber erstmal rauslassen, wie unwissend ich bin, obwohl du meinen Post 
nicht einmal richtig gelesen hast :(.

Dir steht es aber frei mir eine PN zu schreiben. Wenn du mal in der Nähe 
unterwegs bist, bist du natürlich auch herzlich eingeladen dir das mal 
anzuschauen. Das entsprechende Besucher NDA liegt rum...

Mich interessiert nicht, wie man einen Asic prototypt, sondern wie Leute 
ihre FPGA designs "production ready" bekommen und welche 
Sicherheitsmaßnahmen ich in einem FPGA zur Verfügung habe, wenn ich 
diesem in ein Produkt einbaue.

Ich habe eben noch nie ein FPGA Design für freie Wildbahn gesehen. Ist 
das schlimm? Für uns sind FPGAs eben reine Testvehikel. Unser 
Digitaldesign passt sowieso in keinen FPGA rein. Zumindest keinen, den 
wir haben. Die größten, die wir haben, sind Xilinx VU19P. Und wenn wir 
unseren Digitalteil in 4 Sub-Teile spalten, passen diese einzeln da mit 
etwas wohlwollen rein.

A. F. schrieb:
> a) alles, was im ASIC einmal rennen soll, rennt so mit reduzierter
> Geschwindigkeit vorher auch im FPGA.

Das machen wir bspw. etwas anders.
Wir packen möglichst früh so viel, wie geht in den FPGA. Aber eben auf 
reiner RTL ebene. Sprich die Synthese für den FPGA hat außer dem 
funktionalen Verhalten nichts mit der finalen Asic Implementierung zu 
tun. Das machen wir mit dem Hintergrund, dass wir sehr schnell quasi 
über Nacht, eine Prototyping Platform für bspw. Software Kollegen zur 
Verfügung stellen können, die dann ihren Debugger etc., wie sagt man so 
schön, live und in Farbe und bunt, wo anstecken können und da Software 
und andere Sachen entwickeln können, ohne zwei Tage RTL Simulation für 
den Startupcode eines Cortex M zu verbraten... Auf diese Weise steht ein 
FPGA-Image mit großer funktionaler Übereinstimmung bereits wenige Tage 
nach dem Release des RTL Stands zur Verfügung. Zu diesem Zeitpunkt hätte 
die RTL Simulation erst wenige us. bzw ms. simuliert. Und die 
Asic-Synthese wäre noch munter am Zellen schubsen...

Natürlich dient das implizit auch zur Überprüfung, ob der Asic tut. Aber 
der FPGA ist bei uns KEIN integrales Element der Sicherstellung, dass 
der Asic tut. Das wird durch die entsprechenden simulativen / formalen 
Verifikationen sichergestellt. Für die Emulation nehmen wir bspw. ein 
Cadence Palladium. Ist halt kein Prototyp, an dem Leute live was testen 
können und nen JLink / Lauterbach anstöpseln können, um zu testen ob 
ihre debugging setups tun.

A. F. schrieb:
> die in den ASICs eingebaut werden sollen, werden sogar in den FPGAs getestet.

Das ist für uns bspw. nicht praktikabel. Erstens steht eine volle 
Netzliste inklusive Scan-Pfaden erst sehr spät zur Verfügung. Zweitens 
bringt mir, außer, dass sie den FPGA füllt, eine Scan Kette zum 
prototypen im FPGA gar nichts. Diese muss ich sowieso über eine DfT 
Simulation prüfen. Im FPGA fehlen mir sämtliche clock controller (OCC), 
die die Clocks für den scan test bespaßen und etwaige 3rd Party IPs, die 
im Scan Pfad liegen. Bspw. haben unsere zugekauften PLLs und PHYs von 
der Foundry auch Scan-Ketten und sind demenstprechend mit in der Kette 
verbaut. Im FPGA fehlen die. Außerdem kann ich die Scan Kette mit den 
unzähligen Clockgates im Design sowieso nicht richtig auf einen FPGA 
mappen. Da würde mich interessieren, wie ihr das macht. Blöd formuliert 
mappt die ASIC-Synthese viele "FF enables" auf Clock-Gates und baut so 
hundertausende Sub-Clocknetze. Diese kann ich so im FPGA ja auch nicht 
mappen, weil einfach die routing Resourcen dafür fehlen. Die Clock gates 
sind aber für den Scan test relevant.

In dem (traurigen) Wissen, dass der Beitrag ein Fehler war und man hier 
nicht diskutieren sollte: Einen schönen Nachmittag.

[Rick D. (rickdangerus)]

M. N. schrieb:
> sondern wie Leute
> ihre FPGA designs "production ready" bekommen und welche
> Sicherheitsmaßnahmen ich in einem FPGA zur Verfügung habe, wenn ich
> diesem in ein Produkt einbaue.
Irgendwie kann ich deine Frage nicht nachvollziehen.

Hier rennen einige FPGA-Designs seit einigen Jahren 24/7 durch, ohne das 
ich da speziell was 'production ready' machen musste.

Da kommt der FPGA-Chip oder ein FPGA-Modul aufs PCB, dann die 
entsprechende Beschaltung ringsrum und wenn der/die/das Bitstream im 
Flash drin ist, ist man fertig.
Ich brauch da keinen Schutz gegen Bitkipper. Der Bitstream ist mit einer 
Prüfsumme gesichert. Solange der Flash nicht ausfällt, startet das FPGA 
ganz normal beim Einschalten. Wobei ein- bzw. ausschalten ja bei mir nur 
sehr selten vorkommt.

Ich brauch auch keinen zusätzlichen Testcontroller, die irgendwie Logik 
testet oder BScan-Ketten abklappert.

Ich brauche auch kein Lock-Step-Design. Hat ja mein Handy und mein PC 
auch nicht...

[A. F. (chefdesigner)]

M. N. schrieb:
> Ist halt kein Prototyp, an dem Leute live was testen
> können und nen JLink / Lauterbach anstöpseln können, um zu testen ob
> ihre debugging setups tun.
Du kannst an jeden FPGA etwas dranstöpseln und sogar eigene 
Test-Funktionen einbauen, die es gestatten, Verhalten zu sehen, wie es 
bei MCU-Debuggern auch möglich ist.

[Martin S. (strubi)]

M. N. schrieb:
> Wird soetwas auch bei FPGAs gemacht? Wie wird hier bei kritischen
> Projekten sichergestellt, dass die Config keine bitkipper hat, oder
> irgendwelche routing Elemente den Geist aufgeben? Kann man Die
> Konfiguration regelmäßig neu laden? Oder gibt es Prüfsummen-Geschützte
> Logikelemente?

Das korrekte Laden eines Bitstream muss ich a priori der 
FPGA-Architektur des Herstellers ueberlassen. Also: Siehe HW-Referenz 
des entsprechenden Target.

Ich schmeisse mal ein paar Stichwoerter rein:
- JTAG-Cosimulation: Was in der Simulation tut, muss genau so in der HW 
tun (einzige Aenderung: Virtuelles JTAG auf hartes JTAG umschalten).
- Safety: Redundante Strukturen bauen, mit Fehlervektoren in der 
Co-Simulation fuettern
- Security: Glitch-Attacken im Blick behalten (siehe auch Stromverbrauch 
bei Zaehlern)

Wenn CPU-Kerne im Spiel sind und Haftungsausschluesse eher nicht gehen, 
setzt mein Spezi auf Stackmaschinen die mit Fehlerfortpflanzung besser 
klarkommen als ein ARM.

Und dann das ganze nach der Synthese nochmal in der Post-route 
(Gate-level) mit den gesamten Timings. Das ist dann immer sehr 
aufschlussreich :-)

Ob ein Element im ASIC aussteigt oder im FPGA, weil irgend ein schnelles 
Elementarteil wo reinballert, ist fuer mich statistisch einerlei. Der 
Rest geht dann sehr ins Detail, da spielt dann eher die Technologie eine 
Rolle und wie die Packages und Dies aussehen. Schlussendlich gibt der 
Kunde und die Norm den ganzen Rabbel vor, obs Sinn macht oder nicht.

[J. S. (engineer)]

FPGAs und ASICs sind technisch nicht zu vergleichen, damit gibt es 
naturgemäß unterschiedliche Ansätze und Schwerpunkte. Das gilt für die 
Entwicklung und auch die Tests im Feld. Z.B. schleppen viele 
ASIC-Entwickler ihre dort gewonnenen Erkenntnisse aus der Verifikation 
in die FPGA-Welt, was nicht immer zielführend ist. Man muss da etwas 
genauer hinsehen:

Ein Großteil der Freiheitsgrade in einem ASIC sind im FPGA überhaupt 
nicht verfügbar und müssen folglich auch nicht verifiziert werden, da 
sie fest implementiert sind und nicht erst vom Entwickler gebaut werden. 
Es reichen dann funktionelle Simulationen und der direkte Übergang zu 
einem Endtest mit bereits implementierter Hardware. Das gilt in der 
Entwicklung sowie auch im Feld.

Wenn man von bestimmten Formen von "analogen Verschaltungstricks", 
asynchronen Schaltwerken und selbstlaufenden Oszillatoren mal absieht, 
hat man nämlich diejenigen elektrischen Effekte, die einer näheren 
Untersuchung bedürfen und die dann auch Probleme machen können, nur im 
Bereich der IOs und der umliegenden Elektronik.

Dort wo elektrische Probleme in ASICs intern per Redunanz gelöst werden, 
z.B. durch Schaltungsredundanz bei Hazards, gibt es in FPGAs 
entsprechende Logik, die das alles vermeidet: Die FFs sind z.B. 
glitchfrei gebaut, die Metastabilität auf ein Minimum reduziert und in 
den Timings berücksichtigt.  Clock-Chains mit Progression, wie man es 
früher gern gebaut hat, gibt es im FPGA nicht, wenn man sie nicht 
explizit aufbaut und auch passend constrained. Das Schaltverhalten der 
fest verbauten Komponenten wird durch virtuelles Platzieren unter 
Berücksichtung des timings vollzogen, wobei das reale Timing der 
Bauelemente bekannt ist und nicht rückgewonnen oder verifiziert werden 
muss (und damit auch nicht optimiert werden kann). Dieser große Aspekt 
bei ASICs fällt bei FPGAs praktisch komplett weg.

Die Elektronik an sich - auch die IOs und deren Pegel - wird nur 
konfiguriert, also im Rahmen bekannter Grenzen genutzt. Die Verifikation 
beschränkt sich daher die Simulation von IO-Timings, deren Zustände und 
das Verhalten des Logikdesigns, welches diese Komponenten aktiviert und 
nutzt. Die Korrektheit wird per Logiksimulation verifiziert und im 
Einzelfall auch getestet, also anhand einer Baumusterprüfung vollzogen.

Im Feld geschieht die Sicherstellung durch die bereits angesprochene 
Überwachung der Konfiguration sowie Inhalte von RAM-Zellen und der 
SRAM-Speicherblöcke. Für alles gibt es mehr oder weniger automatisierte 
Funktionen und IP-Blöcke, die je nach den Anforderungen der Branche 
implementiert werden. Eine sehr tiefe Überwachung der FPGA-Interna macht 
dabei aber nur in wenigen Fällen wirklich Sinn, denn das geht aus 
FMEA-Sicht sehr schnell in die komplette Überwachung des PCBs, deren 
Elektronik und der Gerätemechnik über, welche funktionell und technisch 
viel anfälliger sind.

Die Wahrscheinlichkeit dass z.B. infolge von hohen Feldstärken oder 
Strahlung irgendwelche Signale im FPGA verfälscht werden oder gar Bits 
in den internen Speicherzellen oder der Config kippen, ist um ein 
Vielfaches geringer, als für mögliche Fehler aufgrund von Störungen auf 
externen Leitungen zu DDR-RAMs oder seriellen Datenbussen.

Im Sinne der Gesamtgerätesicherheit ist also die externe Elektronik, 
deren funktioneller Ablauf und das elektromechanische zunächst zu 
sichern und mit Redundanz auszustatten. Danach kommt lange nichts.

Im letzten Schritt kann man sich die Absicherung des FPGAs überlegen, 
ein Design per Duplizierung, gfs mit Assymmetrierung abzusichern und 
dabei parallele und sequenzielle Redundanz einzubauen. Solche Sachen wie 
die o.a. technische Signalredundanz gibt es heute fast nur noch für 
externe Elektronik, weil die FPGAs innen innerhalb ihrer Clock - Domain 
- Grenzen voll synchron gebaut werden. Man kann sie natürlich asynchron 
bauen, aber das bringt kaum Vorteil, wird von den Tools nicht gut genug 
unterstützt und macht kaum einer. Die sich daraus ergebenden 
Unsicherheiten im Betrieb gibt es also in der Regel gar nicht.

Sobald man nämlich bei FPGAs beginnt, "analog" zu bauen und mit gating, 
händischen Clocknetzen und Taktverschiebungen für Partialdesigns zu 
bauen, wird sofort sehr viel mehr verifikations- und testpflichtig, weil 
es z.B. auf Temperatur- und Streuung hin untersucht werden muss, da das 
nicht mehr durch das Modell abgesichert ist. Dann muss auch die 
Verifikation mit Timing anhand der Platzierung erfolgen und 
Exemplar-Betrachtungen gemacht werden.

Wie gesagt, macht das keiner, wenn nicht unbedingt nötig, weil es der 
grundsätzlichen Strategie beim FPGA-Design, nämlich nur abstrakte 
boolsche Logik zu bauen und den Rest dem tool zu überlassen, völlig 
konterkariert wird. Damit kommen sofort große Unsicherheiten in den 
Entwicklungsprozess, die man ja durch die Nutzung eines FPGAs eigentlich 
herausnehmen möchte. Es ist dann rasch die Grenze erreicht, wo es 
effektiver ist, eine Funktion durch externe Chips zu realisieren, bzw. 
das gesamte Design in einen ASIC zu verpflanzen, weil ich dann eben 
diese Freiheitsgrade habe und sie von den Compilern unterstützt werden.

Als Beispiel: Wenn man ein Altera-Design in einen hard copy versetzt(e) 
und dann in Richtung physischer Optimierung ging, konnte der Compiler 
allein schon durch Verschieben der Elemente, ohne eine Änderung der 
Struktur den kritischen Pfad um 35% entspannen und das design lief fast 
um 50% schneller. Durch Hinzufügen von FFs, die im FPGA an diesen 
Stellen nicht verfügbar waren, gelangen weitere ca. 20% und durch 
Umplatzieren von Elementen und FFs nochmal >10%. Das ganze Viech lief 
dann fast doppel so schnell - mit völlig equivalentem 
Produktionsprozess!

Fazit: Was bei deiner Frage mitschwingt, nämlich die Anforderung an 
funktionale Sicherheit im Feld, wird bei FPGAs im Gegensatz zu ASICs 
schon durch Restriktionen im Entwicklungsprozess gelöst und tritt so gar 
nicht erst auf. Im FMEA-Prozess steht die technische Sicherung des FPGA 
ziemlich weit unten an. Soweit das FPGA physische Probleme machen kann, 
gibt es ausreichende Mechanismen und Methoden, per Redundanz, TMR - ich 
nehme gern QMR - und funktionelle Überwachung des Systemverhalten zu 
sichern.

Das gilt auch für eventuelle sporadische Fehler, die ein FPGA machen 
könnte, welche lange Rechenketten betreffen und die nur schlecht zu 
erkennen sind. Für solche Zwecke gibt es neben der brute force 
Duplizierung auch Beobachtermodelle, welche das Systemverhalten 
modellieren und abschätzen, was ein FPGA "sehen" kann und was es an 
Daten ausrechnen kann. mit einer zweiten Beobachterinstanz kann man das 
Rechenmodell des FPGA selber zum DUT machen, abbilden und überwachen. 
Damit bekommt man sogar kleine Rechenfehler im Rauschen entdeckt. Solche 
Dinge muss man dann machen, wenn man Fehler voneinander abgrenzen will, 
Temperatur-, Strahlungs- und Spannungsgrenzen des Designs ausmessen 
will. BTDT

[Gerhard H. (ghf)]

J. S. schrieb:

> Die Wahrscheinlichkeit dass z.B. infolge von hohen Feldstärken oder
> Strahlung irgendwelche Signale im FPGA verfälscht werden oder gar Bits
> in den internen Speicherzellen oder der Config kippen, ist um ein
> Vielfaches geringer, als für mögliche Fehler aufgrund von Störungen auf
> externen Leitungen zu DDR-RAMs oder seriellen Datenbussen.

(Space-Blickwinkel:)
Nö. Der Chip ist groß wie ein Daumennagel aka Wirkungsquerschnitt
und hat MBit-weise statische RAMs zur Konfiguration; da werden in der
"richtigen" Umgebung sicherlich früher oder später Bitkipper auftreten.
Daten wie Batterie-Ladezustand sind vergleichsweise unwichtig /
selbstkorrigierend, aber die Position im Orbit in ns seit der Referenz-
position darf nicht verloren gehen, das ist essentiell für
Laufzeitmesungen zu anderen Gebilden etc.

Da bleibt für die wichtigen Sachen eigentlich nur Triple Module
Redundancy mit voting, auch wenn das teilweise nur zur Selbst-
beruhigung dient. Wer kann schon sagen, ob ein SEU ein ganzes
Clocknetz trifft oder nur den output des 4711-ten clockbuffers
der von place&route&opt. hingebastelt wurde?
Der FPGA-Benutzer bekommt das normalerweise nicht zu sehen.

Das KonfigurationsRam muss dann eben alle paar Minuten neu geladen
werden, aus einer bekannt guten Quelle (c). Da kommt erschwerend
hinzu, dass BlockRAMs/ROMs auch nur Fenster ins KonfigurationsRAM
sind. Bei BlockROMs ist das weitgehend egal, aber die Register eines
PicoBlaze-Prozessors überleben das neue Laden nicht. Ich habe den
PicoBlaze umgeschrieben, dass er nur UserLand-FlipFlops benutzt.
Er ist etwas größer geworden, aber eigentlich nicht langsamer.

Ich habe hier in einem früheren Leben schon mal einen thread
losgetreten:
<    Beitrag "Hat hier noch jemand die Xilinx AppNote XAPP-186?"     >

404 xapp-186 not found, heute ist es egal.  Die TMR-tools von
Xilinx haben wir nie bekommen, nicht mal die Lötvorschriften
für (damals) aktuelle HiRel Virtexe. Hat auch so funktioniert.

Ich sollte meine TMR-Bibliothek in aktuellem VHDL neu schreiben
als open source. Aber ich will nicht, dass das bei den Mullahs
oder bei Putler landet.

Gruß, Gerhard

[J. S. (engineer)]

Gerhard H. schrieb:
> da werden in der
> "richtigen" Umgebung sicherlich früher oder später Bitkipper auftreten.
Zweifellos, aber dafür haben wir ja eine Config-Überwachung. Ich habe 
bezüglich der Fehlfunktionen von FPGA bei Strahlung (Schwerionen, 
Neutronen und eben auch Gamma, besonders Röntgen) recht viel 
Projekterfahrung und kann sagen, dass die Bitkipper nur ein kleiner 
Ausschnitt sind. Da gibt es SEEs an Ports, die wahrscheinlicher sind und 
auch Dotierung von PN-Übergängen, die zur schleichender Degradation 
führen.

Wo das vorkommt, muss man das gesamte System redundant auslegen. Darin 
inbegriffen ist dann auch das, was das FPGA so tut - gleich, ob 
Strahlungs-geschädigt, oder von EMI betroffen. RAMs sind natürlich ein 
Kandidat, die heute aber eigentlich jeder auf dem Zettel hat und ECC et 
al einbaut, wo benötigt. Auch da zeigt sich interessanterweise, dass 
heutige FPGAs durchausaus unempfindlicher sind, als externe DDR-RAMs. 
Daher stehen die auf der tosave-Liste inzwischen VOR den FPGAs, was 
Implementierungsaufwand angeht.

Die Fragestellung ist dann jeweils auch, wie schnell man einen Fehler 
findet und sicher als einen solchen einstufen kann. Das permanente 
Checken z.B. der Konfiguration oder von Block-RAMs ist mitunter zu 
langsam, um einen sicheren Betrieb zu gewährleisten.

Und es ist eine Frage der Kosten: Nicht selten ist es billiger, die 
kritischen Systemteile statt 3, einfach 4x aufzubauen, als die 
Systemteile selber noch weiter abzusichern und viel zusätzlichen 
Designaufwand zu betreiben. Dann kannst du z.B. bei einem Gerät trotz 
Ausfall eines Teils, mit voller TMR weitermachen.

[M. N. (bmbl2)]

Rick D. schrieb:
> Da kommt der FPGA-Chip oder ein FPGA-Modul aufs PCB, dann die
> entsprechende Beschaltung ringsrum und wenn der/die/das Bitstream im
> Flash drin ist, ist man fertig.
> Ich brauch da keinen Schutz gegen Bitkipper. Der Bitstream ist mit einer
> Prüfsumme gesichert.

Meine Frage bezog sich im Detail auf den bereits konfigurierten Zustand. 
Wenn ich einen FPGA habe, der bspw. SRAM basierte LUTs hat. Wie stelle 
ich sicher, dass die SRAM Zelle in dieser LUT nach 6 Monaten runtime 
nicht einfach mal umkippt.

J. S. schrieb:
> Zweifellos, aber dafür haben wir ja eine Config-Überwachung. Ich habe
> bezüglich der Fehlfunktionen von FPGA bei Strahlung (Schwerionen,
> Neutronen und eben auch Gamma, besonders Röntgen) recht viel
> Projekterfahrung und kann sagen, dass die Bitkipper nur ein kleiner
> Ausschnitt sind. Da gibt es SEEs an Ports, die wahrscheinlicher sind und
> auch Dotierung von PN-Übergängen, die zur schleichender Degradation
> führen.

Danke für die Antwort. Der Hinweis auf SEM-IPs und das klärt das Ganze 
jetzt für mich.

Ich habe mich einfach gefragt, wie man das beim FPGA macht, wo man eben 
nicht die vollständige Logik unter Kontrolle hat.

J. S. schrieb:
> RAMs sind natürlich ein
> Kandidat, die heute aber eigentlich jeder auf dem Zettel hat und ECC et
> al einbaut, wo benötigt. Auch da zeigt sich interessanterweise, dass
> heutige FPGAs durchausaus unempfindlicher sind, als externe DDR-RAMs.
> Daher stehen die auf der tosave-Liste inzwischen VOR den FPGAs, was
> Implementierungsaufwand angeht.

Wie handhabt ihr das ECC Handling der SRAMs?

Ich schildere mal meine Bauchschmerzen damit:
In einer Technologie, die wir haben, sind tatsächlich die Fehlerraten 
der SRAM Zellen relativ gering und eine essentielle Gefahr kommt vom 
Wordline decoder der RAMs. Sprich, es wird eine falsche Adresse 
zugegriffen, oder wenn es schlecht läuft, werden gleichzeitig mehrere 
wordlines aktiviert und die RAM Zellen schießen sich gegenseitig ab, was 
man dann an kaputten Daten wieder merken würde.

Den Inhalt kann ich natürlich mit ECC bspw. modifizierter Hamming Code 
für SECDED absichern. Damit ich den Fehler der Adressdecoder noch mit 
abfange, kann ich natürlich den ECC sowohl über Daten, als auch über die 
Adresse rechnen. Da fange ich, bei klassischem SECDED aber eben nur 
Fehler ab, die höchstens eine Hamming Distanz von 3 im Adresspfad haben. 
Wenn mir der Decoder stirbt, ist die Wahrscheinlichkeit aber gar nicht 
so gering, dass die Adresse mehr als 2 modifizierte bits daneben liegt. 
Da haben wir dann nur die Möglichkeit entweder noch eine CRC mit höherer 
Hamming Distanz mitzuschleifen, oder eben einen RAM zu bauen, der ein 
volles Address-Reencoding macht, und die selektierte Wordline und 
sens-mux wieder re-encodiert in eine Adresse. Und natürlich auch das 
one-hot encoding der wordline prüft.
Der absolute Abschuss sind dann noch solche RAMs, die redundant 
ausgeführte Sense-Amplifier haben und zeitversetzt Redundanz die 
bitlines abfragen, um die Degradation der Verstärker abzufangen.
Dann kommt noch dazu, dass die meisten SRAM Instanzen sich ihr internes 
Timing der Unterschritte eines Zugriffs (precharge, muxing, Auslesen, 
etc...) selbst generieren. Wenn die dafür beide Flanken der Clock 
brauchen, muss man jetzt auch noch sicherstellen, dass nicht nur die 
Frequenz der Clock rising edge zu rising edge passt, sondern auch noch 
ein duty-cycle monitoring mit einbauen, falls die Clock aus einer aus 
einer Primärquelle und keinem Teiler kommt. Der duty cycle monitor ist 
jetzt wieder Zusätzlicher analoger aufwand und kostet Fläche und Strom. 
Wenn der kritische RAM jetzt nicht gigantisch groß ist, kann es dann 
durchaus sein, dass wir den Vogel abschießen und den RAM einfach 
redundant bauen.

[Gerhard H. (ghf)]

M. N. schrieb:

> Wie handhabt ihr das ECC Handling der SRAMs?
>
> Ich schildere mal meine Bauchschmerzen damit:
> In einer Technologie, die wir haben, sind tatsächlich die Fehlerraten
> der SRAM Zellen relativ gering und eine essentielle Gefahr kommt vom
> Wordline decoder der RAMs. Sprich, es wird eine falsche Adresse
> zugegriffen, oder wenn es schlecht läuft, werden gleichzeitig mehrere
> wordlines aktiviert und die RAM Zellen schießen sich gegenseitig ab, was
> man dann an kaputten Daten wieder merken würde.
Der duty cycle monitor ist

... good stuff, but really under NDA...

> jetzt wieder Zusätzlicher analoger aufwand und kostet Fläche und Strom.
> Wenn der kritische RAM jetzt nicht gigantisch groß ist, kann es dann
> durchaus sein, dass wir den Vogel abschießen und den RAM einfach
> redundant bauen.

Wenn man Massen-Influencer hat, wo ein Knoten 100erte von getrennten 
Bits beeinflusst, dann ist man eben am Ende wenn man keinen Zugriff auf 
die Innereien der Baugruppe / des RAMs hat. Dann bleibt nur, tatsächlich 
das ganze RAM 3* aufzubauen und die angesprochene location per 3ple 
Module Redundancy zu heilen. Ja, dann bleiben möglicherweise 255 von 256 
potentionelle Fehler zurück; die kann man eben erst heilen wenn die 
locations tatsächlich angesprochen werden. Das ist schon unbefriedigend, 
aber man kann das Design auch so komplex machen bis die eigenen 
Designfehler überwiegen.

Ich glaube, schon $DAMALS zu 80186-Zeiten gab es den 8707/8708 DRAM 
controller, der beim Refresh die DRAMs putzen konnte. Damals herrschte 
gerade Panik wegen DRAMs in Keramikgehäusen und Alpha-Strahlen etc.  Mit 
diesem Feature habe ich mich  $DAMALS völlig zurückgehalten. Die 
Autokorrektur hat die Tendenz, für vergleichsweise wenigstens halbwegs 
ähnliche Performance die  Zeitparameter eher schärfer anzuziehen. Und 
damit fällt man dann nachvollziehbar selber auf die Fr. Nur keine 
schlafenden Profs. wecken, das war Multibus-1 für X-25 Datenvermittlung 
in Büroumgebung.

Und hier geht's um Zuverlässigkeit von FPGAs, wo die Kenntnis des 
Konfigurationsrams auf Xilinx, AMD, TSMC beschränkt ist. Da hab' ich 
nicht die mindeste Tendenz, mich in Dotierungsprofile einzumischen. Und 
dieses RAM enthält auch die BlockRams, Registersätze der CPUs und das 
ist nun mal ein bewegliches Ziel, auch wenn es ein MaskFile gibt, das 
sagt was zur eigentlichen Logik des Chips gehört und was der Benutzer 
selber kaputt gemacht haben kann.

Ich erinnere mich an einen strahlungsgefestigten Spannungsregler von 
STM.
Da wurde auch eingestanden, dass ein direkter SEU-Hit den 
Regelverstärker für einige-zig us zum völligen Hohldrehen bringen kann. 
Die vorgeschlagene Abhilfe war ein fetter Ausgangskondensator, damit der 
Regler auch im Berserker-Mode die 3V3-CPU, FPGA oder was auch immer 
nicht töten kann.

Was soll ich da noch machen, wenn nicht mal meine Vcc sicher ist?

Gähn morgens um halb 3,

Grüße, Gerhard

[J. S. (engineer)]

M. N. schrieb:
> Der Hinweis auf SEM-IPs und das klärt das Ganze
> jetzt für mich.
wobei wie erwähnt dieser check eine Weile dauert, da er zyklisch erfolgt 
und eine relevante Zeit vergehen kann, bis der Fehler erkannt wird. Bei 
größeren FPGAs kann das ms dauern, wenn ich mich recht erinnere. In 
sicherheitskritischen Anwendungen kann das zuviel sein, daher müssen die 
FPGA-Funktionen selber geschützt werden, also das, was der FPGA tun 
muss. Das geht dann eben nur Funktionell durch Überwachung und 
Redundanz. So lässt sich dass dann binnen weniger Takte klären, ob eine 
Ergebnis noch verwertbar ist oder man einen von drei FPGAs neu booten 
muss.

Einer meiner Kunden hat zuletzt den SEM-IP für solche Zwecke eingesetzt 
- die von mir vorgeschlagene Redundanz nicht. Das wird über ein 
System-Duplikat gelöst, d.h. die Redundanz wird gnz außen angesetzt. Hat 
natürlich so seine Tücken.

M. N. schrieb:
> In einer Technologie, die wir haben, sind tatsächlich die Fehlerraten
> der SRAM Zellen relativ gering
wie ich sagt, SRAMs sind super stabil - ich habe zuletzt keine externen 
mehr verbaut, aber die internen sind natürlich abgesichert, wenn nötig. 
Daher rühren ja die meistens 9/8-Architekturen der Block-RAMs. Soweit 
das nach FMEA nicht reicht, kommt weitere funktionelle Bits hin oder 
Redundanz und TMR.

> eine essentielle Gefahr kommt vom Wordline decoder der RAMs.
> Sprich, es wird eine falsche Adresse zugegriffen,
Auch das kann man abfangen, wenn man es protokolliert. In einem System 
habe ich mal ein CRC der Adresse mit in den Daten gespeichert. Wenn dann 
die Adresse ausgelesen wird, muss in den Daten diese Adresse auftauchen. 
Wir wollten das sogar patentieren, aber die Recherche war denen dann zu 
groß. Es ist unklar, ob es das damals gfs schon mal gab. Wir haben es 
dann zum Stand der Technik erklärt. Ich hatte das sogar intern in einem 
Vortrag mit drin. Wenn du das exzessiv machen möchtest, kannst du einen 
kompletten CRC16 über die Adresse und die Daten laufen lassen und das 
abspeichern. Damit ist das Einschreiben und das Auslesen geschützt. 
Unterscheidung des Fehlers wieder über Redundanz mit anderem RAM und 
anderer Adresse. Das Einschreiben des CRC muss aber auch über TMR 
passieren - ebenso das Auslesen. Wenn du das nicht machst, hast du zwar 
Wissen über den Fehler, bekommst aber funktionell keinen Gewinn.

Die Aufgabe damals war, es total strahlensicher zu machen, was mir auch 
gelungen ist.

Heute sind wir 15 Jahre weiter und die SRAMs in den FPGAs sind super 
sicher, wie ich selber testen konnte. Um aber jeden Fehler 
auszuschließen, wird man bei sicherheitskritischen Anwendungen einfach 
das ECC-Bit mitverwenden.

Ansonsten bleibt es bei der o.g. Aussage:

Andere Komponenten im System sind oft viel unsicher. Wenn es an das 
Auslesen von Adressdekodern geht, muss man z.B. auch an Bildsensoren 
denken. Auch da kann ein äußerer Einfluss, oder ein kleines 
Spannungsmanko zu einer Fehlfunktion führen. Und auch da gibt es 
Methoden, mit Redundanz an der Auslese der Sensoren zu arbeiten. Dazu 
muss man dann eventuell sogar die Ausleseelektronik auf dem Chip 
weglassen oder umgehen, bzw trickreich für sich nutzen. Eine Redundanz 
nur über dem Bild ist da meistens zu langsam und nicht überall hat man 
mehrere Kameras desselben Inhalts.

[Christoph Z. (christophz)]

J. S. schrieb:
> M. N. schrieb:
>> Der Hinweis auf SEM-IPs und das klärt das Ganze
>> jetzt für mich.
> wobei wie erwähnt dieser check eine Weile dauert, da er zyklisch erfolgt
> und eine relevante Zeit vergehen kann, bis der Fehler erkannt wird. Bei
> größeren FPGAs kann das ms dauern, wenn ich mich recht erinnere. In
> sicherheitskritischen Anwendungen kann das zuviel sein, , also das, was der FPGA 
tun
> muss. Das geht dann eben nur Funktionell durch Überwachung und
> Redundanz. So lässt sich dass dann binnen weniger Takte klären, ob eine
> Ergebnis noch verwertbar ist oder man einen von drei FPGAs neu booten
> muss.

Alles sehr richtig, das bisher geschrieben wurde. Als Ergänzung noch ein 
paar weitere Stichworte bzw. Hinweise:
- Ob der SEM-IP einen Fehler schnell genug erkennen kann, ist natürlich 
Abhängig von der Anwendung
- Der SEM-IP implementiert INNERHALB eines üblichen SRAM FPGAs kann 
selber der Ort des Fehlers sein. Das sind dann "lustige" Risikoanalysen

> daher müssen die FPGA-Funktionen selber geschützt werden

Es gibt neben den bekannten FPGAs noch andere Typen bzw. Hersteller die 
in kritischen Bereichen eher eingesetzt werden.

SRAM Konfiguration ein Problem? Du kannst auch Flash, SONOS oder ein mal 
programmierbares Antifuse haben.

Bitkipper in Registern/Logikzellen ein Problem? Nimm einen FPGA wo jedes 
Design Element schon im Silizium mit TMR gebaut ist.

Bitkipper im SRAM trotz ECC/SECDEC ein Problem? Geh zu einem Hersteller, 
der seine SRAM Zelle mit 12 Transistoren (statt minimal 6) in einem 
Radiation-Hardened Prozess herstellt.

Bitkipper im SEM-IP ein Problem? Nimm einen extra Antifuse FPGA und pack 
den SEM-IP da rein oder kauf einen Space-Grade CPU der den SEM-IP gleich 
mit eingebaut hat (ist ziemlich neu auf dem Markt).

Radiation Test Reports lesen ist anstrengend und dann darüber 
nachzudenken, welche Test jetzt relevant sind für die eigene Anwendung 
ist komplex (und herausfinden, was relevant ist aber nicht getestet 
wurde...).

Gerhard H. schrieb:
> Die vorgeschlagene Abhilfe war ein fetter Ausgangskondensator, damit der
> Regler auch im Berserker-Mode die 3V3-CPU, FPGA oder was auch immer
> nicht töten kann.

Haha, ja den setzen wir auch ein.
Wenn du dann die Sense-Leitung NACH diesem fetten Kondensator 
anschliesst, ist deine Phase-Gain Margin weg und der Regler ganz knapp 
noch Stabil. Darauf wurde im Application Note nicht hingewiesen, das 
haben meine Analog-Kollegen hier selber gefunden.

[J. S. (engineer)]

Christoph Z. schrieb:
> Nimm einen FPGA wo jedes
> Design Element schon im Silizium mit TMR gebaut ist.

Absolut - in  Si fest verbaut ist allemal besser, aber die laufen in 
derart geringen Stückzahlen, dass das preislich rasch ein Problem wird. 
Eine Systemredundanz für Schaltungen im FPGA oder eben die Elektronik 
kommt da schon billiger. Vor allem wenn man es vorsehen muss, um Testen 
zu können, ob man es überhaupt braucht.


Christoph Z. schrieb:
> Darauf wurde im Application Note nicht hingewiesen,
Häh?  Wann hätte es denn je einen Sinn gehabt, eine solche Information 
NACH der Sicherheitsfunktion zu holen?  Bei einem Regler, der noch 
eingreifen soll, muss es auch DAVOR.

> das haben meine Analog-Kollegen hier selber gefunden.
Was gab es da genau herauszufinden?

Solches Sensing wird ja auch z.B. bei Hybrid-Powering betrieben, wenn 
die Spannung für einen linearen Verstärker aus einem SNT kommt, damit 
der nicht soviel nutzlos Leistung verbrät. Das Steuersignal muss dann 
anhand des Bedarfs regelt werden, d.h. der Abgriff der Information 
erfolgt auch VOR den Block-Elkos der Analogstufe, weil selbige ja den 
potentiellen Verzug abfangen sollen. Man muss ja den Spektralbereich 
regeln, den der Elko nicht abdeckt. Auch eine USV arbeitet ja so. Alles 
andere macht irgendwie keinen Sinn (?)

Christoph Z. schrieb:
> - Der SEM-IP implementiert INNERHALB eines üblichen SRAM FPGAs kann
> selber der Ort des Fehlers sein. Das sind dann "lustige" Risikoanalysen
In der Tat. Und den kann man meines Wissens nicht redundant aufbauen.
Das ist übrigens so ein Beispiel, wo man mit internen und lokalen 
Maßnahmen in eine Sättigung läuft und irgendwann nicht mehr sicherer 
wird, weil die Absicherung gegen Fehler in Richtung Abschaltung dann der 
Ökonommie zuwider läuft. Das ist bei Medizingeräten regelmäßig ein 
schmaler Grad: Schaltest du ab und machst Error-Meldung wodurch es 
dauern ausfällt oder machst du es mit funktioneller Redundanz wieder 
sicherer, wodurch es so teuer wird, dass es keiner mehr käuft.

[Christoph Z. (christophz)]

J. S. schrieb:
> Christoph Z. schrieb:
>> Darauf wurde im Application Note nicht hingewiesen,
> Häh?  Wann hätte es denn je einen Sinn gehabt, eine solche Information
> NACH der Sicherheitsfunktion zu holen?  Bei einem Regler, der noch
> eingreifen soll, muss es auch DAVOR.

In diesem Beispiel ging es darum, dass der Regler eben nicht eingreift, 
weil eben der Regler das Problem ist (durch seine SET Sensitivität).

Der Sinn des Remote Feedback dabei war, das der Regler, solange er 
normal läuft, die Eingangsspannung des FPGAs regelt und nicht seine 
Ausgangsspannung, da mit den Radiation Mitigations halt noch ein 
Widerstand und Diode in Serie dazwischen hängt.

Dieser Bericht hier, hat zwar den Unterschied von local und remote 
Feedback auf das SET verhalten untersucht aber eben verpasst, auch noch 
anzusehen, ob er Regler so überhaupt noch im stabilen Bereich arbeitet:
https://radhome.gsfc.nasa.gov/radhome/papers/T111806_RHFL4913.pdf

[J. S. (engineer)]

Christoph Z. schrieb:
> In diesem Beispiel ging es darum, dass der Regler eben nicht eingreift,
> weil eben der Regler das Problem ist (durch seine SET Sensitivität).
...

Christoph Z. schrieb:
> Dieser Bericht hier, hat zwar den Unterschied von local und remote
> Feedback auf das SET verhalten untersucht
...

das zeigt wie komplex das Ganze schnell wird, wenn man in die Tiefe 
geht. Irgendwann muss jedes Bauteil abgesichert werden.