Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Project title: Team name:

​

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Existing Project title: Frogger Team name: AB Team 9

​

• Have two people play frogger on two different boards. Whoever reaches the other side first wins.
• Both players will be playing on the same “road” that will be displayed on their LED array matrix.
• They will control their frogs through the 4 keys.
• The scores will be kept in the SRAM and will be shown in the HEX lights (or the console if we don’t have time).

• The possibility of the NIOS processor failing will continue to bite at our ankles. Luckily, the processor we developed for Lab 4 seems to be more reliable, so we’ll be building our processor out of that one.
• Communication between two boards is something that we’ve never delved into. So, if we can’t get it to work by next week, then we’ll have to make due with the second player playing on the console instead of another board.
• We are also worried that there may be some lag from one board to the other, so we would have to focus on timing even more.
• Finding another group with the LED matrix wired up will be difficult. The only solution is praying to our gods.
• Apparently, there’s a way to break the board depending on how we connect the two FPGAs… we’ll just consult the TAs.

​

• The rules of the Frogger game.
• How to connect two FPGA boards together using the UART serial communication.
• Building the NIOS processor that will handle the position data coming in and out.
• Develop the software that will manage the two boards.
• Wire up the LED 8x8 array.
• Using the SRAM to hold score data.
• How avoid making the board explode.

• Counter that will keep track of the scores on the board.
• SRAM that will keep track of each of the player’s positions.
• Entire Frogger hardware module.
• Another Verilog module that will output the opponent’s position on the player’s board.
• NIOS processor.
• Software module that will manage the game and output the scores.
• A hardware encoder that will translate the xy-positions to single byte number so that it could be passed down to the other FPGA.

Project concept

Risks & risk reduction work done

​

No prior experience interfacing with VGA.

If VGA fails, we will use a LED array as backup.

​

Prior knowledge / background needed

​

Knowledge of NIOS II processor and SRAM.

Serial Data.

Research displaying out via VGA cable.

C and Verilog programming.

​

​

Deliverables

​

a. Joystick works

b. Button works

c. VGA driver works

d. Minefield displayed

e. Input interacts with minefield

f. Randomly generated levels

g. Display stats to LEDR and HEX

H. Can change size of minefield

​

​

Track: Existing Project title: Minesweeper

Team Name: AB Team 3

​

​

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Future |Project title: Karaoke Machine |Team name: AB Team 8

​

We plan to use the FPGA to make a Karaoke machine.

​

The FPGA will record the voice of the singer and the music track through two different inputs. Then we will control the treble and the bass on the mix audio.

• Basic knowledge of digital signal processing
• Low pass filter
• High pass filter
• How to use peripherals of the FPGA for the audio input and output
• Audio mixing techniques
• FSM’s for the key inputs

• Working output without the equalizer
• Working output with the equalizer
• Varying the bass only
• Varying the treble only
• Varying both the bass and the treble
• Working input with singer’s voice and the audio playback
• Mixing both the correct values of the audio level, treble and bass in the HEX displays
• A lab report showing the descriptions and diagrams of the project, modules , error and failure

• Delay and latency from the microphone
• Missing data from the inputs that can cause the audio to sound interrupted
• Feedback and noise from the microphone
• Incorporating the filtering algorithms into the FPGA

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Future Project title: Perceptron Team name: AC Team 1

​

Our Project Proposal is to create a Machine Learning - Perceptron algorithm in Verilog. We will also be combining a C program for a way to feed in the data. This project will be coming all the knowledge we have gained from past labs and using our knowledge from class.

Our project is based on Perceptron Convergence Algorithm. The perceptron is a binary classification that can learn linear separations, which means that makes predictions based on a linear predictor function. The function maps its input to an output value. The algorithm has a set up parameters that are numerical values (w and b). The data points are called Xn which is what we get from the inputted vectors. The algorithm has a sole hyperparameter is E, which is the number of epochs which passes over the training data. The last variable that is used in the algorithm is Y, which is the true label. Y will be either 1 or –1 depending on the actual classification. The math behind the algorithm (which is what we will be implementing in verilog) is as follows:

​

