VGA controller and accessing external SRAM

[BlackHelicopter]

I'm having trouble understanding how I would implement this. I would like to use external SRAM as a frame buffer for an SVGA video controller (800x600@72 Hz) which has a pixel clock of 50MHz. The trouble is that the read operation for the SRAM controller I've made takes two (50MHz) clock cycles to complete. Now I'm not quite sure how to get this to work. I'm guessing that I'll need to speed up the clock of the SRAM controller to 100MHz by implementing a DCM or maybe improve the controller to read in one clock cycle, but I just wanted to make sure that there's not a 'smarter' way to do this and keep the existing setup and modify things a bit. I've read about line buffers but I'm not sure I fully understand how they work or if one would apply here. To me it sounds like a line buffer is used to transfer data from a faster RAM controller to a slower video controller and buffer a line or multiple lines of video data. Is this true? I guess I don't quite understand the concept. Anyways, thanks for any help!

btw I forgot to mention the RGB data is 12-bits wide (4-bits per color) and the SRAM data bus is 16-bit.

 

[mrflibble]

The trouble is that the read operation for the SRAM controller I've made takes two (50MHz) clock cycles to complete.

Since you didn't explicitely mention how these two cycles are built up ... can you pipeline it?

Latency of 2 clocks to get you data is not a problem, as long as you can keep reading at 1 transaction per clock sustained throughput.

And if not, you can maybe interleave 2 of those srams, and then instantiate 2 sram controllers. Is the 2 clock cycle delay a function of your sram controller design? Or is it because of the specific sram you use?

And if you are reeeeeally desperate you can do a tradeoff in color depth, for example RGB = 3+3+2 per pixel. That way you get 2 pixels for your 16-bits. Probably not what you want, but hey I said if you are really desperate. ;-)

Anyways, if this is in an fpga then by all means run your sram controller at 100 MHz with your DCM-ed clock as you suggested. Problem solved.

 

[TrickyDicky]

Its all a question of bandwidth. If you're using a frame buffer, a single sram, and your pixel clock is 50Mhz, then you can write at this speed, but you'll never have enough time to read it again, which would be pretty uselss. To solve this you need to double the bandwidth. Either you double the clock or more (so you can get twice as much data into or out of the ram) or double the number of rams (meaning you have another interface). With this second one, you can use a swing buffer approach so as you're writing to one memory you read from the other, so you never get any contention.

With a single SRAM, you will probably need some form of FIFO or buffer (a line delay you talk about) to ensure you avoid contention. Because, like you say, you have a 2 clock delay for a read, you'll probably want to read an entire line at a time to make sure you're not constantly holding up the memory access switching from reads to writes. Like mrflibble said - its only a pipeline delay, so if you read a whole line at a time, you're only "waiting" for 2 clocks. If you keep swapping from reading to writing, you're waiting 2 clocks for every read, wasting a lot of time accessing the memory. So because you're reading a whole line, you need to buffer a whole line at the write side. So when the write buffer is getting full, you can dump it to memory (remember its running at 2x input speed so you'll empty it faster than it can fill).

 

[BlackHelicopter]

Thanks for the help guys,

Mrflibble, the 2 clock-cycle delay is a function of my SRAM controller, the actual part is an IS61LV25616-10, so the read cycle time is 10ns, which should allow for a faster SRAM controller design. There's quite a bit of margin in the current design it seems, so one transaction per clock should be feasible. This seems like a good first step.

The board I have has one device of SRAM, SDRAM, and FLASH; so I do have other memory available if necessary for a 'swing buffer', I never would have thought of that.

TrickyDicky,
When I have two separate line buffers like you suggested, one for read and one for write, I believe I just need to determine appropriate times to fill and empty the buffers correct? I'd imagine for the memory read buffer I'd start filling it during the active region (or before?), and for the write buffer I'd empty it near the end of line or front porch? ..or maybe am I making this harder than it really is.. (it's late here and I'm a little tired )

Thanks for the help again!

 

[TrickyDicky]

the read buffer you would fill in enough to so that your output has it ready in time, and the write buffer probably written at the end of an active line - yes.