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.
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
>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: > 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
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.
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
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
>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
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.
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€
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
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
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.