Hallo, ich bin gerade dabei mithilfe des MIG von Xilinx ein Memory Controller zu erzeugen. Die Frage welche sich mir dabei stellt ist, muss man die im MIG eingestellte Taktfreqeunz genau treffen oder ist diese nur ein ungefährer Richtwert? Mir stehen leider nur 40MHz von einem externen Quarz zur Verfügung. Über eine schnelle Antwort würde ich mich sehr freuen! Besten Gruß
Alexander M. schrieb: > Mir stehen leider nur 40MHz von einem externen Quarz zur Verfügung. Jeder FPGA hat heutzutage PLLs, mit denen du höhere Frequenzen erreichen kannst, als dir extern zur Verfügung stehen. Gruß Marius
Der RamCore geht davon aus das du die Frequenz die du beim Erzeugen einstellst, auch am Clk-Eingang des MIG-Moduls anliegt. D.h. du hast beispielsweise 300 Mhz eingestellt dann sollten auch 300 Mhz am sys_clk-Eingang anliegen. Wenn du keine passende Clock hast musste dir vorher eine passende erzeugen per Clockwizard. Du kannst auch irgendeine andere Clock verwenden, ABER deine Preformance is dann eine andere und ob es stabil läuft weiß ich nicht. Als ich angefangen hab mit dem MIG-Core hab ich ohne Wissen/Ahnung verschiedene Frequenzen an den sys_clk angeschlossen, das Ram-Modul hat immer funktioniert in meinen Tests (kurze kleine Test), aber ob das stabil ist /war ??? Es entspricht zumindest dann nicht den xilinx Vorgaben und Specs. Aber weiter im Text, wenn du dir also eine passende Frequenz erzeugt hast, dann musst du noch eine kleine Datei (vom MIG-Core) bearbeiten um die (Clock) dann an den MIG-Core anschliessen zu können, aber das kann ich später noch erklären. Du kannst ne Menge im xilinx Forum dazu finden. Da scheint nen ganz fähiger Foristen aktiv zu sein, der schon mehrere relativ gut verständliche Tutorials für den MIG-Core geschrieben.
Danke für die schnelle Antwort! Mein Problem ist allerdings, dass ich mit DCM/PLL über Multiplikation und Division meine Frequenz von 40 Mhz nie auf eine für den RAM passenden Wert bringen kann. Nehmen wir mal an ich stelle die 3846ps ein, dann braucht der RAM somit 260,01MHZ. Mit DCM/PLL komm ich aber nur auf 260MHz. Eine 266,67Mhz volle Taktfrequenz wäre somit gar nicht möglich. Habe ich da irgend ein Denkfehler? Mach irgend was falsch?
Hallo ziehe mein Fragen zurück, habe eine Lösung gefunden. Das Problem ist die Eingangsfrequenz von 40MHz, mit der geht es nicht, aber mit 50MHz treffe ich wieder die Frequenzen von MIG. Danke nochmal für eure Zeit! Gruß
Trundle Trollkönig schrieb: > Du kannst auch irgendeine > andere Clock verwenden, ABER deine Preformance is dann eine andere und > ob es stabil läuft weiß ich nicht. Ich benutze selber in einem aktuellen Projekt eine PLL, um die nötige Frequenz für die MIG Core zu erstellen. Die MIG Core hat selber nochmal eine PLL oder DCM je nach Einstellung und generiert sich daraus weitere Frequenzen. Habe den DDR2 Ram auch schon sehr lange drin im Projekt und habs auch getestet, ob Fehler beim Lesen oder Schreiben passieren, bisher ohne jegliche Fehleranzeichen. Es ist also nicht unbedingt notwendig die passende Frequenz von außen reinzugeben, da intern in der MIG sowieso eine PLL oder DCM verwendet wird. gruß Cihan
Hallo Cihan, danke für die Info! Würde es dir was ausmachen, wenn du mir als kleine Gedankenstütze dein Projekt schicken könntest? So könnte ich mir vielleicht ein paar Fehler beim Einbinden und Ansprechen des RAMs sparen. Wäre dir sehr dankbar! Gruß
Hallo Maazie, mein Projekt wird dir nicht helfen, da vieles andere schon drin ist, bis du klar kommst wie was gehändelt wird, verlierst du viel Zeit. Ich würde dir folgenden Weg empfehlen: - du kreierst dir mit dem MIG Generator erstmal deine DDR2 Ram Core. - wenn du dann die ganzen ucf technischen einbindunden auch richtig gemacht hast und die mitgelieferte Testbench zum laufen bekommst bzw. verstehts was auch dort gemacht wird, dann kannst du mit Chipscope auch angucken was wirklich intern in der Core passiert - Das einzige, außer der UCF -Pinvergabe, was du machen musst, ist ja deine 266Mhz aus der DCM oder PLL core wo du die 50MHz einbindest und 266Mhz rausbekommst, in den MIG-Core zu integrieren. Dafür musst du in der Infrastruktur-File der Core (ddr2_infrastructure.vhd) den Ibufg zu einem BUFG umwandeln, der dann in die PLL der MIG-Core für die weiteren notwendigen Frequenzerzeugung verwendet wird - Nun hast du ja noch die Testbench, die als 3 x FIFO Struktur aufgebaut ist, wo die Daten, die Addresse und die WR / RD Cmd organisiert werden. - Wenn du den Ram im Betrieb hast, muss die INIT-LED der Core auch angehen, dass könnte z.B. dein erstes Ziel sein Desweiteren würde ich und sicher andere dir bei der Einbindung der DDR2 Core auch weiter helfen. Was ich dir noch empfehlen kann ist, die DDR2 Frequenz evtl. auf 200 MHz zu setzen. Ich hatte selber damals versucht mit 266MHz zu arbeiten, doch leider hatte ich viele Timing-Fehler dadurch im System. Mit 200MHz hatte ich dann diese Probleme nicht mehr. Aktuell habe ich sogar eine Frequenz von 125 Mhz zu laufen. Cihan
Hallo Cihan, dein Plan hört sich gut an. Kannst du mir noch sagen wo ich die Testbench finde, welche mitgeliefert wird und besteht die Möglichkeit ein Verhaltensmodell vom DDR2 RAM zu implementieren um eine umfassenden Simulation auch ohne Hardware machen zu könnnen? Gruß
Wenn du die Core mit dem MIG erzeugt hast findest du im erstellten Ordner 3 weitere Unterordner: docs, example_design, user_design. docs: hier findest du das UG086, quasi die Ansteuerung eines DDR2-Rams. example_design: hier findest du die nötige Core für die Ansteuerung des DDR2s mit einer Testapp + simulation. (Kleiner Hinweis an dieser Stelle, ich habe die Testapp mehr oder weniger für mein Projekt angepasst, was du auch machen könntest) user_design: hier findest du ebenfalls die nötige Core für die Ansteuerung, allerdings ohne Testapp, aber mit Simulation. Mit Testapp meine ich einfach nur eine fertige Beschreibung als Beispiel. Das Beispiel vom MIG schreibt und ließt die ganze Zeit in den DDR2 mit selbst generierten Addressen und Daten. Einfach die Hardwarebeschreibung durchforsten, verstehen, simulieren, testen und entspreched umändern / anpassen. Versuch demnach das Test Projekt aufzusetzen und falls du nicht mehr weiter kommst meldest du dich wieder mit den entsprechenden Details, wo es gerade hakt ebend. Übrigens die nötige UCF Datei findest du auch in den Ordner, aber prüfe evtl. nochmal durch, ob alles richtig mit der Pinvergabe ist. Cihan
Hallo Cihan, versteh ich das Richtig? DDR2_tb_top ist die Testbench. DDR2_tb_test_gen erzeugt Daten und Adressen?? Folgender Projekt stand: - es steht noch keine Hardware zur Verfügung - reine Simulations Umgebung Wenn ich jetzt den Core erzeugt habe, muss ich in meiner Top_level die PLL mit der DDR Frequenz und die 200MHz für idelay_ctr anschließen. Da physisch keine Hardware vorliegt muss ich das Verhaltensmodell einfügen, welches meine Hardware ersetzt. Als nächstes muss ich die Testbench DDR2_tb_top einbinden und den CLK_in für die PLL erzeugen. Dann müsste ich doch aber auch was sehen können oder? Hab ich da einen Denkfehler? Gruß Alex
Ach so, noch was bei mir werden die Dateien: icon4(), vio_async_IN192(),vio_async_IN92(), vio_async_IN100(), vio_async_out32() als fehlend im Projektpfad dargestellt.
Alexander M. schrieb: > Ach so, noch was bei mir werden die Dateien: icon4(), > vio_async_IN192(),vio_async_IN92(), vio_async_IN100(), vio_async_out32() > als fehlend im Projektpfad dargestellt. das ist, wenn ich mich nicht täuche für Chipscope. Die Datei DDR2_chipsope.vhd sollte dafür relevant sein. Aber brauchst du erstmal nicht. Kannst sie auskommentieren. Ich habe auch alle anderen Debug-Geschichten erstmal auskommentiert gehabt. Erst später habe ich auf der Hardware meine eigenen Chipscope-Signale mir angesehen um die Core zu debuggen. Cihan
Alexander M. schrieb: > Hallo Cihan, > > versteh ich das Richtig? DDR2_tb_top ist die Testbench. DDR2_tb_test_gen > erzeugt Daten und Adressen?? Ja. > Folgender Projekt stand: > > - es steht noch keine Hardware zur Verfügung > - reine Simulations Umgebung > > Wenn ich jetzt den Core erzeugt habe, muss ich in meiner Top_level die > PLL mit der DDR Frequenz und die 200MHz für idelay_ctr anschließen. Ja. Evtl. müsstest du 2 x 200MHz einbinden, eine als Taktfrequenz für den DDR2, der mit einer PLL weitere Frequenzen erzeugt und die andere an idelay_ctr für die I/Os. > Da physisch keine Hardware vorliegt muss ich das Verhaltensmodell > einfügen, welches meine Hardware ersetzt. > > Als nächstes muss ich die Testbench DDR2_tb_top einbinden und den CLK_in > für die PLL erzeugen. Warscheinlich muss du einen eigenen TOP_LEVEL.vhd File erzeugen und die mig_36_1.vhd (plus alle anderen relevanten Dateien unter mig_36_1.vhd) und ddr2_tb_top.vhd (auch hier alle anderen rel. Dateien unter ddr2_tb_top) einbinden. Den rest sollte ISE automatisch aufstellen. > Dann müsste ich doch aber auch was sehen können oder? Wenn du dann auch die mig_36_1.vhd mit ddr2_tb_top.vhd im TOP_MODULE.vhd File richtig verbunden hast, solltest du dann auch was sehen können. Als Vergleich kannst du ja mal in den user_design Ordner dir die Files angucken, welche im Vergleich zum example_Design Ordner nicht da sind, um dadurch zu erkennen, welche miteinandere wo harmonieren bzw. verbunden sein müssen. > Hab ich da einen Denkfehler? Versuch am besten so wie oben beschrieben erstmal ein Projekt aufzustellen. ISE wird evtl. schon meckern, dann kannst du ja direkt reagieren. Ansonsten kannst du auch dein Projekt hier als zip posten, damit man sieht wo es gerade hakt. > Gruß Alex Cihan
Alexander M. schrieb: > Welche Datei meinst du mit mig_36_1.vhd? Ups mein Fehler. Ich hatte mein Projekt mit "mig_36_1" benannt. D.h. du müsstest eine Datei haben "Projektname vom MIG-Coregenerator".vhd, diese File ist das Top-Module des DDR2 Rams. Cihan
Hallo, ich blick da nicht durch. Im Anhang ist mal mein Projekt. Ich habe eine PLL eingefügt und diese mit dem Clockeingang des MemContr verbunden. Könntest du dir bitte das mal anschauen was da schief läuft. Komme nicht so richtig vorwärts. Kennst du eine Dokument in dem man den Umgang mit dieser Testbench nachlesen kann? Gruß
Alexander M. schrieb: > Kennst du eine Dokument in dem man den Umgang mit dieser Testbench > nachlesen kann? Schau dir mal das UG086 im Ordner docs an. Da müsste was dazu stehen. Cihan
Wer lesen kann ist klar im Vorteil! Habe den Abschnitt vollkommen übersehen. Sorry für die doofen Fragen!
Zum Simulieren brauchst du erstmal nicht die ddr2_tb_top.vhd file in die sim_tb_top.vhd einzufügen. Die sim_tb_top.vhd sollte eigentlich alles enthalten, du musst lediglich alles ins ISE Projekt einbinden. Desweiteren brauchst du hier auch keine PLL vorerst, da in sim_tb_top.vhd die Frequenzen automatisch generiert werden, du musst lediglich die Konstanten dafür anpassen. Ich muss in diesem Punkt sagen, dass ich selber keine Simulation gemacht habe, ich habe direkt auf der Hardware meine Tests gemacht, und dafür ebend ddr2_tb_top.vhd benutzt. Diese Datei ist nicht unbedingt für die "reine" Simulation gedacht, dafür hast du sim_tb_top.vhd. Versuche mal ohne die PLL und ohne ddr2_tb_top.vhd das Projekt nur mit sim_tb_top.vhd und den nötigen anderen Files aufzubauen. Cihan
Hallo Cihan, die Simualtion des IP in meinem System habe ich erstmal auf Eis gelegt. Ich habe aber eine Frage zum Lesen von Daten aus dem RAM. Laut user guide muss man die Adressen taktsynchron anlegen, der MemContr regelt die Kommunikation zum RAM. Liegen die Werte im Read Data FIFO wird das Signal rd_data_valid gesetzt. Sind dann die Daten zu den entsprechenden Adressen taktsynchron zu clk_tb, oder woher weiß man wann neue Daten anliegen? Gruß maazie
Alexander M. schrieb: > Hallo Cihan, > > die Simualtion des IP in meinem System habe ich erstmal auf Eis gelegt. Warum? Abgesehen davon würde ich dir empfehlen das ganze auf der Hardware zu debuggen mit Chipscope, setzt natürlich eine Hardware voraus, die du evtl. grade nicht hast?! > Ich habe aber eine Frage zum Lesen von Daten aus dem RAM. > > Laut user guide muss man die Adressen taktsynchron anlegen, der MemContr > regelt die Kommunikation zum RAM. Liegen die Werte im Read Data FIFO > wird das Signal rd_data_valid gesetzt. > > Sind dann die Daten zu den entsprechenden Adressen taktsynchron zu > clk_tb, oder woher weiß man wann neue Daten anliegen? > > > Gruß > > maazie der MemContr und die tb laufen mit der selben Frequenz, daher ist es taktsynchron. Der MemContr stellt ein entsprechendes CLK als OUT zur Verfügung, mit dem du die tb taktes. Mit anderen Worten: Du gibts dem MemContr eine INPUT-CLK, woraus er sich seine nötigen Frequenzen generiert. Zusätzlich zu der Generierung der Frequenzen gibt er sie natürlich auch als OUT raus, welche du dann in deinem Projekt verwenden darfst, damit alles Taktsynchron arbeiten kann! Cihan
Hallo Cihan, ich hatte das Problem mit dem DDR2 Mem.Controller (MC) erst mal auf eis gelegt gehabt. Jetzt stehe ich allerdings wieder vor dem Problem, mein VHDL Modell mit dem Mem.Contr. und dem Verhaltensmodell des DDR2 SDRAM, simulieren zu müssen. Im Anhang liegt mal mein Test Projekt. In diesem habe ich auf dem User Interface einen Addresszähler und einen Seriel/Parallel Wandler. Nach dem S/P Wandler liegt ein FIFO in dem die gelesenen Daten gespeichert werden sollen. Weiterhin hängt noch eine PLL für den CLK an dem Clocking Bereich des MC. Am PHY_Interface habe ich das Verhaltensmodell des DDR2 angeschlossen und die DDR2 Modellparameter Datei in die Workspace eingebunden (lagen im Ordner user_design\sim). Ich habe die breite der Bussignale in der Componenten Deklartion des Verhaltensmodell angepasst, da diese dort mit (0 to 0) generiert wurden. Versucht man nun eine Testbench zu erzeugen wird dieser Vorgang immer mit dem Fehler 3317: "ERROR:HDLParsers:3317 - <file>.vhd Line # Library <my_lib> cannot be found." abgebrochen. Dieser Fehler tritt immer genau dann auf, wenn man das Verhaltensmodell an den MC anschließt. Was mache ich falsch? Woher kommt dieser Fehler? Ich würde mich sehr freuen, wenn du mir bei meinem Problem weiterhelfen könntest. Es geht ohne dem Verhaltensmodell einfach nicht weiter! Über Antwort würde ich mich sehr freuen! Mit besten Grüßen Maazie
Alexander M. schrieb: > Was mache ich falsch? Woher kommt dieser Fehler? Welche von Deinen Dateien ist denn nun die Aktuelle?:
1 | TOP_DESIGN.vhd TOP_DESIGN_01.vhd TOP_DESIGN_OMC.vhd |
1 | $ vlib work |
2 | $ vcom *.vhd |
3 | [...] |
4 | -- Compiling architecture Behavioral of TOP_DESIGN |
5 | ###### TOP_DESIGN.vhd(104): ck : IN std_logic_vector((CLK_WIDTH-1) downto 0); |
6 | ** Error: TOP_DESIGN.vhd(104): (vcom-1136) Unknown identifier "CLK_WIDTH". |
Duke
Hallo Cihan, ich ab es geschafft den MemCont. einzubinden. Die Simulation funktioniert wie gewünscht. Den MemCont. habe ich mit einer Pll erzeugt und speise den Sys_clk mit 133MHz und den idle_clk mit 200MHz ein. Diese erzeuge ich mit Hilfe einer Pll aus 50 MHz Eingangstakt. Du hattest geschrieben, dass ich in der Datei ddr2_infrastructure.vhd den Ibufg zu einem bufg ändern muss, damit das funktioniert. Könntest du mir bitte sagen wo ich das genau machen soll. Ich nehme mal nicht an, dass es ausreicht den namen sys_clk_ibufg in sys_clk_bufg zu ändern, oder?! Weiterhin bekomme ich sehr viele Warungen bei der Synthese, welche mit dem MemContr. in Verbindung stehen. (unconntected output port, signal assigned but never used). War das bei dir auch so? muss ich mir hier gedanken machen oder kann ich die Warnungen übergehen? Über eine schnelle Antwort wäre ich dir sehr dankbar! Mit besten Grüßen Alex
maazie schrieb: > Den MemCont. habe ich mit einer Pll erzeugt und speise den Sys_clk mit > 133MHz und den idle_clk mit 200MHz ein. Diese erzeuge ich mit Hilfe > einer Pll aus 50 MHz Eingangstakt. Du hattest geschrieben, dass ich in > der Datei ddr2_infrastructure.vhd den Ibufg zu einem bufg ändern muss, > damit das funktioniert. Könntest du mir bitte sagen wo ich das genau > machen soll. Ich nehme mal nicht an, dass es ausreicht den namen > sys_clk_ibufg in sys_clk_bufg zu ändern, oder?! In der ddr2_infrastructure.vhd Datei werden die Clock mit Primitive Buffern ins System eingebunden bzw. an die PLL der Mem.Core weitergegeben. Da du nun selber von einer PLL oder DCM kommst musst du den Buffer rausnehmen. Bsp:
1 | -- SYS_CLK : IBUFG
|
2 | -- PORT MAP (
|
3 | -- I => sys_clk_125,
|
4 | -- O => sys_clk_ibufg
|
5 | -- );
|
6 | sys_clk_ibufg <= sys_clk_125; -- Primitive ersetzen durch einfache Zuweisung, falls IBUFG unerwünscht! |
Schau mal im UG190 auf den Seiten 107, 108 und 109 nach. Da findest du die Verschaltung 2er PLL, DCM zu PLL oder PLL zu DCM. Je nachdem wie du es in deinem Design verwenden willst, musst du dementsprechend dein Design verschalten. Wenn du beisp.w. die 50MHz in eine PLL einliest und damit die 133 und 200 MHz erzeugst, musst du sie über einen BUFG zur PLL des Mem.Contr. verbinden. Schau nach was du brauchst und verwende es. maazie schrieb: > Weiterhin bekomme ich sehr viele Warungen bei der Synthese, welche mit > dem MemContr. in Verbindung stehen. (unconntected output port, signal > assigned but never used). War das bei dir auch so? muss ich mir hier > gedanken machen oder kann ich die Warnungen übergehen? Das ist normal, habe auch immer so viele Warnings drin gehabt. Nicht abschrecken lassen, denn es funktioniert hinterher auch mit den Warnings. LG Cihan
Hallo Cihan, vielen Dank für den Hinweis, hätte ich eigentlich auch selber drauf kommen müssen! Der eine Error ist jetzt verschwunden, der nächste ist jedoch schon da.
1 | ERROR:LIT:600 - IOBUFDS symbol |
2 | "u_MEMORY_CONTROLLER/u_ddr2_top_2/u_mem_if_top/u_phy_top/u_phy_io/gen_dqs[0].u_iob_dqs/gen_dqs_iob_ddr2_ddr3.u_iobuf_dqs" (output |
3 | signal=u_MEMORY_CONTROLLER/u_ddr2_top_2/u_mem_if_top/u_phy_top/u_phy_io/gen_d |
4 | qs[0].u_iob_dqs/dqs_ibuf) does not have IOSTANDARD specified. Map is unable |
5 | to generate a default IOSTANDARD for IOBUFDS, one has to be explicitly |
6 | provided. |
Ich habe schon ein bisschen im iNet gesucht, aber keine brauchbare Lösung gefunden. Aber der error scheint kein Einzelfall zu sein. Kannst du mit dem Error was anfangen und hast du evtl. eine Lösung parat? Gruß Alex
Prüfe mal ob in deiner UCF-Datei alle IN/OUTs mit einem IOSTANDARD definiert / zugewiesen sind. Die UCF findest du in eine der Unterverzeichnisse der generierten Core! LG Cihan
Hallo Cihan, nicht alle inout Pins haben den gleichen IOSTANDARD.
1 | NET "c0_ddr2_dq[*]" IOSTANDARD = SSTL18_II_DCI; |
2 | NET "c0_ddr2_a[*]" IOSTANDARD = SSTL18_II; |
3 | NET "c0_ddr2_ba[*]" IOSTANDARD = SSTL18_II; |
4 | NET "c0_ddr2_ras_n" IOSTANDARD = SSTL18_II; |
5 | NET "c0_ddr2_cas_n" IOSTANDARD = SSTL18_II; |
6 | NET "c0_ddr2_we_n" IOSTANDARD = SSTL18_II; |
7 | NET "c0_ddr2_cs_n[*]" IOSTANDARD = SSTL18_II; |
8 | NET "c0_ddr2_odt[*]" IOSTANDARD = SSTL18_II; |
9 | NET "c0_ddr2_cke[*]" IOSTANDARD = SSTL18_II; |
10 | NET "c0_ddr2_dm[*]" IOSTANDARD = SSTL18_II_DCI; |
11 | #NET "ddr2_sys_clk_f0" IOSTANDARD = LVCMOS25; |
12 | #NET "idly_clk_200" IOSTANDARD = LVCMOS25; |
13 | #NET "sys_rst_n" IOSTANDARD = LVCMOS18; |
14 | #NET "c0_phy_init_done" IOSTANDARD = LVCMOS18; |
15 | NET "c0_ddr2_dqs[*]" IOSTANDARD = DIFF_SSTL18_II_DCI; |
16 | NET "c0_ddr2_dqs_n[*]" IOSTANDARD = DIFF_SSTL18_II_DCI; |
17 | NET "c0_ddr2_ck[*]" IOSTANDARD = DIFF_SSTL18_II; |
18 | NET "c0_ddr2_ck_n[*]" IOSTANDARD = DIFF_SSTL18_II; |
c0_ddr2_dq, c0_ddr2_ck_n und c0_ddr2_dqs_n haben verschiedene IOSTANDARDs, aber ich denke das muss auch so sein, da die einen Impedanzkontrolliert bzw. differential Signale sind, oder teuche ich mich? Gruß Alex
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.