Was macht ein guter Memory-Test?

Diesen Artikel zu diesem Thema fand ich nützlich: http://www.ganssle.com/testingram.htm

http://hc-ddr.hucki.net/wiki/doku.php/z9001:software:ramtest

Das hängt wohl von der Definition von "richtig" ab - Will man's "richtig" machen, schreibe man alle Werte, die der Speicher aufnehmen kann in allen Permutationen an Nachbaradressen, rein, und schaue, ob man sie wieder auslesen kann. Das dauert natürlich "unendlich" lang, will man auch kurzgeschlossene Address- und Datenleitungen und kaputte Bustreiber erkennen können, dann hat man ganz schön zu tun - Der Benutzer will bestimmt nicht so lange warten, bis so ein Memory-Test abgeschlossen ist.

Also muss man sich was schlaueres einfallen lassen, das aber trotzdem noch schlauer ist als simple Bitpattern lesen und schreiben.

Nachdem ein Memory-Test bei jedem Einschalten wieder aufs Neue durchläuft, braucht man eigentlich nicht "immer alles" zu testen. Ein schlauer Speichertest kann z.B. ab einer von der Uhr- (oder einer Wartezeit bis zu einem Tastendruck des Benutzers) "verzufallten" Anfangsadresse (damit man bei jedem neuen Einschalten andere, zufällige Pattern generiert) ROM ins RAM schreiben und dann vergleichen - Damit bin ich eigentlich bisher immer ganz gut gefahren. Früher oder später findet so eine Routine jeden Fehler, auch solche, wo das Schreiben einer Adresse eine ganz andere verändert.

Tobias

Vielleicht solltest Du noch dazusagen, ob Du da an einzelne Chips denkst, oder an SIMMs, oder installierte Systeme.

Bei 1kB großen Chips würde "sinnvoll" möglicherweise anders aussehen, als bei 2 TeraByte in einer aktuellen Z-Maschine.

Ich würde mir evtl. auch mal die Sachen angucken, die zum defnierten Löschen von Datenträgern benutzt werden (CleanEraser etc.). Da gibt es solche eigenartigen Bitfolgen, die ganz gut sicherstellen sollen, daß man danach nichts mehr auslesen kann, und ich vermute, daß es dafür auch ein paar Texte gibt, wo begründet wird, warum gerade diese Bitfolgen. Und da man damit ja irgendwie "alles" erwischen will, müßte das, in Abwandlung" auch für Tests brauchbar sein. Ist aber nur so eine Idee ...

