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
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.
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.
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.
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?
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.
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
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
im Anhang hier noch die DCM quelldatei (habe ich vom core generator erstellen lassen)
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.
Angehängte Dateien:
-
clock.JPG
5,3 KB
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
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
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.
@roger hab deine Nachricht gerade erst gelesen. Genau den Gedanken hatte ich auch gerade :) Danke
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
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.
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?
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
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
Auch ich würde mir den core sehr gern mal ansehn. Tom
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.
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
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
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
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.