Video buffer/rate matcher

[Altera_Forum]

A picture is worth a 1000 words. 

  what am I looking for ?? SDRAM, VRAM, SRAM, RAMmyhead, should I be looking for ?? My implementation is what is called a ''data buffer'', all data is write and read sequentially.   Just for clarification, when I say write, RAM memory sends current frame to MCU, when I say read, DVI receiver is sending frame to RAM.   Important****I just need one that allows me to write from the chip with a lower frequency writing clock wich will be given by the MCU   I believe FIFO are not deep enough since my write out speed will be almost 20 times less at times. lets say a frame of dvi is 3.93 Mb, (1280*1024*3 bytes), so 3 930 000/24 = 163.75 Kb, each stream of parallel data needs to be near 160Kb deep.   I am just using this as a data rate matcher, my MCU cannot handle the speed of even the lowest resolutions of DVI since many real time calculations are done with the color.   Overflow and lost frames are of no importance, It would be great to start writing out the frame more slowly as it is still being read, but I have no problem just writing out a completed frame, processing with MCU then, clear memory and start read and latch to next new frame.   I hope everybody understand what I am trying to accomplish ??   Best regards, Simon

[Altera_Forum]

From what I gather, I could use some asynchronous SRAM and a memory controller that works in a sequential way. Or I could use some Flow through synchronous RAM, still reading on these. 

 The best way, simplest would be deep FIFO, but those chips are 50$  There is no sequential access memory that is 32 bit wide, si I have to overcomplicate things with random access memory and control it sequentially.  Anybody agree with this solution ??

[Altera_Forum]

If you were going to go the Qsys/SOPC way of things, any type of external memory combined with the Altera Video and Image Processing suite IP components (Clocked Video in/out, Frame Buffer blocks) would work.

[Altera_Forum]

Option 1: a medium/large FPGA will have enough internal RAM to hold a frame. 

 Option 2: external RAM. Weather they're asynchronous SRAM, synchronous SRAM or DRAM, eventually you'll end up having a controller interface with abstracts away the RAM type and just lets you read/write into them.  If you're rolling your own logic, internal RAMs may be simpler to use, as they're true dual ported and can have any width you need. Even after the controller, external RAMs will give you a most strict interface to work with. But as Ted said, if you're using Qsys/SOPC, there are blocks to abstract it all away for you.