Liebes Forum! Wir haben das folgende Problem mit einer unserer Basiskarten: An einem 8Bit-Mixrocontroller in einer Sicherheitsbaugruppe sollen RAM-Bausteine angeschlossen werden, die mit Speichertestzyklen gefahren werden, so dass man erkennt, ob Fehler entstanden sind. Die Fehler entstehen durch starke Strahlung und sollen korrigiert werden. Der Microcontroller besitzt dazu aber nicht die geforderte Bandbreite, wir hätte also Bedarf für einen zwischen-Chip, der das leisten müsste. Ist jemandem ein solche Chip bekannt, der das leisten könnte? Oder muss dort etwas Eigenes her? Einen logischen programmierbaren Schaltkreis könnte man keicht noch integrieren, es fragt sich, ob es für sowas Standardschaltungen gibt. Soweit mir bekannt, machen RAMs im Computer einen ECC - ich weiß aber nicht, wer das auswertet und wie. ? Danke
Gab es fuer solche Sachen vor vielen Jahren nicht ein Parity-Bit? Wenn es z.B. moeglich ist, die Daten in 7 Bit unterzubringen, koennte man das 8te als Parity verwenden und den Bereich zyklisch pruefen. wendelsberg
Ein Parity wird meistens nicht ausreichen. Wir müssten schon mehrere Bits redundant in die RAMs schieben um es sicher zu machen. Wieviel man da braucht, wird noch analysiert.
Reinhard S. schrieb: > Soweit mir bekannt, machen RAMs im Computer einen ECC - ich weiß aber > nicht, wer das auswertet und wie. Wenn es fertige ECC Bausteine für RAMs mal gegeben hat, dann gibt es die sicherlich heute nicht mehr. Sowas ist längst in jene Komponenten gewandert, die RAMs ansteuern. In heutigen Servern also ins Speicherinterface der Prozessoren selbst. Dürfte auf ein CPLD rauslaufen, wenn Software nicht in Frage kommt. Nur kann sich natürlich auch ein CPLD was einfangen, oder der Controller... oder sind nur die RAMs selbst exponiert?
:
Bearbeitet durch User
Von RAM-Fehlern her gesehen, habe ich schon die wildesten Sachen erlebt. Wenn ganze Reihen von Bits kippen, ist das ja noch schnell zu erkennen wenn der RAM vorher mit Nullen oder Einsen getetstet wird. Interessanter sind die manchmal auftretenden Fehler, die man NUR durch Zufallsmuster erkennt wenn sich z.B. irgendwelche Adressbereiche spiegeln. Einen Bereich mit bunter Mischung beschreiben und Prüfsummen über bestimmte Bereiche bilden wäre ja möglich, solange es dauerhafte Daten sind. Aber bei veränderlichen ist die Sache nicht ganz so trivial. Paritätsprüfung zeigt auch nur Fehler WENN zufällig nur ein Bit betroffen ist, wenn es 2 sind, stimmt die Rechnung wieder.
Immer 16Bit verwenden, bei denen die oberen und unteren 8 Bits immer gleich sind und das beim Lesen auch geprueft wird? Ob das natuerlich mit sinnvollem Aufwand in C zu machen ist? wendelsberg
wendelsberg schrieb: > Immer 16Bit verwenden, bei denen die oberen und unteren 8 Bits immer > gleich sind und das beim Lesen auch geprueft wird? Ist im worst case nicht besser als parity. Man sollte zudem vorher genau wissen, gegen was man sich absichern will. Neben persistenten Fehlern in der RAM Zelle gibts ja auch noch transiente Fehler irgendwo anders. Bitleitung, Wortleitung, ... Wenn man einen Wortleitungsfehler korrigieren können will, dann muss man entweder sehr genau wissen, wie das RAM intern aufgebaut ist, oder man nimmt einen RAM-Baustein pro Bit.
wendelsberg schrieb: > mit sinnvollem Aufwand Nicht umsonst werden bei Flugzeugen getrennte Rechner eingesetzt. Es nützt ja wenig, wenn der RAM ok ist und der Fehler bei der Verarbeitung eintritt.
Reinhard S. schrieb: > An einem 8Bit-Mixrocontroller in einer Sicherheitsbaugruppe sollen > RAM-Bausteine angeschlossen werden, die mit Speichertestzyklen gefahren > werden, so dass man erkennt, ob Fehler entstanden sind. Die Fehler > entstehen durch starke Strahlung und sollen korrigiert werden. Nehmt FRAM. Das ist prinzipbedingt strahlungsunempfindlich, behält seinen Inhalt auch ohne Spannungsversorgung und hat keine ernsthafte Grenze für Schreibzyklen. Schau her: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20110015720.pdf http://www.cypress.com/products/f-ram-parallel http://www.cypress.com/products/f-ram-serial TI hat MSP430 Prozessoren mit FRAM. fchk
Smartfusion2. Wahlweise mit dem integrierten Cortex-M3 oder einen 8Biter drauf konfigurieren. SECDED von Haus aus. Mehr kann man implementieren. Bei dem bisher angedachten Szenario sollte auch der SRAM im uC "behandelt" werden. Gibt es noch 8Biter aus alten Zeiten, die das effizient vorsehen? Oder gibt es so etwas in 8Bit auch als neu?
Frank K. schrieb: > TI hat MSP430 Prozessoren mit FRAM. Ist eine nette Idee, aber deren FRAM adressiert wohl eher nicht die Strahlung. Man hat nichts davon, wenn zwar das FRAM seinen Inhalt behält, aber Prozessor und SRAM durch irgendwelche Fehler Unsinn reinschreiben. Da muss man sich schon eine Gesamtlösung überlegen, wenn es wirklich kritisch ist. Sowas wie ein Master/Checker System beispielsweise, in dem mehrere Systeme parallel laufen und auf Gleichlauf kontrolliert werden. Dummerweise steigt die Komplexität um Grössenordnungen, wodurch die Fehlerwahrscheinlichkeit ebenso absteigt. Lars R. schrieb: > Bei dem bisher angedachten Szenario sollte auch der SRAM im uC > "behandelt" werden. Nicht nur RAM ist gefährdet. Auch normale Logik, Register, ...
:
Bearbeitet durch User
>Nicht nur RAM ist gefährdet. Auch normale Logik, Register, ...
Und das Flash. Die Strukturen sind noch kleiner als RAM.
Der beste Schutz wäre Strahlung gar nicht erst ran zu lassen.
A. K. schrieb: > Lars R. schrieb: >> Bei dem bisher angedachten Szenario sollte auch der SRAM im uC >> "behandelt" werden. > > Nicht nur RAM ist gefährdet. Auch normale Logik, Register, ... Ja, berücksichtigt werden müssen die auch. Aber deren Inhalt ändert sich häufiger. Im Idealfall ständig. Es muss auch nicht jeder Treffer ein Flipflop kippen. Wenn man aber den SRAM "länger" nicht "behandelt", so steht nur noch Müll drin. holger schrieb: >>Nicht nur RAM ist gefährdet. Auch normale Logik, Register, ... > > Und das Flash. Die Strukturen sind noch kleiner als RAM. Für das Kippen einer Flashzelle ist der erforderliche Energiebedarf sehr viel größer. Wenn dann die Belastung so hoch ist, dass keine einzige Addition oder Bitoperation mehr korrekt ausgeführt werden kann, so braucht man sich um den Flash auch nicht mehr zu sorgen. Dann funktioniert auch Redundanz mittels gegenseitiger Überprüfung mehrer Systeme nicht mehr.
wendelsberg schrieb: > Immer 16Bit verwenden, bei denen die oberen und unteren 8 Bits immer > gleich sind und das beim Lesen auch geprueft wird? Du bist mir ein Schlaumeier. Wie willst du die Fehler korrigieren, wenn du nicht weißt, welches Byte gestört ist. Für Erkennung und Korrektur von Fehlern in Datenworten sollte man sich mal mit dem Hammingabstand von Codeworten beschäftigen.
Reinhard S. schrieb: > An einem 8Bit-Mixrocontroller in einer Sicherheitsbaugruppe sollen > RAM-Bausteine angeschlossen werden, die mit Speichertestzyklen gefahren > werden Wie kommst Du darauf, daß man einen SRAM testen müsse? Gibt es eine Vorschrift, die Ihr einhalten müßt und in der das explizit verlangt wird? Eine 4-Transistor SRAM-Zelle ist so ziemlich der sicherste RAM-Speicher, da kippt viel eher was in der CPU um. Ein SRAM-Test war nur in den Anfängen nötig, wo die RAM-Baugruppen noch extra Steckkarten waren und die ICs in billigen Sockeln steckten. Da traten in der Tat sehr häufig Kontaktprobleme auf, die RAM-Fehler vorgaukelten.
Peter D. schrieb: > und die ICs in billigen Sockeln steckten. Das ist Deine Theorie. Auch eingelötete hatten Fehler und Zeitprobleme! Wenn Du Dir Bussignale mal genauer ansiehst, wirst Du begeisteret sein, daß es überhaupt so gut funktioniert.
A. K. schrieb: > Dürfte auf ein CPLD rauslaufen, wenn Software nicht in Frage kommt. Nur > kann sich natürlich auch ein CPLD was einfangen, oder der Controller... > oder sind nur die RAMs selbst exponiert? Es ist auch der Controller betroffen, aber die RAMs sind die großen Datenspeicher. Der Controller hat alles temporär und rechnet mehrfach dasselbe.
Ob das hier die richtige Plattform für sowas ist? Wird wohl eher in Richtung ganz schlechte, schlechte und halbgare Vermutungen gehen. Wie man mit sowas umgeht, ist schon echtes Spezialwissen. Wenn Spezialanforderungen bestehen, sollte auch Spezialwissen vorhanden sein, nicht zusammengeklaubtes. Mein Ansatz wäre: -parallele Systeme (mindestens 3) Ganz grosses Achtung, wenn eins abweicht (und nicht unbedingt annehmen, dass das eine abweichende falsch ist, die anderen beiden aber richtig sind) Vielleicht ist in der Raumfahrttechnik was zu finden, ist deren tägliches Brot, Abschirmung auch nur sehr begrenzt möglich. Ältere Technologien mit grösseren Strukturen können (nicht müssen!) strahlungsfester sein. Ringkernspeicher? :-)
Gerhard schrieb: > Ringkernspeicher? :-) Sehr gutes Stichwort. Genau dafür habe ich mal ein FPGA-Design gemacht. Die RAM-Bausteine und die internen Block-RAM-Areale sind leider von Strahlen betroffen, weil CMOS-basierte S-RAM-Technologien aufgrund ihres Herstellungsprozesses / Dotierung einen hohen Einfangquerschnitt für Teilchen und Elektronen haben. Solange es nur Elektronen sind, kann man von ausschließlich temporären Störungen ausgehen, ansonsten muss man Altersdegradation unterstellen, messen und Teile tauschen. Die Störsicherheitsthematik wurde damals ebenfalls mit Redundanz gelöst. Alle benötigten Werte im FPGA und den RAM-Bausteinen mehrfach hinterlegen und beim Laden auf Konsistenz prüfen bzw. durch Mehrfachrechnen zu sichern. die Ist eine klassische Aufgabe für den FPGA. Auch das Image des FPGAs selber kann man so prüfen. Was an Aufwand zu treiben ist, liegt an der Exposition und die Anforderungen (FMEA). Um eine genügende Sicherheit zu haben kann man einfach die Redundanz steigern, also alle Werte 4x und dann einen Mehrheitsvergleich. Das eventuell kaputte kann man so sehr sicher detektieren und gleich wieder hinbiegen. Da muss man dann halt bauen und auch einfach messen, was passiert.
oszi40 schrieb: > Wenn Du Dir Bussignale mal genauer ansiehst, wirst Du begeisteret sein, > daß es überhaupt so gut funktioniert. Der beste RAM-Test nützt nicht die Bohne, wenn ein Anfänger das Layout macht. Ich hatte mal ein Board von nem externen Dienstleister machen lassen, das sah aus, wie das Spiel Misthaufen. Das Oszi hat dann auch schöne Unterschwinger gezeigt (-2V) und es lief unzuverlässig. Ich habs dann selber gemacht und die Signale sahen aus, wie gemalt.
Hab vor Kurzem ein ähnliches Problem gehabt wie Reinhard! Es gibt da so(ooooo) viele Möglichkeiten. Vor Redundanten Speicher (z.B. TMR), über redundante Speicherblöcke (also alles mehrfach speichern und dann Voten) oder über spezielle Checksummen,... bis hin zu alles in Tantal einwickeln und und Worse Case Berechnungen der Warscheinlichkeitshäufung. Man ist sich da in der Raumfahrt auch nicht ganz einig ;-) Ich habe dann für uns (weil u.A. der Platz für redundante Bauteile/Module) nicht ausreichte und uns die Signale an der Logik ausgingen auf ein "größers" MRAM von Everspin ausgewichen. Zusätzlich hat das Latch-Up Protection der Stromversorgung und eine Signalisolierung bei Latch-Up auslösung bekommen (nicht das der Latch-Up von einem Signal gehalten wird). Dadurch das der Platz im RAM größer ist als wir eigentlich brauchen ist jetzt Platz für redundante Daten, Checksummen sowie (ich meine) Hamming Codierte Daten. PS Wie sicherst du denn die Registerflips im µC durch Bestrahlung? Sind ja auch nur "SRAM-Zellen". - Eine Methode ist Zeitliche Redundanz - Alles mehrfach und Zeitlich versetzt durchführen und dann ein "Diff" über die Einzelergebnisse ;-) Ich meine das CNES dazu ein paar schöne Papers hat...
Wenn es eine Sicherheitsbaugruppe ist sollte eigentlich nach ISO26260 ja auch ein Sicherheitskonzept erstellt worden sein. Wurden Euch den die daraus abgeleiteten Sicherheitsziele übersendet? Weil ansonsten ist die "Erfüllung" dieses Requirements ggf. eine unendliche Geschichte, weil sich das ja fast endlos auf die einzelnen Baugruppenkomponenten unterschiedlich dekomponieren lässt.
Reinhard S. schrieb: > An einem 8Bit-Mixrocontroller in einer Sicherheitsbaugruppe sollen > RAM-Bausteine angeschlossen werden, die mit Speichertestzyklen gefahren > werden, so dass man erkennt, ob Fehler entstanden sind. Die Fehler > entstehen durch starke Strahlung und sollen korrigiert werden. Warum nimmst Du nicht, anstatt da einen zusätzlichen Chip dazwischenzufrickeln, gleich ordentliches rad-hardened RAM? BAE zum Beispiel hat soviel davon davon, daß sie die sogar verkaufen! Beispielsweise sei für das SRAM "Independence" (BAE-Nummer 8427352) die "Featureliste" aus dem BAE-Katalog zitiert: "The 16 Mb monolithic SRAM 'Independance' has total-dose tolerance of greater than 1 Mrad and an upset rate of less than 1E-12 upsets per bit-day. Prompt dose levels are >1E9 rad/sec" Die Anderen üblichen Verdächtigen dürften wohl ähnliche Teile im Programm haben.
Jürgen S. schrieb: > Was an Aufwand zu treiben ist, liegt an der Exposition und die > Anforderungen (FMEA). Um eine genügende Sicherheit zu haben kann man > einfach die Redundanz steigern, also alle Werte 4x und dann einen > Mehrheitsvergleich. Das eventuell kaputte kann man so sehr sicher > detektieren und gleich wieder hinbiegen. Warum wieder hinbiegen wenn man eines von den dreien nehmen kann? Oder meinst du eintragen, damit die nicht wieder verwendet werden, ein Speichermanagament auf der Suche nach fehelerhaften Speicherstellen? Dann einen ASIC Baustein und das System von Grund auf aufbauen oder sich bei den NAND oder anderen Herstellergruppen über APP Note schlaumachen, wie die es machen. 'ASIC' meine 2 ct ;-)
Peter D. schrieb: > Ich habs dann selber gemacht und die Signale sahen aus, wie gemalt. Soviel Eigenlob kenn ich nicht von dir - /* http://www.progforum.com/archive/index.php/t-1623.html */ zudem du da ja einen ganz anderen Standpunkt hast. ;-)
.. schrieb: > Jürgen S. schrieb: >> Was an Aufwand zu treiben ist, liegt an der Exposition und die >> Anforderungen (FMEA). Um eine genügende Sicherheit zu haben kann man >> einfach die Redundanz steigern, also alle Werte 4x und dann einen >> Mehrheitsvergleich. Das eventuell kaputte kann man so sehr sicher >> detektieren und gleich wieder hinbiegen. > > Warum wieder hinbiegen wenn man eines von den dreien nehmen kann? > Oder meinst du eintragen, damit die nicht wieder verwendet werden, > ein Speichermanagament auf der Suche nach fehelerhaften Speicherstellen? > > Dann einen ASIC Baustein und das System von Grund auf aufbauen oder > sich bei den NAND oder anderen Herstellergruppen über APP Note > schlaumachen, wie die es machen. > > 'ASIC' meine 2 ct ;-) Tut dem Mann leid, links vergessen: http://asic-soc.blogspot.de/2007/07/sram-cell-design.html http://www.ece.cmu.edu/~cssi/research/pdf/rethinking-asic-design.pdf http://www.embedded.com/design/mcus-processors-and-socs/4007087/Looking-for-new-SRAM-options-in-embedded-ASIC-and-SOC-designs
wg. Strahlung+Bauteile -> z.B.: bei den "Raumfahrern" fragen... http://www.tesat.de/de/bereiche/bauteile-agentur/services
Für sowas gibts extra Mikrocontroller. Sieh dich mal im Raumfahrtbereich um. Da musst du dann aber RICHTIG viel Geld in die Hand nehmen. Auch wenn du "mehrmals rechnest" nutzt dir das unter Umständen nichts: Auch der Programmcounter, die Stelle des Mehrheitsentscheids etc. können betroffen sein. Daher gibt es für RAM spezielle Codes (z.B. den Hamming-Code) mithilfe dessen du Fehlerkorrektur betreiben kannst. Das gleiche gibts dann auch nochmal für die Prozessorregister. Ansonsten ist der restliche Chip auch mit Rad-Hard Technologie aufgebaut, d.h. es werden Zellen verwendet, die weniger empfindlich auf Strahlung reagieren. Du darfst außerdem nicht nur SEU (single event upsets, also bitkipper) betrachten, sondern musst auch weitere Einflüsse (latchup etc.) mit einbeziehen, falls ihr wirklich Strahlung habt. Das Problem ist insgesamt deutlich komplexer als es hier zu beschreiben ist. Kurz gesagt: Such dir Profis die sowas schonmal gemacht haben!
.. schrieb: > Soviel Eigenlob kenn ich nicht von dir - Ein sauberes 8-Bit Layout ist doch kein Hexenwerk. Konkret war es ein DS80C320 an 32MHz. Daten-/Adreßbus in der Mitte geführt und die ICs rechts und links davon angeordnet, fertig. Wer allerdings denkt, das kann der Autorouter auch, der ist schief gewickelt.
Tüddel schrieb: > Wie sicherst du denn die Registerflips im µC durch Bestrahlung? Sind ja > auch nur "SRAM-Zellen". - Eine Methode ist Zeitliche Redundanz - Alles > mehrfach und Zeitlich versetzt durchführen und dann ein "Diff" über die > Einzelergebnisse ;-) Exakt das ist eine Methode, ja. Theoretisch kann jedes FF in einem FPGA betroffen sein, wenngleich das jeweils auch sehr unwahrscheinlich ist. Mehrfach Dasselbe zu rechnen ist im FPGA sehr leicht in einer pipeline zu machen.
Oder aber gleich Redundant! -> Ist ja ein FPGA, der ist ja predetiniert für Parallelität! Gibt sogar Generatoren/Optimierer dafür die in TMR generieren/umwandeln! Sowol Actel/Microsemi als auch Xilinx haben soetwas...
Ein in dem Zusammenhang vielleicht noch ganz interessantes Paper dazu, wie eine software-basierte Lösung zum Schutz vor strahlungsinduzierten transienten Speicherfehlern aussehen kann und wie gut sie funktioniert (getestet u.a. in einem Satelliten): Philip P. Shirvani, Nirmal R. Saxena, and Edward J. McCluskey: Software-Implemented EDAC Protection Against SEUs, Stanford University Center for Reliable Computing Technical Report No. 01-3, May 2001 http://www-crc.stanford.edu/crc_papers/CRC-TR-01-3.pdf -- Michael
Gegen geladenen Teilchen kommt man mit groesseren Strukturen an, wo eine Ladung nicht viel aendert. Gegen schwere Teilchen, wie Neutronen, die die Struktur beschaedigen, die Kurzschluessen hervorbringen, wird's schwierig. Wieviel elektrische Leistung hat man, welche Strahlenmenge an welchen Teilchen erwartet man, welche Rechenleistung benoetigt man. Allenfalls geht auch ein analoger Roehrenrechner ?
:
Bearbeitet durch User
Lars R. schrieb: > Ja, berücksichtigt werden müssen die auch. Aber deren Inhalt ändert sich > häufiger. Im Idealfall ständig. Es muss auch nicht jeder Treffer ein > Flipflop kippen. Wenn man aber den SRAM "länger" nicht "behandelt", so > steht nur noch Müll drin. Die Wahrscheinlichkeit, dass ein bestimmtes Bit während einer bestimmten Zeitspanne kippt, ist aber für alle Bits mit gleichen elektrischen Eigenschaften gleich gross. Oft den Inhalt zu ändern, hilft da nicht. Ich würde sogar sagen, dass oftmaliges Neu-Schreiben die Wahrscheinlichkeit für ein Kippen sogar erhöht, da sich das Bit für eine längere Zeitspanne in einem Übergangszustand befindet, wo es besonders anfällig für Störungen ist. Wenn also der Programm- oder Stackcounter getroffen wird, viel Glück - da hilft keine softwaremässige Redundanz mehr. Generell halte ich es für fragwürdig, warum der Controller funktioniert, das SRAM hingegen dauernd Fehler produziert. Riecht für mich stark danach, dass hier Fehler vorliegen, die man anderweitig wegdesignen sollte als mit einem RAM-Check.
Vermutlich hat der Prof mal was von RAM-Test gehört und verlangt nun, daß das irgendwie reingepappt werden soll. Ein sicheres Design sieht anders aus. Das fängt zuerst damit an, daß man das keinen Anfänger machen läßt, sondern Leute, die schon mit solchen Projekten Erfahrung haben. Sicherheit kann man nicht einfach aus ner Kiste nehmen und drüberstülpen.
P. M. schrieb: > Generell halte ich es für fragwürdig, warum der Controller funktioniert, > das SRAM hingegen dauernd Fehler produziert. Riecht für mich stark > danach, dass hier Fehler vorliegen, die man anderweitig wegdesignen > sollte als mit einem RAM-Check. Da hab ich doch schon in meinem ersten Post drauf hingewiesen... Register sind auch blos RAM-Zellen...
Tüddel schrieb: > P. M. schrieb: >> Generell halte ich es für fragwürdig, warum der Controller funktioniert, >> das SRAM hingegen dauernd Fehler produziert. Riecht für mich stark >> danach, dass hier Fehler vorliegen, die man anderweitig wegdesignen >> sollte als mit einem RAM-Check. > > Da hab ich doch schon in meinem ersten Post drauf hingewiesen... > Register sind auch blos RAM-Zellen... RAM Zellen sind viel kleiner und deswegen empfindlicher. Es gibt ja nicht nur eine Sorte FF in einem Design, sondern man nimmt die immer nur so gross wie nötig. Im SRAM sind die eher klein und sehr dicht gepackt, so dass jedes Strahlungsteilchen auch trifft, im Controller sind die meist grösser und auch nicht so dicht gepackt. Besonders kritisch wird es dann, wenn das RAM als Programmspeicher dient, da wird es ewig nicht neu beschrieben und ein Bitkipper kann dann irgendwann zuschlagen, wenn die Speicherzelle ausgelesen wird. Und bei Programmspeicher wird sie irgendwann ausgelesen. Bei FF im Controller ist die Wahrscheinlichkeit, dass ein Bitkipper keine Auswirkung hat, viel höher. Das Ganze hängt aber auch noch mächtig von der Technologie ab, bei 90nm und 1,8V sind die FF recht stabil, bei 10nm und 1V sieht das schon anders aus. Gruss Axel
:
Bearbeitet durch User
Oder D. schrieb: > Gegen schwere Teilchen, wie Neutronen, die > die Struktur beschaedigen, die Kurzschluessen hervorbringen, wird's > schwierig. Es gibt speziell dotierte Abschirmungen mit Materialien, die einen für die spezifische Strahlung hohen Einfangquerschnitt haben. P. M. schrieb: > Die Wahrscheinlichkeit, dass ein bestimmtes Bit während einer bestimmten > Zeitspanne kippt, ist aber für alle Bits mit gleichen elektrischen > Eigenschaften gleich gross. Oft den Inhalt zu ändern, hilft da nicht. > Ich würde sogar sagen, dass oftmaliges Neu-Schreiben Die Mimik ist ja die, die RAMs mehrfach aufzuziehen und dann durch Neuschreiben die defekten Infos zu korrigieren. Also ein Mehrheitsentscheid. Axel L. schrieb: > RAM Zellen sind viel kleiner und deswegen empfindlicher. Das haben wir auch gefunden. Wenn es Fehler gab, waren die überwiegend im RAM. Peter D. schrieb: > Das fängt zuerst damit an, daß man das keinen Anfänger machen läßt, > sondern Leute, die schon mit solchen Projekten Erfahrung haben. +1! D:
Reinhard S. schrieb: > werden, so dass man erkennt, ob Fehler entstanden sind. Die Fehler > entstehen durch starke Strahlung und sollen korrigiert werden. Du sprichst das etwas zu gelassen aus. Es besteht nämlich ein himmelweiter Unterschied zwischen "Fehler sollen erkannt werden" und "Fehler sollen korrigiert werden". Ersteres ist vergleichsweise sehr viel einfacher. Das sollte selbst dir klar sein. > Der Microcontroller besitzt dazu aber nicht die geforderte Bandbreite, > wir hätte also Bedarf für einen zwischen-Chip, der das leisten müsste. Unsinn. Was man braucht, ist in diesem Fall ein µc mit der geforderten Bandbreite. Und nicht irgendwelche "Zwischen-Chips". > Soweit mir bekannt, machen RAMs im Computer einen ECC - ich weiß aber > nicht, wer das auswertet und wie. Gemeldet wird das per NMI-Interrupt. Behandelt wird es durch den entsprechenden Handler des OS. Wobei "behandelt" z.B. auch einfach bedeuten kann: "Bluescreen" of death. Was z.B. genau dann passiert, wenn eben nur Fehlererkennung, nicht aber Fehlerkorrektur in diesem Handler implementiert ist. Letzteres ist einfach so komplex, dass man es nicht mal eben mit ein bissel trivialer Logik implementieren kann, das würde mindestens einen passend programmierten FPGA erfordern. Oder halt einfach einen hinreichend leistungsfähigen µC. Aaaber: wenn der RAM strahlungsbedroht ist, dann ist es wohl auch der µC. Dann wird es erst richtig kompliziert...
Immer wieder süß wenn monatealte oder jahrealte Threads ausgebuddelt werden :-P "Wickelblei" ist schon innovativ :-P Da könnte man das ganze auch in HF-Gehäuse eingloddern ;-) OK verscuhen wir mal ernst zu bleibeb (ja ich weiß sit schon drei Jahre alt). Welche Art von Strahlung, Alpha, Beta, Gamma ? ECC RAMs mit eigenen Controller gibt es mit Fheler erkennen, 1bit Fehler beheben bis 3bit Fehler beheben und 4bit erkennen war glaube ich das aktuellste. Suchen könnte helfen aber ich bin genauso faul wie der Thread-Starter :-P Dann gäbe es noch die Variante SD-Karte in Alufolie verpackt und jedes Datum mehrfach mit HASH versehen. Wie funktioniert nochmal RAID6 ?
scherzkeks schrieb: > Wie funktioniert nochmal RAID6 ? Nur sooo lange, bis der damit beschäftigte Contoller oder andere GEMEINSAME Baugruppen keine Lust mehr zum funktionieren haben. Goto Start 13.07.2015
scherzkeks schrieb: > Immer wieder süß wenn monatealte oder jahrealte Threads ausgebuddelt > werden :-P c-hater schrieb: > das würde mindestens einen > passend programmierten FPGA erfordern. Das ist eine Überlegung wert. Hat man ja oft, dass der RAM am FPGA hängt. Sicher lässt sich da was tun. Man schaue auch mal hier: Beitrag "Re: FPGA Standards - Safe FSM Implementation"
scherzkeks schrieb: > Immer wieder süß wenn monatealte oder jahrealte Threads ausgebuddelt > werden :-P Schön, dass sich nochmals ein jemand dazu geäussert hat. Ich lese die Beiträge mit Interesse. Ein kleines update an die Leser: Wie schon angedeutet, wurde ein FPGA-Schaltkreis verwendet, der die Daten dupliziert, mehrfach speichert und sich die richtigen heraussucht.
Und wie geht das dann mit der Sicherheit bei internen Prozessorregistern?
meckerziege schrieb: > Für sowas gibts extra Mikrocontroller. Sieh dich mal im Raumfahrtbereich > um. Da musst du dann aber RICHTIG viel Geld in die Hand nehmen. Genau das wollte man nicht, bzw konnte man nicht. Jürgen S. schrieb: > Und wie geht das dann mit der Sicherheit bei internen > Prozessorregistern? Das ist eine gute Frage, muss ich sagen. Eine Frage, auf die ich keine Antwort habe. Ich denke, dass man mit Störungen des Controllers leben muss. Es war aber auch so, daß die RAMs die kritischen Stellen waren. Gfs ist es so, dass RAMs empfindlicher sind?
> Es war aber auch so, daß die RAMs die kritischen Stellen waren.
Theoretisch oder tatsächlich?
Wenn irgendein Computer (abgesehen vom Totalausfall) nicht tut, was er
soll, würde ich als allerletztes den Fehler beim RAM suchen. Das gilt
ganz besonders für Mikrocontroller jenseits der Gigahertz Welt.
c-hater schrieb: > Du sprichst das etwas zu gelassen aus. Es besteht nämlich ein > himmelweiter Unterschied zwischen "Fehler sollen erkannt werden" und > "Fehler sollen korrigiert werden". Ersteres ist vergleichsweise sehr > viel einfacher. Das sollte selbst dir klar sein. Der Unterschied liegt im Hammingabstand der verwendeten Code-Worte und Nutzung dieser Redundanz beim Auslesen, Paritätssicherung von Blöcken ist eigentlich das Gleiche, nur strukturell anders angelegt.
Dann nimm halt einen µC der das kann was gebraucht wird und bastel nicht extern noch was dran. Wie willst du denn sicherstellen das die Verbindung von 8 Bitter zu FBGA keine Fehler hat ? Du brauchst einen µC mit ausreichend internem Ram. Der folgendes Kann. ECC auf RAM und Flash ECC auf allen internen Bussen ; Daten-, Adress-, Peripherie-, .... LockStep auf dem Rechenkern Finden kann man sowas zb im Automobilbereich. Also Automotiv Freigaben nach ASIL "D" zb von TI die HERCULES Reihe (TMS 570), das sind ARM Cortex Rx Infineon die AURIX Reihe, das sind Tricore Die sind zwar von der Rechenleistung im Vergleich zu dem 8 bitter etwas übertrieben. Aber das ist in dem Fall egal, da bei der Anwendung andere Kriterien gelten.
Nur, um das damalige Thema zu einem Abschluss zu bringen diese Info: Das System mit dem FPGA funktioniert gut. Es wurden auf alle Controllerfunktionen in den FPGA hineingenommen. Der Controller arbeitet doppelt und existiert zweimal, d.h. das Problem eventueller Störungen der Prozessorregister (der offene Punkt) ist damit entschärft. Der neue Prozessor ist ein modifizierter NIOS. Er ist langsam, aber sicher und gut zu überwachen. Die ursprünglicher Frage mit dem sicheren RAM ist ebenso gelöst: Drei Einheiten, die alle dieselben Daten in den RAMs haben und sich austauschen, ob sie stimmen. Eine Fehlfunktion läuft maximal einige Takte bis der Überwacher es merkt. Alle Ausgänge sind bis dahin verzögert und gegen nur GUTE Informationen an das Leitwerk weiter.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.