Skip to content

Lab 1: Five-Bit Numeric Display
Part B: Breadboard and FPGA Primer

Lab 1 is designed to give you experience designing, implementing, testing, and prototyping a simple Verilog hardware design. This lab will primarily leverage concepts from Topic 2: Combinational Logic and Topic 3: Boolean Algebra.

You will be implementing a five-bit numeric display that takes as input a five-bit binary value and displays this value as a decimal number using two seven-segment displays. Your implementation will exclusively use combinational logic gates. This five-bit numeric display will be reused extensively across all of the remaining labs. The lab includes five parts:

  • Part A: Unoptimized and Optimized Display

    • Must be completed individually
    • Due 9/13 @ 11:59pm via GitHub
    • Students should work on Part A before, during, and after your assigned lab section during the week of 9/7

  • Part B: Breadboard and FPGA Primer

    • Done with randomly assigned partner
    • Due week of 9/7 during assigned lab section
    • Even though completed with a partner, every student must turn in their own paper check-off sheet in their lab section!

  • Part C: Build System

    • Must be completed individually
    • Due 9/17 @ 11:59pm via GitHub
    • Students should work on Part C before, during, and after your assigned lab section during the week of 9/14

  • Part D: FPGA Prototype

    • Done with randomly assigned partner
    • Due week of 9/14 during assigned lab section
    • Even though completed with a partner, every student must turn in their own paper check-off sheet in their lab section!

  • Part E: Report

    • Done with same partner as in Part D
    • Due week of 9/14, 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.

Here are the steps to get started:

  • Step 1. Check Canvas for your randomly assigned lab partner (click on People, then Groups, then search for your name to find your group named ECE 2300: Lab 1B Group XX where XX is your group number, this only works on a laptop not your phone)
  • Step 2. Find your randomly assigned lab partner
  • Step 3. Find a free workstation
  • Step 4. Ask the TAs for a lab check-off sheet and lab worksheet (use one worksheet per group, but each student needs their own check-off sheet)

You can also find a copy of the lab worksheet online here:

Throughout this handout you will need to complete lab check-off tasks. 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.

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 an FPGA board, a discrete logic board, a USB-B cable, a USB-C cable, and a component box with wires. Do not do anything with the FPGA or discrete logic boards until later in the lab.

1. Combinational Logic Integrated Circuits (ICs)

In Lab 0, we implemented an inverter (i.e., NOT gate), NAND2 gate, and NOR2 gate using discrete transistors on a breadboard. In this lab, we will be experimenting with integrated circuits (IC) which integrate many transitors into a single chip. Take a look at the breadboard and notice how the transistors have been replaced with five ICs. Each IC uses between 12-48 transistors to implement 4-6 logic gates of a specific type (e.g., NOT, AND2, OR2, XOR2, NOR2). For example, the NOT IC uses 12 transistors to implement six NOT gates, and the AND2 IC uses 24 transistors to implement four AND2 gates.

Each IC has an associated datasheet. A datasheet is an official document from the manufacturer that summarizes the functionality, pin out, timing, and operational limits of the IC. Here are links to the data sheets for each of the five ICs we will be using in this lab:

Look through the datasheets and find the propagation delay and the contamination delay of each logic gate. We will be using a supply voltage of 3.3V, so find the Switching Characteristics table that corresponds to this supply voltage. Notice that the table provides a complex delay model that depends on:

  • input value (and whether this causes the output to rise or fall)
  • load on the gate (the load capacitance, if the gate is driving many other gates it would have a high load capacitance, if the gate is driving few gates it would have a low load capacitance)
  • temperature (high temperature makes the gate slower compared to low temperature)
  • package (different packages have different delays)

For our purposes focus on a load capacitance of 50pF and the Recommended values. Consider the largest delay as the propagation delay and the smallest delay as the contamination delay. Fill in the corresponding table on the provided lab worksheet.

Now look through the datasheets and find the pin out for the 14-pin package we are using. The pin out is usually a picture which looks like our IC so look for a rectangle in the Pin Configuration and Functions section like one of the following:

