mikrocontroller.net

Forum: FPGA, VHDL & Co. DDR SDRAM Ansteuerung - Nutzung von XILINX MIG


Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich möchte einen DDR2 SDRAM von Micron mit einem FPGA ansteuern und habe 
von dem Tool MIG (Memory Interface Generator) von XILINX gelesen. Sowohl 
der FPGA als auch der DDR2 SDRAM wird von der Version die ich laufen 
habe unterstützt und ich kann soweit alle Parameter einstellen.

Was ich nicht verstehe ist das "Select Banks" auf der rechten Seite des 
Tools. Ich nutze ein Development Board und somit ist die Verdrahtung ja 
bereits fest vorgeschrieben. Aber wo kann ich einstellen welcher Pin vom 
RAM mit welchem Pin vom FPGA verbunden ist?

Was hat es mit dem Select Banks auf sich, was muss man dort tun?

Hat schonmal jemand mit diesem MIG Tool gearbeitet??

Würde mich freuen wenn ihr eure Erfahrungen posten könntet.

P.S.: Über Anleitungen / Links zum Thema (den user guide von XILINX zu 
diesem Tool ausgeschlossen, denn aus dem werde ich nicht so richtig 
schlau) wäre ich natürlich auch dankbar.

Grüße

Tom

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Pinnummer wird im UCF festgelegt
http://www.mikrocontroller.net/articles/UCF-Dateien
Es könnte sein, dass man die Betriebsspannung pro Bank unterschiedlich 
wählen kann, oder dass verschiedene Bänke unterschiedliche Optionen 
haben. Ich weiß von Altera-MAXII-CPLD, dass die "PCI-Bus"-Option nur auf 
einer von vier Bänken geht.

Autor: DaMicha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

@Tom:
Hab mit vor kurzem auch einen DDR2 SDRAM Controller mit dem MiG Tool 
generiert. Was positiv ist, es hat simulativ schon mal funktioniert.
Leider scheint der Durchsatz des MiG Controller für kurze (bei mir 60 
Byte) Datenbursts auf ca. 45% einzubrechen (Laut Datenblatt das DDR2 
SDRAMs hätte ich ca. 60% erwartet). Irgendwie scheinen die Latencies zu 
groß zu sein, obwohl sie als Controller Contrain richtig eingestellt 
sind. Z.B.: wurden aus 15ns dann ca. 32ns für das aktivieren/adressieren 
einer Zeile.
Zum Glück steigt der Durchsatz aber wieder für längere Bursts und die 
Adressierungsphase fällt kaum noch ins Gewicht.

Vielleicht hat noch jemand die Info (so als Sicherheit - auch für mich 
;-) ), dass der generierte MiG DDR SDRAM Controller vom Durchsatz 
einfach schlechter ist, als ein fertiger Core.

Gruß DaMicha.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit den Bänken ist so gedacht:
Man soll MIG benutzen, bevor man ein board konstruiert. Da wählt man 
dann nur die Bänke aus, an die das Ram soll. MIG wählt schließlich 
selbstsständig aus, welche Pins welche Funktion bekommen und schreibt 
das ins UCF. Man sollte also erst danach sein Platinenlayout erzeugen 
und das nach dem generierten UCF richten.
Laut Xilinx dürfen maximal sehr kleine Änderungen im UCF vorgenommen 
werden (evtl tausch zweier benachbarter Datenpins), besser aber 
überhaupt keine.

Evtl hast du Glück und dein Board wurde nach so einer MIG Vorlage 
gemacht. Wenn nicht dann solltest du einen anderen Speichercontroller 
verwenden, weil es sonst wohl sehr unwahrschienlich funktioniert.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

danke erstmal für die Antworten.

Ich bin inzwischen weiter vorgedrungen und bin auf weitere 
"Kleinigkeiten" gestoßen.

@Matthias: Das ist ja auch schön wenn man selber ein Board erstellen 
will aber will man es wie ich für ein Dev-Board nutzen ist die 
Pinbelegung nunmal vorgeschrieben, da habe ich wohl Pech.

