DDR SDRAM liest dieselben Daten zweimal im READ burst mit BL=2

Klaus Rindtorff Gast #972049
Lesenswert?
• ▲
▼ 
Ich habe einen DDR SDRAM controller basierend auf dem VHDL code von 
Steve Rhoads geschrieben. Dieser wird für das MT46V32M16 auf dem S3E 
starter board verwendet.
Der controller funktioniert prima - aber nur in der behavioral 
simulation. Ich teste ihn indem ich Daten mit 4 mal 2 words in einem 
burst an aufeinanderfolgende Adressen schreibe, diese dann mit 4 2-word 
bursts zurücklese.
In der hardware funktioniert es dann leider nicht. Ich sehe das dasselbe 
word 2 mal hintereinander gelesen wird. Interessanterweise das zweite im 
WRITE burst geschriebene. Also geschrieben AB CD EF GH, gelesen BB DD FF 
HH.
Die clocks sind DCM generiert. Das SD_CK_FB feedback SIgnal auf dem SE3 
SK wird benutzt. Für das Schreiben verwende ich FDDRRSE (ODDR2) FFs.
Mit meinem Ant8 logic analyzer sehe ich dass die nötigen Signale 
generiert werden. Jedoch reicht die zeitliche Auflösung nicht aus um 
einen timing Fehler zu erkennen.

Irgendeine Idee wo der systematische Fehler liegen könnte?
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
SuperWilly Gast #972184
Lesenswert?
• ▲
▼ 
Hat denn Steve Rhoads für sein DDR-Controller-Design
Timing/Placing-Constraints für die Synthese definiert ?
Ohne eine richtig umgesetze Logik für die Einsychronisierung
der Lesedaten und eine richtige Ausgabe der Schreibdaten (Man beachte
Phasenlage von DQS zu DQ) ist die ganze Klamotte witzlos.
Eine Timing-Simulation könnte dir Aufschluss darüber geben, ob die
DDR-Signale an deinen FPGA-Pins richtig aussehen.
Empfehlenswerte Alternative: DDR-Controller IP-Core

Gruß,
SuperWilly
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Klaus Rindtorff Gast #980491
Lesenswert?
• ▲
▼ 
Danke für den Tipp SuperWilly. Wie sich herausgestellt hat war die 
Phasenlage von DQS zu DQ schon ok. Auch die MAXDELAY constraints waren 
nicht so kritisch wie ich dachte.
Aber ich habe wohl das timing der tri-state buffer beim Schreiben falsch 
gewählt, so dass das HIGH von DQS nicht komplett sichtbar war. Nachdem 
ich das korrigiert habe funktioniert es nun bei 100 MHz. Jetzt mache ich 
ersteinmal ein paar READ/WRITE tests um zu sehen wie stabil es läuft.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren