Lab 3: Music Player
Part C: FPGA Prototype V1
Lab 3 will give you experience designing, implementing, testing, and prototyping combinational and sequential logic using the Verilog hardware description language. The lab will continue to leverage concepts from Topic 2: Combinational Logic, Topic 3: Boolean Algebra, and Topic 4: Combinational Building Blocks but will also leverage concepts from Topic 6: Sequential Logic, Topic 7: Finite-State Machines, and Topic 8: Sequential Building Blocks. More specifically, the lab will give students experience with: latches, flip-flops, and registers; Moore and Mealy FSMs; and counters. The lab will continue to reinforce three key abstraction principles: modularity, hierarchy, and regularity.
You will be implementing a music player that takes as input a song selection (via the switches) and a start song signal (via a push button). The music player will then play the chosen song by generating a square wave at appropriate note frequencies suitable for use with a piezoelectric buzzer. An idle signal is displayed using an LED so that the user knows when the player is ready to play a new song. The music player will make use of the adders and muxes from Lab 2. The song selection and the current note are both displayed using seven-segment displays from Lab 1. This lab also serves as a transition from lower-level gate-level (GL) modeling to higher-level register-transfer-level (RTL) modeling. Some of parts of your design will use explicit GL modeling, while other parts of your design will use RTL modeling. Students will have a chance to appreciate how RTL modeling can improve productivity but with less control over the final hardware implementation. The lab includes five parts:
-
Part A: Counter and Note Player
- Due 10/19 @ 11:59pm via GitHub
- Students should work on Part A before, during, and after your assigned lab section during the week of 10/6
- Pre-lab survey on Canvas is (roughly) due by end of lab section during the week of 10/6
-
Part B: Multi-Note and Music Player
- Due 10/26 @ 11:59pm via GitHub
- Plan to work on Part B after fall break and during the week of 10/20
-
Part C: FPGA Prototype v1
- Due week of 10/20 during assigned lab section
- This part will focus on prototyping the code developed in Part A
- Even though completed with a partner, every student must turn in their own paper check-off sheet in their lab section!
-
Part D: FPGA Prototype v2
- Due week of 10/27 during assigned lab section
- This part will focus on prototyping the code developed in Part B
- Even though completed with a partner, every student must turn in their own paper check-off sheet in their lab section!
-
Part E: Report
- Due week of 10/27, three days after lab section @ 11:59pm via Canvas
- Post-lab survey on Canvas is due at the same time as the report
This handout assumes that you have read and understand the course tutorials and that you have attended the discussion sections. This handout assumes you have successfully completed Part A, meaning your counter and note player are all working in simulation.
What do we do if Part A is not done?
We assume students have completed Part A. If your counter is working and passing all of the tests but your note player is not working, we do not recommend trying to get the note player working first. Instead first show a TA your counter passing the tests in Task 2 and then go ahead and focus on Lab Check-Off Tasks 3-7. Once those are done you can go back and try to get your note player working and thus complete Lab Check-Off Tasks 2 and 8+. If your counter is also not working, then you must focus on getting your counter working before you can complete anything in Part C.
Here are the steps to get started:
- Step 1. Find your lab partner
- Step 2. Find a free workstation
- Step 3. Ask the TAs for a lab check-off sheet (each student needs their own check-off sheet)
For each lab report task you must take some notes, save a screenshot, and/or record some data for your lab report. The lab report is not due until after Part D is completed.
For each lab check-off task you must raise your hand and have a TA come to check-off your work. The TA will ask you the questions included as part of the lab check-off task and the assess your understanding using the following rubric: mastery; accomplished; emerging; beginning. If the TA and students together feel the students have not mastered the lab check-off task, the students are encouraged to take a few minutes and try again.
What do we do if the TAs are busy?
Students must maintain a sense of urgency throughout the three hour lab section. When you get to a lab check-off task, raise your hand for 2-3 minutes. If no TA is available you must keep going; if nothing else read ahead and make a plan for the next section of the lab handout. If you do nothing and wait 20-30mins with your hand raised for a TA then you will not be able to finish all of Part C. You must be strategic. Keep moving through the handout and bring over a TA when they are free to possibly look at multiple lab check-off tasks. If you are truly stuck and no TA is available, ask your neighbors. We need to all work together to make sure every student can complete Part C. There are no extensions and students cannot complete Part C at any other time except during their assigned lab section.
Lab Check-Off Task 1: Setup Lab Kit
The TAs will pass out an ECE 2300 Lab Kit to each group. The TAs will record the kit number on your check-off sheet. For this lab, you will receive the FPGA board and a USB cable. Use the USB cable to plug the FPGA board into the workstation.
1. Simulate the Note Player
Before starting to work on an FPGA prototype, you must make sure you have
a working Verilog hardware design that has been thoroughly tested in
simulation. One student should start VS Code on the workstation, log into
the ecelinux servers, source the setup script, and make sure their
individual remote repository is up to date.
Where XX is your group number. Now run all of the tests from a clean
build to ensure your design is fully functional.
% cd ${HOME}/ece2300/groupXX
% trash build
% mkdir build
% cd build
% ../configure
% make check-lab3-partA
We now need to get the files for your design from ecelinux onto the
workstation. This requires multiple steps.
-
Step 1. Click Microsoft Edge on the desktop to open a web-browser on the workstation to log into GitHub and then find your repository
-
Step 2. Start PowerShell by clicking the Start menu then searching for Windows PowerShell
-
Step 3. Use the following command to change to your home directory on the workstation in the lab (where
netidis your Cornell NetID)
- Step 4. Clone your repo onto the workstation by using this command in
PowerShell (where
netidis your Cornell NetID, notice we are using https!):
-
Step 5. In the Connect to GitHub pop-up, click Sign in with your browser
-
Step 6. You may be asked for your GitHub username again and you may be asked to authorize the Git Credential Manager; click authorize git-ecosystem
-
Step 7. Verify that you have successfully cloned your repo by changing into your repo and using
treeon the workstation:
Lab Check-Off Task 2: Verify Design in Simulation
Show a TA that your hardware designs are passing all of test benches
on ecelinux. If your counter is working but the note player is not
working, then the TA will tentatively mark this task with a 3, but you
can come back and try to get the note player working at the end of
the lab to potentially increase your score to a 5. You cannot
continue to the next tasks unless you have at least showed your
counter working in simulation.
2. Setup Quartus Project
Click Quartus (Quartus Prime 18.1) on the desktop to start Quartus. Important: Ensure that the Quartus Version is 18.1 and not 23.1. Then, click Run the Quartus Prime software. You might need to try starting Quartus twice. Setup a new Quartus project using the New Project Wizard:
- Directory, Name, Top-Level Entity
- You must enter the working directory as follows with your NetID!
- Working directory:
C:\Users\netid\lab3c - Name of this project:
lab3c - Name of top-level design entity:
lab3c - Click Next
- Directory does not exist. Do you want to create it?
- Click yes
- Project Type
- Choose Empty Project
- Click Next
- Add Files
- Click User Libraries...
- Click triple dots to the right of Project library name
- Click on This PC, then navigate to your cloned repo by choosing Windows (C:) > Users > netid > groupXX where XX is your group number
- Click Select Folder
- Click Add
- Click OK
- Click triple dots to right of File name
- Click on This PC, then navigate to your cloned repo by choosing Windows (C:) > Users > netid > groupXX > lab3 where XX is your group number
- Shift-click on every Verilog hardware design file (do not include
any files in the
testorsimsubdirectories) - Click Open
- Click Next
- Family, Device, and Board Settings
- Click Board tab
- Family: Cyclone V
- Select DE0-CV Development Board
- Make sure Create top-level design file is checked
- Click Next
- EDA Tool Settings
- Click Next
- Summary
- Click Finish
As in Lab 2, you must use the following steps to ensure Quartus knows your design includes RTL modeling:
- Choose Assignments > Settings from the menu
- Select the category Compiler Settings > Verilog HDL Input
- Under Verilog version click SystemVerilog
- Click OK
3. Synthesize and Analyze Counters
We will start by synthesizing and analyzing the two different counter implementations. Once we better understand the tradeoffs in these implementations, we can make high-level conclusions about their tradeoffs.
Lab Report Task 1: Save Gate-Level Counter Block Diagram
Make sure you have the block diagram for your gate-level counter which you prepared in Part A. If you did not draw a block diagram in Part A, then you must draw a diagram now. Save this diagram since you will be annotating it later in the lab.
Lab Check-Off Task 3: Discuss Gate-Level Counter Block Diagram
Show a TA your GL counter block diagram and the corresponding Verilog code for the GL counter in VS Code side-by-side. The TA will ask you to connect the block diagram to the Verilog code. Explain how loading a new value works. Explain how the enable signal for both registers and the done signal are implemented. Predict where the critical path will go using the block diagram.
3.1. Synthesize and Analyze GL Counter
To synthesize and analyze the GL Counter in isolation use the following steps:
- Find the Project Navigator pane
- Click on Hierarchy to display the drop-down list
- Choose Files and select the
Counter_16b_GL.vfile - Right click on the file and choose Select as Top-Level Entity
- Click on Files to display the drop-down list again
- Choose Hierarchy and confirm that
Counter_16b_GLis shown as the only entity
As in Lab 2, we need to create a timing constraint file. Unlike in Lab 2, we also now need to inform the tools that there is a clock signal as part of our design. Identifying the clock signal will enable the tools work to ensure that our design has no setup or hold time violations. Similar to Lab 2, when finished, the design will either "meet timing" (i.e., the actual critical path delay is less than the constraint and there are no hold time violations) or "not meet timing" (i.e., the actual critical path delay is greater than the constraint or there are hold time violations).
Here are the steps to create a timing constraint file:
- Choose File > New from the menu
- Click Synopsys Design Constraints File
- Click OK
- Enter the constraints shown below
- Click File > Save from the menu
- Name the file timing.sdc
- Save the file in the lab3c directory
We will use the following initial constraints:
# Constrain paths that start at an input port and end at an output port
set_max_delay -from [all_inputs] -to [all_outputs] 20
set_min_delay -from [all_inputs] -to [all_outputs] 0
# Constrain paths that start at a flip-flop and end at a flip-flop
create_clock -name clk -period 20 [get_ports {clk}]
# Constrain paths that start at an input port and end at a flip-flop
set_input_delay -add_delay -clock clk -max 0 [all_inputs]
set_input_delay -add_delay -clock clk -min 0 [all_inputs]
# Constrain paths that start at a flip-flop and end at an output port
set_output_delay -add_delay -clock clk -max 0 [all_outputs]
set_output_delay -add_delay -clock clk -min 0 [all_outputs]
These constraints constrain four kinds of paths:
-
Paths that start at an input port and end at an output port
- These paths must have a maximum delay of 20ns
- These paths must have a minimum delay of 0ns (i.e, the hold time is 0ns)
-
Paths that start at a flip-flop and end at a flip-flop
- These paths must have a maximum delay of 20ns (i.e., the clock period is 20ns)
- The hold time constraint is provided by the timing parameters for the actual flip-flops as opposed to being in the timing constraint file
-
Paths that start at an input port and end at a flip-flop
- These paths must have a maximum delay of 20ns (i.e., the setup time is 0ns)
- There is an additional 0ns of propagation delay outside this module to get to the input port
- There is an additional 0ns of contamination delay outside this module to get to the input port
-
Paths that start at a flip-flop and end at an output port
- These paths must have a maximum delay of 20ns (i.e., the setup time is 0ns)
- These paths must have a minimum delay of 0ns (i.e, the hold time is 0ns)
Now use the following steps to synthesize your design.
- Choose Processing > Start Compilation from the menu
- Wait 1-2 minutes for synthesis to complete
How do I fix "can't open Verilog Design File" errors?
This probably means you did not setup the user library correctly, so
Quartus cannot find the files you are including using the include
Verilog preprocessor directive. You can use the following steps to
fix this:
- Choose Assignments > Settings from the menu
- Select the category Libraries
- Click triple dots to the right of Project library name
- Click on This PC, then navigate to your cloned repo by choosing Windows (C:) > Users > netid > groupXX where XX is your group number
- Click Select Folder
- Click Add
- Click OK
- Choose Processing > Start Compilation from the menu to see if this fixes the issue
How do I fix "Verilog HDL syntax" errors?
This might be because you did not configure Quartus to use SystemVerilog! You can use the following steps to ensure Quartus knows your design includes RTL modeling:
- Choose Assignments > Settings from the menu
- Select the category Compiler Settings > Verilog HDL Input
- Under Verilog version click SystemVerilog
- Click OK
Now let's look at the RTL viewer, technology map viewer, and chip planner.
- RTL Viewer
- Choose Tools > Netlist Viewer > RTL Viewer from the menu
- Drill down in the hierarchy to see the netlist for the counter
- Does the RTL viewer match your expectations?
- Choose File > Close from menu to close the RTL viewer
- Technology Map Viewer
- Choose Tools > Netlist Viewer > Technology Map Viewer (Post-Fitting)
- Drill down into the adder all the way to see the implementation of the full adder
- Does the technology viewer match your expectations?
- Choose File > Close from the menu to close the technology map viewer
- Chip Planner
- Choose Tools > Chip Planner from the menu
- Identify where the logic used to implement your design is located in the FPGA
- Choose File > Close from the menu to close the chip planner
The next step is to analyze the area of your design.
- Choose Processing -> Compilation Report from the menu
- Under Table of Contents choose Fitter > Resource Section > Resource Usage Summary
- Look through the report to determine the number of combinational ALUTs (configurable look-up tables) that are used for your design
- Look through the report to determine the number of dedicated logic registers that are used for your design
You will be working to fill in this data table:
Make a copy of this table, and enter in the data for your GL counter with a 20ns critical path delay constraint. You can find the number of 7-input ALUts, 6-input ALUts, etc in the area report. You can find the dedicated logic registers also in the area report. We will not be sweeping the clock constraint but instead we will only analyze our design with a 20ns critical path delay constraint.
The final step is to analyze the timing (i.e., the critical path delay) of your design. We will analyze timing for the Slow 1100mV 85C Model which is the default choice in the Timing Analyzer.
- Choose Tools > Timing Analyzer from the menu
- Double-click Update Timing Netlist
- Choose Reports > Custom Reports > Report Timing from the menu
- Report Timing
- Clocks - From clock: clk
- Clocks - To clock: clk
- Targets - From: [get_registers *]
- Targets - To: [get_registers *]
- Report number of paths: 1
- Enter the file name as
counter-gl-critical-path.txt - Click Report Timing
- Identify the propagation delay of the displayed path
- Look at the actual critical path (i.e., Data Arrival Path) which shows the longest path from one of the inputs through your design to one of the outputs
- Choose File > Close from the menu to close the timing analyzer
Note that your GL counter will not meet timing. This is because the FPGA tools do not understand that your gate-level flip-flop is actually a register (check the number of dedicated logic registers in the area report to confirm this). The FPGA tools are designed to recognize specific RTL patterns and infer appropriate sequential logic, but they are simply not designed to recognize specific GL patterns. Even so, we can still analyze the critical path in our design.
We will use the following conventions when analyzing the critical path based on FPGA timing reports. The FPGA timing report will have three parts:
-
The clock part of the data arrival path. This is the delay from the clock pin to the flip-flop at the start of the path. We will ignore this part in this class!
-
The data part of the data arrival path. This is the actual propagation path delay from one flip-flop to another flip-flop. This is the part you need to report on in this class!
-
The clock part of the data required path. This is the delay from the clock pin to the flip-flop at the end of the path. We will ignore this part in this class!
The following timing report illustrates these three parts:

