Quartus Tutorial (Windows)

Introduction

This tutorial will walk you through the process of using Quartus to develop circuit designs, simulate them on a computer, and then load them onto the FPGA in the middle of the DE1-SoC board.

The course software is preloaded on Windows machines in the CSE 003 lab and you are welcome to do all the work on those PCs. If you would prefer to work on your own machine, follow the instructions in the Software Setup guide

1. Starting a new project

A Quartus project consists of a folder full of your Verilog code and also a bunch of configuration files that explain how to map that code to the specific FPGA we use for this class.

These projects can be tricky to set up, so for every lab we recommend creating a new folder and unzipping our starter project files into it. You can then start adding new Verilog files as necessary.

To keep things easily findable, we suggest organizing these project folders into a directory called "cse369" in your home folder. If you are using the lab machines, put your work onto your Z: drive (shared across all machines – it should be the drive with your NetID on it).

Go ahead and download that starter project and unzip it into a "lab1" directory.

2. Creating New Modules

Let's describe a circuit with code!

We will create a simple design of a 2:1 MUX – this is a device with two data inputs i0 and i1, and a select input sel. The output is equal to the i0 input when sel==0, and the output is equal to the i1 input when sel==1.

  1. Start Quartus by double-clicking on the DE1_SoC.qpf file.
  2. Write your SystemVerilog code. You can download mux2_1.sv from the Lab 1 specs into your lab1 subdirectory and open them within Quartus. Make sure to check the “Add file to current project” box in the Open File dialog. This file contains the module we are developing (mux2_1) and its test bench (mux2_1_tb) for verification.

For future labs, you can create code files from scratch by following the below steps:

  1. Create a SystemVerilog file. Go to File→New, select “SystemVerilog HDL File”, and hit “OK” (Figure 1).
  2. Name the file. The new file is opened for you in Quartus’ text editor, but doesn’t have a name yet. Go to File→Save As and give it the same name as the module you are designing (e.g., mux2_1.sv as shown in Figure 2). The title bar for the editor pane will change.
  3. Populate the file. Type away! Generally, each file will contain a single module of the same name as the file itself, and that module's testbench. The testbench will have the same name as the module, but with _tb suffixed to the end.
Figure 1: Creating a new SystemVerilog file in Quartus
Figure 2: Saving and naming Verilog files in Quartus

3. Synthesizing a Design

Now that we have the design created in Quartus, we need to check that it is valid Verilog:

  1. Set the “top-level” module. As we go through the class, we will create designs with many different modules all talking to one-another; Quartus needs to know which of the files holds the top-level, complete design. In the upper-left side of Quartus is the “Project Navigator.” Select “Files” in the drop-down menu to the right of the Project Navigator. Right-click on the file “mux2_1.sv,” then select “Set as Top-Level Entity” (Figure 3).
    Figure 3: Setting the top-level Verilog module in a Quartus project.
  2. Run Quartus’ Analysis and Synthesis tool. Look at the top toolbar for the blue checkmark with the purple triangle and the tiny gate symbol (Figure 4). Press that button to have Quartus check whether the design is at least syntactically correct.
    Figure 4: The “Start Analysis & Synthesis” button and where to find it.
  3. Fix any syntax errors. The Analysis and Synthesis tool should run for a little while, and then tell you in the message window (near the bottom of Quartus) that “Analysis & Synthesis was successful.” If it does not, then check your design and any error messages found in the message window – you can usually double-click on the error message and it will take you to exactly where Quartus thinks the error is. Correct the problems, and re-run Analysis & Synthesis.

Once Quartus declares success, we know that the file is syntactically correct Verilog. However, we don’t know whether the design is a proper implementation of the desired functionality. For that, we will simulate the design, which uses the ModelSim simulator to show the actual behavior of our design.

4. Simulating a Design

In addition to Quartus II, we will be using the ModelSim software, which can simulate Verilog designs before you ever run them on actual hardware. To help make using the tool easier, we have provided the following three files as part of Lab1_files_Q17.zip:

  • Launch_ModelSim.bat: A file to start ModelSim with the correct working directory.
  • runlab.do: A command file for ModelSim that will compile your design, set up the windows for the design, and start simulation.
  • mux2_1_wave.do: A default file that sets up the simulation window.
  1. Start ModelSim by double-clicking Launch_ModelSim.bat. This should show a blue title screen before the ModelSim opens.
  2. Simulate the circuit by issuing the command “do runlab.do” in the Transcript pane. The Transcript pane can be found at the bottom of the ModelSim window (Figure 5). The runlab.do file will compile and run the simulation for mux2_1.
  3. View the results in the Wave pane (Figure 6). Time moves from left (start) to right (end), with a green line for each input and output of the design. When the green line is up, it means that signal is true; when the green line is down, it means the signal is false.
