Hi Leute, Fehler in einem seriellen Datenstrom (SPI) sollen per CPLD/FPGA erkannt, aber nicht korrigiert werden. Der Datenstrom besteht aus einzelnen Paketen, welche jeweils 14 Bit lang sind. Jedes dieser Pakete soll einzeln gesichert werden.
Einfaches Parity ist zu unsicher.
Ich weiß noch aus der Codierungsvorlesung, dass die meisten Verfahren bei größeren Datenblöcken deutlich weniger Overhead erzeugen. Leider kommen größere Datenblöcke hier nicht in Frage.
Welche Verfahren kommen hier noch in Frage, wenn man z.B. 3 oder 4 Bit für die Fehlererkennung extra spendieren möchte? Es wäre super, wenn mindestens 2 Bitfehler sicher erkennbar sind. Zur Codierung/Decodierung steht ein CPLD zur Verfügung. Allerdings hält sich der verbleibende Platz darin sehr in Grenzen. Es sollte also ein Verfahren sein, dass wenig Resourcen und wenige Takte frisst.
Wenn Du zwei Bitfehler detektieren willst dann kann man es mit Parity in mehreren Dimensionen probieren. (Parity fuer jedes Bit, Parity fuer jedes zweite Bit, Parity fuer jedes dritte Bit) LDPC waere die FEC Variante davon. Das sollte man auch im CPLD, der ja inhaerent wenig Speicher hat, gut implementierbar sein.
Es gibt 3 und 4 Bit CRCs. Polynome in der Liste in dem pdf Koopman "Cyclic Redundancy Code Polynomial Selection for embedded Networks" im www zu finden.
Das klassische aufwandsarme Verfahren ist zwar Schieberegister, sequentiell. Es gibt aber auch eine parallele Implementierung die für Massenspeicher, Datenkanälen zu Satelliten verwendet wurde. Hatte den Vorteil weniger hohe Taktrate in der Logik zu benötigen.
Ich habe jetzt schon ne Weile gegoogelt, aber ne gescheite Quelle, die das schön erklärt und Beispiele zeigt, habe ich noch nicht gefunden, auch, weil ich den richtigen englischen Suchbegriff noch nicht gefunden habe.
So wie ich das verstanden habe, funktioniert das für 16Bit Nutzdaten doch so (0..F entsprechen den 16 Datenbits):
0 1 2 3 P5 4 5 6 7 P6 8 9 A B P7 C D E F P8 P1 P2 P3 P4 P9
Es werden für alle Spalten jeweils die Paritäten gebildet (P1..P4) Dann werden für alle Zeilen die Paritäten gebildet (P5..P8) Zusätzlich wird aus P1..P4 (oder P5..P8) noch P9 gebildet.
Ich finde keine vernünftige Quelle, wieviele Bitfehler in jedem Fall erkannt werden (wohl mindestens 2).
Kreuzparität ist bis jetzt der Favorit, einfach zu verstehen, einfach implementierbar, wenn man nicht korrigieren sondern nur erkennen möchte. Außerdem kann man bei cleverer Anordnung der Parity-Bits sicherstellen, dass im Datenstrom nicht beliebig viele Nullen hintereinander kommen können, was in meinem Fall wünschenswert ist (bei Odd Parity).
Ja. Wobei das am Ende nur eine sehr spezielle Variante eines linearen Blockcodes. Um die Hamming-Distanz zu bestimmen kannst Du alle Codewoerter generieren und die ensprechenden Distanzen zueinander ausrechnen. Mit Matlab und co. sollte das sehr schnell gehen.
Siehe oben. Rechne die Hamming-Distanz aus. Ich weiss nicht ob das schon mal gemacht wurde oder ob es eine analytische Loesung gibt.
Wenn Du wirklich nur 16Bit hast, dann kommst Du mit 5Bit CRC auf eine HD von 3Bit. Du kannst also 2Bit-Fehler sicher detekieren. Und die meistens von den 3Bit-Fehlern auch.
Es gibt natuerliche theoretische Grenzen aber da musst Du mal in ein- nem Grundlagenbuch der Codierungstheorie nachsehen.
Ich habe gestern nochmal darueber nachgedacht und mit dieser Anordnung kannst Du 3 Bitfehler sicher detekieren. Was dann wieder undetektiert beleibt sind Fehler in einem Rechteck. Also wenn z.B. Bit 5,7,D und F jeweils invertiert sind.
Von daher glaube ich auch, dass P9 ueberfluessig ist. (Zumin- dest fuer die Detektion weil es sich aus den restlichen Parity- Bits ergibt und wenn von denen eines falsch uebertragen wurde, dann musst Du das Paket ja sowieso nochmal neu uebertragen)
Warum muss ich dann nochmal übertragen? Ich habe das so verstanden, dass, egal welches Bit kippt, auch wenn ein Parity kippt, die Daten repariert werden können. Dem Algorithmus ist doch völlig egal, was Parity ist, und was Daten sind. Die Fehlerkorrektur kann ja auch fehlerhafte Paritys reparieren. Die Paritys sichern die Daten und die Daten sichern im Gegenzug die Paritys.
Das Problem paßt am besten zu den Fehlerkorrektur-ICs für parallelen Datenbus. Die hatten Mitte der 80er Jahre Aufwind als man meinte Alpha-Teilchen wären ein bleibendes Problem bei DRAMs.
Im "Intel 8206 EDCU" waren diese Konfiguationen wählbar:
Datenblätter und ApplicationNotes oft noch im www zu finden. Teilweise mit den Tabellen für die Taps der XORs. Die Codes sind nichtzyklisch, deshalb recht theoriefrei, deshalb in Büchern nicht behandelt.
Naja - die Grundlagen (Hamming Distanz/Gewicht), Coderate usw. sind schon nuetzlich.
Kannst Du das etwas ausfuehren? War das Material von den Packages damals kontaminiert oder waren die Prozesse noch nicht so ausgereift. (Aber andererseits waren die Strukturen noch wesentlich groesser.) Ich war damals noch ganz klein - aber ich finde es ganz nuetzlich von alten Geschichten/Fehlern/Fehleinschaetzungen zu lernen.
Ich hab mal gehört, daß anno knips Siemens mal Probleme mit keramischen Gehäusen hatte, die mehr radioaktive Spurenelemente enthielten als üblich und daher vermehrt Bitfehler produzierten. Muß so zu der Zeit der
Zudem war man in der Gehäuseform festgelegt. In der Bemusterungs/Einführungsphase vor dem Shrink waren die Chips oft noch so groß daß man sie nur in sidebrazed Cerdips die wohl speziell für DRAMs entwickelt wurden reinbrachte.
Es wird heute zwar in urban legends rein den Keramikgehäusen zugeschrieben. Praktisch können soft-errors beim Anwender aber viele Ursachen haben. Z.B. gab es damals neueingeführte hochdichte Keramik- Vielschichtkondensatoren empfohlen als Abblockkerkos für ICs die im Betrieb selbstheilenden Kurzschlüsse ( inclusive kurzzeitige Spannungseinbrüche ) hatten.
Sharma hat hinten noch ein dickes Kapitel Radiation Effects rein für Raumfahrt. Amsat verwendet keine rad-hard Teile. SpaceX auch nicht:
Dragon's "Radiation-Tolerant" Design
formatting link
"Last week, NASA revealed that SpaceX's first commercial resupply mission to the ISS experienced a number of anomalies in addition to the shutdown of a Falcon 9 first-stage engine, including the loss of one of three flight computers on the Dragon cargo vessel due to a suspected radiation hit. Over the weekend I spoke with John Muratore, SpaceX director of vehicle certification, who said the loss of the computer was a function of the radiation-tolerant system design on which Dragon relies, rather than hard-to-come-by "rad-hardened" parts that can be costly and difficult to upgrade. ... "
Ob man damit zum Mars kommt wird sich zeigen.
Mehr Nährwert zum Thema des threads hat:
formatting link
( alles scans des Comast Technical Reviews , anhand des cumulative-index pdf suchen )
CTR V14-2 Fall 1984 [pdf] Inukai, Snyder "Parallel implementation of linear feedback shift register circuits"
D.h. normalerweise sieht die parallele Implementierung optisch so aus als ob sie mehr Bauteile als die serielle benötigt. Die serielle muß aber dafür höher getaktet werden. In diesem Falle wurde festgestellt daß die ungeliebte serielle ECL-Implementierung auf Leiterplatte voluminöser war als die parallele die in langsamen 74Sxx laufen konnte. Weil ECL Logik-ICs geringere Integrationsdichte als 74Sxx hat.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.