Ansonsten - auf Chipebene für Kleincomputer - scheint mir auch wichtig, daß der Chip mal schön benutzt worden ist. D.h. man macht erstmal nur für eine bestimmte Zeit irgenwelche Schreib/Lesezugriffe, damit der Chip "warm" wird (z.B. 2 Minuten o.ä. (dafür kann man dann eine Kurve machen, wenn man das Tool "stehen" hat und den optimalen Zeitraum bestimmen). Erst dann kommt eine Lese Test mit irgendwelchen Pattern.

Und: am Besten ist wahrscheinlich, sowas immer mitlaufen zu haben, also ECC RAM ..., und sowas ginge auch als IRQ Routine o.ä. auf Kleinstcomputern (man kann die Prüfsummen ja in den Bildschirmspeicher schreiben ).

Eines der wichtigsten Dinge bei einem "richtigen" Memorytest ist, den Speicher auch mit der maximalen Geschwindigkeit zu testen!

Der Memorytest, den Inmos z.B: für Transputersysteme zur Verfügung gestellt hat, taugt diesbezüglich nichts - mit dem wurden schon Speicherbausteine für gut befunden, deren Ground-Pin nicht mal angeschlossen war!

Also Geschwindigkeit ist (fast) alles bei so einem Test - für die meisten Systeme heißt das, Datenblöcke mittels DMA zwischen

internem und externem, sowie innerhalb des externen Speichers hin - und her zu kopieren.

Für den Speichertest von Maschinen, auf denen Linux läuft, gibt es memtest86 oder memtest86+. Der wird anstelle eines OS geladen und kann somit das gesamte vorhandene RAM testen. Es laufen viele Varianten des lesens und schreibens durch, ein einziger Durchlauf dauert ca. 30 Minuten auf einem Core 2 Duo mit 1,86 GHz.

Aber auch solche Tests schützen nicht vor Fehlern. Es kann ja sein, daß eine Speicherzelle nach dem Test den Geist auf gibt. Murphy eben. Der ist mein ständiger Begleiter bei Service und Reparatur und schlägt manchmal zu.

Abolute Funktionssicherheit gibt es nirgendwo, bei keiner Maschine und bei keinem Menschen.

In der CBM hackers mailing list gibt es auch gerade eine Diskussion um memory tests / Arduino-basierte RAM-Tester:

http://cbm-hackers.2304266.n4.…41256-DRAM-td4668461.html

Ich könnte mir vorstellen, daß ggf. auch die Versorgungsspannung (oder besser der Bereich) im Rahmen der Datenblattvorgaben zum Test hinzugezogen werden sollten. Ist aber kein Wissen meinerseits, sondern eher aus dem Bauch heraus.

Wenn es nur um ein 2114 geht, würde ich das mal in einen C64 packen (Farbram), da sieht man dann schnell, ob es noch Ok ist.

Naja... hier geht es ja wohl eher darum, was einen guten Memory Tester auszeichnet. Klar kann ich das jeweilige RAM dann auch in einen Rechner setzen, aber ich denke, daß es bei diesem Thread nicht die Intention von funkenzupfer war/ist.

Zitat von 1ST1

Wenn es nur um ein 2114 geht, würde ich das mal in einen C64 packen (Farbram), da sieht man dann schnell, ob es noch Ok ist.

Vielleicht ist das ja sogar schon "die Idee" für einen guten Tester. Nur daß halt das Ganze mit einem RPi beschrieben/gelesen wird und als Grafik angezeigt wird.

Zitat von ThoralfAsmussen

Zitat von 1ST1

Wenn es nur um ein 2114 geht, würde ich das mal in einen C64 packen (Farbram), da sieht man dann schnell, ob es noch Ok ist.

Vielleicht ist das ja sogar schon "die Idee" für einen guten Tester. Nur daß halt das Ganze mit einem RPi beschrieben/gelesen wird und als Grafik angezeigt wird.

Oder um das zeitkritische hinzubekommen vielleicht mit nem FPGA?

Wenn der RAM zwar mit ner Taktung von 500 Hz funktioniert, kann es immer noch sein, dass er bei 1MHz nicht mehr geht.

Mal ein paar Anregungen:

Diverse Bitmuster schreiben und wieder lesen, mindestens 0000000, 11111111, 10101010, 01010101, 00001111, 11110000, 00110011, 11001100, 00111100, 11000011. Refresh-Test (wieviele Refreshcyclen düerfen ausfallen, bis der Speicherinhalt weg ist. In schneller Reihenfolge immer wieder die gleiche Speicherzelle behämmern und wieder auslesen (und vergleichen), Speicherzelle immer wieder beschreiben, und schauen ob sich der Inhalt von Nachbar-Speicherzellen dadurch ändert (Rawhammer-Methode). Fortlaufende Tests benachbarter Speicherzellen. Zufällige Speicherzellen, ...

Kannst ja mal in den Quellcode von memtestx86 oder yaart (yet another atari ram test) reinschauen.

> @dlchnr ...

> Mit Geschwindigkeit ......... kann ich ein Memory-IC stressen, wenn ich aber die angegebenen Spezifikationen einhalte,

> sagt mir das gar nichts zur Funktion eines ICs.

Es geht hier nicht darum, irgendwelche Timingzeiten auszureizen,

sondern Situationen zu simulieren, wie sie in einem laufenden Systen

ständig auftreten - das einem READ unmittelbar ein READ auf einer ganz

anderen Adresse folgt oder auf einen READ unmittelbar danach (beginnend

mit dem nächsten Clocksyklus) ein WRITE erfolgt.

Wie schon geschrieben, entging dem Memorytest von Inmos für Transputersysteme,

dass bei einem Transputerboard der Ground-Pin der DRAMs nicht angeschlossen

war!

Oder ein anderes Beispiel - ich wurde von einem Konzern beauftragt,

deren Neuentwicklung "zuverlässig" zum Laufen zu bringen. Da dort geklotzt

wurde gab es nicht ein Prototypenboard, sonder "zig" davon:

- ein Handvoll der Boards fiel beim Memorytest durch, der Fehler konnte aber

nicht gefunden werden.

- das Gros der Board bestand den Memorytest, "schmierte" aber beim Programmlauf

binnen weniger Minuten ab.

- drei der Boards liefen stundenlang, manchmal sogar ein/zwei Tage, bis dann

auch bei denen ein Programmabsturtz auftrat.

Mit dem Memorytest, den ich dann für das Board geschrieben habe, waren dann

auch bei den zuletzt gennanten drei Boards nahezu alle Speicherzugriffe

(ca. 70% bis 90%) fehlerhaft!

Bin gerade auf das hier gestossen:

http://arcarc.xmission.com/Tes…ari%20Ram%20Rom%20Tester/

Nachtrag:

http://arcarc.xmission.com/Test%20Equipment/Simcheck/

und hier eine Testfixture:

http://arcarc.xmission.com/Tes…i%20CTS%20Test%20Fixture/

http://arcarc.xmission.com/Tes…tari%20Catbox%20&%20Pods/

Zitat von tokabln

Bin gerade auf das hier gestossen:

http://arcarc.xmission.com/Tes…ari%20Ram%20Rom%20Tester/

Nachtrag:

http://arcarc.xmission.com/Test%20Equipment/Simcheck/

Alles anzeigen

Nun in diesem Post gibt es Informationen zu einem RAM / ROM Tester sowie zu einem Simtester.

Der Post darunter ist tatsächlich nicht wirklich relevant... aber hier kann man schön sehen wie z.B. ATARI seine Produkte getestet hat...

Zitat von funkenzupfer

Ich hab dann die Ein- und Ausgabefunktionen unter CP/M drangebaut.

Cursorpostionierung etc sind VT-100 kompatibel.

Das wäre für meinen Intertec Superbrain interessant, von dem ich immer noch nicht weiß, ob das RAM nun eigentlich okay ist oder nicht. Aber der verwendet keine VT100-Sequenzen, sondern irgend eine andere Terminal-Emulation, die ich erst mal wieder ermitteln müsste. Wäre das viel Aufwand, das anzupassen? Möchtest Du vielleicht die Sourcen irgendwo veröffentlichen, kann könnte ich das auch selbst machen?

Warte... lass mich kurz nachdenken... also ich glaube, ich mach' das besser selbst!

Das Ding bootet ordentlich hoch in sein CP/M, also wird das schon gehen.

Bare metal wäre nicht so cool weil dort ein TMS 2716 verbaut ist, das im Gegensatz zu den üblichen 2716 noch +12 Volt und so'n Quatsch haben will, das kann ich leider nicht brennen.