Welcher externe RAM-Baustein für FPGA (Spartan-3E)?

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.

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).

>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

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

>also kannst du selber in den VHDL Dateien suchen.

Ist mir schon klar -- werde ich auch machen.

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

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

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

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

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

>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

>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

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.

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.

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.

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?