i. Y is equal to the sign of the dot product between W and Xn + b.

ii. Check if the Y value is the value that we originally intended.

iii. If the Y value is not, then update the value of W and B and go through the loop again.

1. W now becomes W + Yn

2. B becomes B + Yn

Key risk: Creating a method in which to transfer data to and from the board. Also we are wary of challenges that there may be associated with interfacing with the RAM.

​

We are actively looking into multiple methods of data transfer:

SRAM

Flash Programmer

.SOF

a. Way to get info onto/off of the board (HPS, some file, or arduino interface)

b. Fixed point or floating point ALU (or find someone who has already implemented it) (multiply and add)

c. Vector addition

d. Vector Dot Product

e. C program to feed the info in/out

f. Data order Randomizer

g. Epoch Counter

h. Python Program to take MNIST dataset and put it into a useable form

Key Concerns:

• Hardware Resource Usage & Memory
• More memory = higher performance
• More parallelism = faster
• But with thousands of images, we’re concerned with hitting the limits of the board

​

• SRAM
• Both NIOS and Verilog modules need to access the SRAM

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Future Project title: Number Recognition

Team name: AA Team 5

​

• Use the FPGA to recognize handwritten numbers.

​

• NIOSI ii for handling images

​

• FPGA for calculating the most likely classification of the handwritten number

​

The FPGA is useful for calculating tle classification in parallel using the K-Nearest Neighbors algorithm.

• NIOS ii image data and label parsing C program
• VGA I/O to display images and confidence graphics
• SDRAM interface with NIOS and Verilog modules
• Computation Verilog module for Euclidean Distance calculation
• K Nearest Neighbors algorithm implementation.
• Generate classification confidence measures.
• Tuning the algorithm’s parameter K to optimize the algorithm using development data.
• Testing the optimized algorithm for accuracy using a test data.
• Creating the user icontrol interface for inputting images, running the algorithm, and viewing output.

• Qsys & NIOS Processor Implementation
• SDRAM controller interfacing
• VGA controller interfacing
• K-Nearest Neighbors algorithm

​

Our project uses the K-Nearest Neighbors algorithm to classify user-supplied images of handwritten numbers.

​

The algorithm models example images as vectors and calculates the squared euclidean distance between training and input images to classify the number in the input image.

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Future Project title: Breakout Team name: Speedracers

Section: AA Group number: 7

​

We plan to recreate the classic arcade game Breakout.

​

We will start with using purely the FPGA, then expand the project to integrate and C program and input/output from a computer.

​

• User Input module (taken from Bathysphere lab)
• QSys and NIOS II processor implementation
• 8x8 LED array integration (Prereq course)
• Knowledge of game details/specifics
• Stater modules to control the paddle and set up bricks
• Clock divider module
• Counters, FSMs, Clock Timing

• Necessary working components:
• FPGA, Quartus/Verilog, 2D LED Array, Qsys/NIOS II processor, C Programming

​

• Ensure completion by meeting regularly and strictly following the Gantt chart deadlines

​

• Mitigation strategies for high-risk portions:
• Make bricks single-hit
• Simplify pall physics
• Implement auxiliary controls instead of NIOS II processor if too difficult

Breakout game:

• Varying ball speed
• Varying ball rebound angles
• Paddle that moves left/right
• A score/life counter
• Bricks that take multiple hits to break

​

NIOS II Integration:

• Display count for “lives” when they are lost
• Allow user to input control from C terminal

Lab Report:

• Annotated Verilog and C source code for all applications
• Screenshots of testing
• Requirements Doc
• Design Specification
• Functional Decomposition
• Failure Mode Analysis
• Anything we haven’t thought of
• Signature page
• References

Project concept

Risks & risk reduction work done

​

Potential risks

• Proof of concept (show that our project works)
• Check by entering different key for decryption
• Getting the data in and back from the FPGA

Work Done

• Encryption code is completed and in the process of being tested
• Can write 127 byte messages to SRAM and read back; in the process of transferring data between SRAMS

Prior knowledge / background needed

​

Deliverables

