Lab Number 5
John Koutsoyannis
EEL 4712 Section 1518
Wednesdays 4:05 pm : 3/19/08
TA: Jared Bevis
Objectives
The objective of this lab is to study the generation of the control signals required
by a VGA monitor by creating a component VGA_sync_gen that generates those signals.
Using VGA_sync_gen and additional components, a simple color raster image will be
displayed on a VGA monitor.
Pre-Lab
The first part of the pre-lab calls for the creation of a behavioral VHDL file for a
component called VGA_sync_gen. In the lab document, we are given a number of
defined constants that we can use in our code that represent values of certain elements of
the VGA display. For example, H_DISPLAY_END, with the value 639, represents the
width of the screen in pixels, so when the counter reaches 639, the code in
VGA_sync_gen tells it that it needs to move to the next horizontal line.
All of the constants and how they are conditionally used are in the commented
VHDL code on the following page. The Hcount and Vcount functional simulations are in
Figures 1 and 3, respectively, and the horizontal and vertical refresh period simulations
are in Figures 2 and 4, respectively.
Figure 1 – Hcount functional simulation
Figure 2 – Horizontal refresh period (functional sim)
Figure 3 – Vcount functional simulation
Figure 4 – Vertical refresh cycle (functional sim)
The second part of the pre-lab calls for the utilization of three additional parts to
implement a color raster picture composed of 8x8 blocks, where each block consists of
256 RGB blocks in a 16x16 grid. We will need a block ROM, which contains the RGB
values for each of the 256 blocks, a part which generates the current block row, and a part
which generates the current block column.
The block row and column counters were fairly simple to implement. I simply
made a VHDL file that set the upper nibble of T, which connects to the address bus of the
ROM, to bits 6-3 of the Vcount, and the lower nibble of T to bits 6-3 of the Hcount. I
originally had a small problem related to this “driver_logic” component that I will discuss
in the conclusion. The driver logic VHDL design is on the following page. The block
row and column counter simulation is below, in Figure 5.
Figure 5 – Block row and column counter functional simulation
The block ROM was created using a Quartus component called AltSyncRAM,
which consisted of a buffered address input bus, a buffered “q” output bus, and a 256word RAM block in the middle. It takes the address from the “driver_logic” output, and
outputs 3 bits that correspond to a combination of Red, Green, and Blue. The
simulation for the block ROM is below, in Figure 6. There is no design file because it’s a
predefined component from the megafunctions/storage library in Quartus.
Figure 6 – Block ROM functional simulation
The final part of the pre-lab was the final test setup, where the VGA_sync_gen,
Block ROM, and block row and column counters are all wired together to make a circuit
that displays a raster picture. The final design is relatively intuitive: The
VGA_sync_gen’s Vcount and Hcount output to the driver_logic component, which
translates them into an address for the block ROM, which uses the address to output
q[2..0], which connect to the board’s VGA Red, Green, and Blue pins, respectively. The
pin assignments are visible on the vga_driver.bdf schematic. The RGB signals are
ANDed with the video_on signal from the VGA_sync_gen.
Since the AltSyncRAM’s output is delayed by 2 clock cycles, thanks to the 2
DFF’s in the design, we must accordingly delay the video output of the RGB signals by 2
clock cycles, so that the colors appear in the appropriate places on the screen. This issue
was another small stumbling block that will be discussed in the conclusion. This is
shown in the vga_driver.bdf design schematic on the following page. The final design
simulation is below, in Figure 7. It shows the RGB outputs of 2 horizontal lines of the
screen, which is a good abbreviation of what a complete simulation would look like.
Figure 7 – Final circuit functional simulation
In-Lab Procedure
In lab, we were asked to do 3 things: display the brom.mif colors repeating across
the entire monitor, display our original .mif file on the monitor, and modify our design so
that only one brom.mif 16x16 block would appear on the monitor.
The first objective presented a problem where a small line of 2 pixels were
appearing on the left side of the screen, where they shouldn’t be. This was because I
wasn’t delaying the video_on signal to match the clock cycle delay of the RGB signals.
After I updated my design, everything displayed perfectly.
The second part of the procedure was trivial. I only had to change the
AltSyncRAM component to use my creative.mif file instead of the brom.mif.
The third part of the procedure would need a modification of the VGA_sync_gen
design file. I actually only had to change two constants: H_DISPLAY_END AND
V_DISPLAY_END. I changed their 640x480 values to 128x131, uploaded the new
design, and the monitor displayed only one 16x16 block.
Conclusion
Compared to the previous labs, this lab was unique because of the interaction with
a device outside of the Cyclone board. Technically, the monitor can be viewed as just
another device connected to the Cyclone with wires and jumpers, like an LED bank, but
it is obviously a vastly more complicated device. I would say that the most difficult part
was creating the VGA_sync_gen component, because it required the understanding of
what signals are required at precisely what time. Fortunately, it wasn’t too difficult,
because all of the useful values were given to us in the defined constants.
I did run into a couple of obstacles during the pre-lab. For example, I had
originally used bits 9-6 of Vcount and Hcount, but the picture was much too large as a
result (as brought to my attention by the TA), which meant that the ROM address was
incrementing too slowly. Adjusting the use of the Vcount and Hcount bits such that the
ROM address would increment faster easily fixed the problem.
Also, in the final design, the picture was appearing “early”, meaning that the
picture was slightly off (shifted to the right by 2 pixels), because the video was being
output before the RAM output was ready. As a result, colors were not exactly where they
should have been on the monitor. This was remedied by delaying the video signal by the
same amount that the RGB data was being delayed in the AltSyncRAM component (due
to the two DFF’s).
Also, there was a significant Quartus annoyance that was causing it to not upload
updated designs to my board properly. For some reason, it was necessary to power cycle
the board every time I wanted to upload an updated version of my design. This problem
had me scratching my head for quite a while during lab until I came up with the fix.
In the end, though, I was able to properly display the original brom.mif color
design on the monitor, as well as my own creative.mif design.
The color design in the creative.mif file was drawn by my girlfriend. I gave her a
piece of engineering paper (green with little squares), squared off a 16x16 section, and
gave her colored pencils of the available RGB combinations. The result was very nice,
albeit quite tedious to enter into the creative.mif file.