SRAM Timing Messung

**matt** · 15. Dezember 2020

Guten Tag

Dank China-Fake-SRAM fang ich Schaltung und Code fertigzustellen.

Meine Schaltung schreibt in 2 Adresse , einer davon ist mit 1 geschrieben und andere 0.

Dann wird zwischen Adresse hin und her springen. Verzögerung zwischen Ausgang und Eingang wird gemesst.

Code ist relativ primitiv Schaltung ebenso.

Erstmal mit UMCs SRAM messen. Messergebnisse: 7ns /10,5ns

Dann Cypress CY7C199-20PC messen. Ergebnbisse: 14/15ns

Chinafake ist nun dran.. es gibt 2 version: Einer hat fette und kurze Schrift an Rückseite. 8 /8.5, andere Exemplare 10 /10.5ns

Nächste Fake: der mit Taiwan und dünne Schrift an Rückseite 8/9,5ns, , andere Exemplare 9/9

Sehr warscheinlich ist beide Fake-SRAM mit 15-18ns Timing

Ich müsste mal Datenblatt durchlesen.

Grüss

Matt

**matt** · 15. Dezember 2020

Code ist für Atmega 328p geschrieben, ist auch auf andere Atmega portierbar.

C

#include <avr/io.h>
#include <util/delay.h>
#include <stdint.h>

/// ATMEGA 328p

#define  WE PD2
#define  OE PD3
#define  DATA PD4
#define  ADDR PD5


int  main (void) {
    
    DDRD = 0xFF ;       //all PD is output
    
//    Address  low, data low, setting.
    PORTD = (0 |(1<<PD3));           // /WE low, /OE high, Data low, Addr low.
    PORTD |= (1<<PD2);               // /WE high, /OE high.
//  Address high, data high, setting.
    PORTD |= (1<<PD4)|(1<<PD5);      // Data high, Addr high
    PORTD &= ~(1<<PD2);                // WE pulse
    PORTD |= (1<<PD2);                // WE pulse    
    
    DDRD &= ~(1<<PD4);                 // Data line switch to input.
    PORTD &= ~(1<<PD3);                // OE enable.
    
    
while (1)    {
    
    PORTD ^= (1<<PD5);                // Address toggling
    _delay_us (1);
    
}
    
}

Alles anzeigen

OE , WE , Addresse (einfach einer von mehre dran anschliessen) und Daten (einer von 8 nehmen) Restliche Daten und Adresse schaltet man auf Masse

Adresse und Daten wird auch aus Schaltung an Oszi gehängt.

Schaltplan braucht man nicht Es ist so primitiv.

**root_42** · 15. Dezember 2020

Cooles Projekt! Ich habe noch einen Arduino mit dem ich den DRAM Tester von FozzTexx nachbauen will.

**scorp** · 15. Dezember 2020

Ich habe auch mal eine Grafikkarte gehabt, wo die DRAMs kaputt waren und ich habe da was gebastelt. Leg' es hier mal ab, falls jemand Interesse hat:

https://github.com/necroware/dram-tester

**Dosenware** · 15. Dezember 2020

Meh, werd den Cache einfach einbauen und Oszi an OE + Dx hängen - wird schon klappen... oder halt den Logikanalyzer...

**matt** · 15. Dezember 2020

Ich benutze Arduino Software nicht, viele Gründe spricht dagegen. Eins kann ich sagen: Timing ist bei Arduino recht beschissen.

Ich benutze nur Hardware, weil ich nicht für 3€ Fertigteile µC Controller zusammenlöten möchte. Da ist Arduino nano recht parktisch und ich muss nicht zusammenlöten.
AVR-GCC wird genutzt.

**matt** · 15. Dezember 2020

Zitat von Dosenware

Meh, werd den Cache einfach einbauen und Oszi an OE + Dx hängen - wird schon klappen... oder halt den Logikanalyzer...

Nope, OE -Zugriff ist da schneller, allerdings hat paar IC mit unterschiedliche Timing gleiche Werte.

Wichtiger ist Zugriffszeit (= Adresse ändern und dann müsste Daten in innerhalb dieser Zeit ankommen), da messe ich.

**scorp** · 15. Dezember 2020

Ja, das stimmt absolut. Ich habe selbst mehrere Nanos und Minis für dies und das.....

**matze79** · 15. Dezember 2020

Arduino Software fügt nur Abstraktion hinzu.

Mag ich auch nicht.

**root_42** · 15. Dezember 2020

Das hier ist der Tester:

https://github.com/FozzTexx/DRAM-Tester

**scorp** · 15. Dezember 2020

Zitat von root_42

Das hier ist der Tester:

https://github.com/FozzTexx/DRAM-Tester

