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
@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
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
