SRAM arbeitet mit kurzen Lesezyklen, fällt mit längeren aus

Ich beobachte ein ziemlich seltsames Verhalten eines IS62WV51216BLL-55TLI SRAM-Chips, der mit einem FPGA verbunden ist. Wenn ich es mit den kürzestmöglichen Lesezyklen ausführe, funktioniert es wie erwartet:

Geben Sie hier die Bildbeschreibung ein (hier lese ich den erwarteten Wert 0xCF9C3063. Ein Tick ist 6,25 ns)

Wenn ich jedoch versuche, längere Lesezyklen zu verwenden, schlägt dies auf mysteriöse Weise fehl: (hier lese ich den Wert 0x136000D0 anstelle von 0x1360EC9F. Ein Tick ist 6,25 ns)Geben Sie hier die Bildbeschreibung ein

Wie Sie sehen, erscheinen irgendwann die richtigen Daten auf dem Datenbus, werden aber schnell durch einen falschen Wert ersetzt. Dies passiert sporadisch jedes Mal an einer anderen Adresse, und das erneute Lesen derselben Adresse ein zweites Mal funktioniert gut:

Geben Sie hier die Bildbeschreibung ein (Hier lese ich beim ersten Mal den Wert 0x18E06439 und beim zweiten Mal den erwarteten Wert 0x18E0E71F)

Hat jemand eine vernünftige Erklärung dafür? Stimmt etwas mit meinem Lesezyklus nicht? Hier ist der Lesezyklus aus dem obigen Datenblatt als Referenz:Geben Sie hier die Bildbeschreibung ein

Alle meine Diagramme wurden mit SignalTap (im FPGA integrierter Logikanalysator) mit 160 MHz erstellt. Alle Ausgangspins des SRAM-Controllers werden registriert:

// ** Output Pin tcm_address_out 

reg                       tcm_address_outen_reg;     

always@(posedge clk) begin
 if( reset ) begin
   tcm_address_outen_reg <= 'b0;
 end
 else begin
   tcm_address_outen_reg <= 'b1;
 end
 end             


reg [ 19 : 0 ] tcm_address_out_reg;   

 always@(posedge clk) begin
 tcm_address_out_reg   <= tcs_tcm_address_out[ 19 : 0 ];
  end


assign  tcm_address_out[ 19 : 0 ] = tcm_address_outen_reg ? tcm_address_out_reg : 'z ;

Das tcm_address_outSignal wird dann mit den sram_addrin den obigen Diagrammen gezeigten Pins verbunden, die wiederum mit den A0- A18Pins des SRAM-ICs verbunden sind. Andere Stifte sind auf ähnliche Weise verbunden. Die Länge der Drähte/Leiterbahnen zwischen einem FPGA-Pin und einem SRAM-Pin beträgt etwa 10 cm. Der SRAM IC hat 1uF + 100nF Keramikkappen zwischen den GND- und VDD-Pins auf beiden Seiten.

PS. Ich habe versucht zu halten C S ¯ die ganze Zeit behauptet, was die Sache nicht besserte. Ich habe auch eine Modifikation ausprobiert, wo Ö E ¯ wird 12,5 ns später geltend gemacht C S ¯ und wird für 12,5 ns zwischen aufeinanderfolgenden Lesevorgängen deaktiviert (unter Beibehaltung C S ¯ ). Das hat nicht geholfen:

Geben Sie hier die Bildbeschreibung ein

