www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Welcher externe RAM-Baustein für FPGA (Spartan-3E)?


Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich möchte an einen FPGA (Xilinx Spartan-3E) einen externen RAM-Baustein 
anschliessen.

Konkret geht es darum: Ich lese von AD-Wandlern mit dem FPGA Datenworte 
ein und möchte die im externen RAM ablegen. (Ich schreibe also stets an 
aufeinander folgende Adressen)

Dieser Schreibvorgang soll möglichst schnell sein, und ich brauche 
mindestens 8 Mbit -- mehr ist natürlich immer gut. Das Auslesen erfolgt 
deutlich langsamer.

Dynamischen RAM erscheint mir als zu kompliziert -- es soll ja selbst 
auf dem Spartan-3E Starterkit Probleme machen.

Bleibt also im wesentlichen statischen RAM. Synchrones statischen RAM 
scheint teuer und schwer beschaffbar zu sein. Mehr verbreitet ist wohl 
asynchrones statischen RAM -- das wird auch auf dem alten Spartan-3 
Starterkit eingesetzt.

Ist also asynchrones statischen RAM (z.B. CY7C1061AV33) die optimale 
Wahl?

Welche Schreibrate kann ich damit erreichen?

Gruß

Stefan Salewski

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan Salewski (Gast)

>Dieser Schreibvorgang soll möglichst schnell sein, und ich brauche

ZAHLEN!!! Möglichst schnell kann heute auch heissten 10 Gbyte/s.

>mindestens 8 Mbit -- mehr ist natürlich immer gut. Das Auslesen erfolgt
>deutlich langsamer.

>Dynamischen RAM erscheint mir als zu kompliziert -- es soll ja selbst
>auf dem Spartan-3E Starterkit Probleme machen.

Glaub ich nicht.

>Ist also asynchrones statischen RAM (z.B. CY7C1061AV33) die optimale
>Wahl?

Es ist eine brauchbare Lösung.

>Welche Schreibrate kann ich damit erreichen?

Kommt auf den RAM drauf an. Viele haben 70ns Zugriffszeit, macht ca. 14 
MHz. Die schnellen mit 15ns und weniger sind meist ziemlich klein.

MFG
Falk

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Datenrate kein Thema ist (70ns Zugriffszeit): PSRAM.
Wenns etwas schneller sein soll (10ns): SRAM, bei 8MBit gerade noch 
zahlbar
Wenns billiger sein soll: SDRAM
Wenns möglichst schnell sein soll: DDR2, bei sequentiellem Zugriffen 
sollten die Latenzen kein Probleme darstellen. Aber braucht halt mehr 
Logik für den Controller.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
628512-70 M bei Reichelt für 3,50

Zwei Stück davon ergeben 8 Mbit.
Für ein Hobbyprojekt wohl bezahlbar.

MFg
Falk

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Falk,

>ZAHLEN!!! Möglichst schnell kann heute auch heissten 10 Gbyte/s.

Mein AD-Wandler schafft bis 100 MS/s (Mega-Samples pro Sekunde).
Deshalb wäre es optimal, wenn ich auch mit 100 MHz Werte ins RAM 
schreiben könnte. (Ich kann aber auch mit weniger leben.)

>Glaub ich nicht.

Es gab jedenfalls eine Reihe von Berichten, dass der dynamische RAM auf 
dem Spartan-3E Starterkit nicht richtig funktioniert hat -- auch hier im 
Forum.

Die vom mir ins Auge gefassten RAM-Bausteine wie CY7C1061AV33 (1M x 16 
Static RAM) haben 10 ns Zugriffszeit (tAA=10ns). Aber: Nach 
Tietze/Schenk ist diese Zeitangabe eher auf den Leseprozess bezogen, und 
selbst wenn man nach den Timingdiagrammen (bei entsprechenden 
Signalverzögerungen) theoretisch mit bis zu 100 MHz Schreiben kann, 
heißt das noch nicht, dass man es mit dem Spartan-3E hinbekommen kann. 
(Ich habe da gestern Abend etwas mit Google gesucht -- die Meinungen 
bzw. Empfehlungen gehen da weit auseinander. Dass ich mindestens mit 
einigen 10 MHz schreiben kann ist mir schon klar.)

Gruß

Stefan Salewski

