Basys 2 VGA generation - where to store image for rendering

[Josef]

Hello everyone,

I am a little newbie to generating VGA from any development kit, today I made a simple VGA image generation working on Basys 2 board with Spartan 3E-100. In code I'm currently using construction with IF sections for setting pixel colors at the required coordinates, but I think that this is not the best practise, because images is in this case programmed like in a ROM... So I would like to ask what is the best practise for storing images in Spartan 3E-100 next intended for displaying by VGA? I would prefer to have one component driving displaying to VGA from something like a buffer what can be modified outside of VGA component by pixels. My first idea was design own video RAM to FPGA in VHDL, but idea has failed after I waited for synthesis like a 20 minutes and nothing happened then I read some forum questions on RAM on FPGA and CPLD and I guess that 300 kB RAM (640x480 pixels represented by 1 byte per pixel) I am not able to achieve on Spartan 3E-100, am I correct? The next idea was use some external SRAM like AS6C4008 from Alliance Memory, but problem I think is on access time, because pixel clock 25 MHz is 40 ns and AS6C4008 access time is 55 ns, so I think that this is not a solution either. Last idea I have use on-chip RAM memory on FPGA, but currently I don't know whether is this idea correct and also how is correct way to use on-chip RAM on Spartan 3E and where I say to ISE that on-chip RAM I'm going to use in my design. Can anyone tell me whether my last idea can be realized or is also out of bounds and what is the best way to doing something like a video RAM or video array for VGA? Thank anyone in advance for reply. Best regards, Josef

[xc6lx45]

Hi,

the 3E-100 has 72 kBits of block RAM so using it for graphics memory won't work directly. What you could do is reduce the resolution to prove the concept.

Another approach (if that works for you) is text-based video generation. You can still do minimal graphics by redefining some unused characters.

Check the attachment to this post.

https://forum.digilentinc.com/topic/8905-spi-tft-display/?do=findComment&comment=26974

[D@n]

@Josef,

I had roughly the same problem on the Basys3 board: there wasn't enough on-board RAM for a frame buffer.  I chose one solution, and have since discovered others who have used two other solutions.

1. My solution was to store the image in flash.  Since the flash was only questionably fast enough to drive a 25MHz pixel stream, I compressed the images using both a small number of bits per pixel (expanded with a programmable colormap) and run-length encoding.  This worked great for static images and even a business slide show.  If you are at all interested in this approach, one of the keys to my success was the VGA simulator.  You can find an article discussing both how it works and how to use it here.
2. I know others (at Digilent even!) have created a sprite-based capability.  This allows video generation as part of a pipeline that "adds" items to the display as it moves through.  In this manner, there were able to build things like pacman without using a frame buffer.
3. A third approach that I've thought of using is to purchase some HyperRAM.  One-bit squared is selling a HyperRAM that takes two PMod ports, yet gives you access to higher speed memory than your Basys2 will likely be able to use.  (You can slow it down, though, and still use it)  The logic to drive a HyperRAM isn't all that complex, and so quite doable.

Hope this helps,

Dan

[Josef]

Hello,

thank you for your answer. I found also SDRAM IS42S16400J from Integrated Silicon Solution Incorporated. This memory has access times few nanoseconds (max 10ns). Do you think that this could be the way?

Thank you in advance for your response

Josef

[Josef]

@D@n

Thank you for your response. I like your 3rd idea, so the solution generaly can be using a DDR memory, is it right? And what SDRAM as I mentioned above, could be also useful?

Best regards

Josef

[D@n]

@Josef,

If you've never built an SDRAM controller, it can be a challenge.

The HyperRAM interface is a bit simpler to use, and the performance is just as good if not better.

Dan

[Josef]

@D@n

Ah, in implementing memory controllers I don't have any experience, so it can be challenge implementing also SRAM controller and I think also DDR controller (I'm afraid of sensitivity both clock edges what I currently can't imagine how I will implement something like this). At SDRAM I only looked for access times. I have last question about generating VGA image. Can HyperRAM on two PMODs works on higher resolution? Space I think have enough (I think 8 MB), able working on 100 MHz, so resolution 1024x768 256 colors will be also possible also on Basys 2 with increase of pixel clock, am I right?

Best regards

Josef

[D@n]

@Josef,

I've gotten burned too often by trying to do math in public and getting it wrong, so forgive me if I don't comment on what is and isn't possible for a given clock rate.  The HyperRAM Pmod I cited above can handle one 16-bit transaction every 10ns once you get it going.  Not sure if that gets you what you need or not.

I will say that DDR controllers can be quite hard, SDRAM is complex but (eventually) quite doable, and SRAM and HyperRAM are both easier.

Dan