The pin out specifies the purpose of each pin on the IC. Each IC has 14 pins, so you need to figure out the purpose of all 14 pins. Some pins will be for the power supply (Vcc) and some will be for ground (GND). Pins which are the input to a logic gate will be labeled A or B. Pins which are the output for a logic gate will be labeled Y. So for example, in the top left pin-out, there are pins labeled 1A, 1B, and 1Y which correspond to the two inputs and output of the first logic gate in the IC. Use the datasheets to draw how the logic gates inside each IC connect to the pins on the provided lab worksheet. We have already filled in the logic gates for the NOT IC as an example. Note that we have oriented our ICs in the breadboard so pin 1 is always in the bottom left corner of the IC.

Lab Check-Off Task 2: Datasheets

Use your worksheet, to show a TA what you have collected from the datasheets including the propagation delay, contamination delay, and pin out of each logic gate.

1.1. NOT Gates

Let's go ahead and test a single NOT gate in the NOT IC. Use a wire in your component box to connect the input of the inverter in the bottom left corner of the NOT IC (i.e., pin 1) to one of the digital inputs on the IO board. Then use a second wire to connect the output of this inverter (i.e., pin 2) to one of the digital outputs.

Always double check your wiring!

Always have both partners double check wiring before turning on the power to your discrete logic board. Incorrect wiring could cause a short circuit and potentially destroy the ICs and/or create some smoke!

Once you have double checked your wiring with your partner, turn on power to the discrete logic board using the power button on the IO board. Toggle the input switch and observe both the input and output LEDs. Confirm your circuit is operating correctly.

1.2. Two NOT Gates

Let's now prototype two NOT gates with the output of the first NOT gate connected to the input of the second NOT gate as shown below.

Remember to always turn off the power to the discrete logic board whenever you are making changes to your wiring. Once the power is off, wire up the digital circuit as follows.

Once you have double checked your wiring with your partner, turn on the power to the discrete logic board. Toggle the input switch and observe both the input and output LEDs. Confirm your circuit is operating correctly.

Connnect oscilloscope channel 1 to the output of the second inverter, and oscilloscope channel 2 to the input of the first inverter. You can connect the ground probe points to the male header in the bottom right corner of the breadboard. Use what you learned in Lab 0 to capture a waveform of the rising transition.

  • Reset the osilloscope by pressing Default Setup
  • Press channel 2 to display both channels
  • Press Menu On/Off to get rid of the menu
  • Set the trigger to be halfway between 0V and 3.3V
  • Press Single button
  • Switch the input
  • If the waveform looks very weird, press Single and switch input the other way

You should see two rising waveforms. Recall that the gate delay is the delay from when the input waveform reaches halfway between 0V and 3.3V to when the output waveform reaches halfway between 0V and 3.3V. We can use cursors on the scope to measure the gate delay.

  • Press Cursor
  • Rotate the Multipurpose knob to move the left cursor to when the input waveform is halfway between 0V and 3.3V
  • By default, the cursor is moves at a coase grain; if you press and hold the Multipurpose knob you can move the the cursor at a fine grain; press and hold again to switch back to coarse grain
  • Once you are done with the first cursor, press the Multipurpose knob quickly and adjust the right cursor to when the output waveform is halfway between 0V and 3.3V
  • Now zoom in by rotating the Horizontal Scale knob such that the scale is 1us
  • Continue to adjust the cursors to get a good measurement
  • The display will show you the delta time between the cursors which is the gate delay

Note that the measured gate delay will much much larger than what was in the datasheet because our breadboard prototype is driving a much larger load.

Lab Check-Off Task 3: Measure Gate Delay

Then toggle the input and verify that the output LED is expected. Show a TA your measured gate delay using the cursors on the oscilloscope. You do not need to remeasure the gate delay from scratch. Just show a TA what you have captured on your own.

1.3. AND, OR, XOR, XNOR Gates

Remove all your wiring for the NOT gate. Connect two digital inputs and one digital output to one of each of the remaining four logic gates. Try the four possible inputs and confirm that each gate operates as expected.

2. Pair/Triple Detector Breadboard Prototype

