how to reduce vga memory????????

hi..
      i m using spartan-2 ......... and have designed a very simpl
vga controller on it ...... now i wanna interface an external ra
with it .......... i m available only a sram of 32 kbit * 8 = 256 k
memory which is not dual port.......
              i wanna store 640*480 pixels data on it ... as i nee
only 8 colors ...so 3 bits for each pixel ...
              is it possilble to reduce memory to make according t
desired requiremeents ........ and to use it although it is not dua
port ..

fahadislam2002 wrote:

>       i m using spartan-2 ......... and have designed a very simple
> vga controller on it ...... now i wanna interface an external ram
> with it .......... i m available only a sram of 32 kbit * 8 = 256 kb
> memory which is not dual port........
>               i wanna store 640*480 pixels data on it ... as i need
> only 8 colors ...so 3 bits for each pixel ... 
>               is it possilble to reduce memory to make according to
> desired requiremeents ........ and to use it although it is not dual
> port ...

You have two choices:

1. Timeslice access between whatever is writing to your video memory, 
and the vga controller. You'll need some pretty fast SRAM to do this - I 
suspect your dot-clock is around 30MHz (33ns)? So you'll need SRAM twice 
as fast as this.

2. Use some sort if FIFO and write to the SRAM only during the blanking 
intervals on the vga controller. This will of course limit your 
bandwidth writing to the video memory.

As for memory size, my calculations give 115.2KB required for the 
display, though it's horribly aligned. Storing 2 pixels/byte requires 
153.6KB. Not sure where you got 256KB from?

Regards,
Mark

Mark McDougall wrote:

>> it .......... i m available only a sram of 32 kbit * 8 = 256 kb 
>> memory which is not dual port........ i wanna store 640*480 pixels
>> data on it ... as i need only 8 colors ...so 3 bits for each pixel
>> ...               is it possilble to reduce memory to make
>> according to desired requiremeents ........ and to use it although
>> it is not dual port ...

> As for memory size, my calculations give 115.2KB required for the 
> display, though it's horribly aligned. Storing 2 pixels/byte requires
>  153.6KB. Not sure where you got 256KB from?

Oh, I think you're saying you only have 256k *bits*!?!

You'll have to compress the image then. Depending on the complexity of 
the image, you may get away with RLE - it's pretty simple to decode 
on-the-fly. Otherwise, well, I'm glad it's you doing it and not me! ;)

Regards,
Mark

> Mark McDougallwrote
fahadislam2002 wrote
>
> i m using spartan-2 ......... and have designed a very simpl
> vga controller on it ...... now i wanna interface an external ra
> with it .......... i m available only a sram of 32 kbit * 8 = 25
k
> memory which is not dual port.......
> i wanna store 640*480 pixels data on it ... as i nee
> only 8 colors ...so 3 bits for each pixel ..
> is it possilble to reduce memory to make according t
> desired requiremeents ........ and to use it although it is no
dua
> port ..
>
You have two choices

1. Timeslice access between whatever is writing to your video memory

and the vga controller. You'll need some pretty fast SRAM to do this 
I
suspect your dot-clock is around 30MHz (33ns)? So you'll need SRA
twice
as fast as this

2. Use some sort if FIFO and write to the SRAM only during th
blanking
intervals on the vga controller. This will of course limit your
bandwidth writing to the video memory

As for memory size, my calculations give 115.2KB required for the
display, though it's horribly aligned. Storing 2 pixels/byte require

153.6KB. Not sure where you got 256KB from

