DDR Ram Controller von OpenCores (problem)

[Thomas T. (warhammerth)]

Hallo ich habe mir den DDR Controller von OpenCores geladen 
(http://www.opencores.org/project,ddr_sdr)

Nun meine Frage:
Ich weis nicht wie ich folgende PINs anschließen muss:
      rst_n              | IN  |  external asynchronous reset, low 
active

     sys_rst_qn         | OUT |  sync reset low active, released after 
DCMs are locked, may be used by other modules inside the FPGA


   sys_clk_out        | OUT |  system clock, dcm output, may be used by 
other modules
                                  inside the FPGA as global clock

      clk_fb             | IN  |  DCM feedback clock, must be external 
connected to ddr_sdr_clk !



Vorallem das clk_fb  wo nehme ich das her?
Ich habe gelesen dass es irgendwie nach außen geschleift und über eine 
PLL wieder hineinkommen muss (wegen 90° phasenverschiebeung)   aber wie 
mache ich das?


Hat jemand schonmal dieses Modul genutzt?

Ich habe folgendes FPGA board:

Virtex-4™ MB Development Board (Memec /Avnet)


darauf ist der DDR Ram chip

HYB25D512160BC6

Muss ich da noch irgendwas bestimmtes beachten?... parameteranpassung 
oder so?

[Andreas B. (Firma: www.collion.de) (bergy)]

Hallo Thomas,

> Hallo ich habe mir den DDR Controller von OpenCores geladen
> (http://www.opencores.org/project,ddr_sdr)

Dies ist ein allgemeiner DDR-Codec welcher nicht speziell auf die 
vorhandene IO-Intellegenz deines Virtex4 zugeschnitten ist. Dies 
limitiert die max. Speed des Controllers (wahrscheinlich für Dich kein 
Problem) zum anderen wirst Du wahrscheinlich einige Constraints setzen 
müssen um ein reproduzierbares Ergebnis zu erhalten. Du wirst also nicht 
umhinkommen Dich tief in die Materie einzulesen.
Insofern würde es nicht schaden wenn Du Dir die Dokumentation zum MIG 
bei Xilinx durchliest, auch wenn Du den Core gar nicht nutzt! Der 
Opencores Core entspricht dabei mehr der Spartan3 Variente als den 
Virtex-Cores...

>
> Nun meine Frage:
> Ich weis nicht wie ich folgende PINs anschließen muss:
>       rst_n              | IN  |  external asynchronous reset, low
> active

Wie schon in der Doku steht benötigst Du für den Core ein Resetsignal 
(Low Aktiv). Dieser dient dem Core unter anderem die Initialisierung der 
DDR-Rams zu vollziehen und deren Initialisierungsende abzuwarten. 
Solltest Du kein externes Resetsignal haben, so kannst Du Dir auch 
behelfen in dem Du Dir einen Reset selber bastelst:
Beim Init des FPGAs (nach laden des Bitstreams) sind im FPGA alle 
FlipFlop Elemente in einem definierten Zustand. Dies kannst Du ausnutzen 
um z.B. einen Zähler auf einen bestimmten Wert laufen zu lassen und 
damit einen Resetimpuls für den Core und andere Elemente zu generieren.


>
>      sys_rst_qn         | OUT |  sync reset low active, released after
> DCMs are locked, may be used by other modules inside the FPGA

Im Datenblatt deines Virtex4 steht wielange die DCMs nach dem Anstehen 
eines stabilen Taktes brauchen bis Sie locken. Du bekommst den aktuellen 
Zustand allerdings aus der DCM in Form eines LOCKED Signals heraus. Gibt 
zwar ein paar Erratas zu dem Thema, solange dein Eingangstakt statisch 
zur Verfügung steht spielt das keine Rolle, Du kannst das Lockedsignal 
direkt als sys_rst_qn hernehmen...

>
>
>    sys_clk_out        | OUT |  system clock, dcm output, may be used by
> other modules
>                                   inside the FPGA as global clock

Steht eigentlich auch alles im Kommentar. Dies ist der Takt mit dem die 
interne Logic des Cores läuft. Alles was synchron zum FPGA internen 
Datenpfad laufen soll, kann hier drangehängt werden.

>       clk_fb             | IN  |  DCM feedback clock, must be external
> connected to ddr_sdr_clk !

Ja der clk_fb...
Wie schon erwähnt ist der Core der Spartan3 Implementierung näher als 
dem MIG-Virtex Cores.
Problem bei der Implementierung eines DDR-FPGA Cores ist, das das 
Augenmargin zu Erfassung der Daten eigentlich kleiner ist als die 
seitens des FPGA Herstellers spezifizierten IO-Delay Varianzen.
Darum macht man sich einen Trick zu nutze:
Innerhalb einer Bank und eines IO-Standarts differieren die Einzeldelays 
der Pins nur wenig (die sind hauptsächlich Prozess,Spannungs- und 
Temperaturabhängig). Deshalb wird nun neben den eigentlichen 
Nutzsignalen (die zum RAM gehen) ein Referenzsignal erzeugt und an einem 
Eingang wieder ausgewertet).
Neben den vom FPGA abhängigem Delay versucht man nun auch das 
Signaldelay vom FPGA zum Ram und zurück mit in dieses Feedback Signal 
hineinzubekommen, weshalb das FB Signal im Idealfall exakt 2* der 
Leitungslänge der anderen Signale entsprechen sollte...

Ich befürchte allerdings, das das Memec Board keine solche Leitung 
aufweist, da hier ein Virtex4 spezifischer Core vorausgesetzt wird ( 
welcher ohne eine solche Leitung auskommt, da mit der IO-Intellegenz das 
Delay aktiv auf den Datenleitungen ausgemessen wird)...
Du kannst Dir sicherlich mit einem Provesorium behelfen...

Gruß

Andreas