(d)ram interface

Usually DRAM used for video buffers is accessed enough that it doesn't need any refresh cycles. Otherwise, SRAM is probably easier.

-- glen

It might be better to use one of the fpga's which have built in sram and save yourself a lot of problems.A full dram interface is quite complex and sdram interface is a major design.

I doubt there's be enough internal SRAM for a frame buffer of any great size, except maybe in the really big devices!

DRAM isn't that hard and neither is SDRAM. I did one as my first major bit of FPGA work. With the help of the micron datasheets and VHDL models I made one to do just what I wanted - which was also for video, so had no refresh! After lots of simluation, the first synthesized version Just Worked, which surprised me (even though that's how it's supposed to work :-)

Cheers, Martin

--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

If you can't find SRAM lying around, or don't have enough I/O pins to handle the non-multiplexed address, I'd suggest SDRAM first for ease of use, however if you're not up for a real challenge stay away from DDR parts. Older asynchronous DRAM has a relatively simple interface, but you may find it hard to operate at a reasonable rate for video buffer unless your data bus is quite wide. I've used SDRAM at 100 MHz with little difficulty in meeting timing on Virtex (not Virtex II) and Spartan II in the slowest speed grades. DDR SDRAM can halve your data bus width but it is a challenge to meet timing even at 100 MHz unless you go to a more recent part with DDR registers in the IOB. Not to mention the headache of SSTL_II and its termination and reference voltage requirements, and 2.5V Vccq... Generally I don't use any standard IP for the SDRAM control, but roll my own state logic for the job at hand, which in video buffers is usually streaming input and output with dedicated bandwidth for each (much simpler than general random access). I haven't tried using CPLD's for this, but the state logic is not huge so I imagine it could fit in one. Most of my designs are IO limited in even small FPGA's. If your SDRAM has excess bandwidth, a simple approach to control is to have a constant "superstate" length, say 21 clock cycles which would perform either 16 writes (burst to each of 4 banks),

16 reads, or > "Jezwold" writes:

sram

synthesized

One can build a nice 24Rx64C text VGA controller including a 96 character

5x8 (out of 6x10) pixel character generator ROM in a single18 kbit BRAM; or >40Rx80C + char gen ROM in two BRAMs -- and a few tens of LUTs. This makes a great SoC debugging aid yet consumes as few as 3 I/Os (hsync_n, vsync_n, pixel).

Jan Gray