Autor: nixcheck (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau dir das mal an http://www.sump.org/projects/analyzer/
gibt ja auch ne Spartan E Portierung.  Wenn du 2 Speicherchips 
verwendest kannst du die Datenrate verdoppeln. Geeigneten 10nsec 
Speicher gibt es auch von Samsung z.B. bei Schukat (günstiger).

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Stefan Salewski (Gast)

>Mein AD-Wandler schafft bis 100 MS/s (Mega-Samples pro Sekunde).

Du fängst ja klein an . . .

>Deshalb wäre es optimal, wenn ich auch mit 100 MHz Werte ins RAM

AHHHH! Was ist dass denn? "100 MHz Werte"?

>schreiben könnte. (Ich kann aber auch mit weniger leben.)

Wieviel?

>Die vom mir ins Auge gefassten RAM-Bausteine wie CY7C1061AV33 (1M x 16
>Static RAM) haben 10 ns Zugriffszeit (tAA=10ns). Aber: Nach
>Tietze/Schenk ist diese Zeitangabe eher auf den Leseprozess bezogen, und
>selbst wenn man nach den Timingdiagrammen (bei entsprechenden
>Signalverzögerungen) theoretisch mit bis zu 100 MHz Schreiben kann,
>heißt das noch nicht, dass man es mit dem Spartan-3E hinbekommen kann.

Mach dir um den Spartan mal keine Sorgen, DER kann das. Die Frage ist, 
ob DU das hinbekommst mit dem VHDL und der elektrischen Anbindung.

>bzw. Empfehlungen gehen da weit auseinander. Dass ich mindestens mit
>einigen 10 MHz schreiben kann ist mir schon klar.)

Dein SRAM oben schafft ca. 200 Mbyte/s. Damit sollte man die 100 Msps 
speichern können (wenn pro Sample nur 8 Bit verwendet werden.)

Nimm den RAM, der ist OK. Schliess ihn ordentlich an. Und teste erstmal 
mit 20 MHz. Dann kannst du sich an 100 Msps ranwagen.

MfG
Falk

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Wandler wird doch sicher nicht mehr als 8 Bit pro Sample machen? 
Wenn dein Speicher mit 32 bit angebunden ist könntest du dann 4 Samples 
gleichzeitig schreiben, die Zugriffsrate reduziert sich also schon mal 
auf 25 MHz.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Schau dir das mal an http://www.sump.org/projects/analyzer/

Ja, dieses tolle Projekt von Michael Poppitz ist mir schon bekannt, bloß 
bin ich noch nicht dazu gekommen es mir näher anzusehen.

Ich hatte Michaels Aussagen auch so verstanden, dass er in das 10ns-RAM 
des Spartan-3 Starterkits mit bis zu 100 MHz Werte einschreiben kann.

Allerdings ist er scheinbar der einzige, der das fertig bringt. Das 
hatte mich dann doch etwas zweifeln lassen... Aber gut, ich werde mir 
seinen VHDL-Code demnächst ansehen.

>Geeigneten 10nsec
>Speicher gibt es auch von Samsung z.B. bei Schukat (günstiger).

Danke für den Tipp

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andreas,

>Der Wandler wird doch sicher nicht mehr als 8 Bit pro Sample machen?
>Wenn dein Speicher mit 32 bit angebunden ist könntest du dann 4 Samples
>gleichzeitig schreiben, die Zugriffsrate reduziert sich also schon mal
>auf 25 MHz.

Ja, an so etwas hatte ich auch schon gedacht. Dieser preiswerte 
70ns-Speicher ist dann leider aber noch immer zu langsam. Aber danke für 
den Tipp.

Gruß

Stefan Salewski

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei asynchronen Rams schafft mans nicht wirklich mit 1/Zugriffszeit = 
Datenrate zu schreiben, denn man braucht noch eine State Machine die 
garantiert, dass zuerst Daten und Adressen angelegt werden und 
anschließend Write/Read Enable. Und letztere natürlich auch wieder 
zuerst zurückgenommen werden. Ansonsten gibts hässliche Speicherfehler. 
Ich sage mal mit nem asynchronen 10ns Ram und einem einfachen VHDL 
Design bekommt man 50MHz hin. Mit hässlicheren Sachen (leicht 
phasenverschobene Takte) werden auch 80MHz möglich sein, würde ich aber 
einem Anfänger nicht umbedingt empfehlen.
Wenn man aber wie Andreas oder Falk vorgeschlagen haben die Breite des 
Rams ausnutzt, ist die Frequenz sowieso nicht mehr das Problem.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wenn man aber wie Andreas oder Falk vorgeschlagen haben die Breite des
>Rams ausnutzt, ist die Frequenz sowieso nicht mehr das Problem.