Recall from the discussion section, that the output of a pair/triple detector is one if either two or three of the inputs are one, and the output should be zero otherwise. Here is a gate-level network that implements a pair/triple detector.

Before continuing fill out the truth table on the provided lab worksheet including the intermediate signals W, X, and Y.

We always use simulation to verify a design before prototyping the designs on the lab bench. In the discussion section, we used both a graphical logic simulator which is a good for verifying small breadboard prototypes. Click on this link to launch a very simple graphical logic simulator to verify the pair/triple detector.

2.1. Plan

We need to plan our wiring before actually implementing more complicated breadboard prototypes. Go ahead and carefully draw wires on the corresponding breadboard diagram on the provided lab worksheet.

Lab Check-Off Task 4: Breadboard Planning

Show a TA your truth table and breadboard plan. Explain where each of the four logic gates in the gate-level network will be located in the actual combinational logic ICs.

2.2. Wire

Wiring all four gates at once is unlikely to be successful and will be difficult to debug. So you must use an incremental design strategy!

  • Step 1: Wire the OR2 gate with inputs in0/in1 and connect W to one of the digital outputs. Verify it is working by trying all eight inputs in your truth table. Make sure you are seeing the expected values for the intermediate signal W. Once you are sure this first step is working you can remove the wire connecting W to one of the digital outputs.

  • Step 2: Wire the AND2 gate with inputs W/in2 and connect Y to one of the digital outputs. Verify it is working by trying all eight inputs in your truth table. Make sure you are seeing the expected values for the intermediate signal Y. Once you are sure this first step is working you can remove the wire connecting Y to one of the digital outputs.

  • Step 3: Wire the AND2 gate with inputs in0/in1 and connect X to one of the digital outputs. Verify it is working by trying all eight inputs in your truth table. Make sure you are seeing the expected values for the intermediate signal X. Once you are sure this first step is working you can remove the wire connecting X to one of the digital outputs.

  • Step 4: Wire the final OR2 gate and connect out to one of the digital outputs; verify it is working by looking at the expected values for the output in your truth table.

Lab Check-Off Task 5: Demonstrate the Pair/Triple Detector

Show a TA that your pair/triple detector is correct by exhaustively trying all eight possible inputs and confirming that they match what is in your truth table.

3. Field Programmable Gate Arrays (FPGAs)

Our goal for this semester is to build a complex digital system with over ten thousand logic gates. With about 20 logic gates per breadboard we would need 500 breadboards, which would completely cover four lab benches. Clearly this would be nearly impossible with a breadboard prototype! So we will mostly be using a field programmable gate array (FPGA) to prototype our digital systems. An FPGA has a sea of tens of thousands of logic gates integrated into a single chip. The key is that the wiring between these logic gates is left undefined when the chip is fabricated. We can think of an FPGA as tens of thousands of logic gates with configurable wires. This enables us to configure an FPGA on the lab bench by specifying how we want to connect the logic gates in the chip together. It is analogous to how our breadboard started with around 20 logic gates and we were in charge wiring those gates together. The difference is an FPGA has many more logic gates and these logic gates are all integrated into a single chip. With an FPGA we can connect a bunch of AND gates to a bunch of OR gates, or a bunch of XNOR gates to a bunch of NAND gates inside the FPGA right on our lab bench. Throughout the semester, in both lab and lecture, you will learn much more detail about what is in an FPGA, but for now a good mental model is: an FPGA is a sea of tens of thousands of logic gates with configurable wires all integrated into a single chip.

FPGAs come with development environment, which is a complex piece of software that helps us get our design from a hardware description language to something that can be configured on the FPGA. This includes:

  • Synthesizing your design from a higher-level description into the primitive logic gates that are available on the FPGA.

  • Placing your design to determine which FPGA resources should be used for each primitive logic gate in the design.

  • Routing your design to configure the wires and thus connect the primitive logic gates togther.

For this class, we will be using Quartus Prime ("Quartus") development environment. Quartus is installed on all lab machines, and will be used during the FPGA prototyping parts of lab assignments.

3.1. Setup Quartus Project

