Hallo liebe Community, da Ihr mir bisher immer freundlich und schnell auf die Spruenge geholfen habt. Nochmal ein CPLD-Neuling-Problem. Ich verwende eine XC9536XL-5 zwei DRAM banks anzusteuern. Die DRAMS unterstuetzen CAS-before-RAS refresh den ich auch verwende. Sowohl das Schreiben als auch Lesen klappt gut, fuer eine Bank auch problemlos (der Pfad mit den Inverter auf die BUFE). Die DRAMS sind auch 100% ok. Nun mein Problem, es scheint, dass sich ab und an etwas "glitch"-aehnliche (?!) einschleicht, und zwar teste ich die RAMS mit einem Testprogramm (insgesamt 8MB, lower und upper 4MB). Die Lower 4MB sind 100% ok, bei den upper 8MB gibt es ca. 40 - 80 Lesefehler, die auf einen fehlerhaften CAS-before-RAS refresh hindeuten (jeweils meist ein bit von HIGH auf LOW hat die Ladung verloren). Zur Ansteuerung... Inputs: - BANK ist jeweils low oder high -> lower oder upper 4MB Bank - BANK ist immer nur gueltig, wenn ein RISING auf PH2CLK kommt - PH2CLK, liegt auf GCK2 (pin 44) Outputs: - CAS und RAS direkt auf die DRAMs Was hab ich bisher probiert (Betonung auf probiert)... - Buffer bei den Ausgaengen, mit SLEW rate SLOW und FAST -> kein Erfolg - BUFG am PH2CLK -> kein Erfolg Bin etwas ratlos, ich sage deswegen probiert, weil die Fehlerquote mit 40 bis 80 von 4 Millionen recht gering ist, und ich quasi keine Chance hab sie mit dem Oszi zu erwischen... Was habe ich als Neuling uebersehen ? Hab ich Glitches wegen dem FF ? Ich wuesste aber nicht wo? Liegt es an der Signalqualitaet von PH2CLK? Warum klappt es dann aber immer, wenn BANK = LOW ist ? - d.h. nur bei BANK = HIGH gibt es die Probleme? Werde mir noch PH2CLK mit den Scope anschauen, ggf. einen Schmitttrigger bevor er auf den XC9536 geht... ?! Vielen Dank im voraus... Ich denke am Ende werde ich wieder viel gelernt haben! A2Enthusiast
Angehängte Dateien:
-
CAS_RAS_Bank_selector.png
6,6 KB
AppleII E. schrieb: > Die Lower 4MB > sind 100% ok, bei den upper 8MB gibt es ca. 40 - 80 Lesefehler, die auf > einen fehlerhaften CAS-before-RAS refresh hindeuten (jeweils meist ein > bit von HIGH auf LOW hat die Ladung verloren). Das klingt für mich überhaupt nicht nach einem Refresh-Problem. Kommen die 40-80 Lesefehler denn wenigstens immer wieder reproduzierbar auf den selben Adressen (das wären dann bezüglich Retention die schwächsten Zellen). Und hängt der Fehler dramatisch von der Temperatur ab? (Ein Puster mit Eisspray müsste aus 80 Retention Fehlern sofort 0 Fehler machen). Dass auf dem chip-externen Datenbuss immer ein Bit von High auf Low kippt deutet eher auf ein Signalintegritätsproblem auf dem Datenbus hin. DRAMs dieser größer arbeiten intern mit differentiellem Signaling. Was auf dem externen Bus als 1 unterwegs ist wird mit 50% Wahrscheinlichkeit intern als 0 gespeichert (und ist damit überhaupt nicht Retentionkritisch). Umgekehrt zeigen sich Retentionfehler auf dem externen Bus mit 50% Wahrscheinlichkeit bei Lowpegel (obwohl es intern natürlich die Einsen sind, die wegsterben). Wenn dein Testprogramm den fehlerhaften Wert mehrfach ausliest kannst du prüfen, ob es nur ein Signalintegritätsproblem beim Lesen war oder beim Schreiben: Signalintegritätsprobleme beim Schreiben landen falsch im Zellenfeld und sind bei jedem Auslesen falsch. Signalintegritätsprobleme beim Lesen haben keinen Einfluss aufs Zellenfeld: bei einem Lesen sind sie falsch, beim wiederholten Lesen bekommst du aber schon die richtigen Daten. Wenn es Signalintegritätsprobleme auf dem Datenbus sind, solltest du das durch entsprechend kritische Datenmuster verstärken können: wenn du also als Datenmuster eine Folge von xFE-x01 benutzt (und Rotationen davon, also xFC-x02, xFB-x04, xF7-x08....) , dann wird das eine Bit besonders kritisch getestet. AppleII E. schrieb: > Bin etwas ratlos, ich sage deswegen probiert, weil die Fehlerquote mit > 40 bis 80 von 4 Millionen recht gering ist, und ich quasi keine Chance > hab sie mit dem Oszi zu erwischen... Lass dein Testprogramm möglichst schnell einen Trigger ausgeben, sobald es einen Fehler erkennt. Wenn dein Speicheroszi einen hinreichen tiefen Speicher hat, dann kannst du zum Fehler zurückscrollen.
Verstehe - danke für die Hinweise. Folgendes lässt mich entsprechend rätseln. Die lower und upper Bank besteht jeweils aus zwei 4Mbitx4 ICs. Ich hatte auch schon auf die RAMS getippt... aber ich habe sowohl das lower "RAM-Paerchen" als auch die higher Pärchen an beiden CAS0,RAS0 und CAS1,RAS0 gehabt. Die ICs (beide upper 4MB und lower 4MB) haben als eine 4MB Bank fehlerfrei für Tage funktioniert, keine R/W Fehler, keine Refresh-fehler. Wie habe ich getestet - jeweils einen Buffer-Block de-aktiviert durch E auf ground, und dann den anderen Buffer-Block. Die Sache ist die, der Bufferblock, der jeweils über den Inverter angesprochen wird, also bei LOW = Bank 0 funktioniert. Der Bufferblock der direkt angesteuert wird, also bei HIGH = Bank zwar nie R/W Probleme, aber diese seltenen Refresh Probleme. Danach habe ich jeweil die Blöcke vertauscht, so dass die beide PCB Leitungen getestet wurden, um Probleme mit den Signalleitungen auszuschliessen. Es lag nicht am PCB. Wieder hat der Bufferblock ohne Inverter Probleme bereitet und er mit dem Inverter (Bank = 0) keine.... Sehr seltsam... Weitere Ideen dazu ? Danke!
Zur Ergänzung: - Die Fehler kommen auf unterschiedlichsten Adressen - Es hat jeweils nur 1 bit von 8 einen Fehler - Jeder Bitfehler ist jeweils ein LOW bit statt einem HIGH bit
Sorry noch eine Ergänzung zum Ablauf des Testprograms: Phase 1: - alle Bitkombinationen werden pro Speicherzelle geschrieben und wieder gelesen, dann kommt das nächste Byte dran, angefangen bei Byte 0 von Bank bis zum letzen Byte der Bank 1. ---> Hier tretten -NIE- R/W Fehler auf Phase 2: - um sicher zugehenen, dass auch nach einer gewissen Zeit keine Bitfehler vorliegen (Refresh-Probleme), wird nun ein sich änderndes Bitmuster (Byte 0 ... 00 FF, Byte 01 FE, usw über den kompletten Speicher Bank 0 bis Bank in einem Rutsch geschrieben, und erst nach dem kommpletten Beschreiben wieder ausgelesen, angefangen von Byte 0, Bank 0 bis zum letzten Byte der Bank 1, hier ist die Aufälligkeit --- BANK 0 hat -NIE- verloren Bits / Fehler, NUR die BANK 1 macht Probleme
Heutige DRAM halten den Inhalt locker über viele 10ms. Sollte ein Refresh verloren geht, macht das nix, weil bei CAS-before-RAS ein interner Zähler benutzt wird. D.h. da wird nicht mal eine Zeile vergessen. Verletzungen der Precharge-Time merkt man üblicherweise an dem Ausfall einer ganzen RAS-Zeile, da wackelt nicht nur ein Bit. Es könnte auch ein Groundbounce-Effekt sein, wenn du eine 0 statt einer 1 liest. Das CPLD versucht zB. an den Adressen zuviele Pins auf 0 zu ziehen, damit ist der interne GND so verschoben, dass ein High-Pegel trotzdem als 0 erkannt wird. Das deutet dann aber auch auf ein zu knappes Timing hin. Hast du mal die Adressleitungen mit langsamer Slew-Rate probiert? Ansonsten könnte man noch bei einem Digital-Oszi die Persistance auf 100% stellen und schauen, ob im integrierten RAS/CAS/Daten-Verlauf irgendwo verdächtliche Glitches bzw. Unregelmässigkeiten auftauchen. Und als letzter Strohhalm kann man versuchen, ob sich mit 10-20p Cs von GND gegen RAS, CAS, etc. was ändert. Auch 100-220R gegen GND bzw. VCC sind da gut. Wenn sich was ändert, hast du ein Glitch bzw. Timingproblem...
:
Bearbeitet durch User
Danke fuer die Strohhalme... werde ich ich alles ausprobieren und meine Erkenntnisse mitteilen :)
Angehängte Dateien:
-
pic_60_1.gif
19 KB -
pic_60_2.gif
19 KB -
pic_60_3.gif
19 KB
Mir ist bei manchen Zugriffen folgendes aufgefallen (siehe Bilder) Gelb (Ch1) = PH2CKL (bei steigender Flanke, ist die BANK gültig) Cyan (Ch2) = BANK (ist gleichzeitig auch Datenleitung D6, ist ein gemultiplexter 24Bit Adressbus, D0-D7 sind Sowohl die Bank Adress (wenn D6) als auch die Daten) Der Zustand tritt selten auf, könnte also mit meinen Problem zusammenhängen?! Übrigens die Datenfehler tretten nur - beim Lesen des oberen 4MB Blocks auf (PH2 steigend und Bank auf HIGH) - Es sind nicht nur nach 0 gekippte Bits sondern auf nach 1, auf beliebigen Bit Positionen
AppleII E. schrieb: > ist ein > gemultiplexter 24Bit Adressbus, D0-D7 sind Sowohl die Bank Adress (wenn > D6) als auch die Daten) kannst du die Busstruktur mal skizzieren? Kann es sein, dass du Schreib/Lesezugriffe und CAS-before-RAS Zugriffe nicht richtig richtig synchronisiert kriegst? AppleII E. schrieb: > Der Zustand tritt selten auf, könnte also mit meinen Problem > zusammenhängen?! kann es durchaus, für mich sieht es auf den ersten Blick nach einem Buskonflikt aus, der ja wahrscheinlich nicht eingeplant sein dürfte. Wie oben schon geschrieben: lass das Testprogramm einen Hardwaretrigger für das Oszi erzeugen, sobal ein Fehler detektiert wurde. Dann kannst du leicht nachprüfen, ob in den µs vor jedem Fehler ein ein solcher "Buskonflikt" auftrat.
Angehängte Dateien:
-
bus.png
20 KB
Hier der Schematic. Die Adressleitungen A0-A10 gehen direkt per 33 Ohm Widerstand auf die DRAM Adressleitungen. Die Sache ist die, dass wenn ich jeweils nur einmal 4MB teste, es tage/nächtelang ohne jede Fehler durchläuft. Jetzt wollte ich zusätzlich eine weitere Bank ansprechen um auf 8MB zu kommen. Die Bankadress ist jeweils auf D0-D7 gelegt (vom Prozessor) 65816 und ist bei einem steigenden PHI2CLK gültig. In dem Fall werte ich nur D6 (lower / upper 4MB) aus gebe dann entweder den CAS/RAS Pärchen für die entsprechenden RAMs frei. Interessant ist auch, es läuft stundenlang problemlos, wenn ich schreibe und direkt wieder lese... nur wollte ich sicher gehen dass es keine Refreshprobleme gibt, und schreibe dann die kompletten 4MB bzw. 8MB mit einem Muster dauert einige Minuten und lese es dann erst nach Minuten wieder. Wie gesagt lower 4MB alles Prima, upper 4Mb mit wenigen Fehlern. Die zwei Spannungslevel ergeben sich durch die Mischung 5V nativ und 3.3V vom XC9536XL ... Was mich irritiert ist aber der Spike nach unten.
AppleII E. schrieb: > Hier der Schematic. und wo ist jetzt hier bitte der gemultiplexte 24bittige Adress und Datenbus? Und wo genau an dieser Schaltung hast du deine Messung aufgenommen? AppleII E. schrieb: > Die zwei Spannungslevel ergeben sich durch die Mischung 5V nativ und > 3.3V vom XC9536XL ... interessante Info, dass du mit unterschiedlichen Spannungspegeln arbeitest. Und du hast die Info wirklich keinen Moment zu früh gegeben, und sie auch nicht unnötig detailliert ausgeführt. AppleII E. schrieb: > nur wollte ich sicher gehen dass es keine > Refreshprobleme gibt, und schreibe dann die kompletten 4MB bzw. 8MB mit > einem Muster dauert einige Minuten und lese es dann erst nach Minuten > wieder. Zum Punkt Refresh habe ich schon einen Tip gegeben: gib ab und zu einen Hauch Kältespray auf das DRAM. Wenn die Anzahl der Fehler nicht sofort um eine Größenordnung zurückgeht, ist es kein Retentionfehler. Ich kann mir immer noch eher vorstellen, dass die ändere Zugriffsart bei deinem zweiten Test (lange Blöcke jeweils nur mit Schreibzugriffen, dann nur mit Lesezugriffen) zu einem Fehler auf deinen Bussen führen, der beim ständigen Wechsel zwischen Schreiben und Lesen nicht auftritt. Aber ich finde die Beschreibung deines Systems so bruchstückhaft und unüberschaubar, dass ich keine weiteren Tips außer den bereits gegebenen für habe: Achim S. schrieb: > (Ein > Puster mit Eisspray müsste aus 80 Retention Fehlern sofort 0 Fehler > machen). Achim S. schrieb: > Wenn dein Testprogramm den fehlerhaften Wert mehrfach ausliest kannst du > prüfen, ob es nur ein Signalintegritätsproblem beim Lesen war oder beim > Schreiben Achim S. schrieb: > Wenn es Signalintegritätsprobleme auf dem Datenbus sind, solltest du das > durch entsprechend kritische Datenmuster verstärken können Achim S. schrieb: > Lass dein Testprogramm möglichst schnell einen Trigger ausgeben, sobald > es einen Fehler erkennt.
Fehler gefunden... Habe einen statt des BUFE einen OBUFE verwendet und schon ging es. Warum, k.A. Hätte gedacht der ISE compiler ist "inteligent" genug um für Outputs
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.