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?
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
Bitte 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.