Naja. Richtig viele IO-Pins hat man nur bei BGA-Gehäusen, das wollte ich 
zunächst nicht verwenden. Ich will zunächst das PQ208 Gehäuse verwenden, 
da hat man maximal ca. 150 IO-Pins. Davon sind aber einige nur 
eingeschränkt nutzbar. Wenn ich den gleichen Adressbus für mehrer 
RAM-Bausteine verwende (ein FPGA-Pin auf mehrere Address-Eingänge der 
RAMs) muss ich etwas auf die Signalqualität achten und das Layout wird 
aufwendiger. Evtl. will man ja auch mehrer Kanäle/ADCs haben, dann wird 
es schon etwas eng.

>Bei asynchronen Rams schafft mans nicht wirklich mit 1/Zugriffszeit =
>Datenrate zu schreiben, denn man braucht noch eine State Machine die
>garantiert, dass zuerst Daten und Adressen angelegt werden und
>anschließend Write/Read Enable. Und letztere natürlich auch wieder
>zuerst zurückgenommen werden. Ansonsten gibts hässliche Speicherfehler.
>Ich sage mal mit nem asynchronen 10ns Ram und einem einfachen VHDL
>Design bekommt man 50MHz hin. Mit hässlicheren Sachen (leicht
>phasenverschobene Takte) werden auch 80MHz möglich sein, würde ich aber
>einem Anfänger nicht umbedingt empfehlen.

Ja, ähnliche Aussagen habe ich gestern auch mit Google gefunden.
Wenn man es ganz sauber macht braucht man wohl eine State-Maschine.
Ich könnte ja mit 100 MHz externem Takt arbeiten und den Takt im FPGA 
verdoppeln...
Und/Oder aber man könnte für die verschiedenen Signale Delays 
generieren, der Spartan-3E hat mit DCM usw. ja einiges zur Verfügung.

Das das alles nicht einfach ist ist mit klar -- anfangs genügt mir auch 
25 MHz Schreibrate.

Weiß jemand wie Michael Poppitz das bei seinem Logik-Analyzer macht?

Von Xilinx gibt es kein Beispiel für SRAM?

Oder wird es mit synchronem SRAM einfacher 100 MHz zu erreichen?

Gruß

Stefan Salewski

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan Salewski (Gast)

>aufwendiger. Evtl. will man ja auch mehrer Kanäle/ADCs haben, dann wird
>es schon etwas eng.

Was ja auch sehr sinnvollist für einen Anfänger . . .

>Ich könnte ja mit 100 MHz externem Takt arbeiten und den Takt im FPGA
>verdoppeln...

Dito.

>Und/Oder aber man könnte für die verschiedenen Signale Delays
>generieren, der Spartan-3E hat mit DCM usw. ja einiges zur Verfügung.

Dito.

>Von Xilinx gibt es kein Beispiel für SRAM?

Weil das so trivial ist, dass sich das nicht lohnt.

Adresse, CS und RD anlegen -> Resezugriff
Adresse, Daten und CS, anlegen, kurzen WR Pulse -> Schreibzugriff

Steht alles nochmal im Datenblatt.

>Oder wird es mit synchronem SRAM einfacher 100 MHz zu erreichen?

Wozu? Mit deinem 16 Bit Datenbus kannst du locker die 100 Mbyte/s mit 50 
MHz reinschreiben. Mach das erstmal, dann reden wir weiter.

MFG
Falk

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wozu? Mit deinem 16 Bit Datenbus kannst du locker die 100 Mbyte/s mit 50
>MHz reinschreiben.

Aha. Ich meinte mich an Aussagen zu errinnern (comp.arch.embedded?), 
dass auf die lockere Art nur ein Schreibzugriff auf 4 Taktzyklen möglich 
ist. (State Maschine mit 4 States.)

>Mach das erstmal, dann reden wir weiter.
Etwas vorraus denken/planen schadet selten!

