# Is 55ns SRAM fast enough to drive low resolution VGA?

I can't seem to wrap my head around the math.

Assuming I want a 640x480x256 VGA signal, and I had an FPGA or fast micro-controller to drive it, would 55ns be able to handle it?

Meaning each byte of the 8-bit memory would translate to one pixel. Also assuming my R-2R ladder was setup to something like RRRGGBBB.

I have a very specific reason to use DIP SRAM. I can find speeds down to about 15ns but small sizes. The 512k I want to buy tops out at 55ns.

If someone could give me examples of how the bandwidth is calculated, it might help me decide to use the 512k or maybe do something different with multiple 15ns chips.

Thanks!

• Don't weigh against green; results will be very grainy. – Ignacio Vazquez-Abrams Nov 23 '16 at 21:27
• Pixel clock for 640x480 resolution is ~31MHz. Start from it. – Eugene Sh. Nov 23 '16 at 21:28
• That was just an example. For my specific needs, I will probably use something like RRGGBBxx (xx = ignore) or maybe RRGGBBIx where I = intensity. – cbmeeks Nov 23 '16 at 21:28
• Remember you can interleave more than one RAM chip for faster access. – Brian Drummond Nov 23 '16 at 21:33
• 640x480x60Hz uses a 25 MHz pixel clock so you'd need 1 byte every 40 ns (for 73 % of the time). You also want to be able to write display data to your RAM so let's assume we want two RAM byte accesses in that 40 ns: one to read and display a pixel, one to R/W display data. So you can either buy faster RAM or wider RAM. A 32-bit wide RAM using 55 ns chips could serve up four bytes in one 60 ns read and they'd last 160 ns. This illustrates the arithmetic, you can explore the permutations further. Hope this helps :-) – TonyM Nov 23 '16 at 22:15

640x480x60Hz uses a 25 MHz pixel clock so you'd need 1 byte every 40 ns (for 73 % of the time).

You also want to be able to write display data to your RAM so let's assume we want two RAM byte accesses in that 40 ns: one to read and display a pixel, one to R/W display data.

So you can either buy faster RAM or wider RAM. A 32-bit wide RAM using 55 ns chips could serve up four bytes in one 60 ns read and they'd last 160 ns.

This illustrates the arithmetic, you can explore the permutations further. If you're using an FPGA, you can do some clever prefetching stuff to burst-read multiple dwords and get more R/W slots in between them.

$${1 \over 55 \text{ ns} } = 18 \text{ MHz}.$$

640x480 @ 60 Hz VGA uses a pixel clock of 25.175 MHz, so there's no way you can drive that from a 55 ns SRAM. If you can't find a large enough 15 ns SRAM, you can group a couple of them together with an address decoder.

• No address decoder, just a larger data bus. – TEMLIB Nov 23 '16 at 23:10

Yes, you can do it, but not (exactly) easily. As has been pointed out, 640x480x60 VGA requires a 25 MHz clock rate, or a 40 nsec access/cycle time. So, if you're in this all the way with your 55 nsec chips, is to use two of them. If you look at your pixels as being either odd or even (lsb of address being 0 or 1) it's clear that you can provide read addresses at 12.5 MHz while reading 2 bytes per clock, then driving the display at 25 MHz. Something like

simulate this circuit – Schematic created using CircuitLab

Note that, since there are now physically 2 ICs, they only need to be 256k.

Also, please keep in mind that writing to your RAM will cause display noise, since the display will pick up the write data as display data. Since you are doing pixel-level RAM control, rather than character, you will need to do a lot of writes, and therefore will have a lot of screen noise.

You need to know the pixel rate. Using raw calculations for a 640x480 image including blank pixels, the VGA frame size could be 800x525. Since you are not going to use any intermediate buffers, your pixel rate @60fps must be 800x525x60 = 25.2MHz. That's a pixel rate.

Now, depending on the standard, like RGB or YUV4:2:2, and the bit depth (like 8bit), you will need 24bit and 16bit per pixel (3bytes and 2bytes respectively). Thus, your byterate is tripple or double of the pixel rate.

In your case, you need to supply the each byte of data at 25.2MHz, whereas your 55ns memory can do it at ~18MHz, and 15ns can do it at 66MHz.

640x480 a 1 byte per pixel at 30 frames is 9.2Mbytes/sec (640 x 480 x frame rate x bits per pixel), or to put it another way, with an 8bit data bus, 9.2Mtransfers a second. Now, you also need to be able to write that data into the ram equally fast, so that makes 18.4MT/s. 1/18.4MT = 54ns per transfer, right on the limit.

However, if you run at 25 or 20fps, you should be just fine as that would only need a cycle time of 65 and 81ns respectively which your 55ns SRAM should be able to handle comfortably.

You can always use two SRAMs together as a 16bit bus (you'd be reading two pixels at once instead of just one) this cuts your speed requirements in half but adds a bunch of extra pins.

• This is incorrect, because real VGA signal has also some blanking times between lines. I mean the real pixel speed is higher. It's approximately 25 MHz, as duskwuff or TonyM already pointed out. – Al Kepp Nov 23 '16 at 22:29
• Unfortunately you've tried to average the data rate per second and get a lower number. It's the peak transfer rate that's important. There'll be a lot of pixel reading then a pause between lines and at screen end. They could read a line slowly and buffer it in fast FPGA RAM and all sorts. But in truth, use the pixel clock period as the byte access period and then there's spare needed for display data R/W, as you say. – TonyM Nov 23 '16 at 22:37
• Yeah, you're right, I kept thinking it was an LCD for some reason (where the update rate is a bit more arbitrary) I think it's time I went to bed before I give out any more bad advice – Sam Nov 23 '16 at 22:40