@DaMicha: Zum Durchsatz kann ich Dir leider nichts sagen da es bei mir 
nach wie vor nicht funktioniert.

Nun zu den Neuigkeiten:
Vorweggenommen das Design funktioniert nicht und ich weiss auch noch 
nicht warum, es gibt da ja so einige mögliche Gründe.

Frequenzen:
Das MIG tool generiert den Controller ja so als ob er den Takt sowie den 
doppelten Takt (in meinem Fall 100MHz und 200MHz) von aussen bekommt (es 
sind Pins vorgesehen für differenzielle Takte). Da ich auf dem Board 
aber nur die 100MHz habe, habe ich die 200 mit dem DCM intern erstellt. 
Folge war das sich nichts synthetisieren lässt da die Puffer nicht 
korrekt sind und so weiter. Also habe ich den Controller manuell 
abgeändert (negativen Taktpin entfernt und Puffer auf interne geändert) 
und speise den Controller nun mit der DCM. (auch das ucf file habe ich 
natürlich dementsprechend geändert)

Was die Pinbelegung angeht habe ich mich dazu entschlossen das ucf-file 
einfach an mein Pinout anzupassen (was bleibt mir auch anderes übrig?)

Dann habe ich eine kleine FSM geschrieben welche an einer bestimmten 
Adresse ein einzelnes write macht (als ein burst) das ganze danach 
wieder liest, vergleicht und wenn gelesenes mit geschriebenen 
übereinstimmt eine LED anschaltet. (zum Testen eben ob es überhaupt 
funktioniert)
Und siehe da die LED bleibt aus.

Ich weiss jetzt nicht so recht wo und wie ich ansetzen kann nach Fehlern 
zu suchen. Vielleicht ist es das geänderte Pinout, vielleicht irgend 
etwas anderes.

Hat irgendjemand eine Idee wie ich am besten vorgehen sollte?

Autor: Michael Niegl (bigmike47)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das selbe auf einem ML410 gemacht sowohl fuer DDR als auch DDR2 
die beide nicht direkt vom MIG unterstuetzt werden (habe einfach manuell 
ziemlich viel im VHDL Code geaendert) und beide laufen wunderbar. 
Versuch einfach mal den Fehler zu finden, sprich an welcher Stelle Dinge 
schief gehen. Moegliche Fehlerursachen koennten sein: DCM im Controller 
lockt nicht, IDELAY primitive  lockt nicht, init des RAM controllers 
haengt irgendwo, dummy write/reads des controllers sind nicht 
erfolgreich usw.
du musst erst mal das Problem finden, bevor du es loest.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

es hat eine Weile gedauert bis ich wieder Zeit gefunden hab weiter an 
dem Controller zu arbeiten. Herausgekommen ist dabei bis jetzt 
folgendes:

Mein Testprogramm wird garnicht erst durchlaufen da es mit clk0_tb 
getaktet ist und dieser Takt überhaupt nicht anliegt.

Ich hab das idelayrdy flag aus idelay auf eine LED nach aussen geführt 
und sie bleibt aus. Wenn ich richtig annehme das dieses Signal 1 wird 
sobald das modul idelay fertig ist, dann passiert dies nie. (Vielleicht 
gibt es ja aber dort auch nur einen Impuls oder so und ich seh ihn nur 
nicht, keine Ahnung)

Was könnte der Grund dafür sein das dieses readyflag nie gesetzt wird? 
Hast du noch Vorschläge an welcher Stelle ich weitersuchen kann um das 
Problem zu finden?

Danke schonmal

Tom

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab noch etwas ausprobiert:

wie weiter oben schonmal geschrieben erzeuge ich die nötigen 200MHz 
intern mit einer DCM welche wiederum von aussen mit 100MHz (Quartz auf 
dem board) versorgt wird.

Ich habe die 200 MHz mal an einen Pin nach aussen geführt und mit dem 
logic analyzer angesehn und das sieht folgendermaßen aus:

   _    __      __    _
