VHDL SDRAM Controller

>Edit: Gerade auf dem Spartan 6 Board ist es ueberaus unsinnig diesen SDR
>Speicher zu nehmen. Der Spartan 6 kann wunderbar mit DDR2 SDRAM umgehen.

So wie ich gehört habe, sind SDR-RAMs deutlich einfacher in der 
Ansteuerung. Vielleicht sind die Boards mit SD-RAM aus 
Anfängerfreundlichkeitsgründen mit SD-RAM ausgestattet.

Ich will das RAM des Spartan-6 verwenden und denke, dass nach 10 Jahren 
irgend jemand mal einen Treiber dazu geschrieben hat und hoffe, diesen 
zu finden.

Der ZPPino scheint es zu verwenden, aber wenn ich es richtig sehe, sind 
das hier alles nur Simualtionsfiles:
https://github.com/alvieboy/ZPUino-HDL/tree/dcache/misc/ddrsdram/src

Warum SDRam?

im Hobby:
das kann man auch mit mittlerer Erfahrung in Betrieb nehmen. Notfalls 
sogar den Core selbst schreiben.

im Job:
nur wenn es fertig ist, wird keiner neu eindesignen. Für niedrige 
Zugriffzeiten gibts z.b. ZBT Rams, für große Speicher sind DDR2+ besser.


Fertige SDRam Controller:
habe da so meine Erfahrungen gemacht...die meisten aus Hobbyprojekten 
sind irgendwo fehlerhaft. Am ehestens als Startpunkt zu verwenden.

Die professionellen funktionieren zwar meist gut, sind aber recht 
unflexibel und setzen oft auf AXI oder ähnliches. Wer damit arbeiten 
will, für den ists aber auch ok.


Simulation:
freemodelfoundy.com

Was Speicher betrifft bin ich da noch nie enttäuscht wurden. 
Funktioniert sehr gut und deckt gerne auch kleine Timingverletzungen auf 
mit denen man gar nicht gerechnet hat.

Carl schrieb:
> So wie ich gehört habe, sind SDR-RAMs deutlich einfacher in der
> Ansteuerung.
Ja und noch einfacher sind DRAMs.
Wenn man verstehen will, wie das Ganze funktioniert, empfehle ich dort 
mit den Datenblättern anzufangen. Da sind die Grundlagen noch ausfürlich 
erklärt.

Bei den nachfolgenden Systemen (SDRAM -> DDR-RAM -> DDR2) wird oft nur 
noch auf die Unterschiede eingegangen.

Duke

Duke Scarring schrieb:
> Carl schrieb:
>> So wie ich gehört habe, sind SDR-RAMs deutlich einfacher in der
>> Ansteuerung.
> Ja und noch einfacher sind DRAMs.

Nein DRAM's sind komplizierter da asynchron, SRAM also Statischer RAM 
dagegen ist simpler als SDRAM (synchron dynamische RAM) rsp SDR-RAM 
(Single data rate ram). Mit SDRAm wurden auch speicherbänke eingeführt, 
was den prefetch ermöglichte und den Zugriff auf einzelne bits 
vereinfachte. DRAM's sollte man also meiden und sich für SRAM oder SDRAM 
entscheiden.

Project MaVo schrieb:
> Nein DRAM's sind komplizierter da asynchron

Nein, nur weil's nicht synchron ist, muss es
nich komplizierter sein (z.B. musst keine
Init-Sequenz implementieren werden, was aber auch
nicht sonderlich kompliziert ist).

Ich würd's eher wie Duke Scarring sehen, ein Blick
in die Datenblätter ist auf jeden Fall lohnenswert.

Sigi schrieb:
> (z.B. musst keine
> Init-Sequenz implementieren werden, was aber auch
> nicht sonderlich kompliziert ist).

das spricht erst recht für SRAM...

Es geht aber um dieses Board:
Beitrag "XC6SLX16 Spartan 6 Entwicklungsboard"

Und das hat nun mal ein SDRAM.