Regards
Mark[/quote:43f0423306

Hi..
      first thanks for responding.......
1-  From time slicing u mean slicing between rows and colums o
between
a fixed no of pixels 
2-  I m using HM62256ALP-8 ... and its speed is 80ns  :(  ..

fahadislam2002 wrote:

> Hi... first thanks for responding........ 1-  From time slicing u
> mean slicing between rows and colums or between a fixed no of pixels
> ? 2-  I m using HM62256ALP-8 ... and its speed is 80ns  :(  ...

For 640x480, scanline time is 31.77us. At 4 bits/pixel, you need to 
fetch 320 bytes in that time, which gives you ~100ns per byte. You'd 
also need to pre-fetch a scanline on-chip since the actual dot clock is 
around 25.175MHz (2 pixels = 79ns).

But then your SRAM bandwidth utilisation is approaching 100%, which 
leaves no time for the CPU to update the video memory. I suppose it 
would be possible to output interleaved VGA, and use every other 
scanline to allow the CPU to update video RAM, but that has other design 
implications.

Not ideal... :(

Regards,
Mark

On Fri, 19 Aug 2005 10:58:28 +1000, Mark McDougall <markm@vl.com.au>
wrote:

>+<fahadislam2002 wrote:
>+<
>+<> Hi... first thanks for responding........ 1-  From time slicing u
>+<> mean slicing between rows and colums or between a fixed no of pixels
>+<> ? 2-  I m using HM62256ALP-8 ... and its speed is 80ns  :(  ...
>+<
>+<For 640x480, scanline time is 31.77us. At 4 bits/pixel, you need to 
>+<fetch 320 bytes in that time, which gives you ~100ns per byte. You'd 
>+<also need to pre-fetch a scanline on-chip since the actual dot clock is 
>+<around 25.175MHz (2 pixels = 79ns).
>+<
>+<But then your SRAM bandwidth utilisation is approaching 100%, which 
>+<leaves no time for the CPU to update the video memory. I suppose it 
>+<would be possible to output interleaved VGA, and use every other 
>+<scanline to allow the CPU to update video RAM, but that has other design 
>+<implications.
>+<
>+<Not ideal... :(
>+<
>+<Regards,
>+<Mark
********

You can set the sram up in two banks of 8 bit width each. So that when
the video controller reads the sram it reads two bytes at a time, even
and odd address. The CPU can write to the ram in either 8 or 16 bit
mode. Then use IDMA. When the uP clock is low then the video circuit
accesses ram. When the uC clock is high then the uC acesses the ram.
This works well with processor speeds up to about 25 MHz. When using
dram you need to consider the dram cycle time, not access time, needs
to be half the CPU cycle time max.

An old technique used in 8 bit computers from the 80's.  

80nS cycle time ram will put a maximum of 12.5 Mhz CPU speed. In
reality it would be better to run the CPU at 12 MHz for better margin.
This adds more complex circuits in addressing the ram. One needs to
multiplex the video and cpu addresses as well as data buss. Nothing
really to difficult that can't be done in a FPGA though.

james  

james wrote:

> You can set the sram up in two banks of 8 bit width each. So that
> when the video controller reads the sram it reads two bytes at a
> time, even and odd address. 

I got the impression (either rightly or wrongly) that the original 
poster only has a single 8X256KB SRAM to play with, most likely he's 
doing this on an eval board of some sort?!?

> An old technique used in 8 bit computers from the 80's.

Yeah, I've seen an 80's arcade game time multiplex RAM access to two 
6809 processors using a similar method - from memory the two cpu clocks 
were 180 deg out of phase?!? Clever.

Regards,
Mark

On Tue, 23 Aug 2005 10:29:51 +1000, Mark McDougall <markm@vl.com.au>
wrote:

>+<Yeah, I've seen an 80's arcade game time multiplex RAM access to two 
>+<6809 processors using a similar method - from memory the two cpu clocks 
>+<were 180 deg out of phase?!? Clever.
*****

6800 was 180 out of phase,the 6809 uses a quadrature phased clock, 90
degrees. Does nice, the internal logic machine now has four
transistions or states for every clock cycle. The 68HC11 also uses the
same clock scheme.

jame

fahadislam2002 wrote:
> hi...
>       i m using spartan-2 ......... and have designed a very simple
> vga controller on it ...... now i wanna interface an external ram
> with it .......... i m available only a sram of 32 kbit * 8 = 256 kb
> memory which is not dual port........
>               i wanna store 640*480 pixels data on it ... as i need
> only 8 colors ...so 3 bits for each pixel ...

You don't have enough memory for a direct pixel array so you're going
to have to do something else, like maybe RLE compression.

Another thing you could do is make a tiled controller, similar to that
used by some 8-bit computers of the 80s, and even things like the
Nintendo Gameboy Advance.

View your 640x480 screen as an array of 80x60 tiles, each one being 8x8
pixels.

Your screen is now a tile array.  Each array entry is a 2 byte tile
index, so thats 80x60x2 = 9600 bytes.

This leaves ~23K bytes for tile data.

A tile is 8 pixels wide @ 3-bits per pixel = 24 bits (3 bytes).
A tile is 8 pixels high @ 3-bytes per row = 24 bytes / tile.

So your 32K byte memory can store the main tile array plus 965 tiles.
That's pretty good - it can give the illusion of a full bitmapped
display until the screen gets too busy.

The Gameboy Advance allows tiles to be horizontally and vertically
flipped (using two control bits in the tile index) which improves
shareability even more, at the expense of more complicated scan-out.


Good luck.

Paul.

Paul Marciano wrote:
> So your 32K byte memory can store the main tile array plus 965 tiles.
> That's pretty good - it can give the illusion of a full bitmapped
> display until the screen gets too busy.

Just to continue on this thought for a bit.

Every 8 VGA rows you will read in a new line out of the tile array.
Each row is 80 bytes x 85ns = 6.8us.

For each entry in the tile row, read the tile data into a block RAM.
You'll need 80 x 3 x 8 = 1920 bytes of block RAM (or 15K-bits).  The
smallest Spartan 2 has 16K-bits.

Each tile is 24 bytes, giving 24 x 80 x 85ns = 163.2us to read them
all.


>From this you can generate 640 x 8 VGA pixels without any further
external memory accesses.

640x480@60Hz = 32us/row, so you're generating (8 x 32us) 256us of
screen information using 170us of memory access time, assuming zero
idle time.

This leaves 33% SRAM bandwidth for CPU writes (perfect case timing).


Some 8-bit micros of days gone by would assert WAIT (or equivalent CPU
signal) to pause the processor during memory access conflicts.  That
might be applicable in this context.


If you want to get more sophisticated, for a given tile array row, only
read the tile data once.  So if your tile array uses tile #100 three
times, don't read the tile #100's data three times - only read it once.

For sophistication++ view the block-RAM tile data as an LRU cache, and
only populate tiles you haven't already got or are dirty (snoop CPU
writes) and only retire tiles you're not going to use in the current
tile array row.

Good luck.

Paul.