Autor: nixcheck (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weiß jemand wie Michael Poppitz das bei seinem Logik-Analyzer macht?
Als open source - also kannst du selber in den VHDL Dateien suchen.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>also kannst du selber in den VHDL Dateien suchen.

Ist mir schon klar -- werde ich auch machen.

Autor: nixcheck (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal ernst du hast ja erstmal reinen Schreibzugriff. Das ist vom timming 
sichere sehr viel anspruchsloser als der sonst üblich 
Schreib/Lesezugriff.

Autor: Breti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Bei asynchronen Rams schafft mans nicht wirklich mit 1/Zugriffszeit =
>Datenrate zu schreiben, denn man braucht noch eine State Machine die
>garantiert, dass zuerst Daten und Adressen angelegt werden und
>anschließend Write/Read Enable. Und letztere natürlich auch wieder
>zuerst zurückgenommen werden. Ansonsten gibts hässliche Speicherfehler.

Genau das ist mir gerade vor ein paar Tagen mit dem Spartan3 Starterkit 
auch passiert. Ich habe mir eine Grafikkarte in VHDL geschrieben und 
versucht möglichst schnell in das SRAM zu schreiben. Dabei gab es häufig 
Schreibfehler in das Ram. Am Ende habe ich dann den Schreibvorgang, wie 
schon von Michael vorgeschlagen, in mehrere Zyklen aufgeteilt (/WE 
getrennt von Daten/Addr setzen). Seitdem funktioniert es.

Es wunderte mich aber trotzdem, da ich das Datenblatt so verstanden 
habe, dass man Daten, Addr und WE gleichzeitig anlegen kann.

Gruß,
Thomas

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan Salewski (Gast)

>dass auf die lockere Art nur ein Schreibzugriff auf 4 Taktzyklen möglich
>ist. (State Maschine mit 4 States.)

Dann hast du das irgendwie falsch verstanden bzw. es war in einem 
anderen Zusammenhang gemeint. Ausserdem kann man da schon in 4 States 
aufteilen, wenn die dann mit 100 MHz laufen und steigende sowie fallende 
Flanke nutzen gehts wieder.

>>Mach das erstmal, dann reden wir weiter.
>Etwas vorraus denken/planen schadet selten!

Sicher, aber als Beckenrandschwimmer über den Iron Man zu philosophieren 
ist albern.

MfG
Falk

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Breti (Gast)

>Es wunderte mich aber trotzdem, da ich das Datenblatt so verstanden
>habe, dass man Daten, Addr und WE gleichzeitig anlegen kann.

Anlegen schon, aber WE muss wieder weggenommen werden, bevor auf die 
nächste Adresse umgeschaltet wird. 4 Zyklen.

ADDRESSEN und CS anlegen
WE auf low
WE auf HIGH
warten

Die Adressen generiert man einfach mit jeder 2. steigenden Flanke bei 
100 MHz. WE generiert man mit fallender und steigender Flanke der 100 
MHz. Muss man ein wenig aufpassen, geht aber.

MfG
Falk

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Es wunderte mich aber trotzdem, da ich das Datenblatt so verstanden
>habe, dass man Daten, Addr und WE gleichzeitig anlegen kann.

Es ist auch so, allerdings müssen die exakt gleichzeitig kommen, bzw. WE 
leicht verzögert gegenüber dem Rest. Das Problem ist nicht der Speicher, 
sondern das FPGA, da wenn du alle Zuweisungen auf eine Flanke machst die 
nicht umbedingt wirklich gleichzeitig kommen. Die Relation der Signale 
untereinander ist nicht garantiert, nur dass sie alle in einem 
bestimmten Zeitraum vor/bzw. nach der Taktflanke wechseln.

Autor: Breti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Es ist auch so, allerdings müssen die exakt gleichzeitig kommen, bzw. WE
>leicht verzögert gegenüber dem Rest. Das Problem ist nicht der Speicher,
>sondern das FPGA, da wenn du alle Zuweisungen auf eine Flanke machst die
>nicht umbedingt wirklich gleichzeitig kommen. Die Relation der Signale
>untereinander ist nicht garantiert, nur dass sie alle in einem
>bestimmten Zeitraum vor/bzw. nach der Taktflanke wechseln.

Daran hatte ich auch gedacht. Ich hatte mir überlegt, dass wenn z.B. bei 
der Adressgenerierung eine andere tiefe des Logiklevels vorhanden ist 
als z.B. beim /WE, es beim FPGA evt. zu leichten Verschiebungen an den 
Ausgangspins kommen könnte.
Ich hatte dann versucht alle Ram Signale bei Erzeugung internen Signalen 
zuzuweisen und dann in einem weiteren Prozess diese Signale an die 
Ausgangspins zu senden (so dass die Signale also einen Takt versetzt 
anliegen). Leider hat das aber auch nicht geholfen. Vielleicht reicht da 
ja sogar schon der Unterschied beim Routing der Signale im FPGA.

>Anlegen schon, aber WE muss wieder weggenommen werden, bevor auf die
>nächste Adresse umgeschaltet wird. 4 Zyklen.
Würden dann nicht 2 Zyklen reichen?
Also z.B.
Zyklus 1:
Addr, Data anlegen
/WE = auf low
Zyklus 2:
/WE = wieder auf high

>Die Adressen generiert man einfach mit jeder 2. steigenden Flanke bei
>100 MHz. WE generiert man mit fallender und steigender Flanke der 100
>MHz. Muss man ein wenig aufpassen, geht aber.
Das klappt aber nur solange die /WE Logik nicht von irgendwas abhängt, 
was wiederrum mit der steigenden Flanke verknüpft ist. Ich hatte da mal 
ein Problem deswegen mit ISE, welches dann (korrekter Weise) den maximal 
Zulässigen Takt halbiert hat.

Gruß,
Thomas

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich hatte dann versucht alle Ram Signale bei Erzeugung internen Signalen
> zuzuweisen und dann in einem weiteren Prozess diese Signale an die
> Ausgangspins zu senden (so dass die Signale also einen Takt versetzt
> anliegen). Leider hat das aber auch nicht geholfen. Vielleicht reicht da
> ja sogar schon der Unterschied beim Routing der Signale im FPGA.

Um das korrekte Verhältnis von Ein- und Ausgangssignalen an den Pins zu 
garantieren, greift man zu Timing Constraints an den Ports. Dann kann 
man sich auch drauf verlassen, dass /WE und Adressen gleichzeitig 
anliegen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Matthias (Gast)

>nicht umbedingt wirklich gleichzeitig kommen. Die Relation der Signale
>untereinander ist nicht garantiert, nur dass sie alle in einem
>bestimmten Zeitraum vor/bzw. nach der Taktflanke wechseln.

Nanana, sooo ist das auch nicht. Das FPGA kann schon SEHR gleichzeitig 
Signale generieren, ein Skew von weniger als 500ps ist da problemlos 
machbar.

MFG
Falk

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Breti (Gast)

>Daran hatte ich auch gedacht. Ich hatte mir überlegt, dass wenn z.B. bei
>der Adressgenerierung eine andere tiefe des Logiklevels vorhanden ist
>als z.B. beim /WE, es beim FPGA evt. zu leichten Verschiebungen an den
>Ausgangspins kommen könnte.

Sowas macht man bei solchen Freqeunzen nicht (mehr). Da müssen ALLE 
Signale sinnvollerweise aus Registern gespeist werden, um einen maximal 
Freqeunz und timingreserven zu erreichen.

>anliegen). Leider hat das aber auch nicht geholfen. Vielleicht reicht da
>ja sogar schon der Unterschied beim Routing der Signale im FPGA.

Darauf sollte man auf KEINEN Fall bauen!

>Würden dann nicht 2 Zyklen reichen?
>Also z.B.
>Zyklus 1:
>Addr, Data anlegen
>/WE = auf low
>Zyklus 2:
>/WE = wieder auf high

Naja, wenn aber WE ein wenig schneller ist, dann schreibst du vielleicht 
noch was in die alte Adresse rein, die im 1. Zyklus mit wechselt.

>ein Problem deswegen mit ISE, welches dann (korrekter Weise) den maximal
>Zulässigen Takt halbiert hat.

Das ist normal, weil ja ein Signal von der Stiegenden zu fallenden 
Flanke gültig werden muss. Sinnvollerweise packt man dort keine Logik 
rein, sondern nur FlipFlop an FlipFlop.

@ T.M. (Gast)

>Um das korrekte Verhältnis von Ein- und Ausgangssignalen an den Pins zu
>garantieren, greift man zu Timing Constraints an den Ports. Dann kann
>man sich auch drauf verlassen, dass /WE und Adressen gleichzeitig
>anliegen.

Nööö, man muss schon bissel nachdenken und das richtige tun. Eben halt 
die Signale DIREKT aus FlipFlops speisen und diese in den IO-Zellen 
platzieren.

MFG
Falk

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nööö, man muss schon bissel nachdenken und das richtige tun. Eben halt
> die Signale DIREKT aus FlipFlops speisen ...

Dass die Signale aus FF kommen müssen ist klar, das ist ja durch ein 
(hoffentlich) synchrones Design auch gegeben.

> und diese in den IO-Zellen  platzieren ...

Schön und gut, wenn man das Tool dazu zwingen kann. Bei Xilinx mag das 
gehen, bei Actel zB. nicht. Da steht bei "Mapping Register in IO-Cell" 
der kleine Nebensatz "when possible". Und dann kann man sich nicht drauf 
verlassen und kann das Ganze durch In/Output Delays noch absichern. 
Diese lassen sich sowieso nur auf einen Takt beziehen, sodass man auch 
nur Signale, die aus FFs kommen, damit belegen sollte. Damit bin ich 
zumindestens immer gut gefahren.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ T.M. (Gast)

>Dass die Signale aus FF kommen müssen ist klar, das ist ja durch ein
>(hoffentlich) synchrones Design auch gegeben.

Nicht zwangsläufig. Man kann auch Ausgangssignale nochmal über 
Kombinatorik erzeugen (Melee/Moore-Automat), dann ist es Essig mit dem 
Timing.

MFG
Falk

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, aber dann sollte man sie vor dem Pad einsynchronisieren, wie man das 
am Eingang ja auch macht. Aber ich sehe, wir verstehen uns soweit ;-)

