Tag zusammen. Mich würde mal interessieren, ob ihr noch SRAM einsetzt. Preislich und von der Größe her ist DDR2/DDR3 ja an sich nun wirklich über jede Frage erhaben. Bei Projekten wo schnell viele Daten nicht unbedingt am Stück relevant sieht geht aber ddr schnell in die Knie. Ich habe dann öfter versucht den Speicher so zu organisieren, dass meine Daten auf Bänke so aufgeteilt werden, dass nicht nach jedem zufälligen Zugriff eine row zugemacht werden muss. Aber wenn ich so überlege und mal gucke was die Hersteller anbieten sind (ok zum viel höheren Preis, aber der ist ja manchmal auch untergeordnet) Sram bis zu ansehnlichen Größen (also das heißt so ab 512 k x 16 bit) mit <= 10 ns gut vertreten. Andererseits soll der Speicher nun auch nicht unberechenbar abgekündigt werden, daher stelle ich mir die Frage, wie die Zielgruppe für größere, schnelle Sram aussieht. Meine Frage: wer stellt hin und wieder ähnliche Überlegungen an? Wie siehts bei euch aus?
Es ist schon einige Zeit her, dass ich mir diese Frage gestellt habe. Entweder ich fasse mich kurz, d.h. der interne Speicher reicht aus, oder ich brauch so viel Speicher, dass der Preisunterschied jegliche Diskussion verbietet. Soweit mir bekannt gilt die alte Regel: SRAM = schnell = Platzintensiv (Silizium) = Stromsparender DRAM = langsamer = Sparsamer beim Platz (Silizium) = mehr Energie immer noch. Hinzu kommt noch, dass bei den meisten µP die Speicheranbindung würglich nicht das Gelbe vom Ei ist, so dass in vielen Fällen der eventuelle Geschwindigkeitsvorteil (sram) stark zurückgeht.
@zu Gast (Gast) >Mich würde mal interessieren, ob ihr noch SRAM einsetzt. Der hat nur noch für Bastler und GAAAANZ wenige Anwendung seine Berechtigung. >Preislich und von der Größe her ist DDR2/DDR3 ja an sich nun wirklich >über jede Frage erhaben. > Bei Projekten wo schnell viele Daten nicht >unbedingt am Stück relevant sieht geht aber ddr schnell in die Knie. Dafür gibt es Caches in Form von BRAMs in FPGAs. >Sram bis zu ansehnlichen Größen (also das heißt so ab 512 k x 16 bit) >mit <= 10 ns gut vertreten. Für den gleichen Preis oder weniger bekommt man die 10fache Menge SDRAM/DDRx. > Andererseits soll der Speicher nun auch >nicht unberechenbar abgekündigt werden, daher stelle ich mir die Frage, >wie die Zielgruppe für größere, schnelle Sram aussieht. Das ist ein absteigender Ast. Vielleicht noch für kleine uCs. Für ein neues Design mit einem FPGA würde ich keinen SRAM mehr nutzen.
>Dafür gibt es Caches in Form von BRAMs in FPGAs.
Ja klar. Aber wenn der Datenstrom keine großen Lücken hat, wo man den
Chache auch leeren kann, gibt es ein Problem.
Organisiern des dram wie ich oben schrieb ist bis jetzt meine Lösung
gewesen, weil DDRx ja nun mal preislich und von der Größe her erdrückend
ist.
Warum haben denn deiner Meinung nach viele Hersteller teils riesige
Srams im Program. Für paar Bastler sicher nicht. Abgesehen von packages
um die man als Bastler wohl einen Bogen macht.
Was ist deine Einschätzung?
@zu Gast (Gast) >>Dafür gibt es Caches in Form von BRAMs in FPGAs. >Ja klar. Aber wenn der Datenstrom keine großen Lücken hat, wo man den >Chache auch leeren kann, gibt es ein Problem. >Organisiern des dram wie ich oben schrieb ist bis jetzt meine Lösung >gewesen, weil DDRx ja nun mal preislich und von der Größe her erdrückend >ist. Auch dieses Problem ist lösbar. Anstatt wild verteilte Speicherzugriffe in einem kleinen SRAM zu machen, schreibt man linear, burstartig in einen deutlich gößeren SDRAM und speichert einfach Daten und Adresse. Das zurücksortieren kann man hinterher bzw. nebenbei machen, je nach Anwendung. >Warum haben denn deiner Meinung nach viele Hersteller teils riesige >Srams im Program. Für paar Bastler sicher nicht. Nein. Weil es nach wie vor diverse ICs gibt, welche sowas brauchen. Oder halt Nischenanwendungen, die den Aufwand eines SDRAM-Controllers scheuen bzw. nicht leisten können. Bzw. um alte Design weiter produzierbar zu halten (legacy support). Trotzdem ist das Marktvolumen der SRAM sehr klein im Verhältnis zu den SDRAMs. Echte, asynchrone DRAMs gibt es neu AFAIK gar nicht mehr.
Tja das ist so auch meine innere Sicht. Habe nur 2 Projekte mit DDR2 gemacht und da war halt einige Planung nötig, dagegen ist ein schnöder Sram verführerisch. Wenn der Zwischenspeicher im FPGA relativ groß sein muss, ist ggf. ja nur wegen dem Bram ein größerer FPGA nötig und da könnte ein teurerer Speicher ja auch gegen gerechnet werden. Bei Video ist das alles vermutlich schnigges. Darum hab ich meinen Hirnfurz gerne mal zur Diskussion gestellt. Es kann auch gerne hier weitergehen. Zu 100% ist mir aber der Markt jetzt immer noch nicht klar. Natürlich sind die Sram eine Niesche. Aber welche (alten) ICs aufeinmal MB-weise Sram brauchen (die gabs ja nun mal annu-knispel auch nicht) die sie früher nicht brauchten kann ich mir nicht vorstellen. Kann natürlich auch etwas sein wie breit aufgestellt sein... Postet gerne eure Meinungen, das interessiert mich.
Es gibt auch SD-RAMs, welche nicht DDR sind. Die sind in der Handhabung nicht ganz so ekelhaft wie DDR-RAMs. Siehe die meisten Terasic/Altera-FPGA-Boards.
@ Josef G. (bome) >Es gibt auch SD-RAMs, welche nicht DDR sind. Die sind >in der Handhabung nicht ganz so ekelhaft wie DDR-RAMs. Die haben aber das gleiche Problem, daß sie bei verteilten Einzelzugriffen ohne Burstbetrieb DEUTLICH langsamer werden. Und genau darum geht es hier.
Falk Brunner schrieb:
>Das ist ein absteigender Ast. Vielleicht noch für kleine uCs.
Ich habe auch schon darüber nachgegrübelt. Ich hätte auch gerne
externe SRAM für kleine µCs. Ich habe noch eine Schachtel voll
Zillog µCs ohne internen SRAM, nur wie anschließen? Früher
war das einfach, da hatten die µCs nach außen einen parallelen
Daten und Adressbus, bei den neueren µCs haben die Hersteller
so etwas nicht mehr vorgesehen, da müßte man das irgendwie
seriell machen. Ich weiß nicht ob es auch serielle SRAM gibt?
Serielle EEPROM gibt es ja.
@Günter Lenz (Gast) >so etwas nicht mehr vorgesehen, da müßte man das irgendwie >seriell machen. Ich weiß nicht ob es auch serielle SRAM gibt? Ja. Oder FRAM, der durch seine extrem hohe Anzahl an Schreibzyklen fast wie RAM benutzt werden kann. https://www.microchip.com/design-centers/memory/serial-sram-serial-nvsram Aber serielle RAMs sind noch kleiner und langsamer als SRAMs!
Amateur schrieb: > Soweit mir bekannt gilt die alte Regel: > SRAM = schnell = Platzintensiv (Silizium) = Stromsparender > DRAM = langsamer = Sparsamer beim Platz (Silizium) = mehr Energie > immer noch. Baue mal einen DDR3 Controller in einem FPGA und miss mal den Strom. Dann nimm ein SRAM, das nur gepulst betrieben wird und fast keine fabric logic braucht. Und?
Wenn man beim Lesen der Daten definierte Latenzen braucht, nimmt man SRAM. Die aktuelle Generation nennt sich QDRII: https://www.renesas.com/en-eu/products/memory/qdr-ddr-sram.html#productList Duke
Duke Scarring schrieb: > Wenn man beim Lesen der Daten definierte > Latenzen braucht, nimmt man SRAM. Die Latenz beim Lesen ist auch bei SDRAM definiert. Falls das bei Verwendung des Xilinx-Werkzeugs MIG nicht so sein sollte, liegt es nicht am SDRAM. Einschränkend hierzu: Es gibt PSRAMs, welche auch als SDRAM betrieben werden können, wo das bei dieser Betriebsart nicht gilt. Jedenfalls meine ich, im Datenblatt so etwas gelesen zu haben.
Ratgeber schrieb: > In welchen Fällen benötigt man das? Im meinem Fall war es eine Signalverarbeitung im Funkbereich. Josef G. schrieb: > Die Latenz beim Lesen ist auch bei SDRAM definiert. Ja, aber da kann Dir der Autorefresh dazwischenfahren. Oder wenn Bankswitching stattfindet, dann schwankt die Leselatenz auch. Klar kann man alles abfangen bzw. den Refresh durchführen, wenn er in den Kram passt. Dann baut man sein Design im Wesentlichen um die Eigenschaften des SDRAM-Controllers. Es hat halt beides seinen Preis. Duke
SDRAM kann wegen des refresh requirements nicht als nichtflüchtiger Speicher eingesetzt werden, batteriegepuffertes SRAM schon. In den Bereichen, in denen ich arbeite, gibt es Fälle, in denen Daten über ein (auch asynchrones) Reset heraus bestehen bleiben müssen, da hat ein SRAM schon noch seine Berechtigung. Aber es wird tatsächlich immer schwieriger, noch an Bausteine heranzukommen. FRAM sieht auch sehr interessant aus, ist allerdings nach momentanem Stand der Technik und des Preisgefüges noch keine realistische Alternative.
Duke Scarring schrieb: > Josef G. schrieb: >> Die Latenz beim Lesen ist auch bei SDRAM definiert. > Ja, aber da kann Dir der Autorefresh dazwischenfahren. Nein, den Refresh macht man zwischen den Zugriffen, zB. abwechselnd Schreib/Lese-Zugriff und Refresh. > den Refresh durchführen, wenn er in den Kram passt. > Dann baut man sein Design im Wesentlichen > um die Eigenschaften des SDRAM-Controllers. Man baut den SDRAM-Controller passend zum Design.
Es gibt diverse (Spezial)CPUs, die halt nur mit SRAM arbeiten. Garade im Bereich der Telekomumikation gab/gibt es da einige.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.