Let's go ahead and use Quartus to create a project for our pair/triple detector. We will be using Quartus Prime 18.1 Lite. Do not use version 23.1; you must use version 18.1. To start Quartus, double-click on the Quartus Prime icon on the Desktop of a lab machine:

Quartus Start-Up

You may see the following prompt when starting Quartus: Select "Run the Quartus Prime software", then click OK. We've found that Quartus often quits the first time after this, so you may need to re-open the application.

After starting Quartus, go to File -> New Project Wizard. This will start an interactive prompt menu to help create your project. In the menu:

  • Directory, Name, Top-Level Entity:
    • Using the file searcher, create a new directory for your project in your Documents. Name it lab1b. Select this as the "working directory" for your project - the path should look like C:/Users/netid/Documents/lab1b
    • Name your project lab1b by typing in the appropriate field. The "top-level design entity" should be automatically filled appropriately
    • Click Next

Incorrect Folder

If Quartus gives an error that it can't create the project, make sure that you're creating the project in your Documents folder. Quartus will give a default location of its installation folder -- make sure to change this.

  • Project Type:
    • Select "Empty Project
    • Click Next
  • Add Files:
    • Skip this for now; we'll add our design files later
    • Click Next
  • Family, Device & Board Settings:
    • Switch to the Board tab:
    • Make sure "Family" is set to Cyclone V and "Development Kit" is set to Any
    • Select DE0-CV Development Board (this is the FPGA board for the class)
    • Make sure "Create top-level design file" is checked
    • Click Next
  • EDA Tool Settings:
    • Skip this section for now. These are extra tools that can be used to analyze your design, but we won't be using them
    • Click Next
  • Summary:
    • Click Finish to finish creating your project

Wait for Quartus to set up your project. After that, you'll be left with a blank project to work on and configure as we wish.

Quartus Hangs When Creating Project

If Quartus hangs after clicking Finish this might be because you used the default folder as the working directory in the very first dialog box. Students do not have write access to the default folder. You must kill Quartus and start over being sure to create a new directory for your project in your Documents folder.

3.2. The Top-Level Module

One of the hardest parts of working with FPGAs is making sure that the development environment knows how to map your design to the physical pins on the board. Luckily, Quartus was able to do this for us. When we selected "Create top-level design file", Quartus automatically created a template module, and hooked up all of the pins correctly in its configuration. This module is now the top-level module; it is the module that will actually be put on the board. If we want to create any extra logic, it must be contained within this module.

To see what this module looks like, go to the Project Navigator, and change the entities from Hierarchy to Files. You should see a file named DE0_CV_golden_top.v; this is the file where our top-level module was generated. Double-click the listing to open the file in Quartus.

Missing Top-Level File

If this file is missing, you may not have selected the DE0-CV Development Board, or may not have checked "Create top-level design file" when creating your project.

The module should look very similar to Verilog modules that you've seen in lecture, although with many inputs and outputs. These represent all of the possible inputs and outputs of our FPGA hardware. We won't use all of these right now, but will instead focus on two signals in particular:

  • SW: The physical switches on the board. These are a logical 1 or 0 depending on whether the switch is up or down, respectively. These are coming into our FPGA hardware, and are therefore inputs to the top-level module.

  • LEDR: The (red) LEDs on the board. These are "on" or "off" depending on whether our logic sets them to a 1 or 0, respectively. These are going out of our FPGA hardware, and are therefore outputs of the top-level module.

These signals are multi-bit wires; they represent a collection of single-bit signals. You can access an individual signal using the bracket notation, similar to many programming languages. For example, if you wanted to set the 0th LED (the first one in the array, starting at 0) to the logical AND of the 0th and 1st switches, you might write:

and( LEDR[0], SW[0], SW[1] );

4. Pair/Triple Detector FPGA Prototype

In this section, we will implement the same pair/triple detector we explored on the breadboard earlier in this lab, except now we will be implementing the pair/triple detector in Verilog and then synthesizing, placing, and configuring the design onto the FPGA.

Remember, we always use simulation to verify a design before prototyping the designs on the lab bench. In the discussion section, we a Verilog simulator to verify our design.

4.1. Implement