Es scheint mehr oder weniger das selbe zu sein, was ich da gebastelt habe. Aber er verwendet digitalWrite(...) für RAS/CAS Signalisierung. Meinen Versuchen nach ist es nicht schnell genug. Der RAS-to-CAS Delay hat einen Maximum, der bei Verwendung dieser Funktionen nicht eingehalten wird. Ich habe starke Vermutung, dass das so nicht funktionieren wird. Da muss man auf die Registerebene gehen um das Timing einigermaßen einzuhalten. Und leider auch dann hatte ich immer noch Probleme. So bald ich versucht habe sequenziell größere Addressräume zu testen konnte ich RAS-to-CAS Delay nicht mehr stabil klein genug halten. Ich habe es mit Arduino Nano getestet....

**root_42** · 15. Dezember 2020

Zitat von scorp

Zitat von root_42

Das hier ist der Tester:

https://github.com/FozzTexx/DRAM-Tester

Es scheint mehr oder weniger das selbe zu sein, was ich da gebastelt habe. Aber er verwendet digitalWrite(...) für RAS/CAS Signalisierung. Meinen Versuchen nach ist es nicht schnell genug. Der RAS-to-CAS Delay hat einen Maximum, der bei Verwendung dieser Funktionen nicht eingehalten wird. Ich habe starke Vermutung, dass das so nicht funktionieren wird. Da muss man auf die Registerebene gehen um das Timing einigermaßen einzuhalten. Und leider auch dann hatte ich immer noch Probleme. So bald ich versucht habe sequenziell größere Addressräume zu testen konnte ich RAS-to-CAS Delay nicht mehr stabil klein genug halten. Ich habe es mit Arduino Nano getestet....

Ich habe einen "normalen" Arduino. Ist der nano langsamer/schneller/gleich schnell? Bin da bis auf den SwinSID sehr unbeleckt... Ich benutze die Arduino IDE lediglich um ESP32 und ESP8266 zu programmieren.

**scorp** · 15. Dezember 2020

Mit "Normal" meinst Du wahrscheinlich den Uno? Nun der Nano ist gleich schnell, nur kompakter. Einen Uno habe ich auch, aber ich benutze fast immer den Nano, weil man den direkt ins Breadboard reinstecken kann. So weit ich weiß gibt es Mini, die langsamer sind und mit nur 8MHz statt 16MHz laufen. Die Minis, die ich habe sind alle 16MHz.

Aber prinzipiell ist so, dass die Arduino API, also die ganzen digitalRead()/digitalWrite() usw. ultra langsam sind, wie @matt es schon gesagt hat. So bald man eine Firmware schreibt, die ins Timing von unter 100ns läuft, sollte man nicht mehr die Arduino API mehr benutzen.

**matt** · 15. Dezember 2020

Könnte ihr Diskussion auslagern? Hier ging um SRAm Timing Messung und nicht DRAM Testen

**scorp** · 15. Dezember 2020

Zitat von matt

Könnte ihr Diskussion auslagern? Hier ging um SRAm Timing Messung und nicht DRAM Testen

Sorry, ich dachte das passt, da die Mitteln im Grunde dieselben sind.... aber ich höre auf dann

**Hoom** · 16. Dezember 2020

Diese China Caches scheinen noch andere Probleme zu haben. So ganz plausibel scheint mir deren Versagen anhand von @matt ˋs Messungen nicht zu sein.

Ich habe hier welche die laufen mit schärfsten Timings super, denen kann man die 10ns tatsächlich glauben. Allerdings nur für 10-30min, danach laufen die noch nichtmal mit den schlechtesten Timings stabil. Ich schätze, hier trifft moderne Fertigung mit kleinen, schnellen Strukturen auf schlechte Verarbeitung und ungenügende thermische Kopplung. Hatte sogar einen Lüfter auf die Chips gebaut, hatte nicht geholfen.

@matt Eine wirklich super Sache, die Du da angehst. Das schafft viele Antworten.

**matze79** · 16. Dezember 2020

Wie gesagt, ich denke die haben einfach Ausschussware neu deklariert.

Das ist nicht unüblich.

**matt** · 16. Dezember 2020

Ich hatte vergessen zu erwähnen.

ich habe auch bei Messung gewundert, dass SRAM aus China unter 10ns packt.. allerdings wenn ich SRAM heiss macht, verschlechtert es dramatisch (stieg auf 12ns ), währendessen orginale SRAM nur um 1ns längere für Antwort braucht. Oszi misst nur Differenz von beide Flanke.

Eigentlich sollte man eher 20% punkt von erste Flanke und 80% von zweite Flanke als Messpunkt nehmen. Das kann meine Tek TDS5054B-NV (eine Schlachtschiff unter Oszi ) jedoch nicht mit spezielle Messbedingung -> Immer mit Cursor herumkurbeln. Da war ich aber zu faul

Dafür ist China-SRAM deutlich besser beim 3.3V (es ist nur um 1ns schlechter geworden (nur beim einer von 2 Fake-Typ getestet), währendessen restliche SRAM ist es viel schlechter geworden.

Meine Mussmatung: Chinese jubelte schnelle 3.3V SRAM an uns unter.

SRAM Timing Messung

Jetzt mitmachen!

Benutzer online in diesem Thema