[OT] ECC RAM

Hi,

Ist leider nen bischen Off Topic... aber weiß von Euch jemand wie bei 64 Bit mit zusätzlichen

8 Bit ein Einzelbitfehler korrigiert wird? Und vor allem: was passiert, wenn eins der ECC-Bits kippt.

Markus

Reply to
Markus Gronotte
Loading thread data ...

Markus Gronotte schrieb:

formatting link

Ich denke mal die machen Golay, Reed-Solomon ist dafür zu aufwendig. Ist aber geraten.

Ist wurscht, welches kippt, solang es in der Summe nicht zuviele sind.

Gruß, JOhannes

--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka "Makus"
 Click to see the full signature
Reply to
Johannes Bauer

Markus Gronotte schrieb:

Codes mit Coderate 64/(64+8)=8/9 existieren.

Das ist egal, jedes Bit läßt sich aus allen anderen rekonstruieren.

Gruß Henning

--
henning paul home:  http://home.arcor.de/henning.paul
PM: henningpaul@gmx.de , ICQ: 111044613
Reply to
Henning Paul

Johannes Bauer schrieb:

Nicht ganz. Die Speicherzugriffszeit wird dann etwas länger, da korrigiert werden muß.

- Henry

--
www.ehydra.dyndns.info
Reply to
Henry Kiefer

Vermutlich deshalb mit realname ...

googlen nach Hamming Code sollte reichen. Encoder/Decoder alle per Standard Array, d.h. ROM/Logiknetz, wegen Geschwindigkeit. Detaillierter kostenpflichtig:

formatting link
Heft 4

Der Decoder wird den Fehler erkennen und korrigieren. Schlimmer wärs wenn diverse Bits kippen, jenseits dessen was der Code zumindest noch als Fehler erkennen kann.

Bei Minicomputern war deshalb scrubbing üblich: ein Hintergrund- programm in der Ruheschleife liest kontinuierlich das RAM. Dadurch sollte vermieden werden daß aus harmlosen Einzelbitfehlern langsam Mehrbitfehler werden.

MfG JRD

Reply to
Rafael Deliano

Rafael Deliano schrieb:

Ah deswegen gibts den Adressbus-Abklapper-Befehl bei der 68K :-)

- Henry

--
www.ehydra.dyndns.info
Reply to
Henry Kiefer

|> Ah deswegen gibts den Adressbus-Abklapper-Befehl bei der 68K :-)

Welchen meinst du da? Falls es nicht movem ist, dachte ich, dass ich alle kenne...

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
 Click to see the full signature
Reply to
Georg Acher

Georg Acher schrieb:

Es gibt einen Testmode-Befehl. Danach zählt die CPU den Adressbus dauernd hoch, bis ein Reset kommt.

- Henry

--
www.ehydra.dyndns.info
Reply to
Henry Kiefer

Naja, ori.w #0,d0 macht das auch und besteht auch nur aus Nullen... Von dem Testmode-Befehl habe ich bis zum 68030 jedenfalls nie was gehört...

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
 Click to see the full signature
Reply to
Georg Acher

Ich bin da vor Monaten mal wohl bei Wikipedia als Einstieg drübergestolpert. Deckt sich auch mit meiner Beobachtung bei Hardwarebasteleien an MacPlus usw., da diese oft mit zählender CPU abstürzten. Kann natürlich auch ein anderer Grund gewesen sein.

Soweit ich mich erinnere, baut Motorola diesen Testbefehl seit mindestens 6809 ein.

- Henry

--
www.ehydra.dyndns.info
Reply to
Henry Kiefer

Mit etwas logischem Nachdenken und dem Wissen, dass Parity per XOR bereits erfunden wurde, solltest Du selber drauf kommen.

Hint:

Man muss die Parity Berechnung ja nicht über alle Bits laufen lassen, man kann auch z.B. die Parity nur der Hälfte aller Datenbits berechnen und dann diese Hälfte jeweils etwas anders auswählen.

Zeigt z.B. das Gesamt-Daten-Parity einen Fehler, aber die Parity über Bit 0 bis 31 nicht, dann muss ein Einzelbitfehler offensichtlich in Bit 32 bis 63 stecken usw.

Weiß ich aber, wo der Bitfehler steckt, dann ist auch sofort offensichtlich, wie das Bit denn nun richtig lautet ;-)

Nunja, auch die kann man in eine Parity Rechnung mit einbeziehen.

Am Ende ist die Parity Rechnung (Hamming Code) so simpel, dass man völlig ohne ROM auskommt. Das ganze passte schon vor gut 25 Jahren in einen TTL Baustein in ALS Technik, also bipolar.

Denn auch der 2^n Decoder war damals bereits erfunden.

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
Reply to
Oliver Bartels

Die erste mir bekannte Erwähnung war in einer BYTE (laut Wikipedia von Dezember 1977). Aber es soll den Begriff schon früher gegeben haben:

formatting link

In einer "Dr. Dobbs" aus jener Zeit (und wohl auch in anderen PC-Zeit- schriften) gab es immer mal wieder "Jux-"mnemonics; unter anderem "BPO"[*]

Gruss, Holger [*] Backspace and Punch operator

Reply to
Holger Petersen

Wenn man denn noch so einen Prozessor rumliegen hat und einen 16-Bit Zähler gerade brauch...

- Henry

--
www.ehydra.dyndns.info
Reply to
Henry Kiefer

Angeblich sollen die Entwickler im 6809 in den 70ern versucht haben für irgendeine Funktion des X-Registers den Mnemonic SEX einzuführen. Wurde aber im letzten Moment von aufmerksamen Vertrieblern bemerkt und eliminiert. Im 68HC12 gibts dann tatsächlich SEX "sign extended into 16 Bit register" aber hat die Attrakivität dieser verquollenen CPU nicht merklich erhöhen können.

MfG JRD

Reply to
Rafael Deliano

Rafael Deliano schrieb:

Den gabs auch offiziell beim 6809. Kann mich noch an ein wunderschönes Plakat der Op-Codes erinnern - ein Kleinod. An so Befehle erinnert man sich leicht ;-)

Vielleicht wurde der Befehl sehr viel später noch umbenannt.

In IPS-Forth wurde der dann übrigens auch umbenannt.

Sex sells - Henry

--
www.ehydra.dyndns.info
Reply to
Henry Kiefer

Hah! Mal die alten Unterlagen durchsehen...wir verbauen noch 6809, man sollte es kaum glauben :)

Ralph.

formatting link

Reply to
Ralph A. Schmid, dk5ras

Warum nicht. Super Prozessor. Hitachi 6309 ist auch interessant.

- Henry

--
www.ehydra.dyndns.info
Reply to
Henry Kiefer

Ja, klar, das Gerät verkauft sich halt immer noch, nur die Peripheriebausteine bekommen wir nicht mehr in ordentlicher Qualität :-( Da haben wir immer wieder unklare Ausfälle...

Ralph.

formatting link

Reply to
Ralph A. Schmid, dk5ras

Gibts den Prozessor überhaupt noch aus Produktion? Oder habt ihr den in ein FPGA verfrachtet? Die Entwicklungsumgebung für 6809 dürfte zumindest ausgereift sein :-)

- Henry

--
www.ehydra.dyndns.info
Reply to
Henry Kiefer

Henry Kiefer wrote: ...

formatting link

hat Files fuer Spartan Entwiclungsboards...

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

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.