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
@ 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
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.
628512-70 M bei Reichelt für 3,50 Zwei Stück davon ergeben 8 Mbit. Für ein Hobbyprojekt wohl bezahlbar. MFg Falk
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
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).
@ 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
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.
>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
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
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.
>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
@ 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
>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!
Weiß jemand wie Michael Poppitz das bei seinem Logik-Analyzer macht? Als open source - also kannst du selber in den VHDL Dateien suchen.
Mal ernst du hast ja erstmal reinen Schreibzugriff. Das ist vom timming sichere sehr viel anspruchsloser als der sonst üblich Schreib/Lesezugriff.
>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
@ 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
@ 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
>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.
>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
> 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.
@ 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
@ 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
> 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.
@ 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
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 ;-)
>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:
1 | process (clk) |
2 | begin |
3 | if rising_edge(clk) then |
4 | addr_pin <= addr_signal; |
5 | data_pin <= data_signal; |
6 | nwe_pin <= nwe_signal; |
7 | end if; |
8 | 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
@ 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
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
@ 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-Timing#Timing_synchroner_Systeme Alles passiert auf ein und der selben Taktflanke! MFG Falk
>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_resources/datasheets/contents/cy7c1380d_8.pdf Aber ich werde Deinen Rat befolgen und nochmal nachlesen. Gruß Stefan Salewski
@ 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
>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
@ 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
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.
@ 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
Bitte? Man kann doch die steigende Flanke des Clocks nicht dorthin platzieren, wo gerade die Adresse geändert wird. Wie soll das denn funktionieren?
Im FPGA selbst arbeite ich natürlich nicht mit der fallenden Flanke. Nur der externe SRAM wird invertiert betrieben.
@ 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
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.
@ 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
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.
@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?
@ 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
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.