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.