mikrocontroller.net

Forum: FPGA, VHDL & Co. SDRAM again - synchrone Logik


Autor: StefanHanke (Gast)
Datum:

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

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

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

Autor: Stefan Hanke (stefanhanke)
Datum:

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

Autor: Klaus Falser (kfalser)
Datum:

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

Autor: Axel (Gast)
Datum:

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

Autor: Stefan Hanke (stefanhanke)
Datum:

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

Autor: Falk (Gast)
Datum:

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

Autor: Chef (Gast)
Datum:

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

Autor: Stefan Hanke (stefanhanke)
Datum:

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

Autor: Axel (Gast)
Datum:

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

Autor: Falk (Gast)
Datum:

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

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

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

Autor: Falk (Gast)
Datum:

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

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

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

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

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

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.

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://epu.ref.nstu.ru/files/downloads/softndocs/X...
falls bei Xilinx nicht mehr vorrätig, hier sind die xapps aufgelistet

Autor: Falk (Gast)
Datum:

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

Autor: Stefan Hanke (stefanhanke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Fehlt nur noch ein Inhaltsverzeichnis . . .
http://epu.ref.nstu.ru/files/downloads/softndocs/X...

 -- stefan

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, Asche auf mein Haupt.

Also xapp 134 ist dein Freund.

MfG
Falk

Autor: Stefan Hanke (stefanhanke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die bisherigen Antworten!
Ich muss mir das Ganze jetzt erstmal durch den Kopf gehen lassen.
 -- stefan

Autor: Stefan Hanke (stefanhanke)
Datum:
Angehängte Dateien:

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

Autor: Falk (Gast)
Datum:

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

Autor: Stefan Hanke (stefanhanke)
Datum:

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

Autor: T.M. (Gast)
Datum:

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

Autor: Stefan Hanke (stefanhanke)
Datum:

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

Autor: Falk (Gast)
Datum:

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

Autor: Stefan Hanke (stefanhanke)
Datum:

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

Autor: Falk (Gast)
Datum:

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

Autor: Stefan Hanke (stefanhanke)
Datum:

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

Autor: ope (Gast)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

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.