1. Encryption
• Subbyte, Shift rows
• Mix Columns, Add Round Key
2. Decryption
• Subbyte, Shift rows
• Mix Columns, Add Round Key
3. Main
• Collect and compile all data
• Interact with NIOS II
4. SRAM stores encrypted and decrypted data to communicate with the PC
5. NIOS II stores generated keys
6. PC - User interface

​

​

​

​

Track: Future Project title: AES Encryption/Decryption Team name: The Best One (AA: Tyler, Thu, Mohamed, Jamie)

• AES encryption works in blocks (e.g. 128 bit)
• Parallelize process using FPGA
• Encrypt:
• Select encryption mode w/ switch
• Type in key and data
• FPGA will encrypt data
• Data stored in SRAM
• Decrypt:
• Type in key, select decryption mode
• FPGA will decrypt encrypted data
• Data stored in SRAM and can be read on console

Project concept

Risks & risk reduction work done

​

NIOS

• One worry is getting the NIOS to work as we add more components and deal with HW/SW integration, but we can build off labs 3 and 4

​

Communication

• Need to figure out how to sync everything up. Have a rough design to make this work
• Build off lab 4 communication modules

​

Strategy

• Break up components into individual modules to allow for better collaboration and easier debugging

​

​

​

Prior knowledge / background needed

Deliverables

​

