Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #233567

Re: ECC-RAM

Show all headers | View raw

Am 11.10.2017 um 15:09 schrieb Hanno Foest:
> Am 11.10.2017 um 02:59 schrieb Gerhard Hoffmann:
> 
>> Ich habe das schon mal zu 80386-Zeiten auf einer Multibus-Karte benutzt.
>> War aber WIMRE in meinem Fall Intel oder Fairchild. Das war damals, als
>> echte Panik aufkam wegen Bitkippern in RAMs in den edlen Keramik-
>> gehäusen. Plastikgehäuse waren eher nicht betroffen, es waren irgend-
>> welche Isotope in der Keramik, die Alphastrahlen verschossen haben.
>> (Kam später raus.)
> 
> Soweit ich mich erinnere, waren diese Keramikgehäuse aber eine 
> Siemens-Spezialität.

Die Halbleiterhersteller kaufen die Keramikgehäuse vom Spezialisten.
Die Wertschöpfung ist im Vergleich zum Chip selbst vernachlässigbar.
Für Billigchips spendiert man gar nicht erst ein Keramikgehäuse.
Man hat dann irgendwelche organische Pampe auf den Chip gepackt
und gut war's, zumindest für langsame Alphateilchen.
Gegen die schnellen in der kosmischen Strahlung hilft auch
daumendickes Blei nix.

> 
>> Bei ECC kann man dermaßen viel falsch machen, dass es für mich eher
>> das Problem ist, als dessen Lösung es gilt.
> 
> Erzähl doch bitte mal, das klingt interessant.

Überlege mal, wie Du so was überhaupt testen würdest. Kobaltquelle?
Den PC zum Beschleuniger schleppen? Wüsstest DU, welche Zelle getroffen
wird und könntest du verifizieren, was dann genau passieren muss
und ob das auch passiert?
Teststrukturen einbauen verHeisenbugt die Schaltung.
(Observing it affects the outcome)
Die Parity über 32+n oder gar 64+n Bits auszurechnen erfordert
komplexe Gatter mit entsprechend vielen Eingängen; die Korrektur
nochmal. Da sind schnell ein paar Takte vergangen bis die Daten
tatsächlich der CPU zur Verfügung stehen. Weil die CPU-Performance
hauptsächlich von der Speicherbandbreite abhängt, verführt das
natürlich zu Kreativität beim Hochpushen des Taktes.
Das Gewissen wird dabei nur mäßig beansprucht, man hat ja ECC.

Weil du oben Siemens-Rams erwähnt hast: Ich habe mal jemanden
kennengelernt, der hatte Siemens-64K-Rams in seiner Z80-Konstruktion
und das lief alles nicht stabil. Nur das Speichertestprogramm, das
dann aber beliebig lange. Ja, die Rams brauchten 8-Bit-Refreshadressen
und der Z80 hatte nur 7. Das dauernde Umpflügen des Speichers hat
das geschickt verdeckt. Auch ein Heisenbug.
Das war unangenehm, da war schon für die ganze Serie eingekauft.


> Ich seh jetzt gerade keinen so ganz großen Unterschied, ob du den 
> Speicher nachlädst oder korrigierst. Meinem Bauchgefühl nach scheint mir 
> das vom FPGA selbst gesteuerte Nachladen anfälliger zu sein - wie gehst 
> du mit Bitkippern in dem Bereich, der für die Nachlademimik zuständig 
> ist, um?

Das Konfigurationsram des FPGAs kann man nicht korrigieren, das
ist im Chip drinnen. Es ist nicht völlig unmöglich, das Ram auch
wieder auszulesen, aber die Daten enthalten auch don't-care-Stellen
und man braucht ein Maskenfile um nur die tatsächlich vorhandenen
Bits zu betrachten. Wo soll man das nun wieder strahlungsfest
aufheben? Da ist es einfacher, jede Minute das RAM aus einem
strahlungsfesten ROM einfach nachzuladen.

