HW 3: Light the Candles

Due March 12, 2024

For this assignment you are going to create a game played on the FPGA dev board. In this game the player’s goal is to light all the candles🕯️, which are represented by the LEDs 0 through 7 (🕯️🕯️🕯️🕯️🕯️🕯️🕯️🕯️) on the board just above the switches.

The game starts by the player pressing the RESET button (BTNR(M17)).

The match/ignitor 🔥 is placed initially at a position 0.

The human player may light the candles by moving the position of the match🔥 to a given🕯️. Repositioning of the match🔥 is triggered using the BTNC (N17) button ⚫ on the board. A player can ignite/reignite at the current position of the match🔥 by setting the switches to zero and pressing BTNC⚫. Any desired horizontal movement in match to another another position is provide by the four switches which indicate a value from 7 to -8, in binary two’s compliment.

Once a candle🕯️ is lit, the player keep the match🔥 in the same position (using delta=0) or to another location using the delta provide by the switches.

Here is the challenge: The candles🕯️ you light will continually be randomly extinguished by the extinguisher🧯 must be relit by the match🔥. More specifically: each time you push BTNC⚫, an extinguisher🧯 will randomly choose a position and also randomly decided whether to extinguish or not. Therefore, the player’s strategy is to make as few presses of BTNC⚫ as possible and choose. Secondly, note that there is no direct indicator of where the 🔥 is so the player must mentally keep track of the match position.

Modules to Write and Test

Module 1: igniter🔥

• igniter (player) module:
  • The declaration should be as follows: module igniter(position, delta, enable_move, sys_clk,clr_n);
    • position: output that indicates the position of the match, this value should always be in the range [0,7]
    • delta[3:0], enable_move: when the enable_move signal is high and a positive clock edge arives, the position should change by the value provided from the signal delta
      • The new position should be calculated according to modular arithmetic (mod 8), e.g. 6+2 becomes 0, 6+3 becomes 1, 2-4 becomes 6, 4-2 becomes 2
    • sys_clk is the system clock signal
    • clr_n is an asynchronous clear signal, which sets the position to 0
• Create a testbench to demonstrate proper behaviour
• Along with the module source and the testbench, provide a waveform or text output from the testbench simulation convincingly demonstrating proper functionality

Module 2: extinguisher🧯

• extinguisher module (will cause a candle to be extinguished at random):

  • module declaration should be as follows: module extinguisher(extinguish, position, enable, clk, clr_n );
  • within this module, implement an internal counter which counts from 0 to 15 repeatedly, it should increment with every cycle of the system clock (100 Mhz) (this is so fast that it will effectively appear as a random value to a human that might sample its value repeatedly)
  • extinguish is a 1-bit output signal, it should be high if the the enable signal is high AND the internal counter is at a value in the range [0 to 7] (thus only half the time indicating a candle to go off if not off already)
  • the position should be a value from 0 to 7 taken from the lower bits of the internal counter
  • enable is a 1-bit input signal, its use is described above (note that is does not affect the internal counter or pos). In the final game it will recieve a signal derived from the jump signal so that a candle might be extinguished every time the play makes a jump.
  • sys_clk is the system clock signal
  • clr_n is an asynchronous clear signal, which should set the position to 0

• Create a testbench to demonstrate proper behaviour

• Along with the module source and the testbench, provide a waveform or text output from the testbench simulation convincingly demonstrating proper functionality

Module 3: candle_controller🕯️

• Create a module to store and control the state of the candles.

• The declaration should be as follows: module candle_controller(candle_state, pos_to_set, set_enable, pos_to_clear,clear_enable, sys_clk,clr_async);

  • candle_state[7:0]: an output which indicates the state of the 8 candles (a high designates a lit candle)
  • whenever the set_enable signal is high, the pos_to_set[2:0] provided in the same clock cyle is used to set the corresponding candle bit high
  • whenever the clear_enable signal is high, the pos_to_clear[2:0] provided in the same clock cyle is used to clear the corresponding candle bit
  • a set should have precedence over a clear if both are commanded to the same position in the same clock cycle
  • sys_clk: is the system clock signal
  • clr_async: an asynchronous which whenever it is high the value of 0 should be loaded into the state register

• Create a testbench to demonstrate proper behaviour

• Along with the module source and the testbench, provide a waveform or text output from the testbench simulation convincingly demonstrating proper functionality

(note added May 21, 2024 based on earlier discussion: a consequence of this specification is that the value extinguised is based not based on the updated position since there is a register delay in the extinguisher. A combinational pathway through the extinguisher could avoid this, but it was not requested in this version of the HW)

Module 4: Top Module to implement the game

At this point you can assemble the game from the parts you’ve created, any required glue logic, and an appropriate contraints file. The results should be demonstrated on the FPGA board. I have provided a one-shot module that creates a one-cylce pulse every time the button is pressed and held to prevent multiple presses being registered due to bouncing (I don’t know if it is required on this board or not but I thought it would be safer to do this). You should include this in your design. You should provide this and all source code including the ucf used for your project. (I do not mandate a testbench to be submitted for this module, but I recommend you create one or more and simulate as much of your design as possible before testing on the board.)
debounce_and_oneshot.v

Special Note

When you implement your physical design, you may note that one of the switches is “trimmed” from the design. Give this some thought and investigate what it says about the arithmetic performed and the hardware synthesis process. Also consider how it relates to a players strategy in using the interface. You may include a discussion in your report if you like but I am not specifically asking for it.

Report

Create a report that briefly explains your completion for each part as well as the top module, and provide a description of the testing results. Your discussion should include a description of the tests performed and text or waveform outputs from stimulations. Provide pictures and text outputs directly in the report. If a text output is too long to include in a report, include the output as a file with your submission, then make reference to it and included only key output lines in the report itself. Also, make references to source files used where appropriate. Your report should be able to convince someone that your design works and your simulation-based testing is sufficient. Your final physical testing for the last module should be discussed as well.

Grading Guidelines (subject to small changes with announcement)

Correctness (40 pts) e.g.

• Completeness of homework and matching specifications

Design (20 pts) e.g.

• Usage of Blocking and Non-blocking according to lectures
• Choice for Default case
• Unnecessary use of extra clocks in design

Test-bench and thoroughness of testing and reporting (15 pts) e.g.

• Use of $finish letting TA/Grader know that simulation is complete

Style (10 pts) e.g.

• Well-commented code
• Meaningful variable names
• Meaningful file names

Documentation (15 pts) e.g

• Student should clearly state to what degree that the code is complete and works
• Block diagram of the design
• Students should clearly state Usage Instruction: if its Board assignment
• Legible/Readable Results/Graphs/Waveform Presentable

Late Policy:
One or Two day late: 20/100 points off