1. Create a board to track ships, missiles, and blown up ships
2. Integrate board with software
3. Create a scoreboard to keep track of ships destroyed
4. Design a protocol for communicating between players (eg starting a game, sending moves, notifying players of end game or destruction changes)
5. Add support for setting up a game (i.e. getting the board set up and sending a game request for another player)
6. Add an event loop for playing a game (reading input, handling, and printing output
7. Add support for ending a game
8. Stretch goal: add sound effects

Track: Existing Project title: Battleship Team name: AA Team 6

​

We plan to implement a game of battleship that you can play on the DE1_SoC using the NIOS II microprocessor.

​

​

We will integrate the software and hardware by sending signals back and forth to manipulate the state of the game stored in SRAM.

​

​

​

​

​

​

​

​

​

​

• ​
• Counters have been developed for use for syncing and timing purposes

​

• We will build off the NIOS that we built in labs 3 and 4, adding components as necessary

​

• We will need to form a communication protocol built off that developed in lab 4

​

• We will use additional SRAM, similar to that of lab 3.

​

• We need to come up with a good representation of the board

​

• Stretch goal: add audio effects

​

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Future Project title: Snake v2 Team name: Seattle SuperSnakes

​

A multiplayer game interfacing with a cell phone, bluetooth low energy board, FPGA, and VGA display.

​

Players can issue commands indicating snake movement, which are transmitted and interpreted via UART communication protocol.

​

Commands acts as triggers to the FPGA modules that instantiate logic pertaining to the logistics of the game, which update the state of VGA output

Application - User Interface

Application - Communication Protocol

Interface - Phone to Bluetooth Module

Communication - Bluetooth Module to FPGA

FPGA - Single Player Snake

FPGA - Multiplayer Snake

VGA Display Output

System Integration

​

​

Key Risks:

Phone Application (Android).

Communication protocol between phone and Bluetooth module.

Communication protocol between Bluetooth module and FPGA.

​

Risk Reduction Work Done:

Android/ ioS Application.

Bluetooth module is now able to recognize simple button pressed and released on phone application.

​

Prior Knowledge:

UART Communication Protocol.

Arduino Programming.

FPGA Programming.

​

Background Needed:

Bluetooth Communication.

Android Application Programming.

Utilization of Available Communication Protocols of the FPGA.

​

​

​

​

​

Source: Google Images

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Existing Project title: Battleship Team name: AC Team 3

​

We are going to use two DE1_SoC by utilizing microprocessor, GPIO, SRAM and serial-parallel-serial network to implement the Battleship Game.

In the game, each player has to guess the location of opponent’s ships and use weapons to hit them in a 8*8 battlefield, which is 64 address in SRAM.

Users can choose three different kinds of ships, and different ships have different weapons that can cause different damage effects.

It will send data after player attacks opponent, as opponent receives the attack data. Then, the program will write the data into SRAM and Eclipse Console Window.

​

​

1. Allow user to choose to be player 1 or player 2.

(player 1 will attack first)

• Users can type their command in Eclipse Console Window (ship location, attack location)
• User can choose the direction of the ship.
• Three kinds of ships, each ship occupies various spaces in the battlefield (1,2,4 slots).
• Each type of ship has unique symbol shown in the battlefield.
• Different kinds of ships have different weapons that may cause different damage effects.
• 64 address of SRAM to store the battlefield system.

1. Need to check if the location where the users choose is available to put a specific ship in. There might be memory overlap.
2. We need to add more components to the NIOS, which may cause errors.
3. Need to make sure to correctly update the SRAM during each process.

1. User Interface Design
2. Qsys and NIOS implementation. We will build off Lab 3.
3. Serial Communication, as we did in Lab 4.
4. SRAM Implementation
5. Clock Timing
6. Battleship game experiences.

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Existing Project title: Checkers Team name: Shady Oaks

(AB team 6)

​

With the DE1_SoC using the NIOS II microprocessor, we plan to implement a game of checkers.

​

We plan to have an 8x8 checkerboard where we’ll display different checker pieces with different color LEDs. We’ll use serial communication and SRAM in our project.

​

We will integrate the software and hardware by communicating with the DE1_SoC to manipulate the state of the game stored in SRAM.

​

We will use the system console for user interface and interaction, HEX displays to indicate victory, and 8x8 LED array to indicate board state.

​

Potential Risks

• UART Communication Errors

Reduction Work

• Implementing a checksum on outcoming and incoming UART data.
• Define “Packets” to send to LEDS with Header and Footer Bytes.

• Display the game board as a 8x8 LED array
• Allow the user to select the checker they want to move
• Allow 2 player game play
• Allow the user to select the direction to move their checker
• Allows for a king to be indicated with a blinking LED

• NIOS II Processor
• UART Serial communication
• SRAM Implementation
• GPIO Integration
• Checkerboard experience
• 8x8 LED Array timing, wiring, and implementation.

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Future Project title: Pitch Shifter Audio Synthesizer

Team name: Go Huskies (EE/CSE 371AB Team 7)

​

​

Work Done:

• Configure audio drivers (ADC/DAC).
• Connect hardware to NIOS and SDRAM.
• Write algorithm for pitch shifting.

Risks:

• Convert Matlab code into C code
• Potential bugs when running the pitch shift algorithms on NIOS processor

We will need to be familiar with:

• How to build in verilog/System Verilog.
• How to make memories for buffers.
• How to write code for the NIOS in C.
• Basic knowledge of signal processing (such as in E E 235.)
• Understanding of how the Pitch Shifting algorithm works.
• How to use external SRAM on DE1-SoC.
• How to use the audio peripherals on the DE1-SoC.

​

• Working NIOS processor with SDRAM and on-chip memory enabled
• Use audio codec I/O on the FPGA to gather and playback sound waves
• Various versions of test codes for recording, simple volume/pitch modifications, playing back functionalities
• Pitch shift core algorithm in Matlab and C
• User interfaces, like buttons and hex display on the FPGA for controlling and output the pitch shifts
• Detailed lab report showing the descriptions of the project, procedures, algorithms, error and failure, etc.

Description:

Store audio data, and then shift all of the pitches. An important part of Autotune and other audio synthesis.

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Future Project title: The Cool Cam Team name: Golden Eagle

​

The goal of this project is to implement an edge detection on real-time video output through the FPGA. This will be achieved by the use of the D8M-GPIO peripheral camera obtained through the EE lab store. The peripheral camera is equipped with starter-code that already implements real-time video. The software stores two frames at a time into the frame buffer in the SRAM. Then, based on certain switches we will apply different filters and different effects.

Potential Risks:

• Edge Detection using Verliog, if we are not using a MP.
• Accessing The image buffer and modifing it and output it through VGA.
• Debugging!!

Work Done:

• Getting the whole thing to work as we aim!

​

• Frame Reader Module: Reads in the image buffer from the camera.
• Frame Writer: Writes in the image buffer in memory and returns the address of where the image starts.
• Filtration Module: Based on the the key pressed, different filters will be applied on the images such as ( low/high pass, bandpass, some manipulation with rgb coloring, etc.)
• Main Module: links all the sub modules, and outputs the image buffer through VGA.

Prior Knowledge:

Some experience with implementing edge detection algorithms in Matlab as well as experience in Digital Experimental Arts concepts; the latter of which may be useful if we implement the high-pass and low-pass filters successfully and move on to more experimental image manipulation.

Background Needed:

Read/Write to the SRAM, and know how the generated filters interact with images. And See how different filtration may affect quality/noise.

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Existing Project title: Battleship Team name: AB Team 1

​

We are going to play portable game battleship on DE1_SoC based on the knowledge we have learned before. We have two types of battleship that the player could choose, attack submarine and ballistic missile submarine. Different submarine has different type of weapon. You can avoid the attack by your movement or by anti-ballistic missiles. There is a win/lose checker to counter the score and decide who is the winner. Our game needs 2 players so that we need to implement a communication system. Also our project needs to use both verilog and c.

Potential risks:

1. Many variables and pins need to be named and set
2. The movement of ship and missiles need to be precise
3. How to block the attack if we don’t want to move
4. Building a large battlefield

​

Work done:

1. Using SRAM to save and update data from battlefield
2. Build and test a precise timer to control the game

1. NIOS II Processor
2. Communication system
3. SRAM
4. Interlock
5. Timer
6. GPIO
7. Combination between C and Verilog

1. Interlock
2. CPU
3. Communication system
4. Weapon selection
5. Win/loser Checker

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Future Project title: Magic Mic Team name: Team Amber

​

We will be implementing a sound effects circuit using the DE1_SoC board and a microphone.

​

To do this, we will take in audio input through the microphone port on the board, apply various filters to it, and send the modified audio back out through the line out port.

​

These filters could include effects such as pitch-shifting, reverb, echo, and delay.

Risks:

• Need to make sure there’s good enough audio capture in the DE1_SoC to produce a reasonable result.
• Need to make sure audio can be stored in such a way that effects can be applied.

​

Work done:

• We have implemented a basic playback loop with the microphone and confirmed that the quality is good enough to use.

• Audio effects
• Interfacing audio with the DE1-SoC board
• Microphone interface
• Signal processing
• Low pass filters
• Verilog programming

• Basic audio playback
• Three different effects modules
• Real time playback demo
• “Sampled” playback demo
• Lab report

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Future Title: Audio Looper Team name: What is an FPGA? (Section AA Team 8)

​

Using the NIOS II processor, we will receive and audio signal from the DE1_SoC’s audio codec and store sections of it in SDRAM. These sections can then be played back by sending the stored data back to the audio codec to send to Line-Out.

By continuously looping (i.e. replaying) these sections, we can mimic the behavior and functionality of a looper pedal, commonly used by solo performers to create live compositions without the need of multiple performers

• C programming
• Signal processing with a focus on audio
• NIOS II Usage
• Familiarity with looper pedals

• Unable to configure audio reading / writing / storing from scratch?
• Use systemCD Demo
• Unable to handle storing / looping multiple sections of an audio signal?
• Simply combine sections and write them in the same memory location instead of each having their own
• Can’t add / multiply samples correctly?
• Let the user deal with it

• Properly map user input for recording
• Record 44khz SR signal from Line-In
• Display recording status in LEDs
• Auto-play and loop recorded audio
• Channel Muting
• Support for multiple buffers in SDRAM
• 2-channel recording & playback
• 4-channel recording & playback

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Future Project title: Cooley-Tukey Fast Fourier Transform Team name: Sharks with Frickin’ Laser Beams on Their Heads (SWFLBOTH)

Section AB Team 5

​

• Read in audio
• Perform a Fast Fourier Transform
• Cooley-Tukey algorithm
• Divide and conquer can be done in parallel on hardware
• Display frequency domain output to two 8x8 LED boards
• Output the audio read in to�assist with debugging (also�provides option to not have�to hear piercing frequencies)

Risk Reduction Done:

• Audio input - This driver has already been developed
• Audio output - This driver has already been developed
• LED driver - This driver is currently being developed
• FFT module - Research has been done and the course staff consulted during the planning phase; development of this module and its sub-modules has already been started

​

Risks:

• Implementing the algorithm in Verilog (as opposed to higher level languages with pre-written libraries)
• Ensuring signal is not distorted in converting between analog and digital signals
• Wiring the circuit correctly and avoiding short-circuits or other hardware issues

• Audio Input Driver
• Audio Output Driver
• 8x8 LED Board Driver
• FFT Sub-Module (radix-2 base case calculation)
• FFT Top Module (manage sub-module connections, input and output)
• 64-bit Two’s Complement Adder With Overflow Detection And Handling
• 64-bit Two’s Complement Multiplier With Overflow Detection And Handling

• How to use the audio input/output jacks on the DE1-SoC
• How to interpret the data received
• How to ensure stable signals are read
• An understanding of the math behind the Cooley-Tukey algorithm
• How and why it works
• Sampling rates
• Frequency resolution

• Two’s complement, binary, fixed-point addition and multiplication with overflow management

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Existing Track Project title: Board Game Collection

Team name: Section AB Team 2

​

​

​

​

​

1. Serial communication interface
2. Text-base based user interface
3. Graphical display
4. NIOS II processor based system
5. Tic-Tac-Toe game
6. Reversi game
7. Gomoku game
8. A top level system

• Serial Communication
• Platform Designer and Nios II EDS
• Software / Hardware Integration
• UART
• SRAM
• Timing synchronization / Cross clock domain
• Frames(form of data transmission)
• Pin assignments for the LED Matrix
• Rules of Tic-Tac-Toe, Reversi and Gomoku

Risks: 1. NIOS II system / Platform designer

2. Reversi Game Logic

4. Communication between 2 boards

Risk Reduction:

1. Simplify Reversi Rules

2. Or reduce the number of games

Plan: Building a FPGA-based board game collection

Games included: Reversi, Gomoku, Tic-Tac-Toe

Components: Game logic implemented in FPGA

Text-based user interface

Graphical display on LED Matrix

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Existing Project title: 2P Hangman Team name: Team Yeet (AA Team 4)

​

• two DE1 SoC boards connected to two computers running Nios II for Eclipse application.
• will be able to communicate with each other through serial communication.
• randomly choose a word and store in its SRAM.
• each player will then start guessing one character at a time on their respective computers.
• Each computer has its own instance of the game, hence, choosing one character from one computer will not have an effect on the game of the other computer.

• Serial communication - UART port connection
• Tx/Rx between boards for the random word and scoreboard
• Accounting for cases when both players will at the same time.
• Check if the buffer is working correctly by sending single characters at a time, and gradually increasing the number of characters sent.
• Basic communication work to be done to send and receive strings first between two boards before proceeding with integrating the entire game.

​

• Creating microprocessor
• Creating SRAM/ROM for storage
• Serial communication
• C program integration with the board
• C programming
• Platform Designer

• Nios II with SRAM/ROM
• User input interface via keyboard
• CPU
• String Comparator
• TUI (Text based User Interface)
• Score comparison of two different boards
• Lab Report

Project Concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Future Project title: Spectrum Analyzer Team name: Homies

​

Use the FPGA to display a signal’s frequency spectrum

• Audio input from line-in
• Compute the DFT (FFT)
• Display output over VGA

• Discrete Fourier Transform
• FFT algorithm
• CORDIC (sinusoidal LUT)
• Real/Imaginary components
• Analog-to-Digital Converter
• Sampling the input audio
• SRAM/Shift Register
• Audio sample buffer
• VGA

Risks

• Many new peripherals (Audio, VGA)
• FFT

​

Risk Reduction

• 8x8 LED drivers from previous project
• CORDIC LUT for DFT
• DFT vs FFT

1. VGA module output, change the display on a monitor. (8x8 LED matrix)

2. AUX input to the FPGA, output sound

3. SRAM/Shift Register read and write

4. Write and read audio data into the SRAM

5. Display audio data from SRAM on VGA

6. Display DFT with sine wave input

7. Display frequency spectrum in real-time

8. (Extension) Implement the FFT algorithm

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Future Project title: Flappy Dubs

Team name: Programmable Peasants - Lab AC - Team 6

​

​

​

• Make a Flappy Bird clone called Flappy Dubs
• Output over HDMI
• Built using general purpose sprite based 2D graphics accelerator

• Game logic in Verilog
• FPGA Block Ram
• Sprite Storage
• Frame Buffers
• 2D Sprite Rasterization
• VGA Scanning Module
• HDMI encoding and OSERDES output

​

Risks:

• HDMI Output
• Memory Bus to write all the sprites
• Integration of game logic with visual display modules

Reduction:

• Tiered Complexity!
• HDMI Module Written
• Similar Games written in 271/369
• Printing of single sprite working

• Flappy Dubs game written completely in SystemVerilog
• Modules: pipe and dubs locations (game logic), player input
• Simple Parameterized 2D Graphics acceleration framework.
• HDMI Output modules for rasterization and OSERDES.
• Comprehensive Lab Report

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Existing | Project title: Maze Runner | Team name: AA Team #2

​

Our project idea is to create a two player “maze race” game where two players race through a maze on separate DE1-SoC boards and communicate to one another when they reach the end of the maze. The first player to reach the end will win the stage and the maze will reset.

​

The score will be stored in an SRAM attached to both DE1-SoC boards. It will be update when a board/player wins a game or when the overall system is reset. This score will be displayed to both users through a HEX display driver.

​

Bluetooth and UART serial communication will be used to communicate between both boards.

The main risk with this game is getting the NIOS II processor to cooperate. This processor has given us issues in past labs and is an integral part of the implementation of this game.

​

To mitigate this risk, we are trying to only use the processor when needed, and we plan on building hardware modules (using System Verilog) on top of the existing system to give us the additional functionality we desire

1. NIOS II Processor
2. Serial Communication
3. SRAM
4. Timing Issues/Synchronization
5. Bluetooth connectivity

1. Wiring and testing of both LED arrays
2. Implementation of the maze game.
3. SRAM Implementation
4. Hex Display Driver
5. Bluetooth Communication
6. User Input Driver
7. Timing Validation Concerns

Project concept

Risks & risk reduction work done

Prior knowledge / background needed

Deliverables

Track: Future | Project title: Edgy Pictures | Team name: AC Team 5

​

We will make Snapchat, but for the FPGA. In summary, the project will be interfacing a camera onto the FPGA to take photos, which then use the parallel nature of the FPGA to convolve the image with a kernel matrix, and then display the resulting image on VGA to a monitor. We will modularize these separate components so that

we can verify their functionality independently in order to meet the requirements for the project.

​

Major Risks

​

Camera functionality (D8M-GPIO)

​

VGA functionality

Risk Management

​

Slow down system to take one frame at a time

​

Add delay between image and convolution to ensure we see the correct output to VGA

VGA module

​

Image data storage

​

Image convolution module

​

Custom convolutions

​

Camera module

​

Camera Configuration

​

User interface

• Image convolutions and convolutional kernel operations
• Frame buffers and image storage
• Video formatting and representation within verilog modules
• VGA display requirements
• Knowledge of camera operations and how settings like frame rate physically operate

Project concept

Risks & risk reduction

Prior knowledge / background needed

Deliverables

Track: Existing | Project title: Connect 4 | Team name: AB Fantastic 4

​

Connect Four!

​

Take turns flipping switches on the DE1_SoC!

​

VGA Output!

​

Challenge your TA!

VGA will require more work than anticipated

​

Using NiosII may become too cumbersome

​

Project could have been over-scoped

​

Power outage

Intimate knowledge of Connect 4 rules & win conditions

​

UART Serial Communication

​

VGA Output

​

DE1_SoC Development:

Quartus project,

Qsys for NiosII,

Eclipse for NiosII

1. Nios II
2. Handles user input (switches)
3. Verilog code modules
4. VGA Display
5. Quartus Project
6. Lab Report

Print to Eclipse console

or use LED array

​

Implement the game as hardware

​

We decided to choose an achievable project

​

Yikes