Das geht im Prinzip wie das Booten des FPGAs aus dem ROM, man muss
nur rechtzeitig den Ladetakt stoppen, bevor das FPGA sein globales
Reset am Ende der Ladesequenz aktiviert. Dann wäre nämlich der
Zustand der Benutzer-Schaltung futsch. Wenn man alles richtig
macht, ist das für die Funktionaltät auf Benutzerebene völlig
transparent. Man nennt den Vorgang Scrubben.

Nun ja, nicht völlig transparent. Es gibt im Xilinx Virtex
die Möglichkeit, einen Logikblock statt als Gatter lieber
als 16-Bit-Ram zu benutzen. Das ist in Wirklichkeit ein kleines
Fenster ins Konfigurationsram. Man ahnt schon, was passiert,
wenn man das Konfigurationsram alle Minuten in seinen Grund-
zustand zurücksetzt.

Meine Software-Kollegin hat sich beschwert, dass ihre Register
eine Vorliebe für bestimmte Werte entwickelt haben, wenn man sie
lange genug in Ruhe gelassen hat.(die Register).
Kurz, man darf diese Ramblöcke in einem gescrubbten System nicht
verwenden. Unglücklicherweise benutzt der Picoblaze-Prozessor das
für seine Register. Ich durfte also den Picoblaze umbauen, dass
er nur D-Flipflops benutzt hat. Das war eigentlich recht simpel.
Nebenbei hat es bewiesen, dass das Nachladen funktioniert.  1/2 :-)

Die Nachladelogik ist im Benutzerland von genau dem FPGA, das
nachgeladen wird. Wenn sie getroffen würde, wäre das Spiel aus,
der Inhalt des Konfigurationsspeichers würde ganz langsam
vergammeln.

Deshalb wird alles, was wichtig ist 3-fach redundant ausgeführt.
Jedes FlipFlop, jedes Gatter. Alles ist streng synchron.
In jedem Takt werden die 3 FlipFlops miteinander verglichen.
Wenn eins abweicht, wird es als falsch angesehen und statt dessen
die Mehrheitsmeinung benutzt. Nach dem nächsten Takt ist die Welt
dann wieder in Ordnung.

Dem FPGA-Compiler ist das alles ein Graus. Er stellt umgehend
fest, dass er 2/3 der Logik einsparen kann und dass trotzdem
das gleiche rauskommt. Das ist ihm erstaunlich schwer abzu-
gewöhnen. Der wichtigste Trick dagegen waren je 3 Input-Pins für
True und False. Die wurden ausserhalb des Chips fest mit 0 oder
3.3V verbunden. Das hat man dem Compiler aber nicht verraten.
Optimierungsversuche liefen deshalb ins Leere.

Ich habe mir eine schöne Bibliothek gemacht, die von oben
wie standard_logic / sl_vector aussieht und die Verdreifachung
und die Abstimmung über die Resultate fast völlig verbirgt.
Es gibt auch von Xilinx ein Tool dafür, das gilt aber rechtlich
als Kriegswaffe und darf nicht aus den USA exportiert werden.



> 
>> Unter meinem Schreibtisch würde ein China-Motherboard mit ECC-Feature
>> eher keine Heimat finden.
> 
> Auch hier würde mich die Begründung interessieren
> 
> Ich habe zwei (!) Mal kaputtes RAM gehabt, was zu seltenen Crashes und 
> kaputten Daten geführt hat. Nachdem irgendwelche Checksummen von Dateien 
> nicht stimmten, war der Fall klar, aber memtest hat trotzdem noch 18 
> Stunden gebraucht, um mir Fehler zu zeigen. Sowas wollte ich nie wieder, 
> entsprechend werkelt hier jetzt ECC-RAM unter meinem Schreibtisch. Daß 
> es wirklich funktioniert, und das Mapping der RAM-Sockel auf die 
> Vorstellungen meines Betriebssystems, hab ich ausprobiert, indem ich mit 
> einem an 0 Volt angeschlossenen Widerstand am Speicher rumgeprokelt habe 
> -> haufenweise Fehler angezeigt / korrigiert.
> 
> Im Betrieb hab ich in den letzten 5? Jahren dann nur einen Fehler geloggt.