Dergute W. schrieb:
> Moin,
>
> Carl schrieb:
>> Es geht aber um dieses Board:
>> Beitrag "XC6SLX16 Spartan 6 Entwicklungsboard"
>>
>> Und das hat nun mal ein SDRAM.
>
> <spock-mode><braue-hochzieh>Faszinierend</braue-hochzieh></spock-mode>
> Da gibt's wohl noch mehr Boards mit SDRAM. Warum hab' ich mich auch
> schon gefragt...
> Beitrag "Re: Terasic DE10-Nano & weitere Fragen"
>
>
> Gruss
> WK

FPGA- und ARM-Teil können nicht gleichzeitig auf das DDR SDRAM 
zugreifen. D.h. es gibt Verzögerungen beim Zugriff und der Durchsatz 
wird bei kleineren Datenmengen ziemlich schlecht. Hier hat das mal 
jemand ausgemessen:

https://github.com/UviDTE-FPSoC/CycloneVSoC-time-measurements

Es ist also schon sinnvoll den Speicher für FPGA und HPS zu trennen.

Außerdem ist es eine nette Herausforderung einen eigenen 
SDRAM-Controller zu schreiben.

Mike schrieb:
> Dergute W. schrieb:
>> Carl schrieb:
>>> Es geht aber um dieses Board:
>>> Beitrag "XC6SLX16 Spartan 6 Entwicklungsboard"
>>>
>>> Und das hat nun mal ein SDRAM.
>>
>> Da gibt's wohl noch mehr Boards mit SDRAM. Warum hab' ich mich auch
>> schon gefragt...

Waren noch im Lager und mussten vertickt werden.

> FPGA- und ARM-Teil können nicht gleichzeitig auf das DDR SDRAM
> zugreifen. D.h. es gibt Verzögerungen beim Zugriff und der Durchsatz
> wird bei kleineren Datenmengen ziemlich schlecht.

Bei den genannten boards gibt es keinen ARM-Teil.

>Edit: Gerade auf dem Spartan 6 Board ist es ueberaus unsinnig diesen SDR
>Speicher zu nehmen. Der Spartan 6 kann wunderbar mit DDR2 SDRAM umgehen.
Ja, auch wegen dem Hardcore-Memorycontroller, aber für die meisten 
Anwendungen reicht SDRAM völlig.
Vielleicht hat SDRAM auch Vorteile bei random Zugriffen, da sich DDR2 
u.ä. wegen dem 4n Prefetch mit Zugriffen kleiner als ein Burst 'schwer' 
tut. Um dass zu kompensieren muss man halt aus den knappen BRAM-Blöcken 
Caches aufbauen. Das spart man sich vielleicht bei SDRAM's.

Autor: Mike (Gast)
>Außerdem ist es eine nette Herausforderung einen eigenen
>SDRAM-Controller zu schreiben.

Es ist auch eine nette Herausforderung, sein eigenes Betriebssystem zu 
schreiben. Sollte man auf jeden Fall mal gemacht haben.

C. A. Rotwang schrieb:
> Vielleicht hat SDRAM auch Vorteile bei random Zugriffen, da sich DDR2
> u.ä. wegen dem 4n Prefetch mit Zugriffen kleiner als ein Burst 'schwer'
> tut.

Nein, denn mit der Frequenz steigt auch leider immer die Latenz,
aber ebenso steigt der Durchsatz, einer der Vorteile bei jeder
neuen DDR-SDRAM-Familie.

Sigi schrieb:
> C. A. Rotwang schrieb:
>> Vielleicht hat SDRAM auch Vorteile bei random Zugriffen, da sich DDR2
>> u.ä. wegen dem 4n Prefetch mit Zugriffen kleiner als ein Burst 'schwer'
>> tut.
>
> Nein, denn mit der Frequenz steigt auch leider immer die Latenz,
> aber ebenso steigt der Durchsatz, einer der Vorteile bei jeder
> neuen DDR-SDRAM-Familie.

Nein, ist keine Frage der Taktfrequenz sondern eine Frage der 
Speicher-Architektur, die Frequenzbereich sind für die versch. Speicher 
sogar überlappend, einfach mal die Grundlagen der Speicherarchitekturen 
nachschauen. Oder ein Blick ins Datenblatt werfen