Autor: Breti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Eben halt die Signale DIREKT aus FlipFlops speisen und diese in den
>IO-Zellen platzieren.

Also wenn ich einen zweiten Prozess habe, der mit steigender Flanke die 
Register in die IOs schiebt, dann habe ich ja genau die Flip Flops, die 
alles gelichzeitig "freischalten" sollen. Dies war mein Ansatz, um das 
Problem zu lösen.

Das sah dann bei mir ungefähr so aus:
process (clk)
begin
  if rising_edge(clk) then
    addr_pin <= addr_signal;
    data_pin <= data_signal;
    nwe_pin  <= nwe_signal;
  end if;
end process;

Allerdings weiß ich jetzt nicht, wie ich ISE beibringen kann die Flip 
Flops in die IOs zu verlagern. Kann mir da mal jemand einen Tipp geben, 
wie das geht?

Gruß,
Thomas

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Breti (Gast)

>Allerdings weiß ich jetzt nicht, wie ich ISE beibringen kann die Flip
>Flops in die IOs zu verlagern. Kann mir da mal jemand einen Tipp geben,
>wie das geht?

Dafür gibt es eine Option in den Mappereinstellungen.

MFG
Falk

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
>Stefan Salewski schrieb:
>>Deshalb wäre es optimal, wenn ich auch mit 100 MHz Werte ins RAM
>AHHHH! Was ist dass denn? "100 MHz Werte"?

