Lab 6: Communicating Sequential Logic
Overview
In the last lab, we developed a single FSM to accomplish our task. Now we want to build a more complex system with multiple, interconnected FSMs. Careful creation of a block diagram, along with design and testing of each individual piece, will be key to getting this working well.
Design Problem – Tug of War
Sweat pouring from their brow, body straining, muscles pulsing back and forth, we have the epic conflict that is Tug Of War! It's time to update this rope-based team sport into an electronic analog of finger-pounding power!
We're going to build a 2-player game using the KEY3 and KEY0 buttons and inputs and LEDR9 to LEDR1 as a 9-light playfield. A single LED on the playfield will be lit to indicate the current position of the "ribbon/knot." A player wins by moving the light off his or her end of the playfield.
Design Rules:
- The "ribbon/knot" starts at the centermost LED (LEDR5).
- Player 1 presses KEY0 to move the light one LED to the right and Player 2 presses KEY3 to move the light one LED to the left.
- When a player wins, display the number (1 or 2) of the victor on the 7-segment display HEX0.
- Use SW9 as the reset signal.
- You should use the 50 MHz clock directly (pin CLOCK_50) to control the whole design – we'll assume no player can press the button faster than 25 million times a second…
If you tried to design the entire game as one big state machine, it would get pretty complex and testing would be incredibly difficult. Instead, we are asking you to break it down into smaller pieces for easier testing and for practice making interconnections between different parts of a system.
User Input
To deal with metastability, make sure you send each user input through at least one DFF (we recommend two) before you use it in your logic. This is known as a flip-flop synchronizer.
Since our clock is fast, each button press will span many cycles. Design a simple FSM that works as an edge detector (i.e., its output is high for only 1 cycle for every button press, no matter how long).
Playfield
It is certainly possible to design a single FSM for all 9 lights; however, we want you to design an FSM for each location (LED). A given playfield light needs to know the following:
- Does it start as True or False?
- Which button(s) were just pressed?
- Am I currently lit? Are my right and left neighbors currently lit?
With this information plus the reset signal, it's now possible to figure out whether or not this light should be lit during the next clock cycle. Suggested SystemVerilog starter code for a light can be found in normalLight.sv (code). You may want to create a separate, but similar, module for the center light.
Victory
You can tell when someone wins by watching the ends of the playfield – when the leftmost LED is lit and only the left button is pressed, the left player wins. Similar logic can be found for the right player. Build a unit that controls the HEX0 display based on these victory conditions.
Suggested Interconnections
The modules you design will read user input from KEYs and control the playfield (LEDR) and victory output lights (HEX). The modules described above are only suggestions. You are free to create the design using any number of different modules as long as it is not a single, monolithic FSM.
Build each of the pieces and test them independently in ModelSim before combining them together. Make sure that you can reset your system. TEST EACH ELEMENT IN MODELSIM BEFORE TRYING TO HOOK IT ALL UP. TEST THE WHOLE THING IN MODELSIM BEFORE DOWNLOADING TO THE FPGA. If you try to do everything by just downloading it to the FPGA you will have lots of trouble getting this lab working, and subsequent labs will be much harder – simulation and good test benches are your friend, and will significantly speed up your debugging.
Only once you have all the pieces, and then the entire system, working in ModelSim should you download the design to the FPGA and test the working game (the fun part!).
Lab Requirements
Lab Report
Due before Wednesday section, submitted as a PDF on .
- The top-level block diagram, showing the major modules and how
they are interconnected.
- Top-level ports should be shown as external inputs and output.
- All instantiated modules should be shown as individual blocks with at least their module name labeled.
- The name and directionality should be clear for all port connections.
- Don't forget an accompanying explanation to help the reader.
- For each of the major modules, include a state diagram (if applicable) and screenshot of the ModelSim simulation. Also include a ModelSim simulation for the top-level module.
- A screenshot of the "Resource Utilization by Entity" page, showing your design's computed size.
- How many hours (estimated) it took to complete this lab in total, including reading, planning, designing, coding, debugging, and testing.
- Separately, upload the SystemVerilog code for all of the elements of your design, including the test benches. You MUST have a test bench for the basic elements and the overall design.
Lab Demo
Due by the end of the day on Friday, but typically during your assigned demo slot or a scheduled support hour.
- Explain your top-level block diagram.
- Demonstrate the simulation of your overall design.
- Demonstrate your tug of war game working on the DE1 board.
- Be prepared to answer questions on both the theoretical and practical parts of the lab.
Grading
Working Design
100 points for correctness, style, and testing.
Bonus
Up to 10 points for developing the smallest circuit possible – measure this the same way as in Lab 5. Note that the "Resource Utilization by Entity" report will give you the sizes of each of the modules in your design, so you can focus your sizing improvement efforts accordingly.