Hallo Forum, ich bin im Besitz einer Denkblockade und moechte sie gerne loswerden. ;) Ein SDRAM-Baustein und die zugehoerige Controllerlogik werden mit dem gleichen Takt versorgt. Da die Controllerlogik synchron ist, aendert sich der Ausgang bei jeder positiven Taktflanke. Dummerweise wird aber genau hier auch auf dem SDRAM die Eingaenge gesampelt. Also werden hier immer setup/hold-Verletzungen auftreten. Wie wird dieser Konflikt aufgeloest? In den Datenblaettern sieht es so aus, als ob der zustaendige Controller synchron zur negative Taktflanke arbeitet (der Testbench eines Micron-Bausteins arbeitet so). Man koennte auch versucht sein, die Signallaufzeiten zwischen den Bausteinen miteinzuberechnen. Noch eine andere Loesung waere, das eine Clocksignal mit einer 180 Grad Phasenverschiebung zu versehen. Da ich quasi unerfahren bin, weiss ich auch nicht, inwiefern eine moegliche Loesung die Geschwindigkeit der Controllerlogik beeinflusst. Meine einzige Erfahrung besteht bisher in einem asynchronem FIFO, das mit einem Medvedev-Automaten gesteuert wurde. Zur Info: Die Logik wird spaeter auf einem Spartan 2E600 laufen. Vielen Dank -- stefan
Deine 180Grad entsprechen (für den symmetrsichen Clock) einer Taktinversion - soviel vorab. Generell gibt es drei Möglichkeiten, so einen Baustein zu betreiben: a) Mit leichtem oversampling im Rahmen des Jitters, wobei einiges an TRickesn notwengi ist b) Mit etwas mehr, als dem doppelten Takt, was zu einem einfachen Timing führt c) wie bei Dir, mit starr verkoppeltem Takt. Im Fall c musst Du nur bei allen Taktflanken nach beiden Seiten sicherstellen, daß Du nicht in der vorausgegangenen (weil nacheilenden) oder folgenden (weil vorauseilenden) Zyklus reinläufst. Üblicherweise gibts und nimmst Du dazu alleLeitungen im gleichen Takrahmen - alos positiv und invertierst nur den Takt. Aufgrund der Lauf- und Schaltzeiten kann es aber manchmal besser sein, den Takt nur um 90 Grad oder so zu verschieben - das musst Du am individuellen Timing festmachen. Was genau meinst Du mit "Eingänge gesampelt"? Könnte es sein, daß Du mit doppelter Taktrate abtaktest? - also wie bei b) ?
Hallo Jürgen! > a) Mit leichtem oversampling im Rahmen des Jitters, wobei einiges an > TRickesn notwengi ist Das scheidet dann wohl aus. > b) Mit etwas mehr, als dem doppelten Takt, was zu einem einfachen Timing > führt Das hört sich interessant an. Dann bräuchte ich einen Takt von >200 MHz. Das Taktverhältnis kann aber nicht beliebig sein, sonst treten irgendwann wieder Timingprobleme auf. Geht nicht auch 3:2 oder 5:4? Eine Phasenverschiebung braucht der Takt sowieso. Dann stellt sich noch die Frage, ob die vorhandene Controllerlogik da mitmacht. Das bezweifle ich momentan stark. Eventuell kann ich das SDRAM direkt ansteuern. > c) wie bei Dir, mit starr verkoppeltem Takt. > > Im Fall c musst Du nur bei allen Taktflanken nach beiden Seiten > sicherstellen, daß Du nicht in der vorausgegangenen (weil nacheilenden) > oder folgenden (weil vorauseilenden) Zyklus reinläufst. Üblicherweise > gibts und nimmst Du dazu alleLeitungen im gleichen Takrahmen - alos > positiv und invertierst nur den Takt. Aufgrund der Lauf- und > Schaltzeiten kann es aber manchmal besser sein, den Takt nur um 90 Grad > oder so zu verschieben - das musst Du am individuellen Timing > festmachen. Ich habe gestern mit einem ehemaligen Dozenten darüber gesprochen. Der meinte, dass man erst das komplette Design auf den Chip bringt. In irgendeinem Report (wahrscheinlich PAR, hab mir das noch nicht angeschaut) müsste dann eine "Clock-to-Output"-Zeit auftauchen. Ist es das, was du mit "individuellem Timing" beschreibst? Dann bräuchte man noch eine gewisse "Sicherheitszeit", die die Signallaufzeit zum SDRAM-Baustein ausdrückt. > Was genau meinst Du mit "Eingänge gesampelt"? Die Signale an sich sind analog. Wenn man die Setup- und Holdzeiten wegläßt, dann entspricht die steigende Taktflanke einem Samplingvorgang. > Könnte es sein, daß Du mit doppelter Taktrate abtaktest? - also wie bei > b) ? Nein. -- stefan
Mit der DCM kann man z.B. in einem Xilinx phasenverschobene Takte erzeugen. Das geht mit 90°, 180°, 270° aber auch mit einer beliebigen Phase. Damit kann man die Abtastung der Eingänge genau so legen wie man sie braucht. Mit einem Fifo oder mit einer 2. Abtastung bringt man die Daten dann wieder in das originale Taktdomain. Wenn es ausreicht, kann man auch die IDELAY Eigenschaft der Inputblöcke verwenden, bei denen man eine programmierbare Verzögerung der einschaltet. Außerdem kann es günstig sein, den Takt für den SDRAM Baustein im FPGA mit DDR-Outputregisterns zu erzeugen (gibt es die beim Spartan 2?). Damit kann man eine genauer Phasenlage zwischen SDRAM-Takt und den Steuersignalen wie CMD erreichen.
"Da die Controllerlogik synchron ist, aendert sich der Ausgang bei jeder positiven Taktflanke. Dummerweise wird aber genau hier auch auf dem SDRAM die Eingaenge gesampelt. Also werden hier immer setup/hold-Verletzungen auftreten." Nicht notwendigerweise. Da die Daten etwas brauchen, bis sie aus dem FF in Deiner Controllerlogik kommen, der Takt aber direkt kommt, ist der Takt immer etwas schneller und die Daten werden dann erst mit dem nächsten Takt übernommen. Im Prinzip so wie das bei einer synchronen Schaltung immer ist. Dabei muss das Boardlayout das natürlich berücksichtigen. Viel spannender wird das Ganze allerdings beim Lesen aus dem SDRAM, weil dann das Verhältniss von Deinem Takt zu den Daten vom Layout des Boards abhängt. Gruss Axel
DCMs und die DDR-Register sind leider im Spartan3, nicht im Spartan2 enthalten. IDELAY-Primitiven sind erstmals in den Virtex4-Bausteinen drin. Klaus Falser wrote: > Mit einem Fifo oder mit einer 2. Abtastung bringt man die Daten dann > wieder in das originale Taktdomain. Das verstehe ich nicht. Das ist beim Lesen aus dem SDRAM? Da wollte ich den gleichen Takt nehmen, mit dem die Controllerlogik Daten reinschreibt. Es wird so sein, dass ich zuerst das SDRAM vollschreibe, danach öfters (sequenziell, nicht wahlfrei) auslese. Axel wrote: > Nicht notwendigerweise. Da die Daten etwas brauchen, bis sie aus dem FF > in Deiner Controllerlogik kommen, der Takt aber direkt kommt, ist der > Takt immer etwas schneller und die Daten werden dann erst mit dem > nächsten Takt übernommen. Im Prinzip so wie das bei einer synchronen > Schaltung immer ist. Dabei muss das Boardlayout das natürlich > berücksichtigen. Der Takt kommt ebenfalls vom Spartan2. Er müsste also (theoretisch) dieselbe Verzögerung aufweisen wie die Datensignale. > Viel spannender wird das Ganze allerdings beim Lesen aus dem SDRAM, weil > dann das Verhältniss von Deinem Takt zu den Daten vom Layout des Boards > abhängt. Das verstehe ich wahrscheinlich nicht in der Gänze. Die Daten mögen nicht mehr synchron zu dem Originaltakt sein, aber sie sind "ungefähr synchron" zum phasenverschobenen Takt, und der steht ja in direktem Verhältnis zum Originaltakt. -- stefan
@Stefan Hanke >DCMs und die DDR-Register sind leider im Spartan3, nicht im Spartan2 >enthalten. IDELAY-Primitiven sind erstmals in den Virtex4-Bausteinen >drin. Leute, machts doch nicht komplizierter als es ist. Nen popeligen SDRAM mit (100?) MHz auf nem S2 anzusteuern ist ja nun weiss Gott nicht DER Hit. Dazu gibts tonnenweise Application Notes von Xilinx. Im Prinzip braucht man nur 1 oder 2 DLLs um die Takte vom SDRAM und FPGA-Logik in Phase zu bringen. Dann isses ein ganz normales synchrones Design (Logisch mit FlipFlops in dien IOs um das Timing zu optimieren). Nix mit Doppelabtastung, asynchronen FIFOs etc. >Der Takt kommt ebenfalls vom Spartan2. Er müsste also (theoretisch) >dieselbe Verzögerung aufweisen wie die Datensignale. DLL ist das Zauberwort. Wird in diesem Fall zum Deskew (Phasenangleichung) verwendet. >Das verstehe ich wahrscheinlich nicht in der Gänze. Die Daten mögen >nicht mehr synchron zu dem Originaltakt sein, aber sie sind "ungefähr >synchron" zum phasenverschobenen Takt, und der steht ja in direktem >Verhältnis zum Originaltakt. Sie sind synchron zum Takt, der am SDRAM anliegt. Deine Aufgabe ist es, diesen Takt in eine definierte Phasenlage (optimal = 0) zu deinem FPGA-interen Takt zu bringen. MfG Falk
Wieso sollen die Signale "in Phase gebracht" werden? So wie ich das sehe, sind die Takte hart verkoppelt und es geht nur um die Annahme der Daten. Das geschieht mit simplem Eintakten. Man generiert sich eine entsprechend hohe Clock mit einem Vielfachen der Taktfrequenz und verzögert um ein z.B. die fallende Flanke. Beispiel: Bei einem Takt von 200MHz, kann man auf 5ns/2 -> 2,5ns genau verzögert annehmen. Die Delays in den Zellen sind oft ungenau!
Falk wrote: > Leute, machts doch nicht komplizierter als es ist. Nen popeligen SDRAM > mit (100?) MHz auf nem S2 anzusteuern ist ja nun weiss Gott nicht DER > Hit. Dazu gibts tonnenweise Application Notes von Xilinx. Nein, das stimmt nicht. Es gibt zwar ein Haufen pdfs für Speicherschnittstellen, aber kaum was für den Spartan2E. Ich riskiere zu behaupten, dass die alle irgendwelchen spez. Features benutzen. Schon klar, dass das kein technologischer Anspruch mehr ist, die Schnittstelle hat ja auch schon ein paar Jährchen auf dem Buckel. > DLL ist das Zauberwort. Wird in diesem Fall zum Deskew > (Phasenangleichung) verwendet. Könntest du das ein wenig ausführen? Danke. -- stefan PS: Eventuell trägt es zur Zielrichtung der Diskussion bei, wenn Ihr mir sagt, welche Randbedingungen Ihr wissen müsst (Takte, Verschaltungen, etc). Sonst habe ich nichts mehr davon. Ich fange einfach mal an: Der Spartan2E bekommt einen 50MHz Takt. Der Takteingang des SDRAM-Bausteins hängt an einem Pin des Spartan2E. Mein ursprünglicher Gedanke ist, die 50MHz per DLL zu verdoppeln und dann diesen Takt sowohl nach außen zu schicken als auch intern für die Controllerlogik zu verwenden.
Also beim Schreiben geht der Takt direkt an den SDRAM, die Daten kommen aus einem FF, welches mit dem gleichen Takt geschaltet wird. Wenn also der Takt wechselt, übernehmen die FF den neuen Wert und geben ihn aus. Da ist also mindestens die Verzögerung der FF drin. Der Takt geht dagegen direkt nach aussen. Von daher sind die Daten immer später als der Takt. Das kann durch Boardlayout unterstützt werden, indem der Takt die kürzeste Leitung bekommt. Beim Lesen wird im Regelfall der Takt, der an den SDRAM liegt, wieder in den Controller eingelesen, bildet also quasi eine Schleife vom Controllerausgang zum SDRAM und wieder zum Controllereingang. Damit sind die Daten aus dem SDRAM wieder synchron zu dem Takt am Controllereingang, weil das Delay der Daten von SDRAM zum Controllereingang der gleiche ist wie vom SDRAM Takt zum Controllereingang. Dieser Takt (der eine beliebige vom Boardlayout abhängige Verzögerung zum Originaltakt hat) wird dann vom Controller zum Latchen der Daten verwendet und diese dann intern synchronisiert. Ist allerdings ne Weile her, dass ich mich damit beschäftigt habe, vielleicht gibt es heute bessere Lösungen. Gruss Axel
@Chef >Wieso sollen die Signale "in Phase gebracht" werden? So wie ich das >sehe, sind die Takte hart verkoppelt und es geht nur um die Annahme der Sicher, aber die Phase ist duch die Laufzeiten (vor allem im FPGA) erstmal undefiniert. Das muss man korrigieren. >Daten. Das geschieht mit simplem Eintakten. Man generiert sich eine Ach ne? >entsprechend hohe Clock mit einem Vielfachen der Taktfrequenz und Klar, die 800 MHz DDR2 RAM machen sich einfach 1.6 GHz zum Eintakten. >verzögert um ein z.B. die fallende Flanke. Beispiel: Bei einem Takt von >200MHz, kann man auf 5ns/2 -> 2,5ns genau verzögert annehmen. Die Delays >in den Zellen sind oft ungenau! Sie sind wesentlich genauer und kleiner als deine hier propagierten 2,5ns. @Stefan Hanke >> Hit. Dazu gibts tonnenweise Application Notes von Xilinx. >Nein, das stimmt nicht. Es gibt zwar ein Haufen pdfs für >Speicherschnittstellen, aber kaum was für den Spartan2E. Ich riskiere zu Spartan-II ist praktisch Spartan-IIE. Ob nur 2,5 oder 1,8V Kernspannung ist egal. >behaupten, dass die alle irgendwelchen spez. Features benutzen. Ja und? >Schon klar, dass das kein technologischer Anspruch mehr ist, die >Schnittstelle hat ja auch schon ein paar Jährchen auf dem Buckel. Eben. >> DLL ist das Zauberwort. Wird in diesem Fall zum Deskew >> (Phasenangleichung) verwendet. >Könntest du das ein wenig ausführen? Danke. xapp136 xapp174 Huch? Wo sind sie denn? Also vor einigen Jahren (jaja, das Äonen in dieser Branche) gabs noch drei oder vier gute Xapps zum Thema SDRAM. Ich werd heute abend mal zuhause nachschauen, ob ich da noch was habe. Wie es scheint will Xilinx nur noch V4 und V5 pushen und dreht damit den "alten" FPGAs langsam den Support ab. Politik, naja. >PS: Eventuell trägt es zur Zielrichtung der Diskussion bei, wenn Ihr mir >sagt, welche Randbedingungen Ihr wissen müsst (Takte, Verschaltungen, etc). Sonst habe ich nichts mehr davon. Ich fange einfach mal an: >Der Spartan2E bekommt einen 50MHz Takt. Der Takteingang des >SDRAM-Bausteins hängt an einem Pin des Spartan2E. Mein ursprünglicher >Gedanke ist, die 50MHz per DLL zu verdoppeln und dann diesen Takt sowohl >nach außen zu schicken als auch intern für die Controllerlogik zu >verwenden. Soweit, so gut, aber der Teufel steckt im Detail. Eine DLL kann auf 100MHz verdoppeln, du brauchst dann aber ein 2. zm den Takt für den SDRAM in Phase zu schieben. Warte bis morgen, ich denke ich hab da noch ein paar PDFs. MfG Falk
da sind sie doch noch, einfach Google machen lassen: http://www.xilinx.com/bvdocs/appnotes/xapp136.pdf Synthesizable 200 MHz ZBT SRAM Interface http://www.xilinx.com/bvdocs/appnotes/xapp174.pdf Using Delay-Locked Loops in Spartan-II FPGAs
@Christoph Kessler
>da sind sie doch noch, einfach Google machen lassen:
Ja, die sind da. Aber es fehlen einige andere, z.B. gabs mal welche für
100 MHz SDRAM im S2.
MfG
Falk
Hab noch zwei gefunden: http://direct.xilinx.com/bvdocs/appnotes/xapp454.pdf DDR2 SDRAM Memory Interface for Spartan-3 FPGAs http://direct.xilinx.com/bvdocs/appnotes/xapp384.pdf Interfacing to DDR SDRAM with CoolRunner-II CPLDs aber für SpartanII sehe ich noch nichts, das würde mich auch am meisten interessieren, für mein altes Trenz-Board
http://direct.xilinx.com/bvdocs/appnotes/xapp183.pdf Interfacing the QDR SRAM to the Xilinx Spartan-II FPGA (with VHDL Code) http://www.xilinx.com/products/design_resources/mem_corner/resource/xaw_dram_ddr.htm ein Powerpoint-Vortrag zum Interfacing von SDRAM: http://www.xilinx.com/esp/wired/optical/collateral/sdram.pdf Xilinx Solutions for Synchronous DRAMs (SDRAMs) Ja das meiste ist für Virtexm, die alten Familien werden kaum noch erwähnt.
http://epu.ref.nstu.ru/files/downloads/softndocs/Xilinx/D2/xilinx/appnotes/pdf/ falls bei Xilinx nicht mehr vorrätig, hier sind die xapps aufgelistet
@Christoph Kessler >http://epu.ref.nstu.ru/files/downloads/softndocs/X... >falls bei Xilinx nicht mehr vorrätig, hier sind die xapps aufgelistet Fehlt nur noch ein Inhaltsverzeichnis . . . MfG Falk
> Fehlt nur noch ein Inhaltsverzeichnis . . . http://epu.ref.nstu.ru/files/downloads/softndocs/Xilinx/D2/xilinx/appnotes/xapp.htm -- stefan
Vielen Dank für die bisherigen Antworten! Ich muss mir das Ganze jetzt erstmal durch den Kopf gehen lassen. -- stefan
Angehängte Dateien:
-
SDRAM_Deskew_Layout.jpg
38 KB
Falk wrote: > Soweit, so gut, aber der Teufel steckt im Detail. Eine DLL kann auf > 100MHz verdoppeln, du brauchst dann aber ein 2. zm den Takt für den > SDRAM in Phase zu schieben. Genauso wirds in allen Memory-Controllern gemacht, die in den diversen xapp's beschrieben werden. Allerdings glaube ich, dass die Taktrückführungsleitung auf dem Board nicht existent ist ... Problem. Ich bekomme durch die Diskussion den Eindruck, als ob es zwei Herangehensweisen an das Thema gibt. Einerseits kann man versuchen, die beiden Takte gegeneinander 180 Grad phasen zu verschieben. Dadurch bekommt man dann die für Datenblätter typische Waveforms. Andererseits kann man versuchen, die beiden Takte gleichphasig zu bekommen -- dazu braucht man eine DLL, die als "negatives Verzögerungsglied" (Wikipedia) den Takt so verschiebt, dass am Takteingang des SDRAMs genau die gleiche Phase ist wie im FPGA selber. In diesem Fall braucht man die phasenverschobenen Ausgänge der Xilinx DLLs nicht; wie im xapp134. Das Ganze "mutiert" zu einem synchronem Schaltkreis. Der Vorteil der zweiten Lösung besteht IMO in der Allgemeinheit des Ansatzes -- sofern eine Taktrückführungsleitung vorhanden ;-) Die Begründung im xapp134 finde ich allerdings ziemlich schwach. Damit die Phasen exakt gleich sind, müsste am Feedbackeingang von der DLL0 auch exakt der Takt vom SDRAM anliegen. Allerdings muss dazu das Feedback-Taktsignal durch einen IBUFG, dessen Delay einer Phasenverschiebung gleicht. Es ist allerdings nur davon die Rede, das Delay des OBUF auszugleichen. Ich habe die entsprechende Grafik an dieses Posting angehängt, damit ihr nicht im xapp rumsuchen müsst. Auf meiner Todo-Liste für nächste Woche steht ganz oben Timing-Verhältnisse in synchronen Schaltkreisen (da habe ich doch leider größere Defizite, als ich annahm) und DLL-Schaltkreise. Ich weiss zwar, was das Ergebnis ist (sein sollte), aber nicht, wie es erreicht wird. -- stefan
@ Stefan Hanke >Ich bekomme durch die Diskussion den Eindruck, als ob es zwei >Herangehensweisen an das Thema gibt. Einerseits kann man versuchen, die Schnipp schnapp >Ganze "mutiert" zu einem synchronem Schaltkreis. Du hast das Problem richtig erfasst. >Die Begründung im xapp134 finde ich allerdings ziemlich schwach. Damit >die Phasen exakt gleich sind, müsste am Feedbackeingang von der DLL0 >auch exakt der Takt vom SDRAM anliegen. Allerdings muss dazu das >Feedback-Taktsignal durch einen IBUFG, dessen Delay einer >Phasenverschiebung gleicht. Es ist allerdings nur davon die Rede, das >Delay des OBUF auszugleichen. Ich habe die entsprechende Grafik an Jain, der Delay das IbufG ist a) sehr klein und b) identisch mit dem zweiten IbufG, damit sind die Phasen zwischen dem Takt im FPGA und am SDRAM wieder gleich. In deinem Fall, wo das Board keine Taktrückführung hat, kannst du eben mit den vier möglichen Phasenverschiebungen (0/90/180/270 Grad) probieren, welche bei deimen Layout die optimale Phasenlage für den SDRAM erzeugt. Dann musst du aber das Routing für diesen Takt irgendwie eingrenzen bzw. festlegen, damit nicht nacher bei jedem neuen Place&Rout das Timing sich verändert. Ist zwar nicht die schönste und solideste Lösung, aber sollte für einen Laboraufbau gehen. Oder du mchst die Taktrückführung mit ein kurzen Draht, ist auch nicht 100% toll (50 Ohm Impedanz), hat aber auch gute Chancen. >was das Ergebnis ist (sein sollte), aber nicht, wie es erreicht wird. Keine Bange, das bekommst du schon auf die Reihe. Dranbleiben. Du bist auf dem richtigen Weg. MfG Falk
Falk wrote: > Jain, der Delay das IbufG ist a) sehr klein und b) identisch mit dem > zweiten IbufG, damit sind die Phasen zwischen dem Takt im FPGA und am > SDRAM wieder gleich. Dem kann ich nicht folgen. Im folgenden beziehe ich mich auf die relative Lage der Primitiven im Bild. Der obere IBUFG erzeugt eine Phasenverschiebung des gesamten Clock Trees, ist also für die weiteren Betrachtungen vernachlässigbar. Die Instanz DLL0 gleicht die Phasenverschiebung des unteren BUFG aus, DLL1 hingegen gleicht den OBUF und den unteren IBUFG aus. Da aber beide DLLs mit dem selben Takt versorgt werden, muss also der Takt zum SDRAM leicht phasenverschoben sein zum Signal Clk_i. Wenn Delay(OBUF)+Delay(IBUFG)>Delay(BUFG) gilt, dann ist der SDRAM-Takt negativ phasenverschoben. > In deinem Fall, wo das Board keine Taktrückführung hat, kannst du eben > mit den vier möglichen Phasenverschiebungen (0/90/180/270 Grad) > probieren, welche bei deimen Layout die optimale Phasenlage für den > SDRAM erzeugt. Dann musst du aber das Routing für diesen Takt irgendwie > eingrenzen bzw. festlegen, damit nicht nacher bei jedem neuen Place&Rout > das Timing sich verändert. Ist zwar nicht die schönste und solideste > Lösung, aber sollte für einen Laboraufbau gehen. Das geht dann wohl mit den LOC/RLOC-Constraints in der UCF-Datei. Das werde ich dann so legen müssen, dass der SDRAM-Controller möglichst nahe an den Pins liegt, an denen der Baustein angeschlossen ist. > Oder du mchst die Taktrückführung mit ein kurzen Draht, ist auch nicht > 100% toll (50 Ohm Impedanz), hat aber auch gute Chancen. Ja, ich habe schon solche Leitungen auf dem Board gesehen. Eventuell ist das schon die Taktrückführungsleitung. > Keine Bange, das bekommst du schon auf die Reihe. Dranbleiben. Du bist > auf dem richtigen Weg. Vielen Dank! -- stefan
>Das geht dann wohl mit den LOC/RLOC-Constraints in der UCF-Datei. Das >werde ich dann so legen müssen, dass der SDRAM-Controller möglichst nahe >an den Pins liegt, an denen der Baustein angeschlossen ist. Doch, das geht in der UCF-Datei, und zwar indem du den fraglichen Teil zB in einer componente platzierst, instanziierst und für den Namen der Instanz sogenannte RANGE-Constraints vorgibst. Damit platzierst du die Logik und die Verdrahtung der Instanz in dem vorgegebenen Teil des FPGAs. Schau mal im Constraint-Guide nach.
T.M. wrote: > Doch, das geht in der UCF-Datei, und zwar indem du den fraglichen Teil > zB in einer componente platzierst, instanziierst und für den Namen der > Instanz sogenannte RANGE-Constraints vorgibst. Damit platzierst du die > Logik und die Verdrahtung der Instanz in dem vorgegebenen Teil des > FPGAs. Schau mal im Constraint-Guide nach. Danke, Done. Also zuerst eine AREA GROUP aufmachen, in die ich die Instanz lege. Der Area Group kann ich dann per RANGE Platz zuweisen. -- stefan
@Stefan Hanke >> Jain, der Delay das IbufG ist a) sehr klein und b) identisch mit dem >> zweiten IbufG, damit sind die Phasen zwischen dem Takt im FPGA und am >> SDRAM wieder gleich. >Dem kann ich nicht folgen. Im folgenden beziehe ich mich auf die >relative Lage der Primitiven im Bild. Der obere IBUFG erzeugt eine >Phasenverschiebung des gesamten Clock Trees, ist also für die weiteren >Betrachtungen vernachlässigbar. Die Instanz DLL0 gleicht die >Phasenverschiebung des unteren BUFG aus, DLL1 hingegen gleicht den OBUF Hast du die Bezeichungen verwechselt? DLL0 (oben) gleicht die Phase für den SDRAM aus, DLL1 (unten) gleicht die Phase für den FPGA-interen Takt aus. >und den unteren IBUFG aus. Da aber beide DLLs mit dem selben Takt >versorgt werden, muss also der Takt zum SDRAM leicht phasenverschoben >sein zum Signal Clk_i. Wenn Delay(OBUF)+Delay(IBUFG)>Delay(BUFG) gilt, Nein. CLK_i und CLK_SDp sind phasengleich. Der "Trick" besteht darin, dass idealerweise die drei Zweige von CLK_SDp, welche vom Verzeigeungspunkt zu den zwei SDRAMS sowie zurück zum FPGA gehen (CLK_FBp) die gleiche Länge, genauer gesagt, die gleiche Laufzeit haben. >dann ist der SDRAM-Takt negativ phasenverschoben. >Das geht dann wohl mit den LOC/RLOC-Constraints in der UCF-Datei. Das Jain. Mit LOC/RLOC lassen sich nur Komponenten plazieren. Routing ist nur sehr schwierig definierbar. Wenn die Komponenten allerdings festliegen, ändert sich das Routing nur noch minimal. >werde ich dann so legen müssen, dass der SDRAM-Controller möglichst nahe >an den Pins liegt, an denen der Baustein angeschlossen ist. Das ist nicht nötig, durch die DLL und alles andere kannst den Controller nahezu überall plazieren. Der Knackpunkt ist nur der Taktausgang für die SDRAMs. Wenn allerdings eine Taktrückführung auf deinem Board existiert, dann ist auch das egal, die DLL regelt das aus. >Ja, ich habe schon solche Leitungen auf dem Board gesehen. Eventuell ist >das schon die Taktrückführungsleitung. Das wäre gut. MfG Falk
Falk wrote: > Hast du die Bezeichungen verwechselt? DLL0 (oben) gleicht die Phase für > den SDRAM aus, DLL1 (unten) gleicht die Phase für den FPGA-interen Takt > aus. Ja, stimmt. > Nein. CLK_i und CLK_SDp sind phasengleich. Der "Trick" besteht darin, > dass idealerweise die drei Zweige von CLK_SDp, welche vom > Verzeigeungspunkt zu den zwei SDRAMS sowie zurück zum FPGA gehen > (CLK_FBp) die gleiche Länge, genauer gesagt, die gleiche Laufzeit haben. Ja, stimmt, die Zweite. Genau weil sie den gleichen Takteingang haben, werden die Takte phasengleich sein. Aber nicht ganz, nach meinem Verständnis müsste dann CLK_SDp leicht vorlaufen. Durch die Laufzeit zum SDRAM-Baustein wird diese kleine Phasenverschiebung aufgehoben. Am Takteingang des Bausteins liegt dann der gleichphasige Takt an. >>Ja, ich habe schon solche Leitungen auf dem Board gesehen. Eventuell ist >>das schon die Taktrückführungsleitung. > Das wäre gut. OK, dann werde ich mal dafür sorgen, dass so eine Leitung, falls nicht vorhanden, eingelötet wird. -- stefan
@Stefan Hanke >> (CLK_FBp) die gleiche Länge, genauer gesagt, die gleiche Laufzeit haben. >Ja, stimmt, die Zweite. Genau weil sie den gleichen Takteingang haben, >werden die Takte phasengleich sein. Aber nicht ganz, nach meinem Doch, die Phasen sind prinzipiell absolut gleich (jaja, real gibts da immer kleine Toleranzen). >Verständnis müsste dann CLK_SDp leicht vorlaufen. Durch die Laufzeit zum >SDRAM-Baustein wird diese kleine Phasenverschiebung aufgehoben. Am Nein. Die Laufzeiten weren durch die DLLs ausgeglichen, aktiv. D.H. wenn sich die Laufzeiten durch Spannung, Temperatur oder Fertigungstoleranzen ändern, werden sie durch die DLLs kompensiert. MfG Falk
Falk wrote: > Doch, die Phasen sind prinzipiell absolut gleich (jaja, real gibts da > immer kleine Toleranzen). OK, klar. > Nein. Die Laufzeiten weren durch die DLLs ausgeglichen, aktiv. D.H. wenn > sich die Laufzeiten durch Spannung, Temperatur oder Fertigungstoleranzen > ändern, werden sie durch die DLLs kompensiert. ACK. Nochmal vielen Dank für deine Kommentare! :) -- stefan
>> Oder du mchst die Taktrückführung mit ein kurzen Draht, ist auch nicht >> 100% toll (50 Ohm Impedanz), hat aber auch gute Chancen. >Ja, ich habe schon solche Leitungen auf dem Board gesehen. Eventuell ist >das schon die Taktrückführungsleitung. Wonach richtet sich die Länge des "Drahtes" eigentlich? Solang, wie die Länge vom PGA Pin zum Clk Pin des SRAM? Nur eine Stecke, oder Hin- und Rücklauf-Länge? Grüße Olaf
@ ope >>> Oder du mchst die Taktrückführung mit ein kurzen Draht, ist auch nicht >>> 100% toll (50 Ohm Impedanz), hat aber auch gute Chancen. >>Ja, ich habe schon solche Leitungen auf dem Board gesehen. Eventuell ist >>das schon die Taktrückführungsleitung. >Wonach richtet sich die Länge des "Drahtes" eigentlich? Solang, wie die >Länge vom PGA Pin zum Clk Pin des SRAM? Nur eine Stecke, oder Hin- und >Rücklauf-Länge? Steht im der Application Note. Der Takt für den SDRAM kommt aus dem FPGA und verzweigt dann zum SDRAM und FPGA (Rückführung). Diese beiden Abzweige sollten idealerweise die gleiche Laufzeit haben. Die Länge vom FPGA zum Verzweigungspunkt ist prinzipiell egal und kann beliebig lang sein. MFG Falk
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.