# HW 5 ## Objective You are going to extend and modify your previous snake game to implement ***levels*** and ***obstacles***. In particular you will learn to implement and utilize ***case-statement-based state-machines*** and learn to explicitly ***serialize calculations***. ## Due Dates * Due Nov 9: top-level system diagram and top-level game management state-machine description. (5 pts) * Due Nov 19: Project Submission. * Due Nov 20: Report Submission (only updates to the report folders are allowed). ## Description and Requirements * Each level will have 5 food and 10 obstacles (fake food). * The obstacles should be drawn in magenta, but otherwise are like the fence – the game should stop once the snake (head) overlays an obstacle. * Every time the player eats 5 apples within a level, a level is completed. * With each new level, the pace of the game should be increased by a human-perceivable amount (design choice) * The snake size is reinitialized to 1 to start each level * The level score, and the level should be displayed on-screen. ## Design and Implementation Requirements * In this assignment you are required to create a simple ***case-statement-based state machine*** to control and manage levels of the game. * You need to modify your last HW as needed to accept control signals and output status signals to interface with your state machine (This means some of you need to complete AS NECESSARY parts of HW4 in order to complete HW5.) * You need to be able to restart the entire game when BTNC is pressed. * "Obstacle Processor/Manager": In this assignment you are required to create a simple ***case-statement-based state machine*** within a self-contained module that internally generates, stores, and manages obstacles, and it also computes collisions given the appropriate input information about the snake. * Unlike the previous HW for which you may or may not have checked for snake-head to body collisions with _parallel_ check and compare hardware, you should in this assignment _serially_ iterate over the obstacles checking one obstacle for collision in a given clock cycle. There are enough spare clock cycles between the game's frame updates to support serializing this. Overall serialization could require less hardware. * "Food Processor/Manager" this is the same as the obstacle manager, except that food is removed when a collision is detected. As with the obstacle processor/manager, only one comparison may be done per clock cycle. ## Design Approach The design approach and structure is up to you. * I would recommend creating the obstacle management and multi-cycle serialized collision detection module first. * Then separately build a state machine that can control the display to ensure you understand that. * Then build the food manager and test it. * It might be good to build the display module at this point...might help with debugging. * Then, you'll need to implement the top-level game management state-machine. Here is one terse and likely incomplete outline of states that you may follow: * Initial State - send signals to modules to initialize * Wait for subsystems ready (move on to next state after all systems ready) * Get ready for Level * send any control signals required to subsystems, including * initial and level and score for display * initialize commands for obstacle and food and snake modules * wait for any done signals from subsystems as required * Send signals to Start Level * Wait for the outcome from the level * Update internal score and update display if required (wait for scoreboard display drivers) and the go back to starting a new level with updated pace * Finish Game (display an X or some other visual of your choice) ## Additional Notes * Any additional guidelines or submission requirements would be discussed in-class or posted on Piazza and updated in this document correspondingly. ## What to be sure to turn in * Submit the source files, tcl synthesis scripts. (REMEMBER THAT COMMENTING OF CODE WILL BE GRADED). * Create and hand in one multiple Verilog testbench modules that test your design * Create a report that briefly explains your design and your testing You must have one testbench for each module. * Include the output of your Verilog testbench(s) in your report (THIS IS EXPLICITLY GRADED) with additional explanation about each testbench as needed to convince someone that each part of your design works and your simulation-based testing of each module is sufficient. -