War das wirklich so unverständlich formuliert?
Ich möchte eben alle 10ns eine Schreiboperation durchführen -- wie 
vielen Megabytes pro Sekunde das letztendlich entspricht hängt natürlich 
von der breite der Datenworte ab. (Alternierend in verschiedene 
RAM-Module möchte ich nicht so gerne schreiben, weil ich nicht mehr 
beliebig viele Pins am FPGA zur Verfügung habe.)

Ich werde übrigens wahrscheinlich doch ein synchrones SRAM verwenden, 
wahrscheinlich CY7C1380D. Damit sollte nach meinem momentanen 
Verständnis alle 10ns eine Schreiboperation möglich sein (Bei fallender 
Takt-Flanke Adresse und Datenwort anlegen, bei steigender Flanke wird 
beides vom RAM-Chip übernommen.)

Naja, wir werden sehen.

Gruß

Der Beckenrandschwimmer

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan Salewski (Gast)

>>AHHHH! Was ist dass denn? "100 MHz Werte"?

>War das wirklich so unverständlich formuliert?

Es ist eine grausam schlechte Formulierung.

>Ich werde übrigens wahrscheinlich doch ein synchrones SRAM verwenden,
>wahrscheinlich CY7C1380D. Damit sollte nach meinem momentanen
>Verständnis alle 10ns eine Schreiboperation möglich sein (Bei fallender
>Takt-Flanke Adresse und Datenwort anlegen, bei steigender Flanke wird
>beides vom RAM-Chip übernommen.)

