I am planning a low key game console for my own leisure, based on the VGA signal. I have implemented parts of it on breadboards with lots of wires, but it is very error prone, thus my move to the FPGA world.


  • Resolution around 240 columns x 240 lines and 8 bits / pixel.
  • Double Buffering for smooth animations.
  • Micro nova mercury FPGA board (XC3S200A) and 512 KB external SRAM.


What is the best way for implementing the double buffer ? The SRAM device would be a problem when continuously accessed from the signal generator part since it would lock out the writer part for setting pixels. The blanking periods are too short for doing this.

If I would go down with the resolution (132 x 132 @ 8 bpp) I could use the block RAM (288 K bits or 36.000 Bytes). Are there any disadvantages or problems which I don't see yet, when using up the block RAM for such an application ?


  • \$\begingroup\$ Do you really want to invent bicycle? There's a number of 8-bit console / home PC standards you can reuse, which have vast software base. Are you going to write software for your new development yourself? \$\endgroup\$
    – Anonymous
    Oct 10, 2016 at 9:58
  • \$\begingroup\$ You could look to using a block RAM as a pixel buffer and blast that out to the SRAM during blanking periods, to really speed things up, you could use 2 block RAMs, one for the address and another for the actual pixel value. You could use these as FIFOs to help cover up the gaps of not being able to write during active display \$\endgroup\$
    – Pyrohaz
    Oct 10, 2016 at 12:49

1 Answer 1


The external SRAM on the MicroNova Mercury board is a fast one — 10 ns nominal speed — so there should be no problem accessing it at 50 MB/s (or more). You could easily read out a full VGA signal at a raw rate of 25.175 MB/s and still have half of the memory bandwidth available for writes. Of course, the SRAM does not have enough room for two 640×480×8 bits buffers, so you'll have to cut back somewhere. If you do 320×240 @ 60 Hz, you'll only need to read out 4.608 MB/s on average, leaving more than 90% of the memory bandwidth for pixel writing and other purposes.

I see no need to use internal BRAM for pixel buffering; it's a resource that you will find much more useful for other things, such as implementing the controller(s) that will be running the game logic and drawing the pixels.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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