To add our own logic, we will create a new module, and instantiate it within our top-level module. It's good practice to have only one module in a file (with the filename being the same as the name of the module it contains), so let's first add a new file to our project.

To create a new file within your Quartus project:

  • Go to File -> New
  • Click on Verilog HDL File, then select OK
  • You should now see a blank Verilog file. Go to File -> Save As, and save this file as PairTripleDetector_GL.v within your lab1b directory

We now have a new Verilog file included in our design, where we can add our new logic.

Existing Files

For this primer, we'll be creating and editing our design files directly within Quartus. However, this won't be the case for the rest of labs, where you will be downloading and using the design you've already simulated/tested on ecelinux. Later on, when you wish to add files that already exist, you can do so by going to Project -> Add/Remove Files in Project.

When we add new blocks of logic, we want to add them as modules. This involves first creating the module, and then instantiating it wherever we want that logic.

First, let's define our module. In PairTripleDetector_GL.v, define a module named PairTripleDetector_GL that represents the gate-level network above, exactly as done in Section 2.

module PairTripleDetector_GL
(
  input  wire in0,
  input  wire in1,
  input  wire in2,
  output wire out
);

  ...

endmodule

Make sure that it has three inputs (in0, in1, and in2), and one output (out). Make sure that it contains the logic to implement the gate-level network above. Lastly, make sure to save the file when you're done (File -> Save).

4.2. Integrate

We can now integrate this module into the top-level design by instantiating the module in the DE0_CV_golden_top module. If you scroll to the bottom of the DE0_CV_golden_top.v file you will see the module does not contain any logic yet. Go ahead and instantiate our PairTripleDetector_GL module within the DE0_CV_golden_top module. Let's give it the name detector.

The module should have the following connections:

  • in0 should be connected to the 0th switch (SW[2])
  • in1 should be connected to the 1st switch (SW[1])
  • in2 should be connected to the 2nd switch (SW[0])
  • out should be connected to the 0th LED (LEDR[0])

Once you're done, your top-level module should look like the following:

module DE0_CV_golden_top (
  ...
);

  PairTripleDetector_GL detector (
    .in0 (SW[2]),
    .in1 (SW[1]),
    .in2 (SW[0]),
    .out (LEDR[0])
  );

endmodule

Make sure to save this file as well.

Lab Check-Off Task 6: Explain Implementation and Top-Level Connections

Show a TA your pair/triple detector implementation. Show a TA the location of switches SW[0] through SW[2] on the board. Show the TA the location of LEDR[0] on the board. Show the TA your top-level connections in Verilog, and clearly explain how the inputs and outputs of your PairTripleDetector_GL Verilog module will be hooked up to the physical switches and LEDRS on the board. Explain to the TA what is the expected behavior (i.e., when we flip these switches, we expect this to happen).

4.3. Synthesize

In addition to the above, we need to give Quartus information about our timing constraints, so that it can properly analyze the timing of our design and analyze the critical path.

  • Similar to before, go to File -> New to create a new file. This time, select "Synopsys Design Constraints File"
  • Inside the file, add the following Tcl commands:
set_max_delay -from [all_inputs] -to [all_outputs] 20
set_min_delay -from [all_inputs] -to [all_outputs] 0

Timing Commands

These constraints tell the FPGA tools that our critical path delay constraint is 20ns and that the FPGA tools should analyze all paths from every input port to every output port.

  • Go to File -> Save As, and save this file as timing.sdc within your lab1b directory

With our design logic and timing information, we rae now ready to "synthesize" our design for the FPGA. The "synthesis" step includes:

  • synthesis (determining what logic gates we need for our design)
  • placement (determining which resources on the chip will be used)
  • routing (connecting the logic gates as appropriate)

At the end, we'll be left with a synthesized version that can be put on the FPGA. This version is known as a bitstream.

In Quartus, you can perform the synthesis step by going to Processing -> Start Compilation, or clicking the blue "play" button in the top toolbar. This will start the synthesis step. The FPGA toolchain is using many complicated tools, so the entire process may take a few minutes. You can keep track of the progress in the Tasks bar on the left-hand side, as well as with the verbose output log at the bottom. If you made any static errors (such as incorrect syntax, or mixing up inputs and outputs), this is where Quartus will let you know with errors. However, it can't check for dynamic behavior (errors in the logic of your design), as it doesn't know the correct logic; that's up to you as a designer!

