www.mikrocontroller.net

Forum: FPGA, VHDL & Co. DDR2 SDRAM auf XUPV5, init Problem


Autor: SebastianR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: SebastianR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: SebastianR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 %;

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: SebastianR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: SebastianR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: SebastianR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst Du Deinen Taktbaum mal aufzeichnen? Inklusive alle externen Takte 
und internen DCMs?

Duke

Autor: SebastianR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_doc...) 
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

Autor: Duke Scarring (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: SebastianR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau, das ist das Bild, das ich meinte, danke!

Ich habe in der Tat timing Verletzungen. Hier ein Auszug:
 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%; 
  19760 paths analyzed, 1372 endpoints analyzed, 146 failing endpoints 
  146 timing errors detected. (146 setup errors, 0 hold errors, 0 component switching limit errors) 
  Minimum period is   4.207ns. 
 -------------------------------------------------------------------------------- 
  
 Paths for end point i_30 (SLICE_X58Y92.D3), 97 paths 
 -------------------------------------------------------------------------------- 
 Slack (setup path):     -0.457ns (requirement - (data path - clock path skew + uncertainty)) 
   Source:               i_2 (FF) 
   Destination:          i_30 (FF) 
   Requirement:          3.750ns 
   Data Path Delay:      4.129ns (Levels of Logic = 6) 
   Clock Path Skew:      -0.013ns (0.460 - 0.473) 
   Source Clock:         clk0_tb rising at 0.000ns 
   Destination Clock:    clk0_tb rising at 3.750ns 
   Clock Uncertainty:    0.065ns 
  
   Clock Uncertainty:          0.065ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE 
     Total System Jitter (TSJ):  0.070ns 
     Discrete Jitter (DJ):       0.108ns 
     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

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: SebastianR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok. Ich hab greade noch das im ug086 gefunden:
If the user clock domain is different from clk_0 / user_clk of the MIG,
the user should add FIFOs for all data inputs and outputs of the
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

Autor: SebastianR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: SebastianR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

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.