**ECSE 222: Digital Logic - Lab 3** *Fall 2018* - [McGill University](http://www.mcgill.ca) - [Electrical & Computer Engineering](http://www.ece.mcgill.ca) Prof. [Derek Nowrouzezahrai](http://www.cim.mcgill.ca/~derek), derek@cim.mcgill.ca *TAs responsible for this assignment: * [Arash](arash.ardakani@mail.mcgill.ca) and [Alex](zixuan.yin@mail.mcgill.ca) __Due Date:__ The week of November 26 during your assigned lab section __Guidelines:__ - Carefully and thoroughly read this lab document - Follow the instructions to complete the lab - Notify the TA when you're ready to be evaluated - While this work is conducted in groups, each member is expected to fully understand every component of the solution! $~$ $~$ $~$ $~$

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: - a VGA video controller, - a memory unit for the game sprites, and - a state machine to control the behavior of the game. 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.](raster_scan.jpg) 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 delay[^footnote1]. 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 communicated[^footnote2], 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](ftp://ftp.altera.com/up/pub/Altera_Material/Boards/DE1-SoC/DE1_SoC_User_Manual.pdf). 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](coords.gif) 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](ftp://ftp.altera.com/up/pub/Altera_Material/Boards/DE1-SoC/DE1_SoC_User_Manual.pdf) 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](https://eewiki.net/pages/viewpage.action?pageId=15925278). 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](ftp://ftp.altera.com/up/pub/Altera_Material/Boards/DE1-SoC/DE1_SoC_User_Manual.pdf). Step 1 ------- Start by reading the DE1 [user manual](ftp://ftp.altera.com/up/pub/Altera_Material/Boards/DE1-SoC/DE1_SoC_User_Manual.pdf)'s specification on VGA. ![DE1 VGA Connections](vga_conn.png) 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: - Setting up a project from bootstrap source files. Step 3 ------- Add your own code for the following files: - video_blank.vhd - vga_controller.vhd 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: - Using the Signal Tap tool. 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: - fully explain the HDL code works, - demonstrate a screen with the correct colored lines pattern, and - demonstrate the timing dragram for one horizonal scanline. # Evaluation rubrick: - __[3 pts]__ Explain your VGA controller - __[2 pts]__ Screen shows correct colored bars - __[2 pts]__ Explain your trigger condition - __[2 pts]__ Signal Tap shows 1 horizontal scanline timing diagram - __[1 pts]__ Code comprehension: you will be asked about how to achieve a different resolution [^footnote1]: The terms "front porch", "sync pulse" and "back porch" are nothing more than a naming convention used in the literature. [^footnote2]: This is where the pixel data is actually communicated!