If you get no errors, after a few minutes, you should see the following output in the log produced at the bottom of Quartus:

Quartus Prime Full Compilation was successful

4.4. Analyze: RTL Viewer

Quartus can help us visualize what logic gates our design maps to. Go to Tools -> Netlist Viewers -> RTL Viewer. This should open up a new window to view how Quartus implemented our design.

We can see that our design takes in some of the switches as inputs, and outputs to an LED.

Our modules are initially represented as boxes (abstracting away the internal logic), but we can also click the "+" to open up the design and see the underlying gate-level network that Quartus mapped our design to. Compare this gate-level network to the one above; they should be the same! This is because we are using explicit gate-level modeling. Later in the course we will raise the level of abstraction and there will be a much bigger difference from the input Verilog and what is shown in the RTL viewer.

When you're finished, you can close this pop-up window.

4.5. Analyze: Technology Map Viewer

The RTL Viewer showed us the gate-level network, but what if we want to visualize exactly which resources were used on the FPGA? The Technology Map Viewer can help us with this.

  • Go to Tools -> Netlist Viewers -> Technology Map Viewer (Post-Fitting). This should open up a pop-up window that shows our entire design that came with our template top-level module.
  • To focus on our design:
    • Click the "+" at the top to open up a new tab.
    • In the "Netlist Navigator" panel on the left-hand side, under DE0_CV_golden_top -> Instances, drag the instance of PairTripleDetector_GL to the new tab
  • Click the "+" on the module instance to show the underlying FPGA resources

You should see only one block that makes up the logic. This is known as a "LUT" (Look-Up Table), but we'll reference this as a reconfigurable truth table. When we configure our FPGA, we tell this table what outputs it should have for every input, to represent our design. This design is relatively simple, so it only needs one truth table, but later designs will require more due to increasing complexity.

When you're finished, you can close this pop-up window.

4.6. Analyze: Chip Planner

Next, let's see if we can visualize exactly which portions of the FPGA are being used. Navigate to Tools -> Chip Planner to open up the Chip Planner window.

This helps us visualize exactly which portions of the chip are being utilized - the highlighted portions are being used for our design. Our design isn't too large, so very few resources are being used. Quartus also has different granularities for how much logic is being used - each of these rectangles is a "LAB" (Logic Array Block).

We can also see what each of these LABs are doing. The upper LAB was a ground signal that Quartus created, but the other LAB was a logic gate that Quartus used to implement our design. Zoom on on this block (View -> Zoom In, or Ctrl + Space), and click on the highlighted portion within it. The smaller highlighted portion is an "ALM" (Adaptive Logic Module) - each LAB contains multiple ALMs. Each ALM contains multiple logic gates - you can start to get a sense of how much logic our FPGA can represent!

On the side, you should be able to see what the ALM is used for (indicated in the name), as well as the Boolean logic equation that it implements. In this case, our ALM is determining what the out port of our detector module should be.

When you're finished, you can close this pop-up window.

4.7. Analyze: Area Reports

Quartus also generates reports for us to gain numerical results for our design. The first one we'll look at is the area report - we want to know how many resources our design needs. For this class, we'll approximate a design's area by how many FPGA resources it uses.

Navigate to Processing -> Compilation Report. In the tab that opens up, under Fitter -> Resource Section, click on Resource Usage Summary. This will open up a report that shows you how many resources are being used on the FPGA. We will primarily use the Logic Utilization number as an estimate of how much of the FPGA is being used to implement the design, and the number of ALUTs as the number of logic gates used to implement the design.

4.8. Analyze: Timing Reports