https://de.transcend-info.com/Support/FAQ-296
https://de.wikipedia.org/wiki/Dynamic_Random_Access_Memory#Prefetch
https://www.winbond.com/resource-files/w9864g6jt_a03.pdf

Letzterer sollte  der vom Trenz Max1000 Board sein

Der Durchsatz steigt eben nur bei Zugriffen mit minimalen Burstlängen, 
bei Einzelwortzuigriffen steigt er sogar. Und je nach Anwendung fallen 
die Daten eher mit inkrementierender Addresse oder "hin und Her an 
(CPU-Arbeitsspeicher, Interleave bei ECC zur Burstfehler Konvertierung 
(CD-ROM), Butterfly-Filter).
Das könnte also ein szenario sein, wo SDRAM gegenüber DDR2 und Konsorten 
Sinn macht; auch ohne Caches, die ohnehin nur bei zeitlicher und lokaler 
Nähe der Zugriffe Sinn machen.

Dergute W. schrieb:

> Wenns jetzt von mehreren Firmen Boards mit SDRAM drauf gibt, muss das
> ein firmenuebergreifendes Lager sein.
>
> Seltsam? Aber so steht es geschrieben... ;-)

Klar gibt es so ein übegreifendes Lager - das nennt sich 'Distributor' 
mit denen man sich als 'kleiner' Boardhersteller (<10k/a boards) 
vertragen muss.
Die speicherhersteller brauchen Millionenstückzahlen bevor sie mal ne 
Charge durch die wochenlange Fertigung prügeln.

C. A. Rotwang schrieb:

> Der Durchsatz steigt eben nur bei Zugriffen mit minimalen Burstlängen,
> bei Einzelwortzuigriffen steigt er sogar.

Typo am morgen - macht Kummer und sorgen ;-). Es soll heissen:

Der Durchsatz steigt eben nur bei Zugriffen mit (minimaler) Burstlängen,
bei Einzelwortzugriffen sinkt er sogar.

>Da gibt's wohl noch mehr Boards mit SDRAM. Warum hab' ich mich auch schon 
gefragt...

Dass es bei Terasic noch so viele (der billigeren) Boards mit SDRAM 
gibt, liegt wahrscheinlich daran, das Altera/Intel mit der kostenlosen 
Quartus-Edition keinen kostenlosen DDR-IP-Core zur Ansteuerung 
mitliefern; den gibt es nur in der Bezahlversion.

Bei Xilinx gibt es die DDR-Cores kostenlos für ISE und Vivado.

Jope
>Bei Xilinx gibt es die DDR-Cores kostenlos für ISE und Vivado.
Hallo Jope,
wo kann man die finden?

Ich finde einen Multiport-Memory-Controller Manual, aber keinen Sourcen.
https://www.xilinx.com/support/documentation/ip_documentation/mpmc/v6_06_a/mpmc.pdf

Carl schrieb:
> Jope
>>Bei Xilinx gibt es die DDR-Cores kostenlos für ISE und Vivado.
> Hallo Jope,
> wo kann man die finden?
>
> Ich finde einen Multiport-Memory-Controller Manual, aber keinen Sourcen.
> 
https://www.xilinx.com/support/documentation/ip_documentation/mpmc/v6_06_a/mpmc.pdf

Die muss man sich mit dem MiG generieren ... 
https://www.xilinx.com/support/documentation/ip_documentation/ug086.pdf

Vielleicht solltest du erst das Code generieren erst mit einfachen Cores 
üben bevor du dich an etwas für richtige Männer, richtige Frauen oder 
richtige Diverse machst.
https://china.xilinx.com/support/documentation/sw_manuals/xilinx2012_4/ug896-vivado-ip.pdf

>Hallo Jope,
>wo kann man die finden?

Wie schon von "Project MaVo" beantwortet ist das der MIG (bei ISE im 
Core Generator zu finden).

Aber wie erwähnt, nur für DDR-Cores, nicht SDRAM, das auf Deinem Board 
ist.
Dein Board ist von Qmtech. Von denen bekommst Du auch Boards mit 
DDR3-Speicher, für die der MIG Cores generieren kann:
https://qmtechchina.de.aliexpress.com/store/4486047