The above image shows that you should count the delay from the start of the path until the signal leaves the initial flip-flop or register module as the clock-to-q delay, and you should count the delay from when the signal enters the final flip-flop until the end of the path as the setup time. If you select multiple cells in the Incr column and hover your mouse it will display a pop-up showing the sum of the delays along that portion of the path.
Also notice that the propagation path delay and the slack do not add up to the clock constraint. This is due to clock skew. Clock skew means the clock reaches the initial and final flip-flops at a different times. We know from lecture that the setup time constraint including clock skew is as follows:
Where \(t_{pathdelay}\) includes \(t_{pd,cq}\), \(t_{pd,comb}\), and \(t_{setup}\). The difference between the left hand side and right hand side of the above inequality is called the "slack", so we can turn this inequality into an equality as follows:
We know \(t_{constraint}\) (we specify this in the timing constraint file), \(t_{pathdelay}\) (this is in the timing report), and \(t_{slack}\) (this is also in the timing report). So we can calculate the effective clock skew as follows:
The effective clock skew is different from what you will see in the timing report because the tools are using a more complicated calculation. For our purposes you should always use the effective clock skew as calculated above. A negative effective clock skew means the clock reaches the final flip-flop before it reaches the initial flip-flop. A positive effective clock skew means the clock reaches the initial flip-flop before it reaches the final flip-flop.
Enter the slack and critical path delay in the data table. The spreadsheet will calculate effective clock skew for you.
Lab Report Task 2: Collect Data for Gate-Level Counter
Save your completed data table with your analysis of the gate-level counter and include it in your report. Draw the critical path on your block-level diagram. Annotate the clock-to-q delay, the propagation delay of each block along the critical path, and the setup time on your block level diagram. Save the critical path timing report text file and include it in your report. You only want to save the Data Arrival Path from the timing report text file. Do NOT include anything else from the timing report text file. You must format the critical path with a fixed-width font and size the font such that it fits on a single page. You might need to delete some rows from the critical path to make it fit. Try to make sure that the remaining rows still clearly show where the critical path goes. If you do not follow this requirements then we will ignore your critical path in the lab report.
Lab Check-Off Task 4: Discuss Gate-Level Counter Area and Timing
Show a TA your data table and timing report. Explain why there are no dedicated logic registers. Show a TA the critical path on your block diagram and clearly show how the delays in the timing report correspond to the delays annotated on the block diagram. Is this the critical path you expected?
3.2. Synthesize and Analyze RTL Counter
Use the same process to synthesize and analyze the RTL counter in isolation. Remember to change that hardware module to be the top-level entity using the following steps:
- Find the Project Navigator pane
- Click on Hierarchy to display the drop-down list
- Choose Files and select the
Counter_16b_RTL.vfile - Right click on the file and choose Select as Top-Level Entity
- Click on Files to display the drop-down list again
- Choose Hierarchy and confirm that
Counter_16b_RTLis shown as the only entity
Go through the same process of looking at the RTL Viewer, Technology Map Viewer, and the Chip Planner. Spend time looking at the Technology Map Viewer and try to figure out how the blocks in the Technology Map Viewer connect to your Verilog implementation. Hint: Zoom in on the technology mapper viewer and look at what the different blocks are named. If several blocks are named something related to comparator then they are likely implementing the comparator. If several blocks are named something related to adder then they are likely implementing the adder. The registers should be two green boxes. Again, look at the names to try and figure out which register maps to which green box. Note that sometimes Quartus will embed a mux into a register so consider looking closely at the ports to the register or zooming into see what is inside the register.
Go through the same process of determining the area utilization. Do the number of dedicated logic registers match your expectation? Go through the same process of conducting a timing analysis. Enter the area, slack, and critical path delay in the data table. The spreadsheet will calculate effective clock skew for you.
Your RTL counter should meet timing. This is because the FPGA tools do understand that your RTL flip-flop is actually a register (check the number of dedicated logic registers in the area report to confirm this). As mentioned above, the FPGA tools are designed to recognize specific RTL patterns and infer appropriate sequential logic. You will likely observe that the area is much less than the GL implementation and the critical path is much shorter. This because for the GL counter the tools were not able to actually do any timing optimization because they did not understand how the timing constraints connected to the GL flip-flop, while for the RTL counter the FPGA tools are able to do standard timing optimization.
Lab Report Task 3: Collect Data for RTL Counter
Save your completed data table with your analysis of the RTL counter and include it in your report. Save a screenshot of the technology mapper view for your RTL counter. Annotate this screen shot by circling what logic implements:
- (1) The storage element that keeps track of the current count
- (2) The storage element that keeps track of the finish value
- (3) The logic that increments the count
- (4) The logic that determines what should be the next stored count
- (5) The logic that determines whether the counter is done
Clearly label each circle with the corresponding Verilog code snippet. Save the critical path timing report text file and include it in your report. You only want to save the Data Arrival Path from the timing report text file. Do NOT include anything else from the timing report text file. You must format the critical path with a fixed-width font and size the font such that it fits on a single page. If you do not follow this requirements then we will ignore your critical path in the lab report.
Lab Check-Off Task 5: Discuss RTL Counter Area, Timing, and Technology Mapping
Show a TA your data table and timing report. Justify why the number of dedicated logic registers makes sense. Show a TA your technology map screen shot annotated with Verilog code snippets. Explain to the TA the connection between the Verilog code and the actual low-level logic gates. Are we convinced that RTL modeling does indeed turn into low-level logic gates?
4. Counter FPGA Prototype
We now have a fully verified Verilog hardware design, and we have finished a rigorous comparative analysis of the area and timing of both a GL and RTL counter. The last step is to integrate, synthesize, and configure the FPGA with our RTL design and demonstrate the final FPGA prototype!
4.1. Integrate
We need to change the top-level entity to be DE0_CV_golden_top.v using
the following steps:
- Find the Project Navigator pane
- Click on Hierarchy to display the drop-down list
- Choose Files and select the
DE0_CV_golden_top.vfile - Right click on the file and choose Select as Top-Level Entity
- Click on Files to display the drop-down list again
- Choose Hierarchy and confirm that
DE0_CV_golden_topis shown as the only entity
The New Project Wizard creates a top-level Verilog module for us which
has ports for all of the switches, LEDs, seven-segment displays, and pins
on the FPGA development board. We need to instantiate Counter_16b_RTL
in this top-level Verilog module along with three instances of
DisplayOpt_GL and connect the ports. Students are responsible for
figuring out the appropriate top-level port connections to meet the
following specification.
rstshould be connected to the reset button on the board- The first button is for
clk - The second button is for
load - The left five switches are for
start - The right five switches are for
finish - The first LED is for
done - The two seven-segment displays on the left are for
start - The two seven-segment displays in the middle are for
finish - The two seven-segment displays on the right are for
count

