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.
- Start Quartus by double-clicking on the DE1_SoC.qpf file.
💡 Your PC may hide the file extension, so if you just see “DE1_SoC”, hover over the file and make sure the pop-up information text says “QPF File.”
- Write your SystemVerilog code. You can download
mux2_1.svfrom the Lab 1 specs into yourlab1subdirectory 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.💡 Every Verilog module you write in this class should have a testbench, no matter how small.
For future labs, you can create code files from scratch by following the below steps:
- Create a SystemVerilog file. Go to File→New, select “SystemVerilog HDL File”, and hit “OK” (Figure 1).
- 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.
- 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
_tbsuffixed to the end.
3. Synthesizing a Design
Now that we have the design created in Quartus, we need to check that it is valid Verilog:
- 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. - 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.
ℹ️ This step is actually optional for running simulations. However, Quartus’ interface for compilation warnings and errors is better than ModelSim’s, so we typically prefer to fix our code here. Once you are confident in your syntax, you can skip this step after making small code changes in-between simulation runs.
Figure 4: The “Start Analysis & Synthesis” button and where to find it. - 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.
- Start ModelSim by double-clicking
Launch_ModelSim.bat. This should show a blue title screen before the ModelSim opens.ℹ️ If you instead saw a black window flash by and nothing happened, then your ModelSim is installed at a non-standard location; edit the Launch_ModelSim.bat file and put in the correct path to the Modelsim.exe executable. Save the file and retry.
The path you enter should resemble the following:
C:\intelFPGA_lite\17.0\modelsim_ase\win32aloem\modelsim.exe
If your path shows “modelsim_ae”, modify it to be “modelsim_ase” instead. - 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.
💡 Hitting <Tab> when you have typed “do r” will auto-complete with the full command, since there are no other files in the Lab 1 directory that start with “r”.
- 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.
ℹ️ Any red or blue lines indicate that there is a problem in your Verilog files; check that you have done all of the previous steps correctly.
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. - 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.
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.
- Make sure that the Wave pane is active by clicking anywhere within it (signal list, Msgs column, or waveform viewer).
- Select File→Save Format or press Control-S.
- Overwrite the file mux2_1_wave.do. In general, we will use the format file naming convention of <moduleName>_wave.do.
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.
- Download
mux4_1.sv, which usesmux2_1as 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. - Set
mux4_1.svas 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):
- 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. - Change the “
vsim” line to end withmux4_1_tbinstead ofmux2_1_tbto change the module being simulated/tested. - Edit the “
do” line to end withmux4_1_wave.doinstead ofmux2_1_wave.doto change the waveform settings. Each module should have its own*_wave.dofile, 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!
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.
- 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.
- 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).
- 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.
- Save the waveform as mux4_1_wave.do to create the missing file for simulation.
- 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.
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:
- Make a new lab folder that isn't inside of any of the old ones. Unzip the lab1 "starter project" files into it.
-
For each module you need to:
- Create and populate a new file that contains both the module definition and the corresponding test bench for that module.
- Set the new module file as the top-level module in Quartus.
- Run Analysis and Synthesis and fix any errors it finds.
- Edit runlab.do to include the new module and run its test bench and yet-to-be created simulation view.
- Start ModelSim and perform “
do runlab.do.” Fix any errors the compiler finds. - When it complains about a missing
*_wave.dofile, 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. - 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.
- Connect the DE1-SoC to wall power with the power cord.
- 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.
- 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).
- This will bring up the Programmer dialog box (Figure 12).
- If the “Start” button is active, proceed to the next step.
- If the “Start” button is greyed out, you need to first run click the “Hardware Setup…” button.
- 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!