20 Euro inkl. Versand für das Spartan6-Board mit DDR3 ist doch 
geschenkt.

Genau das ist doch der Grund!

Das "Spielgelumpe" ist doch der Sinn bei den günstigen Cyclone Boards.
Dort kann man als Anfänger super starten und hat noch genug Aufgaben, 
selbst wenn man Erfahrung hat.

Einen DDR2+ braucht man doch in diesem Bereich nicht zwingend, machen es 
aber unnötig kompliziert.

Klar, ich würde auch lieber ein paar Switches und LEDs am DE2-115 gegen 
ein DDR2 tauschen, aber mein Gott, dafür ist es halt nicht gemacht.

Wird doch wohl hoffentlich keiner versuchen ein solches Evalboard mit 
Unmengen Peripherie mit Leben zu füllen und hinterher verkaufen zu 
wollen als Produkt.

Das Blockschaltbild des MT48LC16M16A2 deutet schon seine Komplexität an.

Tobias B. schrieb:
> Samuel C. schrieb:
>> Was wäre denn nach dem Spielgelumpe was sinnvolles auf einem Dev-Board
>> für einen Anfänger? Ernstgemeinte Frage.
>
> Wenn du ein Serienprodukt in kleinen Stueckzahlen hast, dann lohnt es
> sich nicht immer ein komplett neues FPGA Board zu entwickeln. Dann bsit
> du froh, dass es Boards gibt, die nichts anderes drauf haben wie ein
> FPGA, vll. etwas DDR Speicher und die passende Spannungsversorgung. Die
> eigentliche Funktionalitaet kommt dann ueber ein Addon Board, welches
> deutlich guenstiger zu entwickeln ist.


> Aus diesem Grund hat man auch die
> FMC Stecker mit dem Vita 47.1 (oder neuer) Standard ins Leben gerufen.
> Damit kann man dann relativ leicht die FPGA Boards austauschen, ohne
> dass man an seinem Addon Board rumfummeln muss.

Nach meiner Erfahrung sind die die Stecker so teuer und der 
resultierende Aufbau so gröss das an einem Einsatz in einem Embedded 
Gerät nicht sinnvoll ist. solche Kombies kann man in Server oder im 
Prototyping einsetzen.

Ein addon board mit vielpoligen Hispeedstecker selbst zu entwicklen ist 
in gesamtkosten IMHO nicht günstiger als als Gesamtboard ohne Stecker 
und dafür mit angepassten (kleineren) FPGA zu entwicklen. Ausnahme 
Prototypen.

>Muss jeder selber wissen, aber das "Spielgelumpe" ist immer nur so lange
>interessant, bis es zum ersten Mal funktioniert und man fertig gespielt
>hat.

Naja es stellt sich schon die Frage, wo es für die FPGA-Apps wirklich 
DDR2 oder gar drei sein muss und wo bereits SDR-Mem völlig ausreichend 
ist. Soll der DDR-Mem als Speicher für ne ARM-cpu herhalten, da sollte 
man doch gleich ein ARM-board nehmen (RasPi) der läuft locker mit 
höheren MHz als jeder FPGA. Und der Datenstream der in der Mem soll, 
muss erst mal erzeugt werden.
Was so ein gängiger 50 MHz ADC erzeugt schaufelt auch noch ein SDR weg, 
im videobereich hat man auch die Möglichkeit durch ausnutzung der v- und 
h-blancs sowie 'beschränkung' auf eine realistische Farbtiefe resp 
Palettennutzung die Speicherbandbreite akzeptabel gering zu halten.
Vielleicht kann man so sagen, alles was früher (Jahrtausendwechsel) mit 
DRAM realisiert wurde (also vor DDR2 etablierung) kann man auch nocht 
heute
mit FPGFA und SDRAM machen. Das ist ne ganze Menge, wenn man 
beispielsweise an die Videoschnitttechnik etc denkt (amiga-basierend) 
oder auch die Playstation 1 + 2 denkt. 
https://youtu.be/2qU22Hb9v1E?t=2293

Carl schrieb:
> Das Blockschaltbild des MT48LC16M16A2 deutet schon seine Komplexität an.