Ja, genau.

Ich glaube nicht, dass einer der China-Hersteller seinen Krempel
jemals zu einem Beschleuniger geschleppt hat.

Da kaufe ich lieber ordentlichen Speicher und verzichte
auf hochgeschraubtes Timing.
Mit einem Crash alle 5 Jahre kann ich leben.

Gruß, Gerhard

Back to de.sci.electronics | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: ECC-RAM v_borchert@despammed.com (Volker Borchert) - 2017-10-10 18:39 +0000
  Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-10 21:37 +0200
    Re: ECC-RAM v_borchert@despammed.com (Volker Borchert) - 2017-10-10 20:26 +0000
    Re: ECC-RAM Matthias Weingart <mwnews@pentax.boerde.de> - 2017-10-11 06:44 +0000
      Re: ECC-RAM Patrick Schaefer <pa.schaefer@web.de> - 2017-10-11 22:13 +0200
      Re: ECC-RAM Rolf Bombach <rolfnospambombach@invalid.invalid> - 2017-10-11 22:47 +0200
  Re: ECC-RAM Gerhard Hoffmann <gerhard@hoffmann-hochfrequenz.de> - 2017-10-11 02:59 +0200
    Re: ECC-RAM v_borchert@despammed.com (Volker Borchert) - 2017-10-11 03:15 +0000
      Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-11 09:21 +0200
      Re: ECC-RAM Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-11 13:14 +0200
    Re: ECC-RAM Matthias Weingart <mwnews@pentax.boerde.de> - 2017-10-11 06:50 +0000
    Re: ECC-RAM Hanno Foest <hurga-news2@tigress.com> - 2017-10-11 15:09 +0200
      Re: ECC-RAM Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> - 2017-10-12 21:49 +0200
        Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-12 22:25 +0200
          Re: ECC-RAM Gerhard Hoffmann <gerhard@hoffmann-hochfrequenz.de> - 2017-10-14 00:42 +0200
            Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-14 18:54 +0200
        Re: ECC-RAM Hanno Foest <hurga-news2@tigress.com> - 2017-10-13 15:40 +0200
          Re: ECC-RAM Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> - 2017-10-13 17:07 +0200
            Re: ECC-RAM Hanno Foest <hurga-news2@tigress.com> - 2017-10-13 18:26 +0200
              Re: ECC-RAM Gerhard Hoffmann <gerhard@hoffmann-hochfrequenz.de> - 2017-10-14 00:57 +0200
                Re: ECC-RAM Hanno Foest <hurga-news2@tigress.com> - 2017-10-14 03:21 +0200
                Re: ECC-RAM Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-10-14 17:19 +0000
                Re: ECC-RAM Hanno Foest <hurga-news2@tigress.com> - 2017-10-14 21:46 +0200
                Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-14 19:00 +0200
          Re: ECC-RAM Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-14 00:03 +0200
            Re: ECC-RAM Hanno Foest <hurga-news2@tigress.com> - 2017-10-14 03:37 +0200
            Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-14 18:48 +0200
        Re: ECC-RAM Rolf Bombach <rolfnospambombach@invalid.invalid> - 2017-10-13 22:24 +0200
  Re: ECC-RAM Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-10-11 14:04 +0200
    Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-11 18:15 +0200
      Re: ECC-RAM Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-10-11 18:32 +0200
        Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-11 19:00 +0200
          Re: ECC-RAM Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-10-11 22:44 +0200
  Re: ECC-RAM Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-10-14 11:16 +0000
    Re: ECC-RAM Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-10-14 19:23 +0200
      Re: ECC-RAM Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-10-14 18:14 +0000
    Re: ECC-RAM usenet@teply.info (Florian E. Teply) - 2017-10-14 20:23 +0200

csiph-web