Lastly, we can view the timing associated with our design. This tells us how long each path within our design takes. In lecture, we represented this as an abstract timing unit tau, but now that we have an actual design, we can represent our path times in nanoseconds.

  • Navigate to Tools -> Timing Analyzer. This will open up a pop-up window for analyzing the timing of our design.
  • Under the Tasks panel on the left-hand side:
    • Double-click "Update Timing Netlist" to update the netlist for our design

  • Navigate to Reports -> Custom Reports -> Report Timing to create a timing report. This will open up a pop-up for us to tell Quartus what paths to analyze:
    • In Targets, under "From", put [all_inputs]. This tells Quartus to analyze paths starting from our switch signals
    • In Targets, under "To", put [all_outputs]. This tells Quartus to analyze paths ending at our LED signals
    • In Paths, under "Report number of paths", put 100 - this is the number of paths that Quartus will report
    • Click Report Timing

This will generate a timing report for our design:

  • In the top-panel, you should see three paths that Quartus found. They should each start at one of the switches, and end at our LED signal. Note that the "Data Delay" is how long each path takes - the path with the longest delay is the critical path. Right now, the delay may be longer than needed because we told the tools that logic can take up to 20 nanoseconds. If we wanted to be more representative, we'd push the tools to fit the logic in less time. We'll explore this more in Lab 1.

No Paths

If Quartus didn't find any paths, it's likely that you may have missed something in the pop-up window, or in your timing.sdc file. Make sure to go back and double-check them!

  • Click on the critical path, then look at the Data Arrival Path panel. This panel shows how long it takes in nanoseconds for the signal to reach each portion of the logic:
    • The Total and Incr columns show the total and incremental delay for each portion of the path
    • The Location column shows what type of FPGA resource the signal is going through
    • The Element column shows what signal name corresponds to the FPGA resource. Some of these may be generated by Quartus, but you should still be able to see the switch signal, LED signal, and the logic inside your detector module

When you're finished, you can close this pop-up window.

4.9. Configure

With our design synthesized, all that's left is to configure the wires on FPGA for our design. First, make sure your FPGA plugged into the workstation via the USB-B cable. The power button is the large red button on the left of the FPGA.

Go to Tools -> Programmer. This should open a new window for configuring the FPGA:

  • Click on Hardware Setup. Under "Currently selected hardware", you should see your FPGA as an option (appearing as USB Blaster [USB-0]). Select your FPGA, then click Close

  • Click on Start. This should configure the FPGA - notice how this is a lot quicker than the synthesis step. Quartus has already done the difficult part of figuring out how the FPGA should represent our design, so all this step needs to do is communicate that information to the FPGA. You can check when it's done by looking at the "Progress" bar in the top-right.

Once that's done, your FPGA should now implement a pair/triple detector. Try all eight possible inputs and verify that the output matches what you expect from your thruth table.

Lab Check-Off Task 7: Demonstrate the Pair/Triple Detector

Show a TA that your pair/triple detector is correct by exhaustively trying all eight possible inputs and confirming that they match what is in your truth table.

Lab Check-Off Task 8: Turn in Lab Kit

When you are finished with your demo, pack up your ECE 2300 Lab Kit. Return the FPGA board, discrete logic board, USB-B cable, and USB-C cable to a TA who will then record the kit number on your check-off sheet.

5. Unoptimized and Optimized Display

Spend the remainder of the lab section working on your unoptimized and/or optimized display as part of Lab 1A. Use your laptops and/or VS Code on the workstation to log into ecelinux. Your goal is to have some number of modules implemented and tested by the end of the lab section. Remember to take an incremental design approach. Do not implement all of the modules and then start testing! Implement one module and fully test it before moving on to the next module. The TAs are here to help!

Is acceptable for students in the same group to look at each other's code?

Since Part A is meant to be done alone, the course collaboration policy means students cannot look at each other's code. So please work on your own during the remainder of the lab section as you make progress on your unoptimized and optimized displays. As stated in the course collaboration policy, you can ask your partner for "consulting" help but do not share or copy code. Please make sure the code you submit accurately represents your own understanding.

Lab Check-Off Task 9: Verify Design in Simulation

Show a TA the modules you have working by running the corresponding tests. If you do not have any modules working, at least show a TA how your implementation is coming along. Once you have finished showing a TA your progress, the TA will mark which steps are complete, and collect your check-off sheet. You do not need to complete all steps during this lab section!