Nee, die Komplexität wird erst an der statemachine and an den 
timing-diagrammen sichtbar.So ein rechteckreiches Blockbild kannst auch 
für nen Computer angegeben und deren FPGA-re-Implementierung ist auch 
kein Hexenwerk.

http://vmpalvelin.no-ip.info/Computers/A500/A500_BD.jpg
https://en.wikipedia.org/wiki/Minimig

PS:
Bitte vorsichtig sein mit den Kopieren von copyrightgerschutzten 
Material wie Datenblätter. Da genügt ein Link.

Bei Micron wird's wenn ich richtig sehe unter "obsolet" geführt.

Es gibt aber noch ein Datenblatt:
https://www.micron.com/-/media/client/global/documents/products/data-sheet/dram/256mb_sdr.pdf

Wenn ich's richtig sehe, könnte der Kontroller aus dem ersten Post 
vielleicht funktionieren, wenn

1

data_width: positive := 32;    -- host & SDRAM data width

auf 16 umstellt.

Dergute W. schrieb:

> Und natuerlich gibts Anwendungen, wo man das braucht. Stell dir mal 1
> bis N GBit-Ethernet Interfaces vor, deren Pakete zwischengespeichert
> werden sollen, verarbeitet, und wieder ausgegeben. Wenn man damit
> rechnen muss, dass die Linkkapazitaet tatsaechlich auch ausgenutzt wird
> und nicht nur z.B. ein DSL-Router oder ein Internetradio oder ein
> Kuehlschrank dranhaengt, wird das schnell hakelig.

Naja, es geht ja wohl immer noch um Entwicklungskits, nicht um 
handoptimierte, anwendungsspezifische Massenserienboards, die auch in 
jedem Volllast-fall tun. Und für die (Grundlagen-)Entwicklung reicht 
auch ein Board mit einem Ethernet-1000M PHY/MAC und 0815 
Arbeitsspeicher.
Für nen "Deep Packet Inspection" High Traffic Router dessen abhörende 
Anwesenheit mensch anhand der Latenzen kaum bemerken kann, muss man eben 
die auf dem Dev-board gemachten Erfahrungen Designs eben entsprechend 
'hochskalieren', auch bezüglich der bestückten Mems. Aber ein gutes 
Entwicklungsboard zeichnet sich eben gerade darin aus das man für vieles 
ein erstes "Proof of concept" vorlegen kann ohne erst ein Bord selbst 
schnitzen zu müssen.

> Von
> den Bildern her, seh' ich zwar Block-Cs am SDRAM, aber am FPGA sieht das
> fuer mich doch eher duerftig aus. Auf der Unterseite nix, auf der
> Oberseite wenig...Oder verwenden die derweilen so kleine Cs, dass die
> unters FPGA zwischen die Balls passen?

Richtige Idee, falsche Lösung. Block-Kapazitäten kann man nicht nur aus 
Kondensatoren aufbauen, man kann auch die Kapazität zwischen den 
Leiterbahnen, den inneren GND/Vcc-lagen und dem Dielektrikum im Prepreg 
benutzen.
Insofern kann man vom blossen Anschauen der Fotos nicht sagen, ob das 
Speicherinterfacees es auch zur Zufriedenheit tut.

Es sei denn man lässt sich vom Herstellerlogo verführen:
https://store.digilentinc.com/atlys-spartan-6-fpga-trainer-board-limited-time-see-nexys-video/. 
Gebrauchtpreis heute ca. 100€

Der Kontroller hier könnte dich interessieren:

http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller#Version_0.1_-_minimal_controller

Dergute W. schrieb:
> Moin,
>
> C. A. Rotwang schrieb:
>> Aber ein gutes
>> Entwicklungsboard zeichnet sich eben gerade darin aus das man für vieles
>> ein erstes "Proof of concept" vorlegen kann ohne erst ein Bord selbst
>> schnitzen zu müssen.
>
> Ethernetinterface an dem Board haengt, sondern weil verschiedene Boards
> von verschiedenen Herstellern aus nicht offensichtlichen Gruenden einen
> ziemlich uralten und niederperformanten Typ RAM haben, wo wohl jeder ein
> ungutes Gefuehl haette, den in einer neuen Serienprodukt einzusetzen.