Zeig uns den Code. Ich hatte Schwierigkeiten mit ähnlichen Dingen, die mit mehreren Puffern gelöst wurden. Vertrauen Sie auf keinen Fall dem Signalabgriff, wahrscheinlich ist mehr auf den Leitungen, als es sieht.
Ich weiß nicht, was auch immer relevant ist (und nicht zu lange).
Warum kommt OE im selben Moment wie CS?
Versuchen Sie zuerst CS (nicht immer) und dann oe. Wie im Datenblatt.
Der Punkt ist sehr einfach. Wenn es nicht funktioniert, tun Sie genau das, was sie sagen. Wenn es immer noch nicht funktioniert, suchen Sie nach einem größeren Fehler. Mist am Speicherausgang kann ein Symptom für fehlenden Entkopplungskondensator, schlechte Spannung, gefälschte Komponenten oder was auch immer sein. Aber um es auf diese Weise zu untersuchen, müssen Sie zuerst alles nach Vorschrift tun. Vergessen Sie nicht, dass Datenblätter manchmal nicht zu 100 % vollständig sind, insbesondere für Speicher, der normalerweise mit einer CPU verwendet wird, sodass nur eine winzige Minderheit der Ingenieure das Datenblatt liest
Nun ... zunächst einmal sind die Wellenformerfassungen NICHT wie das Chip-Zeitdiagramm des Datenblatts, da Sie die Adresswerte während des Chipauswahlzyklus ändern. Ich weise nur darauf als Unterschied hin, obwohl SRAM-Lesezyklen gut funktionieren sollten, wenn sich nur die Adresse nach der tAA-Zugriffszeit in gültige Daten ändert. Ich bin ziemlich auf der Seite von Gregory hier, da das Problem höchstwahrscheinlich etwas ist, das in diesen Timing-Aufnahmen nicht angezeigt wird. Könnte ein Stromstoß oder -abfall zum SRAM-Chip, Massesprung oder sogar eine Art vorübergehender Konflikt an den SRAM_DATA-Pins sein.
Vor vielen, vielen Jahren arbeitete ich wochenlang an einem SRAM-Leseproblem auf einer Platine, die eine Bank von SRAMs hatte, die über einen bidirektionalen 8-Bit-Buspuffer zu einem 8085-Datenbus gepuffert wurden. Es stellte sich heraus, dass das Problem auf die Richtungssteuerung des Puffers zurückzuführen war, der etwa 2–3 ns am Ende des Zyklus auf die SRAMs zeigte, kurz bevor die Lesezyklusdaten in den Dreizustand übergehen würden.
@MichaelKaras Ich zögere, das gesamte Datenblatt in meine Frage zu kopieren, aber wenn Sie sich Seite 8 ansehen, sehen Sie ein Diagramm, in dem die Adresse während des Lesezyklus geändert wird. Und übrigens tritt mein Problem beim zweiten Lesen (das ohne Radfahren geht) nie auf C S ¯ ), nur beim ersten Lesen, wenn Ö E ¯ wird gerade behauptet.
Ich habe auf das gepostete geantwortet. Ich habe gesagt, dass das Lesen von Adressänderungen auch funktionieren sollte. Haben Sie möglicherweise Signalintegritätsprobleme auf Ihren Adressleitungen? Logikanalysator-Traces neigen dazu, dies zu verbergen.
Es gibt einfach zu wenig Informationen, um weiterzumachen. Sie haben die Schaltung und die Busschnittstelle HDL weggelassen ... Dinge, die für Sie selbst außer Frage stehen, für Außenstehende wie uns jedoch zweifelhaft sind. SignalTap ist nur taktgetastete Daten, keine schnelleren Zwischenprodukte, also nicht viel Nutzen. Entschuldigung, aber da ist es.
@MichaelKaras Das Seltsame ist, dass das Problem während langsamer Lesezyklen auftritt, die ~ 150 ns dauern. Das sind nur etwa 6-7 MHz. Die Drähte zwischen dem FPGA und dem SRAM-IC sind vielleicht 10 cm lang, ich glaube, Transienten haben viel Zeit, sich zu beruhigen.
@TonyM Ich habe keine HDL gepostet, weil ich glaube, dass ich das Problem auf die SRAM-Schnittstelle eingegrenzt habe. Wenn ich ein Problem mit meinem Verilog-Code hätte, würde es dann nicht in den Diagrammen auftauchen? Die Schaltung ist trivial: Jedes Signal wird mit dem entsprechenden Pin des SRAM sram_xverbunden . xUnd würden sich die Transienten nicht während dieser 150 ns einpendeln?
Lassen Sie mich Ihnen ein wenig erfahrenen Rat geben, dann mit Ihrer Nachsicht. Das Problem liegt so wahrscheinlich in dem Teil, von dem Sie wissen, dass es nicht dort liegt, wo das Problem liegt. Die Bits, denen Sie vertrauen, sind die Bits, denen Sie misstrauen. Haben Sie die FPGA-Pinbelegungseinstellungen überprüft? Erste Anlaufstelle. Abgesehen davon kann niemand Sie hinterfragen, wenn Sie Bits haben, denen Sie vertrauen, und Bits, denen Sie nicht vertrauen. Viel Glück damit, überlasse es dir.
@TonyM Entschuldigung, das konnte ich nicht verstehen. Meinen Sie damit, dass es eine sehr gute Chance gibt, dass mein SRAM gut funktioniert und das Problem woanders liegt?
Führen Sie als Experiment den CS- und OE-Übergang zu unterschiedlichen Zeiten durch (eine interne Uhr auseinander sollte dies tun); Ich hatte ungewöhnliche Ergebnisse von einigen Geräten (sowohl SRAMs als auch FPGAs), bei denen diese Signale gleichzeitig übergingen.
@PeterSmith Danke für den Vorschlag. Schauen Sie sich das letzte Diagramm an, ich denke, das ist genau das, was ich versucht habe. Leider das gleiche Ergebnis.
Warum änderst du die Adresse überhaupt mitten im Zyklus? Ich bin wirklich nicht davon überzeugt, dass dies nicht Ihr Problem ist.
Ist es möglich zu erraten, von welchen anderen Stellen (Adressen) des SRAMs die falsch gelesenen Daten stammen? Wie in Ihrem letzten Diagramm, wo 0x620 auftaucht. Irgendeine Ahnung, von welcher Stelle das kommt?
Sie sagen auch, dass die Spuren vom FPGA zum SRAM 10 cm lang sind. Das ist lang genug und die FPGA-Ausgänge haben Übergangszeiten, die schnell genug sind, wo Sie wahrscheinlich und wirklich 22- bis 33-Ohm-Widerstände in Reihe mit jeder Leitung an den FPGA-Ausgängen haben sollten. Beachten Sie, dass die SignalTap-Ansicht der SRAM-Signale von allem, was auf der physischen Platinenebene vor sich geht, "isoliert" ist und Sie wahrscheinlich ein normales Oszilloskop verwenden müssen, um die Signale selbst am SRAM zu untersuchen und den SI (Signalintegrität) zu bewerten. auf die ich vorher anspielte.
Ich würde auch auf Signalpegel achten. Was der Signalabgriff für eine 1 oder 0 hält, unterscheidet sich möglicherweise von dem, was SRAM für eine 1 oder 0 hält. Eingebaute Analysatoren bringen Sie nur so weit und geben Ihnen nur einen Blick aus dem Inneren des Chips. Wenn alles andere draußen so funktioniert, wie Sie es für gut halten, wenn nicht, können sie Sie einfach auf den falschen Weg bringen.
Fortsetzung: Schiffsingenieur „Ich verstehe es nicht, Kapitän, Motor läuft auf Hochtouren, aber wir bewegen uns nicht.“ … Bootsmannsmaat … „Hey Kapitän, was soll ich mit diesem Propeller machen, habe ich herausgefunden zurück.."
Ich würde stark einen trockenen Joint irgendwo im Adressbus vermuten. Pin nur kapazitiv mit der Signalleitung gekoppelt...
Trotz des Namens verwenden hochdichte statische RAMs interne Timing-Generatoren, um Dinge wie die Vorladung des Leseverstärkers usw. zu steuern. Diese werden von den Flanken auf den Steuerleitungen angesteuert. Beachten Sie, dass das Datenblatt besagt, dass die Testbedingungen Übergangszeiten von 5 ns oder weniger annehmen. Dies ist etwas, das Sie in Ihrem Setup überprüfen sollten – langsame Flanken oder Flanken mit viel Klingeln könnten die Symptome hervorrufen, die Sie sehen.
@Trevor, OP ändert die Adresse während des Zyklus, da es sich um einen 2-Takt-Lesevorgang handelt, dh der RAM-Datenbus ist halb so breit wie seine Lesedatenbreite. Das ist alles in Ordnung. Ich denke nur, da wir hier nur einen kleinen Teil des Bildes sehen können, liegt die Aufmerksamkeit auf einem bestimmten Datenelement und es gibt so viele Unbekannte. Wenn ich es war, komme ich zu diesem Stadium und überprüfe alles: FPGA-Pin-Zuweisungen, RAM-Datenblatt gegen Symbol, Uhr, Schienen, alle Bus-Timings usw. Diese Plausibilitätsprüfung dauert eine Stunde und kann viel Zeit sparen. (Entschuldigung, früherer Beitrag war unverblümt, aber genau gelesen, OP, von einem sehr sonnigen Schloss getippt :-) )
@ TonyM Da der SRAM mit unterschiedlichen Timing-Einstellungen arbeitet, würde ich sagen, dass die Pin-Zuweisungen sicherlich in Ordnung sind. Leider habe ich zu Hause kein ausreichend schnelles Oszilloskop, um die echten Signale zu sehen, aber es hört sich so an, als hätte Dave Recht: Dies kann ein Fehler sein, der auf das Klingeln zurückzuführen ist. Schade, dass mein FPGA keine Slew-Rate-Einstellungen hat.
@DmitryGrigoryev, Ihr geposteter Test zeigte Lesevorgänge mit unterschiedlichen Geschwindigkeiten von verschiedenen Adressen - der einzige Unterschied war nicht die Geschwindigkeit. Ich könnte es den ganzen Tag wiederholen, aber es spielt keine Rolle: Es ist wertvoll, sich der Grundlinie sicher zu sein - todsicher -, das nehme ich aus langer Erfahrung :-) (Ich spiele selten die 'alte Soldaten'-Linie!) Nimmt wenig Zeit in Anspruch, schließt das Böse bei der Fehlersuche aus: Vermutungen. Übrigens wäre das Klingeln bei schnellen Lesevorgängen schlimmer als bei langsamen, nicht umgekehrt. Poste die Antwort, wenn du sie findest, viel Glück für einen schnellen Job :-)
@TonyM Oh, ich stimme dir vollkommen zu, ich habe nur darauf hingewiesen, dass es die Eigenschaften eines schlechten Gelenks aufweist und der interne Analysator ihm dabei nicht helfen wird.
@Trevor Ich habe alle Pins mit meinem Multimeter überprüft und auch ein zweites IC-Muster mit den gleichen Ergebnissen ausprobiert.
@DaveTweed Sie hatten Recht - das Hinzufügen von Source-Abschlusswiderständen zu den Pins, die den SRAM ansteuern, hat geholfen. Danke noch einmal!