Figure 5: Entered the command "do runlab.do" into the Transcript pane. Press <Enter> to issue the command.
Figure 6: Simulation results shown in the Wave pane.

5. Navigating the Simulation

The initial waveforms are rather hard to see, so let’s explore the navigation options in ModelSim:

  • Use the Zoom commands: Found in the toolbars near the top of ModelSim.

    Use the left two commands (+ and - magnifying glass) to zoom so that the green waves fill the Wave pane. Notice that the scrollbar at the bottom now becomes useful, allowing us to move around in the simulation. The time for each horizontal position is shown at the bottom. The third button (black-filled magnifying glass) zooms to fit the entire waveform in the window.
  • View signal values in the Msgs column: Left-click anywhere within the waveform viewer (the part with the black background) to move the cursor, which is the yellow vertical line with the time in yellow at the bottom (Figure 7). The Msgs column will update with the signal values at the time specified by the cursor (Figure 8).
  • Use the Wave Cursor commands to jump to points of interest: Also found in the toolbars near the top of ModelSim. To be usable, a single signal must be selected/highlighted (either click on a signal name or somewhere on the green waveform for that signal).

    Select the i1 signal and play with the six cursor movement commands to see what they do.
Figure 7: You can move the cursor (yellow line) within the waveform viewer (black background) of the Wave pane.
Figure 8: The values in the Msgs column will automatically update as you move the cursor.

6. Saving the Simulation View

Once we have adjusted our simulation view to better display our design results, we will often want to save these settings into a file so our next simulation run will return to this Wave pane setup.

  1. Make sure that the Wave pane is active by clicking anywhere within it (signal list, Msgs column, or waveform viewer).
  2. Select File→Save Format or press Control-S.
  3. Overwrite the file mux2_1_wave.do. In general, we will use the format file naming convention of <moduleName>_wave.do.
Now when you re-run your simulation, even after changing the Verilog files, it will have the Wave pane set up exactly the way we left it!

7. More Complex Designs – Create a 4:1 MUX

The 2:1 MUX is a simple design to get you started. But real designs will have multiple files and won’t have all the scripts set up for you. Here we will show you how to build a new, more complex design that will demonstrate how to work with the various ModelSim support files.

  1. Download mux4_1.sv, which uses mux2_1 as a submodule and contains its own test bench, from the lab specs into your lab1 folder. Open them within Quartus, making sure to check the “Add file to current project” box in the Open File dialog.
  2. Set mux4_1.sv as the top-level entity and run the Analysis & Synthesis tool. Fix errors as necessary until successful.

7a. More Complex Designs – ModelSim Command File

Before we can simulate, we need to modify runlab.do for the new design. In the text editor of your choice (e.g., WordPad, Notepad), open runlab.do and make the following modifications (Figure 9):

  1. Add vlog "./mux4_1.sv" to the compilation section. For all Quartus designs, you will have one “vlog” line for each Verilog file in your design. Ideally, the test bench you define will be inside the same file that has the implementation.
  2. Change the “vsim” line to end with mux4_1_tb instead of mux2_1_tb to change the module being simulated/tested.
  3. Edit the “do” line to end with mux4_1_wave.do instead of mux2_1_wave.do to change the waveform settings. Each module should have its own *_wave.do file, so that during debugging of a large project you can switch between different modules to test.

Save runlab.do, run Launch_ModelSim.bat in the lab1 directory, then execute “do runlab.do”.

The system should start simulating, show the waveform pane, and then give an error that it cannot open the macro file mux4_1_wave.do. That’s because we haven’t provided the waveform file for you; you need to create it yourself once you’ve found a simulation view that you like!

Figure 9: The modifications: (1) add files to compile, (2) change the testbench to simulate, and (3) change waveform settings.

7b. More Complex Designs – ModelSim Waveform Macro

