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
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
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%;
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.
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