AUA! Du solltest dich mal über das Timing synchroner Systeme 
informieren.

http://www.mikrocontroller.net/articles/SDRAM-Timi...

Alles passiert auf ein und der selben Taktflanke!

MFG
Falk

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>AUA! Du solltest dich mal über das Timing synchroner Systeme
>informieren.

>Alles passiert auf ein und der selben Taktflanke!

Na ich habe mir die Timingdiagramme im Datenblatt angesehen, da sieht es 
so aus als ob bei beiden Flanken etwas geschieht.

http://download.cypress.com.edgesuite.net/design_r...

Aber ich werde Deinen Rat befolgen und nochmal nachlesen.

Gruß

Stefan Salewski

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan Salewski (Gast)

>Na ich habe mir die Timingdiagramme im Datenblatt angesehen, da sieht es
>so aus als ob bei beiden Flanken etwas geschieht.

Welche? Auf welcher Seite? Seite 13, "TAP Timing" ? Das ist der JTAG 
Port, dort wird das gemacht (steigende/fallende Flanke). Manchmal ist 
das OK und vermeidet Probleme. Aber einem 250 MHz SSRAM steuert man so 
nicht an. Da hast du dir aber einen Boliden rausgesucht. Hoffentlich ist 
der nicht zu giftig, mach eine solide Platine mit kurzen Leitungen. GGf. 
sollte man über den Wellenwiderstand und Terminierung nachdenken, 
wenigstens für den Takt.

MFG
Falk

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Welche? Auf welcher Seite? Seite 13, "TAP Timing" ?

Ich hatte die Seiten 21, 22 und 23 in Auge.

>mach eine solide Platine mit kurzen Leitungen

Klar. Vierlagige Platine, und den RAM-Chip so dicht wie möglich an den 
FPGA. Eventuell beidseitige Bestückung -- FPGA und RAM also Rücken an 
Rücken.

>Boliden rausgesucht. Hoffentlich ist der nicht zu giftig,

Der CY7C1380D ist einer der wenigen synchronen SRAMs dieser 
Größenordnung, den man bei Digi-Key in kleinen Stückzahlen kaufen kann. 
Samples sind für mich nur eine Notlösung.

Und die 100 MHz sind das Ziel, das ich anstrebe -- anfangen werde ich 
mit wenigen Megahertz.

Gruß

Stefan Salewski

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan Salewski (Gast)

>Klar. Vierlagige Platine, und den RAM-Chip so dicht wie möglich an den
>FPGA. Eventuell beidseitige Bestückung -- FPGA und RAM also Rücken an
>Rücken.

Naja, soooo eng muss es auch nicht sein. 5cm Leitungslänge sind da schon 
problemlos drin. Mach dir aber ein paar gute Gedanken über die 
Taktverteilung. Siehe Artikel SDRAM-Timing.

MFG
Falk

