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
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.
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.
:
Bearbeitet durch User
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...
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.
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.
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
:
Bearbeitet durch User
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
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.
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
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.
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.
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
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.
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.