Hallo, ich habe ein Problem mit dem PSRAM (MT45W8MW16BGX) auf dem Nexys 3. Ich habe diesen für den synchronen Betrieb konfiguriert, welcher auch relativ problemlos funktioniert. Ich lese aus dem RAM 32 Wörter (16 bit) Burst und speichere diese in einem FIFO zwischen. Das Ganze dient für eine Art Grafikkarte, welche den Inhalt aus dem RAM auf VGA darstellt. Ich kann alles richtig auslesen, nur bei Adressen auf die die Bedingung (ADDR mod 3200 = 0) zutrifft treten Lesefehler auf. Die Fehler sind bis zur Adresse 3600. Ich habe das ganze Problem auch mit einem IpCore LA (ChipScore Pro) nachvollziehen können. Dort kommen beim Anlegen der Adresse (z.B. 3200) und der nachfolgenden Lesesequenz immer wieder ein paar falsche Daten auf den BUS. Zum Aufspielen der Daten in den RAM nutze ich das von Digilent mitgelieferte Tool Adept. Meine Frage ist nun, ob Ihr ähnliche "schlechte" Erfahrungen mit dem Tool habt oder ob ich in meinen Routinen suchen soll. Gruß Alexander
>Ich habe das ganze Problem auch mit einem IpCore LA (ChipScore Pro) >nachvollziehen können. Dort kommen beim Anlegen der Adresse (z.B. 3200) >und der nachfolgenden Lesesequenz immer wieder ein paar falsche Daten >auf den BUS. Beim Schreiben mit dem "Tool Adept" oder beim Lesen mit deiner Schaltung im FPGA, wo genau siehst du die Fehler mit Chipscope? Und auf welchem Bus? Kann das "Tool Adept" auch aus dem PSRAM lesen? Wenn ja und die Daten sind nach dem Schreiben fehlerfrei -> deine Routinen...
Beim Lesen mit meiner Schaltung im FPGA, sehe ich den Fehler im direkt angeschlossenen Datenbus des RAMs. Wenn ich das Ganze mit dem Adept Tool auslese, ist der Fehler nicht vorhanden. Wobei hierzu vielleicht zu erwähnen sei, dass das Tool meiner Meinung nach im asynchronen Modus ausliest und schreibt (VERMUTUNG). Also wären es deiner Aussage nach meine Routinen, mich wundert nur, dass der RAM nur bei dieser speziellen Adresse etwas Falsches ausgibt, die 40 Lesevorgänge davor und danach funktionieren einwandfrei. Ich habe mit ChipScope natürlich auch das richtige Anliegen der Adressen geprüft. Ich hänge gleich noch mal ein paar Bilder an, wenn ich Sie auf ChipScope raus bekomme. Gruß Alexander
Mein RAM Takt liegt bei 50 Mhz. Auf Bild 1 sieht man einen richtigen Lesevorgang. Dort gibt es solange fifo_write auf high ist erst einen Block E0E0, dann einen Block 0202, dann noch ein UB 02 und danach nurnoch E0E0 Bild 2, fehlerhaft hat folgende Abweichung: Erst Block E0E0 dann Block 0202 welcher dann kurz von einem Wort E0E0 durchbrochen wird (der Fehler) und dann geht es wieder wie oben weiter. Ich hoffe es ist verständlich. Gruß Alexander
Die Adresse und der Einlese-Takt in der Waveform wären hilfreich.. Wie schnell (slew) sind die FPGA-Outputs zum PSRAM eingestellt, bzw welche Treiberstärke ist eingestellt? Auch mal mit langsameren Takt probiert (25 Mhz)?
Hallo, der slew steht für die ganze Pins auf slow, ich sah es bei 50 Mhz noch nicht ein das zu ändern. Sollte ich das machen ? Als IOSTANDARD nutze ich LVCMOS33. Die Signalstärke des RAMs ist auf half power gestellt. Nein, mit langsameren Takt habe ich es noch nicht probiert, ich dachte bei so vielen validen Lesevorgängen sollte es nicht am Takt liegen. Das ist vielleicht noch einmal zu betonen. Ich lese knapp 90 Blöcke fehlerfrei aus und habe dann 12 Blöcke welche fehlerhaft sind. (Also fehlerhaft in einem einzigen Wort, wie man oben sieht). Dann lese ich wieder 90 Blöcke fehlerfrei aus und dann beginnt das Spiel von vorne. Die Bilder mit Takt und Adresse werde ich baldmöglichst nachreichen, bin gerade an einem Rechner ohne ChipScope Lizenz. Gruß
Ich hatte mal ein "ähnliches" Problem mit dem Basys 2. Dort hatte das BRAM an einigen Stellen bitfehler. Vielleicht ist Dein Problem ähnlich. Und die Synthese legt jedesmal die gleichen Speicherregister in den gleichen BRAM Puffer. Stell doch mal einen Offset beim Auslesen ein, oder lies mal das ganze rückwärts ein. Vielleicht "wandert" dann ja der Fehler.
:
Bearbeitet durch User
Ich verstehe unter BRAM den internen BlockRAM des FPGAs. Hier geht es um den externen PSRAM. Aber ich werde das was du vorgeschlagen hast einmal probieren.
50 MHz sind eigtl. leicht machbar, sind aber auch nur 20 nanosekunden;) Aus den Datenblättern und aus dem Xilinx-Timinreport zu entnehmen: Wielange braucht der Clock zum RAM aus dem FPGA? bzw. wo kommt der Clock her und wie geht er zum PSRAM (Schaltung)? Wielange braucht der RAM für die Anwort (Clock zu Datenraus max)? Wielange brauchen die xilinx-Input Pins? Und wie groß ist der Beitrag des Routings von IO zum Fifo?
Alexander S. schrieb: > Ich verstehe unter BRAM den internen BlockRAM des FPGAs. Hier geht es um > den externen PSRAM. ja, richtig. Meine sehr weit hergeholte Vermutung war: Vielleicht ist ja alles mit dem externen PSRAM in Ordnung, und vielleicht speicherst Du die Daten für die Übertragung (unbewusst) im BRAM zwischen. Wie ist der FIFO implementiert? Vielleicht als Ringpuffer mit einer Länge die mit Mod 3200=0 korrespondiert? Alexander S. schrieb: > Also wären es deiner Aussage nach meine Routinen, mich wundert nur, dass > der RAM nur bei dieser speziellen Adresse etwas Falsches ausgibt, die 40 > Lesevorgänge davor und danach funktionieren einwandfrei. Deswegen: Vielleicht funktionieren sogar alle Lesevorgänge und der Fehler passiert nach dem Auslesen.
:
Bearbeitet durch User
Hallo, die Daten die in der oben dargestellen LA Waveform sind die Daten die direkt hinter einem BUFT und einem zum einsynchronisieren verwendeten fdre FF abgegriffen werden. Dahinten ist noch mal ein FIFO geschalten, der die Daten aber ansonsten richtig ausgibt (also richtig, mit Fehlern). Eckdaten des Fifos (256 bit (128 mal 16 bit) mit 50 Mhz an Interface a und 256 mal 8 Bit mit 40 Mhz an Interface b). Das ganze ist aus einem IpCore von Xillinx entstanden.
Alexander S. schrieb: > Hallo, > > die Daten die in der oben dargestellen LA Waveform sind die Daten die > direkt hinter einem BUFT und einem zum einsynchronisieren verwendeten > fdre FF abgegriffen werden. > > Dahinten ist noch mal ein FIFO geschalten, der die Daten aber ansonsten > richtig ausgibt (also richtig, mit Fehlern). > > Eckdaten des Fifos (256 bit (128 mal 16 bit) mit 50 Mhz an Interface a > und 256 mal 8 Bit mit 40 Mhz an Interface b). Das ganze ist aus einem > IpCore von Xillinx entstanden. Dein LA-Screenprint zeigt Dir die Daten nur so wie das entsprechende FF die Daten auch sieht. Hast Du Timing Constraints für dein RAM eingegeben? Wie sieht das Timing in Bezug auf Setup und Hold aus? Passt das (auch mit den Layout Constraints zusammen). Hier kann es wenn es knapp ist, durchaus sein dass ausgegebenen Pattern auf dem Adressbus das Leseergebnis in Richtung funktioniert gerade nicht mehr beeinflussen. Häng evtl. den Synthesereport in Hinblick aufs Timing an...
Hallo, ich habe leider noch keine Constraints (Timing/Layout) gesetzt. Ich muss ehrlich gestehen, ich kenne mich damit auch noch nicht wirklich aus. Mein maximale Taktfrequenz ist mit 180 Mhz deutlich über dem Haupttakt (100 Mhz) Den Syntesereport hänge ich nachher noch an. Zur Erzeugung meiner MEMCLK nutze ich eine Primitive (ODDR2). Gruß Alexander
Angehängte Dateien:
-
MT45W8MW16BGX.PNG
390 KB
// Verilog Test Fixture created by ISE for module: ramtester Title: Problem about write and read data from the psram on the Nexys3 Link: http://forums.xilinx.com/t5/3rd-Party-Other-Boards-and-Kits/Problem-about-write-and-read-data-from-the-psram-on-the-Nexys3/td-p/225073/page/2 module ramtester_tb; // Inputs reg clk; reg MemWait; // Outputs wire RAM_CEN; wire MEM_OEN; wire MEM_WEN; wire RamCRE; wire MemAdv; wire MemClk; wire [1:0] RAM_BEN; wire [25:0] MEM_ADDR; wire [3:0] an; wire [7:0] seg; // Bidirs wire [15:0] MemDB; MT45W8MW16BGX.PNG Der link da oben geht über 2 Seiten, und da ist auch testcode dabei. Das geht darum das als SRAM ohne Clock zu testen. Also asychron mit 50 MHz . 15ns zu 20ns-FPGA. Somit ist das ohne Clock via FSM testbar, ob dir nicht auf dem Bord-Bus was 'geshared ist, und somit ins gehege kommt. Siehe LCD Display Bus via STRATA FLash-Bus. Bei SPARTAN-3E. Gruss Holger. VHDL Modul: http://forums.xilinx.com/xlnx/attachments/xlnx/OTHERBRD/695/1/testRAM3.rar http://forums.xilinx.com/xlnx/attachments/xlnx/OTHERBRD/691/1/RAMtest.zip
:
Bearbeitet durch User
Hallo, ich danke für die zahlreichen Antworten. Ich glaube ich konnte den Fehler eingrenzen. Werde probieren meinen Code etwas umzuschreiben und melde mich dann noch einmal. Gruß Alexander
Alexander S. schrieb: > Hallo, > > ich habe leider noch keine Constraints (Timing/Layout) gesetzt. Ich muss > ehrlich gestehen, ich kenne mich damit auch noch nicht wirklich aus. > > Mein maximale Taktfrequenz ist mit 180 Mhz deutlich über dem Haupttakt > (100 Mhz) Das hat erst mal nix zu sagen, wenn Du keine Constraints setzt, hat das Synthesetools alle Freiheiten und wenn es meint z.B. ein FF mit welchem Du die Lesedaten von Aussen einzuclocken mitten in den FPGA setzt um eben sagenhafte 180Mhz erreichen zu können, dann hat das Signal im Gegensatz dazu beispielsweise zwischen 3 und 10ns größeren Setup... Ohne Constraints fährst Du mit 100 durch den Nebel und freust dich das Du soweit ohne Unfall gekommen bist... > > Den Syntesereport hänge ich nachher noch an. > > Zur Erzeugung meiner MEMCLK nutze ich eine Primitive (ODDR2). ...sonst würde dein Synthesetool auch das meckern anfangen... wie gesagt kritisch ist die Platzierung von Eingangs- und Ausgangs FFs. Die Synthesetools unterstützen Dich bei der Einhaltung der richtigen Timings (siehe Datenblatt deines Rams), Du musst Ihm nur die Gelegenheit dazu geben...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.