Nein ein SDRAM ist weder uralt noch niederperfomant, sondern passend für 
LowCost-FPGA's, wie bspw. Max10 oder cyclone 10 LP.

Nicht umsonst hat xilinx einen Hardcore-Memorycontroller in den 
Spartan-6 eingebaut, weil mit der konfigurierbaren Logic allein ein 
double rate an den standard-IO's kaum zu schaffen ist oder nur unter 
starker belastungs des xilinx-supports. intel schliesst sogar DDR-RAM 
support für den Cyclone10-LP kategorisch aus. Man sollte nicht den 
fehler machen von der blossen maximalen internen Taktfrequenz des FPGA 
auf die Bandbreite an den interfacen schliessen, zumal double data rate 
eine Verdopplung der Taktfrequenz an Teilen des designs bedeudet.
Xilinx empfiehlt für Softcore-memory designs ohnehin die HighPerformance 
Reihe wie Virtex. Und auch dafür gibt es Evalboards, die dann auch mit 
passendendouble data rate FPGA's bestückt sind.
Und wenn es unbedingt die Billig-FPGA-Schiene sein muss, dann verdoppelt 
man halt den Datenbus um auf doppelte Rate zu kommen.

> Gerade bei so unangenehm zu debuggenden Schnittstellen wie RAM ist's mir
> am liebsten, wenn das Proof-of-concept-Board und das Serienprodukt
> moeglichst wenig Unterschiede aufweisen.

Naja ein Grosser Teil des Unterschieds steckt eben nicht im VHDL-Design 
v. Statemachine und Mem-configuration sondern in der Anpassung 
PCB-trace-skew an  FPGA-IO's, da kommt man kaum ums 
debuggen/SI-qualification am Serienprodukt umhin. Und dann ist man ganz 
schön in den A* gebissen, wenn man sich drauf verlassen muss, das alles 
wie beim Evalboard tut, weil man keine gescheite Messmöglichkeiten auf 
dem PCB vorgesehen hat und sich mit nicht ädequaten Messequipment 
rumschlägt.

> Die
> Unterschiede in der BOM zwischen dem SDRAM und DDRx werden wohl nicht
> kriegsentscheidend sein.

Es ist nicht die BOM die bumm macht .... zwischen single und double data 
rate liegen wegen der frequenzverdopplung im Datenpfad Welten.


> C. A. Rotwang schrieb:
>> Richtige Idee, falsche Lösung. Block-Kapazitäten kann man nicht nur aus
>> Kondensatoren aufbauen, man kann auch die Kapazität zwischen den
>> Leiterbahnen, den inneren GND/Vcc-lagen und dem Dielektrikum im Prepreg
>> benutzen.
> Das kann man natuerlich machen. Man kann aber auch erkennen, das da ein
> Board ist, was ueber Amazon vertickt wird, wo sich offensichtlich der
> Entwickler nicht an die Empfehlungen von Xilinx bezueglich der
> Spannungsversorgung gehalten hat.

Nein, das ist nicht offensichtlich, da die erforderlichen Kapazitäten 
wie bereits hingewiesen, nicht allein durch diskrete Kondensatoren 
realisiert werden können. Kann man auch gerne mal überprüfen indem man 
die Decoupling-C's ablötet - bei guten Starterkits (good Ground Planes, 
good power supply) gehts auch ohne: https://youtu.be/cLy0mVkoLio?t=629
Und da inzwischen so ziemlich alles über Amazon vertickt wird, kann man 
vom Namen der Verkaufsplattform nicht auf die Produktqualität 
schliessen.

Ferner sind die Xilinx-Empfehlungen nicht pauschal, sondern auf 
konkreten Anwendungsfall hin berechnbar. Wenn der SSO anteil eben gut 
verteilt ist, kommt man auch mit ein paar C's an den kritischen V_IO 
aus. Auf dem digilent atlys board finde ich auch keine 
bypass-Kondensatoren unter dem FPGA, sondern nur auf der Bestückseite.
Trotzdem würde ich zu einem digilent-board und nicht zum board vom TO 
raten.