Forum: FPGA, VHDL & Co. VHDL SDRAM Controller


von Carl (Gast)


Lesenswert?

Auf diesem Board ist ein SD-RAM:
Beitrag "XC6SLX16 Spartan 6 Entwicklungsboard"

Wie aktuell sind SD-RAMs heute noch und wo kann man ein VHDL-Beispiel 
dafür finden?

Hier gibt es einen allgemeinen SD-RAM-Controller:
http://www.geocities.ws/mikael262/sdram

Beitrag #5851343 wurde vom Autor gelöscht.
von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

Naja, DDR-SDRAM sind sehr modern, single data rate eher weniger. SDR 
SDRAMs machen halt da Sinn, wo man mit einem FPGA keine DDR I/Os hat. 
Moderne und auch viele aeltere FPGAs haben jedoch wirklich gute DDR I/O 
Ressourcen.

Und in wieweit das wirtschaftlich Sinn macht und wie gut SDR SDRAMs 
verfuegbar sind: keine Ahnung. Bei neuen Designs wuerde ich nie auf die 
Idee kommen SDR SDRAMs zu verwenden.

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.

: Bearbeitet durch User
von Carl (Gast)


Lesenswert?

>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

von FPGA zum Spass (Gast)


Lesenswert?

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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

Carl schrieb:
> 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.

Xilinx schenkt dir einen Controller, allerdings nur fuer DDR SDRAM 
Typen. Evtl. gibt es in aelteren ISE Versionen noch IP Generatoren fuer 
SDR SDRAMs.

Bei opencores.org koennte vielleicht auch etwas dabei sein:

https://opencores.org/projects?expanded=Memory%20core

Der hier sieht vielversprechend aus, ist allerdings in Verilog:

https://opencores.org/projects/sdr_ctrl

: Bearbeitet durch User
von Duke Scarring (Gast)


Lesenswert?

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

von Project MaVo (Gast)


Lesenswert?

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.

von Sigi (Gast)


Lesenswert?

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.

von Project MaVo (Gast)


Lesenswert?

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

das spricht erst recht für SRAM...

von Carl (Gast)


Lesenswert?

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

Und das hat nun mal ein SDRAM.

von Dergute W. (derguteweka)


Lesenswert?

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

von Mike (Gast)


Lesenswert?

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.

von C. A. Rotwang (Gast)


Lesenswert?

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.

von Carl (Gast)


Lesenswert?

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.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Mike schrieb:
> https://github.com/UviDTE-FPSoC/CycloneVSoC-time-measurements
>
Merci fuer den Link. Den muss ich mir mal unters Kopfkissen legen.

> Es ist also schon sinnvoll den Speicher für FPGA und HPS zu trennen.
Das ist voellig klar. Mir ist nur unklar, warum dann eben auf einem 
Board 2 unterschiedliche DRAM-Typen an den jeweiligen 
Memorycontrollern haengen, von denen der eine eben auch schon ein paar 
Jahre aufm Buckel hat, und nicht wirklich die Rakete ist.
Und dann ein anderes Board mit den gleichen RAMs an beiden 
Speicherinterfaces doch schon deutlich teurer ist.
Oder eben wie hier, auf einem Board mit Xilinx-FPGA statt Intel und von 
einem anderen Boardhersteller als Terasic auch nur der olle SDRAM 
Baustein dranhaengt und kein DDR2 oder 3, obwohls der FPGA wohl hergeben 
wuerde.

> Außerdem ist es eine nette Herausforderung einen eigenen
> SDRAM-Controller zu schreiben.
Naja, muss man auch moegen. Man kann auch ein eigenes Flipflop aus einer 
ECC85 bauen. Ist auch ne nette Herausforderung.


C. A. Rotwang schrieb:
> Waren noch im Lager und mussten vertickt werden.
Ja, das waere eine Erklaerung. Zumindest bei Boards von einer Firma. 
Wenns jetzt von mehreren Firmen Boards mit SDRAM drauf gibt, muss das 
ein firmenuebergreifendes Lager sein.

Seltsam? Aber so steht es geschrieben... ;-)
Gruss
WK

von Sigi (Gast)


Lesenswert?

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.

von C. A. Rotwang (Gast)


Lesenswert?

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.

von C. A. Rotwang (Gast)


