RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease

[Mittens]

On Mon, 21 Mar 2011 14:11:54 -0000, PovTruffe <PovTache@gaga.invalid>
wrote:

"PovTruffe" <PovTache@gaga.invalid> a ĂŠcrit :
Hi,

Yet another newbie question:
Is SDRAM fast enough to generate a 720p or 1024p video stream (VGA or
DVI output) using a Spartan-3 or -3E FPGA ?

No response :-((
Maybe my question was not very clear. Let me paraphrase it:
What kind of RAM would you use for a video frame buffer (Spartan-3E) ?
Or would either type of RAM work ?

SDRAM most certainly is fast enough for frame buffering. Think low end PC
chipsets which borrow some of the main memory for the video processor.

If you are going to write the controller and from scratch, it will be so
much easier to use QDR SRAM (dual unidirectional port) instead.

 

[glen herrmannsfeldt]

PovTruffe <PovTache@gaga.invalid> wrote:
(snip)

OK but I have the freedom to choose whatever video size, rate, #
of bits I like.
If I can generate only a 100 x 100 pixel video at 10Hz, thats is fine.

One would assume you're not just reading or writing to the
DDR - you probably
need to do (at least one) of both a frame-buffer read, and
a frame-buffer write.
So 2X (at least) the BW requirements there. How are you going to pack
(20-bit, 24-bit, 30-bit and/or 32-bit?) pixel data
onto a (16/32/48/64 bit)
memory interface? Pack it, or throw away bandwidth?

You might look at some of the Digilent boards. The Spartan3E board
has on-board DDR, and a VGA connector, though only one bit per color.
(It should be possible to dither, though, otherwise only eight colors.)

There are other boards with FPGA, RAM, and VGA connector, too.

That will get you practice with the RAM interface. Then you
can start your own board design. The FPGA has pretty strong
drivers, the RAM might not be so strong, though with only one
module it should be fine. Many systems won't run at full
speed with all modules in place.

-- glen

 

[Joel Williams]

On 22/03/11 10:22 AM, glen herrmannsfeldt wrote:

PovTruffe<PovTache@gaga.invalid> wrote:
(snip)

OK but I have the freedom to choose whatever video size, rate, #
of bits I like.
If I can generate only a 100 x 100 pixel video at 10Hz, thats is fine.

One would assume you're not just reading or writing to the
DDR - you probably
need to do (at least one) of both a frame-buffer read, and
a frame-buffer write.
So 2X (at least) the BW requirements there. How are you going to pack
(20-bit, 24-bit, 30-bit and/or 32-bit?) pixel data
onto a (16/32/48/64 bit)
memory interface? Pack it, or throw away bandwidth?

You might look at some of the Digilent boards. The Spartan3E board
has on-board DDR, and a VGA connector, though only one bit per color.
(It should be possible to dither, though, otherwise only eight colors.)

There are other boards with FPGA, RAM, and VGA connector, too.

I second that - the Digilent Atlys is quite inexpensive (especially if
you're a student) and has four HDMI interfaces (two in, two out) and DDR2.

It all depends on whether this is a PCB and circuit design exercise or
an FPGA development exercise. If it's the latter, spending a couple of
hundred dollars on a professionally designed and tested board will save
you dozens of hours and a lot of frustration.

Trying to get high speed designs working on two layer boards can be a
complete waste of time when things just plain don't work and you have to
start again. A four layer board is actually considerably easier to lay
out for complicated designs and if you're not in much of a hurry, some
of the hobbyist orientated manufacturing services are incredibly cheap.
For example, http://dorkbotpdx.org/wiki/pcb_order charge $10 per square
inch with four layers, and that's for three boards. I'd seriously
consider doing this even if I was using the PQ208 package.

If you're interested in soldering BGA packages at home, have a look at
this project:
http://danstrother.com/2011/01/16/spartan-6-bga-test-board/ . It hasn't
yet been built, but if the reflow oven method works it would be very
easy to adapt this (open source) design for your uses, either by adding
a simple VGA output or an HDMI buffer.

Joel

 

[Gabor]

On Monday, March 21, 2011 7:08:32 PM UTC-4, PovTruffe wrote:

The original question is too ill-posed - I wouldn't take any "rule of thumb"
type response with respect to video - the numbers add up too fast.

OK but I have the freedom to choose whatever video size, rate, # of bits I like.
If I can generate only a 100 x 100 pixel video at 10Hz, thats is fine.

One would assume you're not just reading or writing to the DDR - you probably
need to do (at least one) of both a frame-buffer read, and a frame-buffer write.
So 2X (at least) the BW requirements there. How are you going to pack
(20-bit, 24-bit, 30-bit and/or 32-bit?) pixel data onto a (16/32/48/64 bit)
memory interface? Pack it, or throw away bandwidth?

Yes I am aware of the multiple accesses, read and write, that will be required.
Because of the PQ208 package the memory interface will probably be limited
to 16 bit. And some address lines may not be used as well. I am mainly worried
about the PQ208 high pin capacitance.

You should be worried about pin inductance in the PQ208. In
my experience these packages are not suitable for high-speed
I/O.

Reads and Writes at same time? - can you still guarantee "sequential access"
enough so you don't lose bandwidth efficiencies to the DRAM? Is there
anything else (a CPU?) using the DRAM too that throws this off?

I will probably include a CPU later and try to access the RAM as a learning
exercise.

To the OP - there's no "rule of thumb". Sit down with a pen and paper,
or excel spreadsheet, and calculate you're requirements.

I will do that later. I tryed to make it clear that for this project I do not have
the professional / engineering approach that most of you in this group are
used to. There are no predefined and rigid features for the board. I will just
choose a FPGA, throw a RAM and a few peripherals, then play with the board.
However the PCB will be designed as optimally as possible (shortest trace
lengths, equal length for buses, etc). Later things will become clearer and I will
get a much better feel about the capabilities of a FPGA. Because of the steep
learning curve, if I begin working with all the details, the board will never be
finished this year and I would probably run out of motivation...

The problem with starting with a flawed design just
to "finish this year" is that your board won't do what
you wanted, and then you could be more discouraged.

If you really want to use the large PQ package, you need to
resign yourself to using low slew-rate I/O because of the
horrendous ground-bounce in those packages (even when
using additional "virtual ground" pins).

Single data-rate Mobile SDRAM may be your best choice
because it can run at low clock rates and use only
LVCMOS levels. You won't find a pre-made MIG core
for it, though as you might for DDR memory types.
Writing your own Mobile DDR (also called lpDDR)
controller would be a good exercise as well. I
have used single data rate memories for a number
of video products including UXGA resolution video
capture. You can realize any data rate you need
by making the memory wide enough. It doesn't even
have to be a power of two width. The UXGA capture
board uses 48-bit wide memory which matches the
RGB 2-pixel-wide data stream.

Video buffering is an easier design than a general
purpose memory controller for fully random access.
My controllers usually have a minimum transfer of
one burst to each of the banks in the memory. The
bank overlap allows me to "bury" the precharge and
activate time and keep the interface streaming at
almost 100% of the peak rate.

Good luck on your projects.

-- Gabor

 

[rickman]

On Mar 21, 11:28 am, "PovTruffe" <PovTa...@gaga.invalid> wrote:

"maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> a crit :

No response  :-((
Maybe my question was not very clear. Let me paraphrase it:
What kind of RAM would you use for a video frame buffer (Spartan-3E) ?
Or would either type of RAM work ?

For any application you must calculate what size and speed of ram you
require. So for your application you must determine the memory bandwidth
and the size of memory needed to fit the data into the memory. You know
what your application is and the relevan parameters so you just need to
match those to the standard ram available. You may find that it is not
possible to with the fpga you want to use and you need to choose a higher
spec device.

Thank you for your response. However I was in fact expecting more a rule
of thumb response such as for example "SDRAM would probably work for
VGA resolution at 30Hz rate no more...".

I am still choosing the right components for my first FPGA design that is just
a learning project with no other specific purpose. If I can generate a video
stream thats fine, if not I will do something else (or lower the frame size,
refresh rate, etc).

The challenge is also to design a working Spartan-3 FPGA board with the
largest non BGA package and with only 2 layers. The risk of course is the
board will never work.

If you think about it for a moment, what do they use in PCs for frame
buffer memory? In all of the lower end systems they *share* the main
SDRAM based memory with the CPU. Video does not require a large
bandwidth compared to what SDRAM is capable of. Many years ago when
DRAM had a lower throughput they made special SDRAM which could load a
page from memory into a fast on-chip SRAM. This could then be shifted
out at very high rates to support very fast displays of 1200 x 1024.
Today displays are 2048 x 1152 and larger. SDRAM still works and
doesn't even need a special interface.

Rick

 

[rickman]

On Mar 21, 4:17 pm, gtw...@sonic.net (Mark Curry) wrote:

In article <8JKdnaSMPotTFxrQnZ2dnUVZ8qOdn...@brightview.co.uk>,



Phil Jessop <p...@noname.org> wrote:

"PovTruffe" <PovTa...@gaga.invalid> wrote in message
news:4d876ea8$0$19933$426a74cc@news.free.fr...
"maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> a crit :
No response  :-((
Maybe my question was not very clear. Let me paraphrase it:
What kind of RAM would you use for a video frame buffer (Spartan-3E) ?
Or would either type of RAM work ?

For any application you must calculate what size and speed of ram you
require. So for your application you must determine the memory bandwidth
and the size of memory needed to fit the data into the memory. You know
what your application is and the relevan parameters so you just need to
match those to the standard ram available. You may find that it is not
possible to with the fpga you want to use and you need to choose a higher
spec device.

Thank you for your response. However I was in fact expecting more a rule
of thumb response such as for example "SDRAM would probably work for
VGA resolution at 30Hz rate no more...".

I am still choosing the right components for my first FPGA design that is
just
a learning project with no other specific purpose. If I can generate a
video
stream thats fine, if not I will do something else (or lower the frame
size,
refresh rate, etc).

The challenge is also to design a working Spartan-3 FPGA board with the
largest non BGA package and with only 2 layers. The risk of course is the
board will never work.

For a full HD display running at 60Hz frame rate you need about 125Mpix/s x
24 or 30 bits. Easily within the lowest spec DDR SDRAM as you only need
sequential access. You can always up the bitwidth of the memory to increase
bandwidth if access time proves inadequate but obviously you'll need to
determine that at the outset.

The original question is too ill-posed - I wouldn't take any "rule of thumb"
type response with respect to video - the numbers add up too fast.

One would assume you're not just reading or writing to the DDR - you probably
need to do (at least one) of both a frame-buffer read, and a frame-buffer write.
So 2X (at least) the BW requirements there.  How are you going to pack
(20-bit, 24-bit, 30-bit and/or 32-bit?) pixel data onto a (16/32/48/64 bit)
memory interface?  Pack it, or throw away bandwidth?

Reads and Writes at same time? - can you still guarantee "sequential access"
enough so you don't lose bandwidth efficiencies to the DRAM?  Is there
anything else (a CPU?) using the DRAM too that throws this off?

To the OP - there's no "rule of thumb".  Sit down with a pen and paper,
or excel spreadsheet, and calculate you're requirements.

--Mark

This reminds me of myself many, many years ago when I was dying to
build a terminal from a TV and a variety of ICs. I read Don
Lancaster's book, "TV Typewriter Cookbook" that explained enough of
how it could work that I was able to cobble together my own design. I
think I actually designed it a dozen times on paper before I ever
constructed it. I did eventually get it built and modified a 12" TV
to use as the monitor. 64x25 characters! Back then my eyes could
actually see that.

I would suggest to the OP that he spend a lot of time reading about
other people's designs and do a lot of paper designing before he
builds anything. I learned a lot that way and I think there is a lot
he can learn before he is ready to build the device he is thinking
of.

Rick

 

[Hal Murray]

In article <im9c1r$ofe$1@news.eternal-september.org>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

Later, when I was in college, I had the idea of building
a bit-map display storing the data compressed, as memory was
still pretty expensive. As far as I know, no-one ever tried
that.

Compressed?

Back in the way old days, they had character generator ROMs.
The input (address) was the character code and the bottom bits of the
vertical line address. The output was the bit pattern for that chunk
of the horizontal line.

So instead of storing the dispalay screen bits, you stored the
characters on the appropriate grid.

--
These are my opinions, not necessarily my employer's. I hate spam.

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:
(snip)

This reminds me of myself many, many years ago when I was dying to
build a terminal from a TV and a variety of ICs. I read Don
Lancaster's book, "TV Typewriter Cookbook" that explained enough of
how it could work that I was able to cobble together my own design. I
think I actually designed it a dozen times on paper before I ever
constructed it. I did eventually get it built and modified a 12" TV
to use as the monitor. 64x25 characters! Back then my eyes could
actually see that.

I remember when the TV typewriter was a Radio-Electronics
magazine series. I was interested, but couldn't afford one.

Later, when I was in college, I had the idea of building
a bit-map display storing the data compressed, as memory was
still pretty expensive. As far as I know, no-one ever tried
that.

-- glen

 

[glen herrmannsfeldt]

Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:

In article <im9c1r$ofe$1@news.eternal-september.org>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

Later, when I was in college, I had the idea of building
a bit-map display storing the data compressed, as memory was
still pretty expensive. As far as I know, no-one ever tried
that.

Compressed?

Back in the way old days, they had character generator ROMs.
The input (address) was the character code and the bottom bits of the
vertical line address. The output was the bit pattern for that chunk
of the horizontal line.

No, I meant for bit map graphics. The idea at the time was
to do run-length coding for the bit map. Then decode each scan
line just before displaying it. Software would be needed to
update the display memory, and that might be complicated and slow.
(It would have been on an 8080 at the time.) It is a tradeoff
of memory vs. display logic, and complexity of the display.

I do remember stories about Versatec printers in bitmap mode
decoding compressed data while printing, but I don't know about
doing it each time through a video display buffer. I believe
HP PCL printers also store the page in memory compressed, and
then decompress while printing. There are some pages where the
decompression isn't fast enough, such that that part of the page
has already been printed. The printer prints it anyway, and in
the wrong place on the page.

Now, it used to be that vector graphics, which take up much less
display memory, were common. That doesn't fit with a TV
(or video monitor) display, though. Also, vector graphics works
a little better with a light pen.

-- glen

 

[PovTruffe]

"Mittens" <mittens@_nospam_hush.ai> a écrit :

If you are going to write the controller and from scratch, it will be so much easier to use QDR SRAM (dual
unidirectional port) instead.

The smallest QDR SRAM I could find on Digikey has a 165 pin BGA package !

 

[PovTruffe]

"rickman" <gnuarm@gmail.com> a écrit :

I would suggest to the OP that he spend a lot of time reading about
other people's designs and do a lot of paper designing before he
builds anything. I learned a lot that way and I think there is a lot
he can learn before he is ready to build the device he is thinking of.

This is what I have been doing for the past 2/3 months and still have
thousands of pages to study (hopefully aspirin and coffee are not that
expensive...). At some point I feel the need to get my hands dirty. I
already have experience with digital design though not at very high
speeds. Experience also in PCB design and I have some idea about
what is specific about FPGA layout design (I read about this too)
but with no practical experience on those devices yet.

 

[rickman]

On Mar 22, 2:26 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

Hal Murray <hal-use...@ip-64-139-1-69.sjc.megapath.net> wrote:
In article <im9c1r$of...@news.eternal-september.org>,
glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
Later, when I was in college, I had the idea of building
a bit-map display storing the data compressed, as memory was
still pretty expensive.  As far as I know, no-one ever tried
that.
Compressed?
Back in the way old days, they had character generator ROMs.
The input (address) was the character code and the bottom bits of the
vertical line address.  The output was the bit pattern for that chunk
of the horizontal line.

No, I meant for bit map graphics.  The idea at the time was
to do run-length coding for the bit map.  Then decode each scan
line just before displaying it.  Software would be needed to
update the display memory, and that might be complicated and slow.
(It would have been on an 8080 at the time.)  It is a tradeoff
of memory vs. display logic, and complexity of the display.

That would be an interesting idea. I suppose the hardware to do this
would not be complex. A simple counter would do the trick, but it
would have to run faster than the dot clock and there is plenty of
potential for the size to blow up with certain degenerate patterns
such as alternating 1's and 0's.

I seem to recall that most designers were more worried about improving
the quality of the display since they were often rather limited.
Heck, 1024x whatever was state of the art then. It was hard to find a
monitor that could actually show that level of detail.

I do remember stories about Versatec printers in bitmap mode
decoding compressed data while printing, but I don't know about
doing it each time through a video display buffer.   I believe
HP PCL printers also store the page in memory compressed, and
then decompress while printing.  There are some pages where the
decompression isn't fast enough, such that that part of the page
has already been printed.  The printer prints it anyway, and in
the wrong place on the page.

Now, it used to be that vector graphics, which take up much less
display memory, were common.  That doesn't fit with a TV
(or video monitor) display, though.  Also, vector graphics works
a little better with a light pen.

I was under the impression that the vector graphic displays came from
the CRT side of the design. That was the most efficient means of
displaying lines on the screen at the time and you could even use a
display that held the last image drawn so it didn't need to be
refreshed. This would allow the construction of images too slow to be
drawn in real time. Once the raster graphic hardware got to be better
quality and speed the vector hardware got pushed out rather quickly.
I guess the cost of the digital part of the hardware also had to come
down, but it wasn't like vector graphics electronics was cheap!

Rick

 

[Mittens]

On Tue, 22 Mar 2011 11:04:40 -0000, PovTruffe <PovTache@gaga.invalid>
wrote:

"Mittens" <mittens@_nospam_hush.ai> a ĂŠcrit :
If you are going to write the controller and from scratch, it will be
so much easier to use QDR SRAM (dual
unidirectional port) instead.

The smallest QDR SRAM I could find on Digikey has a 165 pin BGA package !

Presumably the FPGA you will eventually need will have many more balls
than that though.

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:

(snip)

No, I meant for bit map graphics.  The idea at the time was
to do run-length coding for the bit map.  Then decode each scan
line just before displaying it.  Software would be needed to
update the display memory, and that might be complicated and slow.
(It would have been on an 8080 at the time.)  It is a tradeoff
of memory vs. display logic, and complexity of the display.

That would be an interesting idea. I suppose the hardware to do this
would not be complex. A simple counter would do the trick, but it
would have to run faster than the dot clock and there is plenty of
potential for the size to blow up with certain degenerate patterns
such as alternating 1's and 0's.

I believe the idea was that display memory would be bytes with one
nybble the number of zero bits before the next one, and the other
the number of one bits before the next zero. I didn't get far into
the design before I got distracted by other things (like classwork).
Yes, it fails with many complicated displays. (The 4+4 bit allocation
is probably not optimal, either.)

I seem to recall that most designers were more worried about improving
the quality of the display since they were often rather limited.
Heck, 1024x whatever was state of the art then. It was hard to find a
monitor that could actually show that level of detail.

1024 required a pretty expensive monitor.

(snip)

Now, it used to be that vector graphics, which take up much less
display memory, were common.  That doesn't fit with a TV
(or video monitor) display, though.  Also, vector graphics works
a little better with a light pen.

I was under the impression that the vector graphic displays came from
the CRT side of the design. That was the most efficient means of
displaying lines on the screen at the time

Yes, but I believe that it was efficient use of memory that
drove the design. The first graphic display device I remember
is the IBM 2250, well described in a page in www.ibm1130.net,
and was introduced around 1965. I believe display memory was 4K,
but I don't know the word size (maybe 16 bits).

and you could even use a
display that held the last image drawn so it didn't need to be
refreshed. This would allow the construction of images too slow to be
drawn in real time.

The Tektronix terminals, using technology developed for storage
oscilloscopes. The problem was, you can only erase the whole screen,
once something is drawn. But pretty good for the time, allowing
complicated graphics without large display buffers. I believe using
analog circuitry to do line drawing.

Once the raster graphic hardware got to be better
quality and speed the vector hardware got pushed out rather quickly.
I guess the cost of the digital part of the hardware also had to come
down, but it wasn't like vector graphics electronics was cheap!

The analog electronics got a little cheaper over the years, as
economy of scale helped. The digital part got a lot cheaper,
especially large display memories. Also, raster display allows the
use of ordinary video monitors, instead of custom displays
(all the way to the CRT, which likely needed a long-persistance
phosphor.) For the 2250, the refresh rate slowed as the display
got more complicated.

Which reminds me of the story from the Boeing 777, the first
ariplane designed, as I understand it, entirely by computer.
The first comment from the designers when they saw an actual
airplane was how big it looked. (After seeing it on computer
displays for so long.)

-- glen

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:
(snip)

That would be an interesting idea. I suppose the hardware to do this
would not be complex. A simple counter would do the trick, but it
would have to run faster than the dot clock and there is plenty of
potential for the size to blow up with certain degenerate patterns
such as alternating 1's and 0's.

Oh, I forgot in my last post. Remember the Don Lancaster TV
typewrite used MOS dynamic shift registers for display memory.
512 bits (a lot for the time) in an 8 pin package. You have
to keep shifting or the bits go away. That was before affordable
RAM, either DRAM or SRAM. (Around the time of 1101 SRAM and
1103 DRAM.) The HP 9810A desktop programmable calculator uses
1103 1K bit PMOS DRAM.

In the 8080 days, the 2102 1Kx1 SRAM was popular, especially as
reliable DRAM boards were hard to find.

-- glen

 

[PovTruffe]

"Joel Williams" <nospamwhydontyoublogaboutit@nospamgmail.com> a écrit :

It all depends on whether this is a PCB and circuit design exercise or an FPGA development exercise.

Both.

Trying to get high speed designs working on two layer boards can be a complete waste of time when things just plain
don't work and you have to start again. A four layer board is actually considerably easier to lay out for complicated
designs and if you're not in much of a hurry, some of the hobbyist orientated manufacturing services are incredibly
cheap. For example, http://dorkbotpdx.org/wiki/pcb_order charge $10 per square inch with four layers, and that's for
three boards. I'd seriously consider doing this even if I was using the PQ208 package.

$10 - 4 layers ! Why did not you tell me this before ;-))
I thought prices were in the hundreds.

If you're interested in soldering BGA packages at home, have a look at this project:
http://danstrother.com/2011/01/16/spartan-6-bga-test-board/ . It hasn't yet been built, but if the reflow oven method
works it would be very easy to adapt this (open source) design for your uses, either by adding a simple VGA output or
an HDMI buffer.

Great link, this project is very interesting with many things to learn.

I did not realize Spartan-6 had such powerful features (like a mini Virtex...) for
the same price I would have paid for a Spartan-3E (6 input LUTs, hard DRAM
controller, etc).

After some research it seems BGA soldering is not as out of reach as I thought.
The hot plate method is very simple and seems to give very good results.
There are also refusion ovens on eBay under $300.

At the end, I changed my mind and decided to go "BGA / 4 layers / Spartan-6"
Many thanks to all who gave their usefull advice.

 

[PovTruffe]

"Gabor" <gabor@alacron.com> a écrit :

On Monday, March 21, 2011 7:08:32 PM UTC-4, PovTruffe wrote:
You should be worried about pin inductance in the PQ208. In
my experience these packages are not suitable for high-speed I/O.

OK

The problem with starting with a flawed design just
to "finish this year" is that your board won't do what
you wanted, and then you could be more discouraged.

It seems I would better submit the project here before doing anything...

If you really want to use the large PQ package, you need to
resign yourself to using low slew-rate I/O because of the
horrendous ground-bounce in those packages (even when
using additional "virtual ground" pins).

I did not know the PQ packages were that bad.

Single data-rate Mobile SDRAM may be your best choice
because it can run at low clock rates and use only
LVCMOS levels. You won't find a pre-made MIG core
for it, though as you might for DDR memory types.
Writing your own Mobile DDR (also called lpDDR)
controller would be a good exercise as well. I
have used single data rate memories for a number
of video products including UXGA resolution video
capture. You can realize any data rate you need
by making the memory wide enough. It doesn't even
have to be a power of two width. The UXGA capture
board uses 48-bit wide memory which matches the
RGB 2-pixel-wide data stream.

Video buffering is an easier design than a general
purpose memory controller for fully random access.
My controllers usually have a minimum transfer of
one burst to each of the banks in the memory. The
bank overlap allows me to "bury" the precharge and
activate time and keep the interface streaming at
almost 100% of the peak rate.

Good luck on your projects.

Thank you

> -- Gabor