fpga4fun.com

Hi,

I'm working on VGA controller running using BRAM on a Spartan 3E to act as a counter and generate the sync signals, rather than using counters.

It's Xilinx specific, but is quite light on resources. Anybody interested in it?

Hi,

sounds like an other interesting example of "Creative Use of Block BRAM"
(WP335.pdf). How have you addressed your BRAM, what is the content
structure for your SYNC and BLANK signals.

I myself have written a simple VGA component family (3 components)
for simple VGA (X/Y-Pos, no BRAM), Graphics (160x100 in one BRAM)
and Text (40x25, two BRAMs for Text and Font), enough for simple
hobby apps. All three can be placed in a little XC3S50 with only less
than 10 percent CLBs so that I have 90 percent for my additional
components.

I use approx. 6 CLBs for SYNC and BLANK generation for both X- and
Y-Position, so the question is if the use of an extra BRAM is worth the
generation of SYNCs and BLANKs?


Jotta


Btw: The creative use of BRAMs is not only a Xilinx thing, this can also
be used in Altera FPGAs etc.

Hi Jotta,

To get the gist, the easy example is the vsync generator.

The first (9: 0) is the next state which feeds back into the BRAM's address, with (4 :1) also provides the row number for the character ROM - it uses double scan. (9:5) is the "text Y coordinate". (10) is the vsync, and (11) is the vertical blanking signal

So an initialisation table like:
01000000001
01000000010
01000000011
01000000100
01000000101
11000000110
10000000111
10000001000
11000001001
11000001010
01000000000

...has a period of 11 rows, with vertical blanking from rows 6 through 10, and a negative sync pulse for rows 7 & 8. For the first 6 rows the row fed into the character generator is 0,0,1,1,2,2. As (9:5) is all zeros this is all on text row 0.

When you are using 8x10 characters, I skip 6 states to keep everything in step.

It is just a little confusing as the state on the outputs out of sync by one cycle from what you would expect (hence why the blanking is turned off on the final row).

The table controlling hsync has a few more bits (like when to enable the clocking of the vsync generator), but is pretty much the same.

I found that the best way to generate the tables was with a small program...

Sounds like a cool project! I too have used block ram in my video (NTSC) project, but to grab an entire line of video so that it frees more time for back buffer access of a host processor. This is so much better than trying to cycle the bus.

Here is a vid of it working on a Spartan3...
http://www.youtube.com/watch?v=IRroMaaCAn4

Brad

Well, mine isn't as tiny as that - 6xBRAM blocks (2 for char rom, 2 for frame buffer, 1 hsync and 1 vsync), but on top of that it only uses 21 slices!

I wish I could find an FPGA with enough block ram to carry all of my frame buffer resources! I would need an FPGA with 1024x8 to handle both buffers as well as the resources used by the flood fill command.

It's too bad there wasn't such a beast... an FPGA with the amazing SRAM available on the ARM offerings.

Brad

I guess if you went 320x240 doublescan (i.e. 640x480 with 2x2 pixels), and using 8x8 characters (and a blank row top and bottom making it 8x10 on the display) you could display 960 characters on a screen. Maybe you could rotate a 8x9 bitmap and store them 9x8, giving an extra row....

By reduced the character set to 128 glyphs you would need 1024 entries for all the character bitmaps. It would then all fit in 2kx9bit BRAM.

As a bonus, by using 7 bits for characters you get 2 bits for attributes, maybe to index a four entry colour palette stored after the 960 characters.

If you could get away with 64 glyphs, then you get 3 bits for the palette, and could have up to 1536 characters on the screen.

Looking at 40x24 would be like a journey into retro computing though!

Yes, but Lazarus is a full blown 8 buffer game system with a 60MIPs custom GPU and about 20 graphics commands, not a character display. I am actually utilizing 512K of external memory at 10ns here...

http://www.youtube.com/watch?v=IRroMaaCAn4

Even my initial 74HC based logic version uses 128KB...

http://www.lucidscience.com/pro-lazarus ... ype-1.aspx

If I could find an FPGA with a true dual port 512Kblock ram, then life would be great!

Brad

I had a look at your Lazarus video... very impressive. But I found your pages on building it even more interesting. Boy! that is one big breadboard!

I'm more focusing on embedded stuff.. trying to move away from PC104 boards talking to custom display hardware to using off the shelf FPGA development boards, LCD monitors and a minimum custom electronics.