You should ensure your counter is always enabled and that the counter
always increments by 1. Note that FPGA's reset (RESET_N) and all of the
buttons are active-low. Unpressed buttons output a logic one and
pressed buttons output a logic zero. We provide you a suitable template
below for your top-level implementation below. You will need to fill in
how these modules connect to the top-level ports.
Use the following steps when you are ready to integrate the counter.
- Double-click on DE0_CV_golden_top
- Instantiate the template shown above
- Fill in the connections to the top-level ports
- Be sure to use
`include "lab1/DisplayOpt_GL.v"at the top - Choose File > Save from the menu
Lab Check-Off Task 6: Discuss Counter Integration
Show a TA your top-level integration. Discuss how you connected your counter's ports to either constant values or the FPGA's switches, push buttons, LEDs, and seven-segment displays.
3.4. Synthesize
We need to update our timing constraint file as follows:
# Constrain paths that start at an input port and end at an output port
set_max_delay -from [all_inputs] -to [all_outputs] 20
set_min_delay -from [all_inputs] -to [all_outputs] 0
# Constrain paths that start at a flip-flop and end at a flip-flop
create_clock -name clk -period 20 [get_ports {KEY[0]}]
# Constrain paths that start at an input port and end at a flip-flop
set_input_delay -add_delay -clock clk -max 0 [all_inputs]
set_input_delay -add_delay -clock clk -min 0 [all_inputs]
# Constrain paths that start at a flip-flop and end at an output port
set_output_delay -add_delay -clock clk -max 0 [all_outputs]
set_output_delay -add_delay -clock clk -min 0 [all_outputs]
The key difference is that we are specifying that the first push button
(i.e., KEY[0]) will be used as the clock for the counter. From here,
choose Processing > Start Compilation from the menu to synthesize your
design.
3.5. Configure
Now we are finally ready to configure the FPGA for our counter demo!
- Choose Tools > Programmer from the menu
- Click Hardware Setup
- Currently selected hardware: USB-Blaster [USB-0]
- Click Close
- Click Start
Test out your counter. Load in different start and finish values. Press the first push button to toggle the clock. Try resetting the counter. Ensure the displayed count and done signal correspond to your expectations.
Now we want to make sure the counter interactive simulator is working on
ecelinux. First, let's make sure you have the right version.
If +help displays this, then you have the correct version:
If instead +help displays this, then you have the old version:
What do to if we have the wrong version of the simulator?
We pushed an improvement to the simulator over the weekend. You might have forgotten to pull those changes at the beginning of the lab section. Please pull those changes and try again.
Now you can try using the counter interactive simulator with different start and finish values.
% cd ${HOME}/ece2300/groupXX/build
% make counter-sim
% ./counter-sim +start-switches=00000 +finish-switches=01000
% ./counter-sim +start-switches=00011 +finish-switches=01000
Try out your counter simulator for a few values, and make sure that the FPGA behaves identically.
Lab Check-Off Task 7: Demonstrate the RTL Counter
First, show a TA the counter interactive simulator, demonstrating its functionality. The TA will give you a switch configuration. You should first predict what your counter will do, then demonstrate it in simulation. Then demonstrate that your counter on the FPGA produces identical results for the same stimulus. Additionally, demonstrate that your counter can load new start and finish values at any time. Clearly explain to the TA why the counter prototype is different from the calculator prototype in Lab 2; explain how the counter prototype illustrates sequential logic.
5. Understanding GL vs RTL Note Players
You are welcome to experiment with synthesizing and analyzing your GL and RTL note player, but this is not required. In this part, we will focus more on demonstrating our understanding of these two implementations and also using simulation to measure the period and frequency generated by your note player.
5.1. Comparing GL and RTL Note Players
Start by making sure your GL note player implementation worksheet is complete. Students were supposed to complete this worksheet in Part A. If you did not complete this worksheet, please do so now. It is located here:
Now use VS Code to bring up two windows showing the finite-state-machine implemented in the GL and RTL note player control units side-by-side. Carefully compare these implementations and convice yourself of the connection between the three sections (flip-flops/register sequential logic, next state combinational logic, and output combinational logic).
Lab Report Task 4: Save GL Note Player Worksheet
Save this GL note player worksheet since you will need to include it in your lab report.
Lab Check-Off Task 8: Compare GL and RTL Note Players
Start by showing the TA your GL note player worksheet. Explain how this worksheet connects to the GL Verilog implementation. Then show a TA the code in VS Code for the GL and RTL note player units side-by-side. The TA will ask the student to explain the connection between the two implementations including the specific lines of code in both implementations that make this a Moore FSM. Have you convinced yourself that higher-level register-transfer-level modeling eventually turns into lower-level logic gates?
5.2. Measure Note Player Period/Frequency in Simulation
Let's now use the note player interactive simulator to generate a note and measure its period/frequency to convince ourselves that, at least in simulation, our note player could generate the correct notes. Next week we will actually be testing out our note player on the real FPGA and using it to play music!
You can build and run the note player interactive simulator on ecelinux
as follows.
The switches command line option encodes an eight binary number which
is connected to the period input of the note player. We are going to run
our note player with a relatively large clock period of 20480ns. The
period is the number of these clock periods when the clock should be
high. Here is the mapping from switch settings to notes:
period period freq
switches hex dec (cycs) (ms) (Hz) note
0111_1011 0x7b 123 250 5.12 195.31 G3
0110_1101 0x6d 109 222 4.55 219.95 A3
0110_0001 0x61 97 198 4.06 246.61 B3
0101_1011 0x5b 91 186 3.81 262.52 C4
0101_0001 0x51 81 166 3.40 294.15 D4
0100_1000 0x48 72 148 3.03 329.92 E4
0100_0100 0x44 68 140 2.87 348.77 F4
Pick a note and run the note player interactive simulator with the
corresponding switch settings. The note player interactive simulator will
generate a waveform file named note-player-sim.vcd. Open this file
using Surfer. Display the following signals in surfer: clk, rst,
player_state, and note. Then measure the note period in Surfer like
this:
- Choose Settings > Time Unit > ms to display time in milliseconds
- Left-click on the note waveform
- Use the left/right arrow keys to navigate your cursor to a rising edge
- When the red cursor is at the rising edge, press 'M' on your keyboard to add a marker
- Left-click on the note waveform again, and using the left/right arrow keys, navigate your cursor to the next rising edge.
- When the red cursor is at the next rising edge, press 'M' on your keyboard to add another marker
- Surfer shows you the delta which is the period of the note (one rising edge to the next)
- Take a screen shot and record the period
Bring up the note player FSM diagram from the Part A handout. Compare the note player FSM diagram to the player_state signal in the waveforms and make sure you understand how your note player FSM is moving through the four states in the FSM diagram. You might need to zoom in to see the state transitions on the rising and falling edges of the note.
Lab Report Task 5: Save GL Note Player Waveforms
Save the screen shot of the note player waveform. The screenshot should clearly show the measured note period.
Lab Check-Off Task 9: Discuss Note Player Waveform
Show a TA the waveform and the measured period in Surfer for your note player. Confirm that the measured period is as expected given the table mapping switch settings to notes. Show the FSM diagram and the waveform side-by-side. Explain to the TA the different states the note player FSM is moving through.
Lab Check-Off Task 10: Turn in Lab Kit
When you are finished with your demo, pack up your ECE 2300 Lab Kit. Return the FPGA board and USB cable to a TA who will then record the kit number on your check-off sheet, initial the final check-off, and then collect your check-off sheet.