Hallo, ich habe das XUPV5-LX110T Entwicklungsboard und benutze ISE 12.1 bzw. seit kurzem auch 12.3. Mein Problem ist, einen mit MIG generierten memory controller erfolgreich in einem einfachen user design zu instantiieren und auf dem FPGA zu testen. Hierzu habe ich ein ISE Projekt angelegt, in dem ich in einem top level design den controller instantiiere und einfache Schreib-/Lesebefehle ausführe. Zum debuggen habe ich das phy_init_done Signal, sowie die Signale clk0 und clk200 auf LEDs rausgeführt (wobei clk0 ja gleich dem clk0_tb ist). Dort sehe ich schon, dass clk0 nicht vorhanden ist und phy_init_done folglich auch nicht aktiv wird. Der clk0 Takt wird ja letztendlich vom sys_clk[_p,n] erzeugt, deshalb vermute ich, dass es in irgendeiner Form an den constraints für diesen Takt liegen muss. Ich habe auch shcon ähnliche Probleme hier im Forum gefunden (allerdings ohne Lösung). Die DIP switches auf dem Board sind so gesetzt wie es für den RAM erforderlich ist, und auch den 200MHz Takt habe ich mit den SMB Kabeln angeschlossen. Hat vielleicht jemand einen Tipp? Besten Dank im Voraus, Sebastian
Ohne jetzt die MIG-Maske für Virtex-5, geschweige denn den Code vor Augen zu haben: Man gibt im MIG eine Frequenz an, mit der das Memory-Interface laufen soll. Der MIG nimmt WIMRE dann auch genau diese Frequenz als Takt für die sys_clk an (guck mal in die Constraints, der der MIG ausspuckt, was ist dort für sys_clk angegeben?). Wenn das Interface bspw. für 333 MHz erzeugt wurde, aber nur 200 MHz bekommt, haut das nicht hin.
Aber sollten dann nicht zumindest die internen Takte von Controllers, also clk0, clk90, etc. "falsch" aus dem Infrastruktur Modul kommen? Weil den clk0 Takt führe ich ja auf eine LED nach draußen. Oder spuckt das Infrastruktur Modul gar nichts aus, wenn sys_clk falsch ist?
Ergänzung: in der MIG GUI habe ich 266MHz angegeben, wie es auch im MIG Design Creation Dokument steht. In der constraint file ist auch entsprechend das timing angegeben: ... PERIOD "SYS_CLK" 3.75 ns HIGH 50 %;
Also wird Dein für 266 MHz ausgelegtes Design jetzt nur mit 200 MHz betrieben. Da kann es gut sein, dass die PLL keinen Lock bekommt und damit das Memory nicht losläuft, oder es gehen an anderer Stelle Timings schief. Du müsstest jetzt Deine Infrastrukturkomponente so modifizieren, dass die PLL auch mit 200 MHz Eingangstakt die erforderlichen Takte erzeugt. Da steht bestimmt im User Guide was zu. Zu dem Board gibt es bestimmt ein Example, wie wird das dort gemacht?
heißt das, dass sys_clk und clk200 gleich sein müssen? So habe ich das nicht verstanden. Das example design, das vom MIG erzeugt wird, ist genau das mit 266Mhz, so wie es auch im MIG Design Creation Guide steht. Das ist die max. frequenz für den V5-LX110T mit speed grade -1.
Was hast Du für sys_clk angeschlossen? Das müssen die 266 MHz sein, die der MIG verlangt. sys_clk soll auf Pins H14/H15 ankommen, also anscheinend von einem SMA-Stecker. Etwa der?: SebastianR schrieb: > und auch den 200MHz Takt habe ich mit den SMB Kabeln > angeschlossen. Die 200 MHz bekommst Du aus dem Clock Generator auf CLK_FPGA_P/_N (Pin L19 & K19).
Rudolph schrieb: > Das müssen die 266 MHz sein, die > der MIG verlangt Instanziiert sich der MIG nicht - wahlweise - eine (bzw. mehrere) DCM(s) um den Takt für die DDR-Flipflops aus dem Systemtakt zu erzeugen? Duke
Hi, beides stimmt, ich habe die constraints H14/h15 und L19/K19 für die clocks, wie Rudolf geschrieben hat. Der Controller hat ein sog. infrastructure Modul in dem DCM/PLLs für die clocks instanziiert sind. sind folgende statements in der ucf korrekt? NET "sys_clk_p" IOSTANDARD = LVPECL_25; NET "sys_clk_n" IOSTANDARD = LVPECL_25; NET "clk200_p" IOSTANDARD = LVPECL_25; NET "clk200_n" IOSTANDARD = LVPECL_25; Ich weiß selbst noch nicht, was sie bedeuten. Muss mir erst mal noch ein genaueres Bild über die verschiedenen constraint Parameter machen. Oder kann jmd. diese Parameter ohne zu großen Aufwand erklären? grüße, sebastian
SebastianR schrieb: > LVPECL_25 low voltage pseudo ECL (emitter coupled logic) @ 2.5 V [1] Da Du jeweils _P und _N hast, würde ich tippen, das da eher was mit LVDS stehen sollte. Ich weiß nicht ob PECL ein differenzielles Signal ist... Außerdem fehlen da noch timing constraints. Mit IOSTANDARD legst Du nur Spezialitäten der IO-Buffer fest. Schau mal hier : UCF-Dateien Duke [1] http://de.wikipedia.org/wiki/Emittergekoppelte_Logik
Die timing constraints sind: NET "*/u_ddr2_infrastructure/sys_clk_ibufg" TNM_NET = "SYS_CLK"; TIMESPEC "TS_SYS_CLK" = PERIOD "SYS_CLK" 3.75 ns HIGH 50 %; NET "*/u_ddr2_infrastructure/clk200_ibufg" TNM_NET = "SYS_CLK_200"; TIMESPEC "TS_SYS_CLK_200" = PERIOD "SYS_CLK_200" 5 ns HIGH 50 %; Das LVPECL habe ich aus der ucf, die vom MIG generiert wurde. Es gibt auch ein fertiges Beispiel Design zum download von der xilinx Seite (MIG Design Creation ...), dort steht: NET "sys_clk_p" IOSTANDARD = LVDS_25 | DIFF_TERM = TRUE; NET "sys_clk_n" IOSTANDARD = LVDS_25 | DIFF_TERM = TRUE; NET "clk200_p" IOSTANDARD = LVDS_25 | DIFF_TERM = TRUE; NET "clk200_n" IOSTANDARD = LVDS_25 | DIFF_TERM = TRUE; Auch damit funktioniert es nicht. Sebastian
Kannst Du Deinen Taktbaum mal aufzeichnen? Inklusive alle externen Takte und internen DCMs? Duke
Hi, kann gerade nicht scannen, d.h. ich reiche später ein eingescanntes bild nach falls erforderlich. Ich versuche es mal in worten zu beschreiben, auch um herauszufinden, ob es das ist, was du meinst: sys_clk_p und sys_clk_n (pins) gehen in ein IBUFGDS_LVPECL_25 (Eingänge I und IB). Der Ausgang O (sys_clk_ibufg) geht in ein PLL_ADV. Heraus kommen clk0_bufg_in, clk90_bufg_in und clkdiv0_bufg_in die alle drei jeweils durch ein BUFG laufen. Deren Ausgänge sind dann die Signale clk0, clk90 und clkdiv0, die im ug086 (http://www.xilinx.com/support/documentation/ip_documentation/ug086.pdf) auf Seite 372 vom infrastructure module ins interface top module gehen. das clk200_p/n PIN-Paar geht ebenfalls in ein IBUFGDS_LVPECL_25, dessen Ausgang clk200_ibufg dann noch durch einen BUFG. Dessen Ausgang ist dann das Signal im ug086, Seite 372. vielen dank und grüße, sebastian
Angehängte Dateien:
-
ug086_p372.png
73 KB
Im Anhang mal der Auszug, über den wir gerade sprechen. Wir halten fest: Du hast Timing Constraints auf clk200 und sys_clk_[p,n] gesetzt und dein Design läuft nicht und clk0 wird wegoptimiert. 1. Gibt es Auffälligkeiten im Synthesereport? Hast Du den Synthesereport schon mal mit dem Beispieldesign verglichen? (Geht mit einem diff-Tool ganz gut.) 2. Hat Reset die richtige Polarität? 3. Die 200 MHz sollten nur für IDELAY_CTRL sein. Du kannst Dir mit Chipscope mal die Steuersignale fürs IDELAY_CTRL anzeigen lassen. Da solltest Du sehen, ob (und wie) die Init-Sequenz arbeitet. 4. Werden bei der Synthese (bzw. bei Place&Route) die Timings erreicht? Wie ist der Timing-Score? Duke
Genau, das ist das Bild, das ich meinte, danke! Ich habe in der Tat timing Verletzungen. Hier ein Auszug:
1 | Timing constraint: TS_u_ddr_frame_buffer_u_ddr2_infrastructure_clk0_bufg_in = PERIOD TIMEGRP "u_ddr_frame_buffer_u_ddr2_infrastructure_clk0_bufg_in" TS_SYS_CLK HIGH 50%; |
2 | 19760 paths analyzed, 1372 endpoints analyzed, 146 failing endpoints |
3 | 146 timing errors detected. (146 setup errors, 0 hold errors, 0 component switching limit errors) |
4 | Minimum period is 4.207ns. |
5 | -------------------------------------------------------------------------------- |
6 | |
7 | Paths for end point i_30 (SLICE_X58Y92.D3), 97 paths |
8 | -------------------------------------------------------------------------------- |
9 | Slack (setup path): -0.457ns (requirement - (data path - clock path skew + uncertainty)) |
10 | Source: i_2 (FF) |
11 | Destination: i_30 (FF) |
12 | Requirement: 3.750ns |
13 | Data Path Delay: 4.129ns (Levels of Logic = 6) |
14 | Clock Path Skew: -0.013ns (0.460 - 0.473) |
15 | Source Clock: clk0_tb rising at 0.000ns |
16 | Destination Clock: clk0_tb rising at 3.750ns |
17 | Clock Uncertainty: 0.065ns |
18 | |
19 | Clock Uncertainty: 0.065ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE |
20 | Total System Jitter (TSJ): 0.070ns |
21 | Discrete Jitter (DJ): 0.108ns |
22 | Phase Error (PE): 0.000ns |
Da frage ich mich grundsätzlich, wie man mit nicht erreichten Timings von fertigen Modulen wie dem memory controller aus dem MIG umgeht? Es ist doch nicht Sinn der Sache, den noch zu verändern? Die anderen Punkte prüfe ich noch ... danke für die ausführliche Hilfe! sebastian
SebastianR schrieb: > Requirement: 3.750ns > Source Clock: clk0_tb Also 266 MHz auf dem internen Design? Sportlich. Ich habe hier einen Spartan3e. Der läuft intern mit 50 MHz und das DDR-Speicherinterface auf 100 MHz. Der Virtex5 sollte intern mit 100 bis 150 MHz, kleine Designteile sicher auch mit 200 MHz. Aber das komplette interne Design mit 266 MHz laufen zu lassen halte ich für schwierig. Aber das ist ja das Schöne an so einem DDR-Core. Man kann intern mit seiner Wunschgeschwindigkeit arbeiten und nach außen kümmert er sich um die korrekten Memory-Timings. Duke
Was heißt das jetzt konkret? Das Beispiel Design ist falsch? Die angegebenen Timings müssen doch auch mit dem Takt von sys_clk_[p,n] übereinstimmen. Wie hoch der ist, weiß ich nicht, dazu habe ich auch nichts in irgendeinem guide gefunden.
Ok. Ich hab greade noch das im ug086 gefunden:
1 | If the user clock domain is different from clk_0 / user_clk of the MIG, |
2 | the user should add FIFOs for all data inputs and outputs of the |
3 | controller in order to synchronize them to the user_clk. |
Im Beispieldesign/Testbench befindet sich ja nur ein Zähler, ein Komparator und eine FSM. Die könnten auch mit 266 MHz noch laufen. Wie schnell kann denn Dein restliches Design getaktet werden? Duke
Die Stelle habe ich im ug086 auch schon mal gefunden. Im Moment kann ich noch nicht sagen, wie schnell mein user design mal getaktet wird - versuche praktisch erst mal den mem controller zum Laufen zu bringen und zu verstehen, wie genau Daten geschrieben und gelesen werden. Habe den Core jetzt mit 133Mhz erzeugt, so werden alle timings erreicht (score 0). Reset sollte die richtige Polarität haben - nehme ihn so an, wie im ug086. zu 1.: Gibt es da so etwas wie einen Referenz Synthese Report mit dem ich meinen vergleichen kann, oder verstehe ich das falsch?
Hast Du eigetlich das ganze mal simuliert? SebastianR schrieb: > Habe den Core jetzt mit 133Mhz erzeugt, so werden alle timings erreicht > (score 0). Gut. > Reset sollte die richtige Polarität haben - nehme ihn so an, wie im > ug086. Gut. > zu 1.: Gibt es da so etwas wie einen Referenz Synthese Report mit dem > ich meinen vergleichen kann, oder verstehe ich das falsch? Ich dachte Du hättest ein (funktionierendes) Beispieldesign vorliegen, mit diesem hättest Du eine Vergleichssynthese machen können. Duke
Also, sorry für etwas Verwirrung. Ich hatte schlicht und einfach noch ein paar falsche constraints, weshalb der eine Takt nicht funktioniert hat. Nun funktionieren beide Takte und auch das init_done Signal wird '1'. Besten Dank für die Geduld, Duke! Sebastian
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.