Processing math: 0%
\newcommand{\n}{\hat{n}}\newcommand{\w}{\hat{\omega}}\newcommand{\wi}{\w_\mathrm{i}}\newcommand{\wo}{\w_\mathrm{o}}\newcommand{\wh}{\w_\mathrm{h}}\newcommand{\Li}{L_\mathrm{i}}\newcommand{\Lo}{L_\mathrm{o}}\newcommand{\Le}{L_\mathrm{e}}\newcommand{\Lr}{L_\mathrm{r}}\newcommand{\Lt}{L_\mathrm{t}}\newcommand{\O}{\mathrm{O}}\newcommand{\degrees}{{^\circ}}\newcommand{\T}{\mathsf{T}}\newcommand{\mathset}[1]{\mathbb{#1}}\newcommand{\Real}{\mathset{R}}\newcommand{\Integer}{\mathset{Z}}\newcommand{\Boolean}{\mathset{B}}\newcommand{\Complex}{\mathset{C}}

ECSE 222: Digital Logic - Lab 3

ECSE 222: Digital Logic - Lab 3
Fall 2018 - McGill University - Electrical & Computer Engineering
Prof. Derek Nowrouzezahrai, derek@cim.mcgill.ca
TAs responsible for this assignment: Arash and Alex
contents

1  Overview
  1.1  Video Graphics Array (VGA)
  1.2  Synchronization
  1.3  Screen Coordinates
  1.4  Precise Clocking Using PLLs
  1.5  Additional Resources
2  Instructions
  2.1  Step 1
  2.2  Step 2
  2.3  Step 3
  2.4  Step 4
  2.5  Step 4
  2.6  Grading
3  Evaluation rubrick:

Due Date: The week of November 26 during your assigned lab section

Guidelines:

~

~

~

~

Note:

If Quartus freezes at roughly 10% completion during compilation, check the location of your project and VHDL files: storing files on a network drive (e.g., on the campus.mcgill.ca domain) instead of a local drive (e.g., C:\) will cause this issue.

Overview

Over the course of the next two lab assignments you will design a clone of the popular Space Invaders acrade game. Your implementation of this game will comprise several entities wired together to make the game come alive. Specifically, you will design:

This lab will focus on designing a simple VGA video controller. If successfully completed, you will have an implementation that displays color bars on a standard computer monitor. This lab provides less explicit video instructions, relying on you to put more effort into understanding and completing the required tasks. That being said, we're not leaving you completely in the dark: some (incomplete) VHDL source files are provided to help bootstrap you.

Video Graphics Array (VGA)

VGA is a standard that relies on a technique called raster scanning to display images on a screen. This technique outputs pixels onto the screen one at a time, starting from the top left and ending at the bottom right of the screen (i.e., in english reading order). In other words, raster scanning outputs pixels in row-order, from top to bottom.

Once the bottom is reached (and, so, we've completed displaying the desired output image), the raster scan starts back at the top left and repeats. Each top-to-bottom scan is called a “frame” and, if we succeed in drawing a frame at a rate of e.g., 60 Hz, then we can say we're outputing frames at 60 FPS (frames per second). Your final Space Invaders clone will be operate with a video output of 60 FPS.

Each row of outputted pixels is referred to as a “scan line”, the process of moving to the far-left pixel column in order to begin drawing a subsequent scan line is called the “horizontal retrace”, and once every scan line has been completely outputed we perform a “vertical retrace” in order to restart at the top-left pixel.

Raster scanning terminology for a single output frame.

Synchronization

We will develop circuitry (that'll “run” on our FPGA) in order to correctly communicate image data to the computer screen/monitor. At a high-level, this data will come in the form of pixel coordinates and pixel colors: what color do we set each pixel of the image.

Any time two separate devices need to work together to achieve a task, it is useful to have an established protocol in order to synchronize their operations. Displaying video through the VGA interface requires precise timing, as the screen device has strictly defined hoziontal and vertical synchronization pulses.

An image (or “frame”) comprises many horizontal scanlines (one for each “row” of the image). Before allowing pixel data to be transmitted and displayed on-screen, each frame (and every individual scanline in it) follows a very strict synchronization protocol.

A frame starts by expecting two synchronization delays: first, a vertical sync pulse, and then a (frame) back porch. Once synchronized, the frame will allow for horizontal scanlines to be populated until the image data is fully communicated, before finally expecting a terminal front porch synchronization delay1.

During front porch, back porch and the sync pulses, a “blank” signal must be communicated (active low, meaning 0) and the RGB signals must also be set low.

Once the frame is initialized (i.e., after it's vertical sync pulse and back porch expire), then the protocol will expect horizontal scanlines to be communicated, one after the other, according to the following scanline sub-protocol: each horizontal/scan line begin with two synchronization delays, a horizontal sync pulse followed by a (scanline) back porch. Afterwards, the device will expect the scanline's pixel data to be communicated2, before expecting one last (scanline) front porch synchronization delay.

The duration of each of the aforementioned synchronization delays depends on the display resolution you plan on using, and a table detailing these timing constants are found in the FPGA user manual.

Note that it is common practice for VGA documentation to refer to individual clock cycles as “pixels”: for example, if we say that the scanline front porch is 10 pixels long, we mean that it lasts 10 clock cycles.

Screen Coordinates

You would have already learned about Cartesian coordinates in your algebra and calculus classes. Here, when you graph functions, it is common to place the x = 0 and y = 0 origins either at the bottom left or center of your plot; furthermore, you're probably used to having x increase in the right direction and y increase when moving upwards.

VGA video pixel coordinates do not follow this convention. Instead, the x = 0 and y = 0 origin start at the top left corner of the screen (and x still increases when moving to the right), and y increases when moving downwards.

VGA Coordinates

You will also notice that the VHDL source we provide to you makes use of pixel_x and hpos signals, as well as pixel_y and vpos signals. While your initial reaction might be that these signals are redundant, this not in fact the case: pixel_x and pixel_y represent the position of the RGB cursor after synchronization has been completed. The hpos and vpos signals, on the other hand, represent the position of the “raster cursor” that includes the front porch, sync, and back porch delays (as well as the RGB data count). Be mindful of this difference.

Here's an example of the different values that these signals can take when, say, you are drawing the first horizonal scanline (assuming a horizontal screen resolution of 640):
hpos pixel_x
hpos = 0 pixel_x = 0
hpos = hsync + back porch pixel_x = 0
hpos = Sync + back porch + 10 pixel_x = 10
hpos = Sync + back porch + 640 pixel_x = 640
hpos = Sync + back porch + 640 + 1 pixel_x = 640

Precise Clocking Using PLLs

After reading your FPGA board user manual you'll notice that the clock required to drive the video signals are not equivalent to the standard clocks on the FPGA board.

We will use a PLL (phase locked loop) to achieve the desired clock period we will use: this circuit takes a reference clock as input and outputs a clock signal with the desired frequency. You can think of it roughly in line with the clock divider we've already designed, with a major difference being that it can also result in an output clock signal that's faster than the input. We will design our PLL using the Altera wizard (see Instructions Section).

Additional Resources

Another complimentary reference on the VGA protocol is published in this guide. Note, however, some important differences between this guide and your FPGA manual: in the supplementary guide's synchronization diagram (Figure 3), the order of the synchronization delays and the data line timing is different (i.e., RGB raster data -> front porch -> sync -> back porch) than what we outlined about.

For your lab, the timing protocol you will rely on for your signals (i.e., sync -> back porch -> RGB raster data -> front porch) are still valid, albeit being relatively out-of-phase.

Instructions

Your goal is to draw color bars at a resolution of 640 \times 480. The synchronization constants for this resolution setting are provided in the file vga_controller.vhd and were taken from your DE1-Soc user manual.

Step 1

Start by reading the DE1 user manual's specification on VGA.

DE1 VGA Connections

Luckily, you don't have to implement a full VGA driver in hardware. Instead, you will write a module to interface with the VGA digital-to-analog chip on your FPGA board. The pin mapping for this chip can be found in your user manual; you will need to populate the pin planner on your own, this time (with some guidance: see more info in the instructional videos).

Step 2

Unzip the following source files into the folder you will use for the lab: download.

Set up your project using the following guideline:

Step 3

Add your own code for the following files:

Step 4

Up to now, we've relied on Modelsim to simulate and verify the fuctionality of our circuits. In this lab, rather than only simulating our designs, we will use additional tooling to explore the signals that we're actually driving from our FPGA. The tool we'll use here is called the Signal Tap.

By probing the output signals driven from our device to the screen, we can ensure that follow the synchronization protocol needed for correct interafcing with the VGA monitor. Here are some guiding instructions:

Step 4

Perform a full recompile, load the configuration onto your board, and verify its behavior. Debug and repeat, if necessary.

Grading

Once completed, please demo your project to the TA. You will be expected to:

Evaluation rubrick:

1 The terms “front porch”, “sync pulse” and “back porch” are nothing more than a naming convention used in the literature.

2 This is where the pixel data is actually communicated!

formatted by Markdeep