Lesenswert?

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.

von C. A. Rotwang (Gast)


Lesenswert?

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.

von Jope (Gast)


Lesenswert?

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

von Carl (Gast)


Lesenswert?

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

von Project MaVo (Gast)


Lesenswert?

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

von Jope (Gast)


Lesenswert?

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

von Markus F. (mfro)


Lesenswert?

Jope schrieb:
>>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.

Huh?

Der ALTMEMPHY ist kostenfrei und unterstützt DDR, DDR2 und DDR3-Memory. 
Zumindest für die Cyclone, die auf diesen Boards stecken.

Daß diese Boards mit SDRAM kommen, liegt m.E. an etwas anderem: die 
gesamte Bank, an der das DDRx-RAM hängt, muß auf den SSTL-2 I/O-Standard 
eingestellt werden (das geht nur bankweise). Wahrscheinlich hat Terasic 
beschlossen, daß sie dann zu wenig TTL-Pins für ihr sonstiges 
Spielgelumpe frei haben.

von FPGA zum Spass (Gast)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

FPGA zum Spass schrieb im Beitrag #5853374:
> 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.

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

Danach - wenn man mit dem Board dann endlich mal was Sinnvolles machen 
will - ist es nur noch hinderlich.

von Samuel C. (neoexacun)


Lesenswert?

Markus F. schrieb:
> Danach - wenn man mit dem Board dann endlich mal was Sinnvolles machen
> will - ist es nur noch hinderlich.

Was wäre denn nach dem Spielgelumpe was sinnvolles auf einem Dev-Board 
für einen Anfänger? Ernstgemeinte Frage.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

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.

von Samuel C. (neoexacun)


Lesenswert?

Tobias B. schrieb:
> Wenn du ein Serienprodukt in kleinen Stueckzahlen hast, dann lohnt es
> sich nicht immer ein komplett neues FPGA Board zu entwickeln.

Es ging jetzt aber um:

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

Das hat mit Serienprodukt jetzt weniger zu tun. In diesem Fall sucht man 
sich wohl kaum ein Board mit möglichst weit gestreutem Spielgelumpe.

von Carl (Gast)


Angehängte Dateien:

Lesenswert?

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

von C. A. Rotwang (Gast)


Lesenswert?

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

von C. A. Rotwang (Gast)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

Samuel C. schrieb:
> Was wäre denn nach dem Spielgelumpe was sinnvolles auf einem Dev-Board
> für einen Anfänger? Ernstgemeinte Frage.

Alles, was langsam (oder gar unmöglich) wird, wenn man's nachträglich 
selber dranfrickeln will: RAM, in der für das FPGA am besten geeigneten 
Form, so schnell und so breit wie möglich/sinnvoll, HDMI video, u.U. USB 
oder PCIe (aber nur, wenn geeignete IP dafür zur Verfügung steht, sonst 
bringt man sich daran um).

Alles andere kann man (bis der Spieltrieb abgeflaut ist) per fliegendem 
Draht anbinden oder auf dem (in der Lernphase sowieso dranhängenden) PC 
abfackeln.

Ich ärgere mich regelmässig, wenn auf solchen Boards Dinge, für die's 
gar kein FPGA braucht (z.B. per i2c angebundene Beschleunigungssensoren 
oder Näherungsschalter) wertvolle Pins belegen.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Carl schrieb:
> Das Blockschaltbild des MT48LC16M16A2 deutet schon seine Komplexität an.
Ja, im Vergleich zu einem CA3046 oder NE555 schon.
Aber im Vergleich zu einem DDRx-DRAM ist's nicht mehr so ein 
Rieeesending.


C. A. Rotwang schrieb:
> 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.

Naja, wenn man's nicht braucht, braucht man's halt nicht. Wenn einem die 
Datenrate von SDRAM ausreicht, tut aber DDRx auch nicht unbedingt weh. 
Andersrum schon.
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.
Und natuerlich will man dafuer keinen Controller hernehmen. In einem 
Ethernetswitch laeuft auch die breite Masse der Pakete nicht ueber den 
Prozessor, sondern eben ueber spezielle Hardware. Das hat schon Gruende.

