This website uses cookies. By using this site, you consent to the use of cookies. For more information, please take a look at our Privacy Policy.
Home > FPGA Technical Tutorials > Design Recipes for FPGAs Using Verilog and VHDL > A Simple VGA Interface > A VGA Interface in VHDL

TABLE OF CONTENTS

Xilinx FPGA FPGA Forum

A VGA Interface in VHDL

FONT SIZE : AAA

VHDL Top Level Entity for VGA Handling

The first stage in defining the VHDL for the VGA driver is to create a VHDL entity that has the global clock and reset, the VGA output pins, and a memory interface. The outline VHDL entity is therefore given as follows:

11.png

The architecture contains a number of processes, with internal signals that manage the transfer of pixel data from memory to the screen. As can be seen from the entity, the data comes back from the memory in 8-bit blocks and we require 3 × 2 bits for each pixel and so when the data is returned, each memory byte will contain the data for a single pixel. In this example, as we are using a 640 × 480 pixel image, this will therefore require a memory that is 307,200 bytes in size as a minimum. To put this in perspective, this means that using a raw memory approach we can put three frames per megabyte. In practice, of course, we would use a form of image compression (such as JPEG for photographic images), but this is beyond the scope of this book.

end.png

This process returns the current value of the pixel data into a signal called pixel_data, which is declared at the architecture level:

1   signal pixel_data : std_logic_vector ( 7 downto 0 );

This has the red, green, and blue data defined in the lowest 6 bits of the 8-bit data word with the indexes, respectively, of 0-1, 2-3, and 4-5.

Horizontal Sync

The next key process is the timing of the horizontal and vertical sync pulses, and the blanking intervals. The line timing for VGA is 31,770 ns per line with a window for displaying the data of 25,170 ns. If the FPGA is running at 100 MHz (period of 10 ns) then this means that each line requires 3177 clock cycles with 2517 for each line of pixel data, with 660 pulses in total for blanking (330 at either side). This also means that for a 640 pixel wide line, 39.3 ns are required for each pixel. We could round this up to 4 clock cycles per pixel. As you may have noticed, for the pixel retrieval we have a new internal clock signal called pclk, and we can create a process that generates the appropriate pixel clock (pclk) with this timing in place.200 Chapter 14 With this slightly elongated window, the blanking pulses must therefore reduce to 617 clock cycles and this means 308 before and 309 after the display window. 

The horizontal sync pulse, on the other hand, takes place between 26,110 ns and 29,880 ns of the overall interval. This is 189 clock pulses less than the overall line time, and so the horizontal sync pulse goes low after 94 clock cycles and then at the end must return high 95 clock cycles prior to the end of the line. The difference between the outside and inside timings for the horizontal sync pulse is 377 clock cycles and so the sync pulse must return high 94 + 188 clock cycles and then return low 95 + 189 prior to the end of the window

Thus, the horizontal sync has the following basic behavior:

and this can be implemented using a process with a simple counter.png

and this can be implemented using a process with a simple counter:

end process.png

Vertical Sync

The horizontal sync process manages the individual pixels in a line, and the vertical sync does the same for the lines as a whole to create the image. The period of a frame (containing all the lines) is defined as 16,784,000 ns. Within this timescale, the lines of the image are displayed (within 15,250,000 ns), then the vertical blanking interval is defined (up to the whole frame period of 16,784,000 ns) and finally the vertical sync pulse is defined as 1 until 15,700,000 ns at which time it goes to zero, returning to 1 at 15,764,000 ns. 

Clearly it would not be sensible to define a clock of 10 ns for these calculations, so the largest common divisor is a clock of 2 s, so we can divide down the system clock by 2000 to get a vertical sync clock of 2 s to simplify and make the design as compact as possible.

14 end process.png

where the vertical sync clock (vclk) is defined as a std_logic signal in the architecture. This can then be used to control the vsync pulses in a second process that now waits for the vertical sync derived clock:

17 end process.png

Using this process, the vertical sync (frame synchronization) pulses are generated.

Horizontal and Vertical Blanking Pulses

In addition to the basic horizontal and vertical sync pulse counters, we have to define a horizontal blanking pulse which sets the line data low after 25,170 ns (2517 clock cycles). This can be implemented as a simple counter in exactly the same way as the horizontal sync pulse and similarly for a vertical blanking pulse. The two processes to implement these are given in the following VHDL.

37 end process.png

Calculating the Correct Pixel Data

As we have seen previously, the data of each pixel is retrieved from a memory location and this is obtained using the pixel clock (pclk). The pixel clock is simply a divided (by 4) version of the system clock and at each rising edge of this pclk signal, the next pixel data is obtained from the memory data stored in the signal called data and translated into the red, green, and blue line signals. This is handled using the basic process given here:


1 pixel_handler : process (pclk) is

2 begin

3 red <= data(1 downto 0);

4 green <= data(3 downto 2);

5 blue <= data(5 downto 4); 

6 end process;

This is a basic handler process that picks out the correct pixel data, but it does not include the video blanking signal and if this is included, then the simple VHDL changes slightly to this form:


1 pixel_handler : process (pclk) is

2 blank : std_logic_vector (1 downto 0);

3 begin

4 blank(0) <= hblank or vblank;

5 blank(1) <= hblank or vblank;

6 red <= data(1 downto 0) & blank;

7 green <= data(3 downto 2) & blank;

8 blue <= data(5 downto 4) & blank;

9 end process;

This is the final step and completes the basic VHDL VGA handler.




  • XC2V2000-5FF896I

    Manufacturer:Xilinx

  • FPGA Virtex-II Family 2M Gates 24192 Cells 750MHz 0.15um Technology 1.5V 896-Pin FCBGA
  • Product Categories: FPGAs

    Lifecycle:Obsolete -

    RoHS: No RoHS

  • XC4003E-4VQ100C

    Manufacturer:Xilinx

  • FPGA XC4000E Family 3K Gates 238 Cells 0.35um Technology 5V 100-Pin VTQFP
  • Product Categories: FPGAs (Field Programmable Gate Array)

    Lifecycle:Obsolete -

    RoHS: No RoHS

  • XC5VLX110T-1FFG1136CS1

    Manufacturer:Xilinx

  • FPGA Virtex-5 LXT Family 110592 Cells 65nm Technology 1V 1136-Pin FCBGA
  • Product Categories:

    Lifecycle:Obsolete -

    RoHS:

  • XC5VLX110T-2FF1738C

    Manufacturer:Xilinx

  • FPGA Virtex-5 LXT Family 110592 Cells 65nm Technology 1V 1738-Pin FCBGA
  • Product Categories: FPGAs (Field Programmable Gate Array)

    Lifecycle:Active Active

    RoHS: No RoHS

  • XCV300-4PQG240C

    Manufacturer:Xilinx

  • FPGA Virtex Family 322.97K Gates 6912 Cells 250MHz 0.22um Technology 2.5V 240-Pin HSPQFP EP
  • Product Categories:

    Lifecycle:Obsolete -

    RoHS:

Need Help?

Support

If you have any questions about the product and related issues, Please contact us.