2
\$\begingroup\$

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?

\$\endgroup\$
  • \$\begingroup\$ Due to the actual signals required (H-Sync, V-Sync), you'll find that your system will need to run at just over 25 MHz. This means that your period for memory fetch is going to be about 39ns. \$\endgroup\$ – W5VO May 6 '11 at 14:52
  • \$\begingroup\$ Why do you want to store 60 frames in memory? Approaches that I have successfully used only have two frames - a current frame and then the next frame. That big of a memory requirement will be expensive ($20+) \$\endgroup\$ – W5VO May 6 '11 at 15:06
  • \$\begingroup\$ I don't . I want to store one frame in memory. I have to retrieve it 60 time a second though.... looks like this project isn't practical in this form for me right now anyways \$\endgroup\$ – John Burton May 6 '11 at 15:35
  • \$\begingroup\$ Ahhh.... that makes more sense \$\endgroup\$ – W5VO May 6 '11 at 16:19
2
\$\begingroup\$

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.

\$\endgroup\$
5
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Ah yes the link was to an example of the sort of device, not the exact one I'd use. 5v clearly isn't correct.... Yes fpga's can have this amount of memory but I was hoping to use a small one for this. And yes it's just occured to me that at this speed it's likely that an "amateur" designed PCB probably will have issues.... Hmmm \$\endgroup\$ – John Burton May 6 '11 at 10:08
  • \$\begingroup\$ @Thomas O 640x480x24bits = about 7.4 mbits. That works out to about 450 block rams (16kbit BRAM's). That's not going to fit inside any FPGA that we have a budget to buy. \$\endgroup\$ – user3624 May 6 '11 at 15:26
  • \$\begingroup\$ @Thomas O I might have misread the question. He said "One byte color per pixel", which I interpreted as one byte for red, one byte for green, and one byte for blue. If it is 1 byte per pixel, total, then he'll need about 2.5 mbits of RAM, or 150 block RAMs. That's still a huge amount of BRAM's, but doable in a medium sized FPGA. \$\endgroup\$ – user3624 May 6 '11 at 15:36
  • \$\begingroup\$ @David Kessner, I interpreted it as one byte per pixel, in other words some kind of byte stuffing like RRRGGGBB. \$\endgroup\$ – Thomas O May 6 '11 at 15:46
  • \$\begingroup\$ Worth mentioning is that according to DigiKey, 2.5+ mbit FPGA's only come in BGA packages - this may be a non-starter \$\endgroup\$ – W5VO May 6 '11 at 16:18
2
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.