Antworten (1)

Dmitry, um die Lösung für Ihr Problem zu erhalten, müssen Sie es systematisch beheben. TonyM, Trevor, Dave, Michael und Gregory lieferten mehrere Vermutungen, die in Ihrem Design systemisch qualifiziert werden müssen. Nachfolgend stelle ich Ihnen eine Zusammenfassung zur Verfügung:

  • Ihr Board hat ein FPGA mit einem IS62WV51216BLL-55TLI-Chip, der über 10 Zentimeter lange Spuren damit verbunden ist.
  • es liegen keine Informationen zur Leistungsführung oder Leistungsentkopplung vor;
  • Sie haben den Code bei der Auswahl der Adresse gezeigt, es sind keine Informationen verfügbar, wie Sie die Daten in das FPGA-Design einlesen.
  • Es sind keine Boardbilder verfügbar, wir können das Design Ihres Boards und seine Herstellung nicht sehen.

Schauen wir uns die Konfiguration an:

always@(posedge clk) begin
 if( reset ) begin

Bei Ihren Analysatormesswerten fehlt das Rücksetzsignal. Sie müssen nachweisen, dass das resetSignal immer niedrig ist, wenn ein Problem auftritt.

Schauen wir uns nun die Diagramme an. Wie Sie bemerkt haben, ändert sich der Wert E0A0 -> ECA0 -> EC9F -> 00D0, wobei die Änderung auf 00D0 innerhalb des Lesezyklus erfolgt und ein von Ihnen gemeldetes Problem darstellt. Dieses SRAM ist nicht in seinen Eingangs- und E/A-Pins registriert, daher können mehrere Probleme auftreten, wenn es anfängt, falsche Signale auszugeben:

  • Machtproblem. Wenn es ein intermittierendes Stromversorgungsproblem geben würde, würde der RAM-Chip ohnehin mit dem richtigen Wert gelesen werden, da er nicht registrierte Eingänge hat. Sie können versuchen, den Lesezyklus noch weiter zu erhöhen, um zu sehen, ob sich der Wert wieder von 00D0 auf EC9F ändert. Wenn die Stromversorgung vollständig ausfallen würde, würde es zu Datenbeschädigungen im RAM-Inhalt kommen, da dies nicht der Fall ist (und beim zweiten Mal können Sie die richtigen Daten lesen). Ich glaube kaum, dass es sich um ein Stromversorgungsproblem handelt.
  • Steuer- oder Adresssignalproblem. Haben Sie Klimmzüge auf den Datenleitungen? Wenn Sie sie hätten, dann wird Inaktivität als FFFF gelesen, ansonsten kann es alles gelesen werden. Ich würde empfehlen, schwache Pull-ups auf der FPGA-Seite einzuschalten. Es ist wirklich schwer zu sagen, was mit den Steuer-/Adressleitungen passieren könnte, da Kommentatoren darauf hinwiesen, dass Sie die Situation so sehen, wie FPGA die Situation sieht, und nicht, was wirklich auf der Verbindung zwischen FPGA und SRAM passiert.