Our goal is to get the Wave pane properly set up so we can save the waveform settings as a *_wave.do file.

  1. Locate the sim tab (confusingly opened via View→Structure), which may be hidden behind the “Library” or “Project” tabs on the left side of ModelSim. This tab shows the various modules in the design.
  2. mux4_1_tb is the top-level design, which contains dut (“device under test”), the name of the mux4_1 module we are testing. Clicking on the plus next to dut shows the three mux2_1’s inside of the mux4_1: m0, m1, and m. If you click on any of the units in the sim tab, the Objects pane next to it shows the signals inside that module (Figure 10).
  3. Click on mux4_1_tb in the sim tab, select all of the signals in the Objects pane except i, and drag-and-drop them into the Wave pane.
  4. Save the waveform as mux4_1_wave.do to create the missing file for simulation.
  5. Re-run “do runlab.do” from the Transcript pane to get a simulation of the entire design.

Examine the waveforms using the navigation techniques. Figure out what the mux4_1 module actually does.

Figure 10: The sim tab is found on the far-left and contains all of the modules in this design. Selecting a module or submodule will show all of the signals contained in that module in the Objects pane just to the right.

8. Process Recap

You now have the commands necessary to develop new designs, commands you will use for all future labs. Just to make sure you’ve got it, here’s a cheat-sheet of the steps for future Verilog designs:

  1. Make a new lab folder that isn't inside of any of the old ones. Unzip the lab1 "starter project" files into it.
  2. For each module you need to:
    1. Create and populate a new file that contains both the module definition and the corresponding test bench for that module.
    2. Set the new module file as the top-level module in Quartus.
    3. Run Analysis and Synthesis and fix any errors it finds.
    4. Edit runlab.do to include the new module and run its test bench and yet-to-be created simulation view.
    5. Start ModelSim and perform “do runlab.do.” Fix any errors the compiler finds.
    6. When it complains about a missing *_wave.do file, set up the Wave pane by drag-and-dropping signals from the Object pane. Save the waveform setup using File→“Save Formatting”, then perform “do runlab.do” again.
    7. Check the simulation results, correct errors, and iterate until the module works as intended.

This process has two major features: First, it has you test every module before you work on the larger modules that call this unit. This will significantly simplify the design process. Second, you have a separate *_wave.do file for each Verilog file. This keeps a formatted test window for each module, which can help when you discover a fresh bug in a larger design later on. You can always go back and test a submodule by simply editing the runlab.do file to point to the testbench and *_wave.do file for the unit you want to test.

9. Mapping a Design to the FPGA Hardware

So far we have developed and tested a design completely in software. Once it is working, it is time to use Quartus II to convert that design into a form that can actually be loaded onto the FPGA.

To use the switches, lights, and buttons on the DE1 board, we need to hook up the connections of the circuit design to the proper inputs and outputs of the FPGA.

Download the file lab1.sv from the Lab 1 specs into your lab1 folder, add it to your project, then set it as the top-level entity.

We now need to compile the design into a bitfile, a file that can be downloaded to the FPGA. To do that, we press the “Start Compilation” button just to the left of the “Analysis & Synthesis” button we have used before:

This will run the multiple steps necessary to compile the design. You can watch the progress of the compilation in the Tasks pane in the lower-left of Quartus.

10. Configuring the FPGA with the Bitfile

We now need to send the bitfile to the DE1-SoC.

  1. Connect the DE1-SoC to wall power with the power cord.
  2. Make sure that the board is off (i.e., the board should not light up when you plug it in), then connect the board to your computer’s USB. You can then turn on the DE1-SoC.
  3. In Quartus, go to File→Open. In the “Files of type” box at bottom, select “Programming Files (*.cdf …)” and then double-click on ProgramTheDE1_SoC.cdf (Figure 11).
  4. This will bring up the Programmer dialog box (Figure 12).
    1. If the “Start” button is active, proceed to the next step.
    2. If the “Start” button is greyed out, you need to first run click the “Hardware Setup…” button.
  5. This will bring up the “Hardware Setup” dialog box. Set “Currently selected hardware” to “DE-SoC”, and close the dialog box (Figure 13). Click the “Start” button and the DE1 board will be programmed – you’re done!
Figure 11: Open the chain description file (.cdf) to program the DE1-SoC
Figure 12: Programmer dialog box with the “Start” and “Hardware Setup…” buttons highlighted.
Figure 13: Hardware Setup dialog box in case the “Start” button in the Programmer dialog box was greyed out.