Autor: glück (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe den 1382D schon einmal eingesetzt. der clock muss natürlich zum 
adressbus phasenverschoben sein. also adresse bei fallender flanke 
anlegen und mit steigender flanke vom sram übernehmen lassen. ich habe 
mir dazu im dcm einen invertierten clk erzeugt den ich direkt auf das 
sram gelegt habe.

zum layout: bei 150mhz ist eine terminierung nicht nötig gewesen. du 
musst darauf achten, dass die leitungslängen sehr kurz (stichwort 
"lumped system") und idealerweise gleich lang sind. ein 4lagiges board 
ist aber pflicht.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ glück (Gast)

>ich habe den 1382D schon einmal eingesetzt. der clock muss natürlich zum
>adressbus phasenverschoben sein. also adresse bei fallender flanke
>anlegen und mit steigender flanke vom sram übernehmen lassen. ich habe

NEIN! Lies den Artikel SDRAM-Timing nochmal. Und informier dich auch 
allegmein mal im Netz zum Thema. Lies mal die Datenblätter vpon Cypress 
und Micron zum Thema SDRAM. Du wirst erkennen, dass da GAR NICHTS mit 
fallender Flanke gemacht wird.

>mir dazu im dcm einen invertierten clk erzeugt den ich direkt auf das
>sram gelegt habe.

DCM ist schonmal der richtige Ansatz, aber invertierter Takt NICHT! Der 
DCM muss die Phase des FPGA-interen Taktes mit der Phase des Taktes 
direkt am SDRAM ausrichten. Clock Mirror nennt man das im Englischen. 
Gibts auch schöne Application Notes von Xilinx.


>zum layout: bei 150mhz ist eine terminierung nicht nötig gewesen. du

Das ist in erster Instanz UNABHÄNGIG von der Frequenz. Siehe 
Wellenwiderstand. Und zumindest die Taktleitung würde ich mit 
Serienterminieruing betreiben.

MFG
Falk

Autor: glück (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte? Man kann doch die steigende Flanke des Clocks nicht dorthin 
platzieren, wo gerade die Adresse geändert wird. Wie soll das denn 
funktionieren?

Autor: glück (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im FPGA selbst arbeite ich natürlich nicht mit der fallenden Flanke. Nur 
der externe SRAM wird invertiert betrieben.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ glück (Gast)

>Bitte? Man kann doch die steigende Flanke des Clocks nicht dorthin
>platzieren, wo gerade die Adresse geändert wird. Wie soll das denn
>funktionieren?

Aber sicher. Lies den Artikel und denk drüber nach.

>Im FPGA selbst arbeite ich natürlich nicht mit der fallenden Flanke. Nur
>der externe SRAM wird invertiert betrieben.

Ja eben. Was für die FPGA-interen Sachen recht, ist für den SDRAM 
billig. Mit deinem "fallende Flanke" Ansatz halbierst du dir nämlich die 
maximal erreichbare Taktfreqeunz :-0

MFG
Falk

Autor: glück (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich muss ja nicht unbedingt invertieren. Eine leichte Phasenverschiebung 
ist ausreichend. Die Idee ist einfach, dass man mit dem DCM die 
Datenübernahme der SRAMs dorthin legt, wo Setup- und Hold-Zeiten nicht 
verletzt werden. Und am sichersten sollte eine Verschiebung von 180° 
sein.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  glück (Gast)

>Ich muss ja nicht unbedingt invertieren. Eine leichte Phasenverschiebung
>ist ausreichend.

Das ist Rumgemurkse.

> Die Idee ist einfach, dass man mit dem DCM die
>Datenübernahme der SRAMs dorthin legt, wo Setup- und Hold-Zeiten nicht
>verletzt werden.

Jain.

> Und am sichersten sollte eine Verschiebung von 180° sein.

Jain. Ist aber technisch/leistungsmässig unsinnig.

MFG
Falk

Autor: glück (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dass ich innerhalb des FPGAs ausschließlich mit positiver Flanke und 
streng synchron arbeiten kann ist klar (sonst würde ja nichteinmal ein 
Schieberegister funktionieren). Nach Aussen hin habe ich da aber doch 
gerne einen Stellhebel, wie etwa die Phasenverschiebung des DCM. 
Prinzipiell müsste es aber auch ohne gehen, da hast du schon Recht.

Autor: glück (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk:

"Der DCM muss die Phase des FPGA-interen Taktes mit der Phase des Taktes
direkt am SDRAM ausrichten. Clock Mirror nennt man das im Englischen."

Wie stelle ich denn den DCM hier richtig ein? Wie messe ich den Versatz 
am besten?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ glück (Gast)

>Wie stelle ich denn den DCM hier richtig ein?

Steht in diversen Application Notes von Xilinx. Siehe neune Lins in 
SDRAM-Timing.

> Wie messe ich den Versatz am besten?

Ist direkt schwer messbar, weil du nicht an den Takt IM FPGA 
rankommst. Ist nur indirekt messbar, wenn du dir anschaust wann die 
Daten aus dem FPGA ausgegeben werden. Über das Wissen um die Clock to 
output time der IO-FlipFlops kannst du damit relativ gut auf die Phase 
des interenen FPGA-Taktes schliessen.

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.