Aber nochmal was zu dem urspruenglichen Board, um das es hier geht: 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? Koennte es sein, dass nur 
SDRAM-Interfaces am FPGA solche Faxen wie Weglassen/entfernt 
anschliessen von Block-Cs noch halbwegs tolerieren waehrend es eben bei 
DDR um Verrecken nicht mehr einseitig bestueckt geht; dass das schlicht 
der Grund fuer's SDRAM ist?

Gruss
WK

von Jonas B. (jibi)


Lesenswert?

>Samuel C. schrieb:
>> Was wäre denn nach dem Spielgelumpe was sinnvolles auf einem Dev-Board
>> für einen Anfänger? Ernstgemeinte Frage.

Auf jeden Fall, den als Anfänger bringt dir so ein USB-Stick 
formatartiger fpga mit nichts dran gar nichts, vor allem der 
angeschlossene DDR3-RAM funktioniert nur in dem (wen überhaupt) 
mitgeliefertem Beispiel. Wenn du Glück hast is ein Beispieltprojekt mit 
generiertem Core, ucf und allem nötigen dabei. Damit kann man anfangen, 
da lässt man dann schön seine erste LED-blinken und parallel läuft der 
vorgefertigte RAM-COre und dreht Däumchen...so sinnlos :D

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

C. A. Rotwang schrieb:
> 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.

Alles eine Frage der Stueckzahlen und der Funktionalitaet. Ich kann dir 
Beispiele aus meiner beruflichen Laufbahn nennen bei denen es sich lohnt 
und welche bei denen es nicht nicht gelohnt hat / haette.

Fuer mich ist nur wichtig, dass ich eine Wahl habe und mir dann 
ueberlegen kann was fuer meine Anwendung die bestmoegliche Entscheidung 
ist.

Eine Pauschale kann man vll. treffen: Haeufig machen Addon Boards da 
Sinn wo man eine Basis Funktionalitaet braucht, aber verschiedene 
Produktabwandlungen auf den Markt bringen moechte. Und es muessen auch 
nicht immer teure Highspeed Stecker sein, wichtig ist nur, dass die 
Belegung standardisiert ist (und wenn man sich selbst einen auferlegt) 
und dafuer ist nun mal FMC mit Vita 47.1 ein Paradebeispiel. Allerdings 
auch nur eins von vielen.

von Carl (Gast)


Angehängte Dateien:

Lesenswert?

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.

von C. A. Rotwang (Gast)


Lesenswert?

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€

von Dergute W. (derguteweka)


Lesenswert?

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.

Genau. Deshalb gibts auch von mir kein Gequengel, weil nur 0..1 
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.
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.
Der Switch/Router war von mir nur ein Beispiel. Ein Anderes waere z.b. 
ein H26x En/Trans/Decoder mit irgendwelchen Faxen. Da kommt man mit 
SDRAM auch nicht weit. Natuerlich wuerde ich nicht unbedingt die 
Spezial-video-interfaces auf einem simplen Evalboard erwarten; die 
koennen ruhig auf Daughterboards - aber eben ein schnelles, 
zeitgemaesses RAM, wenns denn der FPGA eh' schon unterstuetzt. Die 
Unterschiede in der BOM zwischen dem SDRAM und DDRx werden wohl nicht 
kriegsentscheidend sein.

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.
Und daraus Schluesse ziehen, wie wahrscheinlich es wohl ist, dass da der 
Entwickler tatsaechlich einen Sonderschnitz abgeliefert hat, der bessere 
Eigenschaften hat.

> Insofern kann man vom blossen Anschauen der Fotos nicht sagen, ob das
> Speicherinterfacees es auch zur Zufriedenheit tut.
Nichts liegt mir ferner :-)

Gruss
WK

von Markus F. (mfro)


Lesenswert?

Dergute W. schrieb:
> 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.

ich stell' mir das mittlerweile so vor, dass bei I & X smarte, 
hochbezahlte Marketingburschen hocken, die die (subventionierten) Chips 
erst rausrücken, wenn Terasic & Co so lange unnötiges Spielgemüse und 
lahme RAMs auf das Eval-Board gepackt haben, dass es sicher nicht mehr 
zum (semi-) professionellen oder gar industriellen Einsatz taugt.

: Bearbeitet durch User
von Ale (Gast)


Lesenswert?


von C. A. Rotwang (Gast)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.