Shared Memory Interface Controller für LPDDR3

[Tim T. (tim_taylor)]

Nabend,

ich bin aktuell dabei einen Memory Controller für LPDDR3 zu bauen, 
genauer gesagt für einen MT46H8M32LFB5-6 Chip. Der Speicher soll als 
Framebuffer dienen der mit einem Pixeltakt von ~150MHz ausgelesen wird. 
Durch die relativ simple Art wie VRAM benutzt wird, wird der 
Speichercontroller eigentlich auch überschaubar vom Aufwand her.
Jetzt stehe ich aber vor dem Problem, dass ich von den 32 MByte in dem 
Modul nur einen Bruchteil als Framebuffer brauche und den Rest 
eigentlich auch als RAM für sonstige Aufgaben nutzen könnte, der 
Controller dadurch aber deutlich aufwändiger werden würde.

Darum also meine Frage, würdet ihr das machen (und einiges an Mehrarbeit 
in den Controller investieren) oder lassen weil es doch zu viele 
Probleme nach sich zieht? Oder noch besser, hat jemand von euch das 
schonmal versucht (erfolgreich)?

[Thomas W. (diddl)]

Das Problem ist halt, der Framebuffer muß kontinuierlich gelesen werden.
Im Betrieb auch oft beschrieben.
Das kostet Bandbreite und das bremst die Nutzung des Restspeicher.

Warum nicht ein eigenes SRAM als Framebuffer verwenden?

Der Controller kann ja dann "nach oben" wie ein Speicher aussehen.

[Strubi (Gast)]

In den Blankzeiten kann man die Bandbreite gut für Cache-Bursts ins 
Instruction-Cache verwenden, ist halt sehr Architektur-spezifisch und 
bei komplexen OS ne Bremse.
Der Logik-Aufwand wäre da nicht immens.

[Tim T. (tim_taylor)]

Thomas W. schrieb:
> Das Problem ist halt, der Framebuffer muß kontinuierlich gelesen werden.
> Im Betrieb auch oft beschrieben.
> Das kostet Bandbreite und das bremst die Nutzung des Restspeicher.
Genau das ist das Problem an der Sache, als VRAM ist es sehr einfach, da 
kann man auch gut mit einem 8er Burst arbeiten und in einen Fifo 
puffern. Da ich den RAM einfachheitshalber mit Pixelclock laufen lassen 
will (147MHz vs 166MHz, macht da den Braten auch nicht fett) bekomme ich 
so (nach dem initialen Overhead) ja 2 Pixel pro Takt und hab 
dementsprechend schnell den Fifo befüllt, danach hab ich dann genug Zeit 
für Schreiboperationen ins VRAM und das Refreshen. Eine Zeile beim 
Bildaufbau hat 2256 Pixel, davon 1680 sichbar und 576 im Blanking. 
Während des sichtbaren Bereiches kann ich durch Nutzung aller 4 Bänke 
rechnerisch knapp eine komplette Zeile lesen und auch in einer anderen 
Row neu schreiben, dazu kommt noch der Autorefresh und es bleiben mir 
über 500 Takte für Anderes im Blanking jeder Zeile übrig. Alternativ 
könnte ich auch das komplette Refreshen (4096 * 72ns = ~295µs) ins 
vertikale Blanking (~567µs) legen.

> Warum nicht ein eigenes SRAM als Framebuffer verwenden?
Die Boards sind fertig und keine Neuentwicklung, geht nur um die 
Weiterverwendung von sehr billigem altem Zeug. Ansonsten hätte ich nicht 
freiwillig DDR Speicher für den Framebuffer genommen.

> Der Controller kann ja dann "nach oben" wie ein Speicher aussehen.
Das ist gar nicht erforderlich, es ging mir nur darum nicht 2/3 des 
Speichers sinnlos zu verschwenden. Für das was mir spontan damit 
einfällt, sollte der vorhandene BRAM als Systemspeicher erstmal 
ausreichen.


Strubi schrieb:
> In den Blankzeiten kann man die Bandbreite gut für Cache-Bursts ins
> Instruction-Cache verwenden, ist halt sehr Architektur-spezifisch und
> bei komplexen OS ne Bremse.
> Der Logik-Aufwand wäre da nicht immens.
Stimmt, die Idee da noch einen Cache dazwischen zu setzen dürfte es 
deutlich entschärfen. Müsste dann eigentlich nur dafür sorgen das 
Sprünge innerhalb der entsprechenden Page bleiben oder den Speicher nur 
für Daten verwenden um das Problem zu umgehen.

Danke.

[S. R. (svenska)]

Tim T. schrieb:
> Alternativ könnte ich auch das komplette Refreshen
> (4096 * 72ns = ~295µs) ins vertikale Blanking (~567µs) legen.

Eventuell kannst du dir den Refresh auch komplett sparen, wenn du das in 
den Lesezugriffen vom Framebuffer mit unterbringst. Bei DRAM sind 
Lesezugriffe immer destruktiv, daher geht das. Das spart dann auch 
Bandbreite. Einige Computer machten das früher so.

[Tim T. (tim_taylor)]

S. R. schrieb:
> Tim T. schrieb:
>> Alternativ könnte ich auch das komplette Refreshen
>> (4096 * 72ns = ~295µs) ins vertikale Blanking (~567µs) legen.
>
> Eventuell kannst du dir den Refresh auch komplett sparen, wenn du das in
> den Lesezugriffen vom Framebuffer mit unterbringst. Bei DRAM sind
> Lesezugriffe immer destruktiv, daher geht das. Das spart dann auch
> Bandbreite. Einige Computer machten das früher so.

Generell muss man dafür nicht mal einen Read machen, das aktivieren der 
Row auf der entsprechenden Bank reicht dafür aus. Wenn ich den RAM nur 
als Video Speicher nutze, würde das durchaus reichen, weil der 
entsprechende Bereich oft genug aktiviert wird; nur wenn ich es auch als 
Systemspeicher nutzen will, muss ich dann doch refreshen.