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