__|  |__|  |____|  |__|  |____
2ns          4ns

also 1 für 2ns 0 für 2ns 1 für 2ns 0 für 4ns und dann von vorne. Das 
könnte ja schon das problem sein weil der controller so nicht seine 
200MHz clk bekommt.

Aber wie kann das sein das mir ein so komischer clock erzeugt wird??

Tom

Autor: Tom (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
im Anhang hier noch die DCM quelldatei (habe ich vom core generator 
erstellen lassen)

Autor: Michael Niegl (bigmike47)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der grund dass das readyflag nie gesetzt wird, liegt einfach daran, dass 
deine 200 MHz (und IDELAY laeuft immer mit 200MHz) nicht gut genug bzw. 
nicht vorhanden sind. Locken die 2 DCMs (der fuer 100->200 und der vom 
RAM Controller) ? solange das nicht passt, wird der rest auch nie etwas 
machen.

Autor: Tom (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe mir jetzt meine selbst erstellte DCM (die die 200MHz 
erzeugt) nochmal einzeln angesehn.

Also einzeln synthetisiert und auf den FPGA geladen und die pins nach 
aussen geführt.

gelockt hat die DCM (LED ist angegangen, geht auf Reset aus und danach 
wieder an)
clko_0 und clk_2x sehen einfach nur komisch aus (siehe Anhang). Aber bei 
der Erstellung kann man doch garnicht viel falsch machen oder??

Wieso kommt denn da kein ordentlicher Takt raus?

Hier nochmal die Daten:
100 MHz kommen vom Quartz auf dem Board
200 MHz sollen rauskommen

guckt man sich clk_0 und clk_2x an sieht man einen unregelmäßigen Takt

Autor: Roger Steiner (edge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tom wrote:
> clko_0 und clk_2x sehen einfach nur komisch aus (siehe Anhang).

schau dir das besser mal auf einem guten Oszilloskop an.

Cheers, Roger

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube ich verfolge den Falschen Ansatz, die clock sieht 
wahrscheinlich nur so komisch aus wegen der Abtastung des Logic 
Analyzers.

Ich versuch mal ein ordentliches Oszi irgendwo her zu bekommen.

Die erste DCM lockt also auf jeden Fall.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@roger

hab deine Nachricht gerade erst gelesen. Genau den Gedanken hatte ich 
auch gerade :)

Danke

Autor: Michael Niegl (bigmike47)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dann musst du nur noch sicherstellen, dass auch der zweite DCM lockt, 
sprich alle Frequenzen in den richtigen Ranges liegen und er so lange im 
Reset gehalten wird, bis der erste DCM lockt. Wenn du das nicht 
sicherstellst, wird der zweite DCM so gut wie sicher nie locken

Autor: Tom (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Also der zweite interne DCM (welcher sich in dem modul "infrastruktur" 
befindet) der die clk0 generiert lockt nicht.

Warum weiss ich noch nicht. Ich habe das Modul ja manuell angepasst weil 
ich eben den 200MHz Takt nicht von aussen anlege (so wie vom MIG 
vorgesehen) sondern intern mit der ersten DCM erzeuge.

Ich habe nur die Puffer geändert (und die negativen clock lines 
entfernt) von differntial auf singel aber vielleicht benutzt man ja wenn 
das Signal von intern kommt an irgend einer Stelle nicht einen ANDEREN 
sondern KEINEN Puffer, das weiss ich nicht.

Was genau Du mit dem im Reset halten meinst weiss ich noch nicht. Ich 
hab es so verstanden:

Ich muss irgendwie dafür sorgen das der zweite DCM so lange im Reset 
gehalten wird bis das lock signal von der ersten DCM 1 geworden ist? 
Stimmt das so? Denn dafür sorge ich momentan nicht.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem Reset war anscheinend wirklich das Problem:

Ich habe den ersten DCM vom system reset abgekoppelt, sodass er 
loslaufen und locken kann. Danach kann ich alles andere manuell per 
knopf reseten. Dann lockt auch die 2te DCM und auch das clk0_tb 
Taktsignal funktioniert nun.

Somit werden jetzt auch die Zustände meiner FSM (test write burst und 
read burst mit vergleich der gelesenen und geschriebenen daten) 
durchlaufen und der Vergleich ist erfolgreich. Es wird also gelesen was 
vorher geschrieben wurde. SUPER :)

Da das mit dem Reset jetzt nur provisorisch gelöst ich frage ich mich ob 
ich nicht einfach das systemreset ausschließlich an die erste DCM 
anschließen kann und alle anderen resets mit dem lock signal der ersten 
DCM verbinden kann.

so nach dem Motto:

reset <= not lock_signal_von_erster_dcm;

Könnte man die Sache so lösen?

Autor: Michael Niegl (bigmike47)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so macht man das normalerweise immer

Autor: NorthernLights (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hei,

Xilinx bietet twei verschiedene Möglichkeiten an Source-Synchronous 
Interfaces wie z.b. DDR-SDRAMs anzusteuern. Die erste Möglichkeit ist 
das Strobe/Clk Signal des externen Bausteins auf einen Inputpin des 
FPGAs zu legen (vorzugsweise einen Global/Regional Clockpin) und damit 
die Eingangsregister der Datenpfade zu takten um die Signale in den FPGA 
zu bekommen. Der Nachteil hierbei ist, dass die Daten eventuell 
asynchron zu einer internen Systemclock ankommen und wieder 
resynchronisiert werden müsse, z.B. durch FIFOs. Falls man eine 
Regionalclock oder einen normalen Inputpin für das Strobe/Clock Signal 
des externen Bausteins nimmt, ist man außerdem in der Wahl seiner 
Inputspins für die Datenleitungen sehr eingeschränkt. RegionalClocks 
können normalerweise nur die 3 Bänke um den RegionalClock Pin versorgen 
und bei einem normalern Inputpin können einem die Routingdelays im FPGA 
in die Suppe spucken.
Empfehlenswerter ist die zweite Methode, die auch Xilinx für neuer FPGSa 
mit IDELAY Zellen verwendet, die DirectClocking Methode, die auch die 
vom MIG generierten Cores anwenden. Dazu werden Dummy Transaktionen an 
das RAM geschickt und das empfangene Strobe/Clock Signal von der 
internernen Systemclock gesampled. Mittels einer FSM und den Idelay 
Zellen wird dazu das Strobe/Clocksignal so lange verschoben, bis es 
zentriert zur Systemclock ankommt. Da Strobe/Clocksignal und 
Datensignale des RAMs phasengleich ankommen kann man den ermittelten 
Wert für die Idelayzellen verwenden um alle ankommenden Datensignale 
optimal auf die Sytemclock zu zentrieren. Resynchronistation entfällt in 
diesem Falle. Bei dieser Methode ist es auch völlig egal, wo die Pins 
der Datensignale liegen, solange der Delay vom Strobe/Clock und 
Datensignale auf dem PCB ungefähr gleich sind und die Bänke die richtige 
I/O Voltage unterstützen. Das von Xilinxs MIG generiert UCF enthält nur 
die Constrains für die I/O Pins aber keine Logic Contrains, wie z.B. 
zeitkritische PCI Cores. Solange die Skews der Leitungen auf dem Board 
klein genug sind, kann man die Pins beliebig umlegen.
Wer sein Design kompakt halten möchte kann soagr noch einen Schritt 
weiter gehen und die Sampling Logik für das Strobe Signal komplett 
rausschmeißen und die IDELAY Werte für die einzelnen Datenleitungen von 
Hand berechnen und in das UCF eintragen. Die Werte hierfür bekommt man 
aus dem Datenblatt des RAMs, den Board Delays und den I/O Delays des 
FPGAs.
Einer meiner Diplomanden hat im Rahmen seiner Diplomarbeit einen sehr 
kompakten und schnellen DDR-SDRAM Core für die DirectClocking Mehtode 
entwickelt , da uns der XilinxCore zu langsam und zu groß war (und in 
der 1. Version des MIG auch nicht unbedingt ein Beispiel für gutes 
Design). Der Core läuft bis zu 200 MHz, verbraucht gerade mal ca. 200 
Slices und erreicht durch Back-to-Back Bursts bis zu 98% der 
theoretischen Durchsatzrate des RAM Bausteins. Die Parametrisierung 
erfolgt durch ein VHDL Package, sodaß beliebige DDR-SDRAMs und Taktraten 
verwendet werden können. Initialisierung, Refresh und Bank/Row Switching 
werden automatisch erledigt und sind für den User transparent. Der Core 
ist Open-Source, gut dokumentiert und darf im Rahmen der GPL frei 
verwendet werden. Falls Interesse besteht kann ich den Source-Code gerne 
mal posten.

Gruss,
  NL

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ihr Lieben!

@  NorthernLights
Ich hätte großes Interesse die Core-Lösung, die bei euch entwickelt 
wurde kennen zu lernen. Wenn die ganze Sache auch noch gut dokumentiert 
ist, dann wäre das hervorragend.

Gruß
Manuel

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch ich würde mir den core sehr gern mal ansehn.

Tom

Autor: damicha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

Hab auch Interesse und ne Frage:
Was sind Back-to-Back Bursts?

Ansonsten, 200 Slices sind nicht schlecht. Der MIG Core brauchte so 1100 
Slices, 1800 Register und 2 Blockrams im Virtex5 bei einer 
Datenbusbreite von 16 Bit.

Würde auch gerne mal in Eueren Core schaun ;).

Gruß DaMicha.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich wäre auch sehr interessiert an dem VHDL-Design.

Autor: pwie42 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

ich würde mich auch sehr für einen gpl ddr ctrl core interessieren, da 
ich mittlerweile schon seit einer woche an einem fehler an einem MIG 
generierten core suche.

ich habe so ziemlich die selben voraussetzungen wie es tom oben 
beschrieben hat, nämlich nur eine 100Mhz clk die ich dann intern mittels 
clk_fx auf 200 Mhz aufblase, ich verwende dazu allerdings nur einen DCM, 
den clk_0 (100 Mhz als system_clk), die 90 grad geschiftete clk als 
clk_90, und die am clk_fx generierte clk zur idelay kalibrierung.

Der Fehler der bei mir auftriff ist das ich am dem dqs_pipe FF (das FF 
das nach dem idelay im iob hängt) eine setup violation bekomme wenn ich 
das par model teste.
was ja auch so sein muss, soweit ich das verstehe, denn der idelay hat 
dann das ende der "high" zeit gefunden und shiftet dann auch wieder 
zurück.
allerdings breiten sich die Xe die am ausgang von diesem FF herauskommen 
soweit über das ganze system aus, das es dann irgendwann steht, und gar 
nichts mehr macht.

insofern wäre ich echt froh über einen vernümpftig documentierten 
funktionierenden core, bzw. über jeden tip den mir jemand zur 
beseitigung der setup violation geben kann.

mfg pwie

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ihr Lieben,

mich dürstet es dermaßen nach dem freien Code für den SDRAM cntrl Core, 
das könnt ihr euch gar nicht vorstellen.
Ich sitze jetzt schon ewig an dem Xilinx-MIG-generierten Code und bekomm 
es einfach nicht zum Laufen.

NorthernLights wenn du mal wieder einen Blick ins Forum wirfst, dann wär 
es echt super, wenn du den Code und die Doku dazu posten könntest.

Gruß,
verzweifelter Manuel

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Boa, Leute...

Setzt euch hin, lößt euch von allen generierten Cores, schnappt euch ein 
Oszi implementiert selber was!

Ich will nicht sagen, dass es einfach ist, aber dabei werdet ihr nicht 
nur viel lernen, sondern bekommt wahrscheinlich auch was hin! Nur Mut!



Grüße,

Kest

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.