Ich würde dir folgendes empfehlen:

  • Schalten Sie schwache Pull-Ups auf den Datenleitungen ein, um sicherzustellen, dass bei Problemen mit der Chipauswahl / -freigabe dies als FFFF auf dem Bus angezeigt wird.
  • Erfassen Sie den fehlerhaften Lesezyklus und halten Sie das System an, indem Sie die Logiksonde verwenden, um die Logikpegel an den Pins zu erkennen. Dazu können Sie den RAM mit einigen vordefinierten Inhalten füllen (z. B. 0001 - 0203 - 0405 - ...) und Adressen in einer Schleife lesen, bis Sie einen unerwarteten Wert erhalten, und die Uhr anhalten, wenn dies geschieht. Messen Sie mit einem Multimeter/Logiktastkopf die Spannungen aller Signale – Steuerung, Daten und Adresse – um herauszufinden, wie es außerhalb des FPGA aussieht.
  • Wie die Leute bereits in Kommentaren sagten, überprüfen Sie die physischen Verbindungen. Sie nehmen eine Lupe und sehen sich jede Leiterplattenverbindung an. Sie verwenden eine Nadel, die sie mit etwas Kraft zwischen die Pins des Chips (wenn es sich nicht um BGA, sondern um TSOP handelt) stecken, um sicherzustellen, dass die Pins nicht von den Pads gerissen werden, wenn Sie eine kleine Kraft anwenden (seien Sie sehr vorsichtig, Stifte und Abreißpads nicht wegzubiegen!).
Danke, ich werde die Dinge ausprobieren, die du erwähnst (ich habe noch keine schwachen Klimmzüge ausprobiert und die Uhr angehalten). Der Hauptverdächtige ist meiner Meinung nach das Klingeln, das Dave erwähnt hat, also wäre mein nächster Schritt, das Proto-Board mit einem anständigen Zielfernrohr in ein Labor zu bringen. Wenn das jedoch keine Ergebnisse liefert, gehe ich die ganze Liste durch.
SRAM arbeitet mit kurzen Lesezyklen, fällt mit längeren aus
AntwortenHierDatenschutz-Bestimmungen1y, 0v