RAM device / timings for small VGA project

Question

For a personal hobby project I'm looking to make a small vga display using an fpga. I was thinking of making the display 640x480 pixels with one byte colour per pixel at 60hz (I believe those timings should work on any monitor?)

By my calculation that means I need to read 640*480*60 bytes from the ram every second which is 18432000 bytes per second giving a time per byte of a little over 54ns per pixel.

I'm looking at a device something like this for my memory.

http://uk.farnell.com/cypress-semiconductor/cy62128ell-45sxi/ic-sram-1mb-128kx8-5v-soic32/dp/1650060

The datasheet indicates that it has an access time of 45ns so by my understanding it should be fast enough for my fpga to read the data from it. But I'd have to update it during the period when no data is being displayed as it's not fast enough to complete a read and write in that time.

Are my calculations correct, and would such a device be suitable for using in this way? Or did I miss something?

Answer 1

Here's how I'd do it...

I would start with a Xilinx Spartan-6 FPGA. The reason I'd go with this is because they have "hard cores" for a DDR-SDRAM interface. By hard core, I mean that the circuitry for this memory interface is a dedicated chunk of logic and not in the normal "user programmed fabric of logic". This means that you're going to meet timing, and you don't have to write this logic on your own.

Next, I'd hook up some DDR2 SDRAM to the part. DDR2 SDRAM is fairly inexpensive, easy to get, and certainly fast and large enough for what you want to do. I'd start with a 16-bit wide data bus, and increase that if you need more speed. You can use the Xilinx CoreGen or Memory Interface Generator to get your DDR2 interface core.

The rest is "relatively easy", in that it's just moving data around and generating the proper sync pulses.

One major down-side to this approach is that you're basically limited to using BGA's for both the memory and FPGA. One plus side is that there are FPGA development boards that already have this circuitry on it.

Answer 2

You might be better with using the block RAM in a good FPGA as it will easily outperform the performance of external SRAM; also, if you want to make a PCB, routing will be crucial with 54ns clock times. Also, it looks to be only 5V; what FPGAs work on 5V? You'd need logic level translation, introducing delay into the processing.

I figure you need 300KB and FPGAs can have this amount of memory onboard.

Answer 3

I'd suggest using a 64Kx16 chip or two 128Kx8 chips; that would cut the required data rate in half, allowing alternating 40ns accesses between the display and the CPU. If you don't want to use a 16-bit data bus, and you don't mind limiting the speed of external CPU accesses slightly, you could still get the desired speed with a 40ns access time if the OE time is 20ns. Every twelve half-cycles of a 25MHz clock:

1. Output pixel 0-1 address.
2. Enable low-byte OE.
3. Latch pixel 0 data, disable low-byte OE, and enable high-byte OE.
4. Latch pixel 1 data and output pixel 2-3 address.
5. Enable low-byte OE.
6. Latch pixel 2 data, disable low-byte OE, and enable high-byte OE.
7. Latch pixel 3 data and output pixel 4-5 address.
8. Enable low-byte OE.
9. Latch pixel 4 data, disable low-byte OE, and enable high-byte OE.
10. Latch pixel 5 data and output CPU address.
11. Enable high or low-byte OE or WE.
12. Output data on bus (if write) or latch data at end of cycle.

This would allow remote CPU access at a rate of about 4MHz. Not instant, but not too bad.

BTW, if scrolling will be needed, it might be useful to have 960 bytes of memory hold the start address for each of 480 lines of display data. This would allow regions of the screen to be scrolled without having to move around lots of data.