Driving VGA on FGPA

Thread Starter

mikez

Joined Jan 21, 2013
47
I am currently working on driving the vga port on an FPGA not using Verilog or VHDL. Here is what I have so far. Two 10-bit counters: first one is my horizontal counter that will count up to 800 and once it reaches 800 it will assert CE on my vertical counter and that will move me down to the next row so that the pixels can be colored in a sweeping pattern. I have the logic to turn off my hSync and vSync when I am outside the "active region". I am just a bit confused on where to go from here. I have not been able to find any material on constructing a VGA generator that is not coded in VHDL or Verilog. Anyone have any sites or manuals handy with some info on how to do this?
 

Thread Starter

mikez

Joined Jan 21, 2013
47
I have all of the timing signals - those were given to me in the assignment. I am just confused as to what I need to be doing exactly. I will try and explain what I know and maybe someone can fill in the gaps as to where I need to head from here.

I need a 10-bit counter that will begin counting from 0-799 and will reset once it reaches that value. It will then assert a signal to the vertical counter that will drop it down to the next row and begin counter until it hits 799. I will use comparators to tell where my counters are at and what color to send to that specific pixel.

I am just not sure how to handle sending the signal to tell that pixel to be red, green, blue or some combination of the three colors.
 

thatoneguy

Joined Feb 19, 2009
6,359
The pixels are analog values, usually a multi-bit R2R ladder, one ladder for each color.

Most often, for beginning circuits, RGB are all the same "color", which is high, and is displayed as white. The low is displayed as black.
 

Thread Starter

mikez

Joined Jan 21, 2013
47
Yeah for the assignment I will only be dealing with 4 different colors: black, red, green, and blue. For RGB I will be sending 1's to each pin depending on the color. My main problem right now is being able to construct the vga generator (what actually sends the signal to the monitor). All of the examples I am finding are in VHDL and Verilog and I am trying to stay away from that.
 

MrChips

Joined Oct 2, 2009
30,720
Black is not one of your signals.
There are only three color signals, red, green and blue.
You will need three parallel-in serial-out shift registers for the three colors.
The procedure is the same for each color so we only need to describe the procedure for one color.

Let us assume you use an 8-bit shift register (SR).
You will load the SR 100 times during the hor scan period to crank out 8x100 = 800 pixels per line.
After loading the SR with an 8-bit word, you will shift the data out serially at the pixel clock frequency.

What are your HOR scan frequency, VERT scan frequency and pixel clock frequency?
 

Thread Starter

mikez

Joined Jan 21, 2013
47
Black is not one of your signals.
There are only three color signals, red, green and blue.
You will need three parallel-in serial-out shift registers for the three colors.
The procedure is the same for each color so we only need to describe the procedure for one color.

Let us assume you use an 8-bit shift register (SR).
You will load the SR 100 times during the hor scan period to crank out 8x100 = 800 pixels per line.
After loading the SR with an 8-bit word, you will shift the data out serially at the pixel clock frequency.

What are your HOR scan frequency, VERT scan frequency and pixel clock frequency?
I am not sure what you are asking for by the horizonal and vertical scan frequencies. Are you wondering what my ranges are that I am working with? And I believe the pixel clock frequency is 50 mhz.
 

MrChips

Joined Oct 2, 2009
30,720
You said your timing signals were given to you. What are these?

Let's assume you are using VESA VGA specs for 800x600 display.

Are you using the following:

hor sync = 46.875kHz
vert sync = 75Hz
pixel clock = 49.5MHz

If you are not, then you need to learn about VGA timing specs.
 

Thread Starter

mikez

Joined Jan 21, 2013
47
You said your timing signals were given to you. What are these?

Let's assume you are using VESA VGA specs for 800x600 display.

Are you using the following:

hor sync = 46.875kHz
vert sync = 75Hz
pixel clock = 49.5MHz

If you are not, then you need to learn about VGA timing specs.
Sorry I am a bit scatter brained at the moment. It's the standard frequencies for a 640x480 display @ 60Hz, but the range of values that my counters are going to go are 800x600. And I believe we are using an upgraded pixel clock because the 25MHz clocks were fuzzy on the displays.
 

MrChips

Joined Oct 2, 2009
30,720
Ok, you have to make up your mind.

Are you generating 640x480 @ 60Hz or 800x600 @ 75Hz?

Please post the specs you have been given.
 

Thread Starter

mikez

Joined Jan 21, 2013
47
Ok, you have to make up your mind.

Are you generating 640x480 @ 60Hz or 800x600 @ 75Hz?

Please post the specs you have been given.
I am not being indecisive :confused:. I stated earlier that my active region is 640x480 @ 60Hz, but that my two 10-bit counters I have running will be counting from 0-799 (horizontal) and 0-524 (vertical).



Time it takes to transmit one frame 800x525x40ns = 16.8ms.

That is what I have been provided with.
 

MrChips

Joined Oct 2, 2009
30,720
So your specs for 640x480 @60Hz are:

hor scan = 31.25kHz
vert scan = 59.5 Hz
pixel clock = 25MHz

A pixel clock of 25.175MHz will bring you in line with the VGA standard.
 
Last edited:

MrChips

Joined Oct 2, 2009
30,720
I already gave you some steps. What is your next question?

You will load the SR 80 times to generate the video signal.
Use the timing information shown in the diagram to generate the hor sync pulse.

The vertical sync lasts for 2 hor scans at line 489 and 490.

What more do you need?
 
Last edited:

Thread Starter

mikez

Joined Jan 21, 2013
47
I already gave you some steps. What is your next question?

You will load the SR 640 times to generate the video signal.
Use the timing information shown in the diagram to generate the hor sync pulse.

The vertical sync lasts for 2 hor scans at line 489 and 490.

What more do you need?
How to handle actually telling the pixel what color to be. I have my registers working and hsync and vsync go hi and lo when they are suppose to. I am wondering how I now tell pixelX to be a color.
 

MrChips

Joined Oct 2, 2009
30,720
You will have three SRs to control red, green and blue.
When all bits are 0, the color is black.
When all bits are 1, the color is white.
In total, you have 2^3 = 8 colors to choose from, i.e. each pixel can have any one of 8 colors.

You will need three 640x480 bit maps, one for each of the three colors, red, green and blue.
You will output 80 bytes from each map simultaneously to each of the 3 SRs for each horizontal line.
 

Thread Starter

mikez

Joined Jan 21, 2013
47
You will have three SRs to control red, green and blue.
When all bits are 0, the color is black.
When all bits are 1, the color is white.
In total, you have 2^3 = 8 colors to choose from, i.e. each pixel can have any one of 8 colors.

You will need three 640x480 bit maps, one for each of the three colors, red, green and blue.
You will output 80 bytes from each map simultaneously to each of the 3 SRs for each horizontal line.
Okay and depending on where I am in my active region will be the signal I sent to the SR right? I have to make an 8 pixel blue bored around the entire active region. So what I have done is take two comparators to see that my count is < 8 and > 470 as well as < 8 and > 630. So when my signals are high depending on where the count is I will just pass a 1 to the shift register corresponding to that color?
 

MrChips

Joined Oct 2, 2009
30,720
I wouldn't do that in hardware.
Since at some point you have to generate the graphics content in software I would draw the border in software into the bit map.
 

Thread Starter

mikez

Joined Jan 21, 2013
47
unless Xilinx has that feature built in where I can tell the software how I want to paint the border to the display that would be very handy, but unfortunately I have to implement that in the hardware.
 
Top