Intel FPGA Tools Introduction Quartus Prime 17.0 Lab Manual … · 2020. 10. 10. · Click on browse (“…”) and navigate to demo/cores to add the tool generated IP Now we will

Intel FPGA Tools Introduction

Quartus Prime 17.0

Lab Manual – DE10-Lite Development Kit

Revision Author Date Comments

1.0 D. Nielsen August 2017 Initial Version

Page | 2

Overview This set of labs builds an example design from start to finish, including hardware download and

debug. The design is an SDRAM memory tester. All of the source files are included in the lab

directory. The specifics of the design are included in the class materials.

The Labs are organized as follows:

Lab 1: Creating a new project.

Lab 2: Building the design, including pin assignments and basic timing constraints.

Lab 3: Basic post-fit timing analysis using Timequest.

Lab 4: Basic post-fit power analysis.

Lab 5: Hardware download of design

Lab 6: Hardware debugging using SignalTap

Source files & Directory structure

There lab files should already be loaded on your system. If not, get the fpga_designer.zip file

and extract it to a clean sub-directory .

The directory structure should then look as follows:

Where fpga_designer is the directory you unzipped the file in. The contents are as follows:

/max10_demo/cores Will hold the cores generated in the IP store

/lib Has optional source code library

/src Has the source code for this particular project

/phy The empty directory where you will build your project

It should be noted here that you do not have to set up you project in this manner. This is just one

example of how it could be done. It should also be noted here that all of the labs use the GUI

interface. This is not a requirement and everything can be run form the command line via scripts

once you are comfortable with the tools.

The directory “demo.done” is a completed version after all the labs have been completed as a

reference. The database was removed from the completed design to make the zip file smaller.

NOTE: All steps listed as “Extra Credit” are optional and need not be completed to move on to

the next section. They are included to challenge students to investigate the tools further and

as such do not include complete step by step instructions.

Page | 3

Hardware

The hardware for this series of labs is the DE10-Lite board from Terasic. To complete all of

these labs, you do not need any of the files supplied from Terasic for the board.

All you need is a USB-blaster cable to connect the board to your computer.

Page | 4

Demo Design Overview

The example design used in this lab is a basic memory tester. With the exception of the SDRAM

controller, design is all clear text Verilog so the student is free to examine the code and modify it

for further experimentation. The SDRAM controller was generated within Qsys – Intel’s system

integration tool. For more information on how to use Qsys, refer to the Intel website at the

following link:

http://www.altera.com/products/software/quartus-ii/subscription-edition/qsys/qts-qsys.html

The block diagram of the design is shown in the figure below.

Max 10 FPGA

DataGenerator

RAM TesterSDRAM

ControllerSDRAM

PB SW2

PLL

50Mosc

LEDs

PB SW1

Test Start KeysMaster Reset

Status

PB SW3

PB SW4

Test selection/start Logic

The design consists of three main functional blocks. The first is the SDRAM controller. This

presents an Avalon MM bus interface to the user and performs the required read/write operations

to the SDRAM.

The second block is the RAM tester. This is a hardware engine that runs the actual test. It

generates all the required Avalon bus transactions to read and write the memory and compares

the returned data against the expected data.

The final block is the data pattern generator. This block generates the given data pattern and sets

the address range for the test based on the arrangement of switches, SW[3:1]. If you want to

http://www.altera.com/products/software/quartus-ii/subscription-edition/qsys/qts-qsys.html

Page | 5

change the testing parameters, for example the address range tested or data pattern used, this is

the block that you would modify.

SW0 enables the functionality of the design, and will trigger a heartbeat on LEDR0 when it is

enabled (switched toward the middle of the board). To start a test, make sure SW0 is enabled,

select the desired test using the switches, and then press the pushbutton labeled KEY1. The

status is written to the 7-segment display and is also indicated by the LEDs.

The tests in the code as supplied with the lab are defined as follows:

SW[3:1] Test Name Data Pattern Address range tested

000 Address tag Location address 0x000000-0x03FFFC

001 Random Data LFSR8 Polynomial 0x000000-0x001FFC

010 Walking 1 Walk 1 across 0’s 0x000000-0x00007C


100 Custom 0 Start at 0, increment by 4 0x000000-0x00003C

101 Custom 1 Start at 0, increment by 4 0x000000-0x0003FC

110 Custom 2 Start at 0, increment by 4 0x000000-0x003FFC

111 Custom 3 Start at 0, increment by 4 0x000000-0x3FFFFC

The 7-segment display will display one of three possible status indicators – PASS, FAIL, and run

with a rotating circle to show activity. The status of the test is also indicated by the LEDs. They

are defined as follows:

LED Definition

LEDs

LEDR[0] Heartbeat – this will blink at a low rate to

indicate that the design is loaded and out of

reset.

LEDR[3:1] Indicate the test ID of the test, as defined in

the table above.

LEDR[4] Test running – will be lit while test is

running. This is pulse stretched so you can

see it for even short tests.

LEDR[5] Test fail – will blink rapidly if the test fails.

LEDR[6] Test pass – will be lit if test passes. Will

stay lit until new test is run.

LEDR[7] Test complete – will be lit when test

completes. Will stay lit until new test is run.

Finally, the design can be reset by pressing the pushbutton labeled KEY0, or by toggling the

switch labeled SW0. Resetting the design will turn off all the displays except the heartbeat on

LEDR0 until a test is run.

Page | 6

Lab 1: New Project Wizard

Summary

This is a short lab that completes the basic project setup and adds the required source files to the

project. When completed, the project will be setup and we’ll be ready to move on to creating

constraints.

Lab Instructions

Step 1.1

Open the tools by double clicking the “Quartus Prime” icon or executing the “Quartus Prime”

executable from the command line.

You should now see the image below. The tools will remember the configuration from run to

run, so it is possible that some additional window panes may be visible and others may be off.

For example, it is common to turn off the IP catalog pane once you’re done generating IP.

Step 1.2

Select FILE -> New Project Wizard

This brings up the new project wizard, which has 5 panes.

Step 1.3

Fill in new project information

Page | 7

Pane 1: Basics

Project dir: / demo/phy

Project name: MAX10_TOP

Top-level design entity: MAX10_TOP

Note – The top level entity is case sensitive and must match what is in the source code.

Click NEXT and select “empty project” and click NEXT.

Pane 2: Source files

Now we will add the source files for the project. These fall into three categories – the top level

FPGA files (located in “src”), the non-project specific library modules (in “lib”) and IP modules

generated by the tools (in “cores”). Don’t worry about extra modules – they will be used later.

Only add the files indicated in each step.

Click on browse (“…”) and navigate to demo/src

Select the Verilog source file MAX10_TOP.v and click OPEN.

Next, click on browse (“…”) again and navigate to demo/lib

Select all the Verilog source files (.v – there should be six) and click OPEN.

Click on browse (“…”) and navigate to demo/cores to add the tool generated IP

Now we will be adding source of a different type – QIP files (Quartus IP). You will also see

Verilog but ignore that. Select max10_pll.qip and data_fifo.qip and click OPEN.

If you add files once the project has been created, the file navigator will start in

the project directory and you won’t have to navigate through all the levels from

the Quartus Prime installation directory to the project location.

One last core. Click on browse (“…”) and navigate to demo/cores/sdram_ctrl/synthesis to add

SDRAM controller IP. Again, you will see Verilog files but ignore those. Select sdram_ctrl.qip

and click OPEN.

Click NEXT.

Pane 3: Device settings

Family: MAX 10 (DA/DF/DC/SA/SF/SC)

Devices: MAX 10 DA

To narrow the selections, set the following:

Package: FBGA

Pin count: 484

Speed grade: 6

You should now see a filtered list of devices (in this case, ten). Select 10M50DAF484C6G.

Expand the window if you cannot see all listed devices.

Page | 8

You could also just start typing the full part number in the Name filter box until you find it.

Click NEXT.

Pane 4: EDA tool settings

This doesn’t matter for this lab so we can skip it.

Click NEXT

Pane 5: Summary

Nothing to select – it should look like this:

Click FINISH.

Step 1.5

Look in the project directory. You’ll see three things created by the wizard. The db subdirectory

will contain all the project database files and two project files (qsf/qpf). The max10_top.qpf file

is really just a pointer to the project. Think of it as the icon for the project.

Open the MAX10_TOP.qsf file and look at its contents. It is a series of Tcl commands that

would, if executed, set all the project settings we just selected.

Page | 9

Step 1.6

Type [Ctrl-K] or right click on Analysis and Synthesis in the tasks window and select “start.” It

should complete quickly (< 25 seconds). You should get a few warnings - one warning that

output pins are stuck and VCC or GND, one that there are connectivity warnings and a few that

one of the sub-modules has an expression that evaluates to a constant. This is expected and can

be ignored.

Step 1.7 Extra Credit

Remove the six verilog source files in the demo/lib directory and add them as a user library, not

individual files (hint: Assignments -> settings… library tab). Next, re-run the synthesis and see if

it still works. Do you get additional warnings?

Congratulations, you are done with Lab 1

Page | 10

Lab 2: Build design

Summary

In this lab we will build the physical and timing constraint files and add them to the design.

When the design files are all in place and the tool is properly configured, we’ll build the design.

We are going to use the assignment editor to get the format of the two required physical

constraints and build the SDC file from the examples in the class materials.

Lab Instructions

Step 2.1

The node finder will not work until the analysis and synthesis has been run so first we need to

complete that processing if you didn’t complete it as part of step 1.6 in the previous lab.

Select: Processing Start Start Analysis and Synthesis

After ~25 seconds it should complete. The results will show up in the console window and you

can open the flow report for a summary (MAX10_TOP.flow.rpt) or one of the map reports

(MAX10_TOP.map.rpt or MAX10_TOP.map.summary) located in the output_files directory if

you want detailed information on the synthesis run. Note that it is generally much easy to

navigate these files in the GUI. Spend a few moments looking through the synthesis results to

get a feel for the information provided.

Now we can use the node finder in the assignment editor.

Page | 11

Step 2.2

Next, we are going to see how you can use the assignment editor to make assignments as well as

get command formats and syntax that can then be used in a text editor to add physical

constraints. First we need to open the assignment editor.

Select: Assignments Assignment Editor

Step 2.3

You will notice that there are already some constraints that have been added by the PLL IP core.

We are going to add more.

Add a pinout & IO standard constraint to the MAX10_CLK2_50 signal:

Double click on under the To column in the spreadsheet and bring up the node finder

by clicking on the binocular icon. Change the filter to Design Entry (all names).

Click on List and select the clock pin MAX10_CLK2_50, then click on [>] to move it over into

the selected nodes and then select OK.

Double click under the Assignment Name column and select Location (Accepts

wildcards/groups).

Double click under the Value column and type PIN_N14.

Repeat the process (add another MAX10_CLK2_50 pin) only this time select I/O

Standard(Accepts wildcards/groups) for the Assignment Name and 3.3-V LVTTL for the

Value.

If you type the first letter of the desired selection (“L” for Location, for example)

the drop down list will jump to the first selection with that beginning letter.

Pressing it again gets you to the next entry and so on.

As you can see, this would be a bit tedious to do for hundreds of settings.

Now save this to the QSF by selecting File Save or clicking on the disk icon.

Close the assignment editor. If you open the MAX10_TOP.qsf file now, you should see the

following two lines at the bottom:

set_location_assignment PIN_N14 -to MAX10_CLK2_50

set_instance_assignment -name IO_STANDARD "3.3-V LVTTL" -to MAX10_CLK2_50

Step 2.4

You would now build all the pin constraints based on the templates you just got. To save you the

typing, this is already completed for this board, so open the following file and examine it. Note

this also contains some assignments to make the dual purpose configuration pins available to the

user.

Page | 12

/demo/src/pinout_max10_top.tcl

Once you’ve looked it over, close it and we’ll read it into the project. If the Tcl console is not

visible, select:

View -> Utility Windows -> Tcl Console.

In the Tcl console, run the pinout TCL script with the following command:

We’ve now added all the pinout & IO standard constraints to the design. Re-open the

assignment editor and you’ll see all the added entries. Now save the project.

Select: File Save Project

Now, if you open the MAX10_TOP.qsf file you’ll see all the constraints at the bottom of the file.

We now have all the physical constraints in the project and we can move on to the timing

constraints. Timing constraints are not part of the qsf file.

Step 2.5

We’ll now add timing constraints via a SDC file. It will contain the clock period constraints and

basic IO constraints. We need to constrain the following nodes:

Clocks: Input clock (clk), 100MHz

PLL C0, 100MHz, Drives SDRAM test logic & memory controller.

PLL C1, 100MHz, Drives the clock to the physical SDRAM

I/O pins: SDRAM I/O

The other I/O ports – the switches, LEDs and seven segment display are don’t cares from a

timing standpoint.

There are four SDC files for you to look at that are progressively more refined. Examine these

and see if they make sense compared to the templates in the course materials. For the first pass

of the compile, we’re going to use the max10_top_v1.sdc file.

Select the Files tab in the Project Navigator (top left), then right click on Files and browse to

Add the max10_top_v1.sdc file. It is up one directory and in the src directory. Make sure to

have “All Files (*.*)” selected for the Files of type filter when searching for the .sdc file.

Make sure you set the filter to the correct file type or you will not see what you’re

looking for. The finder defaults to design files (Verilog, VHDL, etc). For this, you

want to select “script files” so that the SDC files will show up.

Page | 13

You’ve now got completed timing constraints.

Step 2.6

Now we’ll compile the design. To run everything:

Hit the Run Icon button on the tool bar or select: Processing -> Start Compilation

This will start from the top and re-read everything. Since we edited the qsf file this is probably

the safest route but it re-runs Synthesis and thus takes longer. On a small design like this it’s not

a big hit but on a larger design it could be painful.

If you wanted to run just the fitter, you can do that by selecting that process alone in the

processing menu.

Select: Processing Start Start Fitter

This will run just the fitter.

If you ran the full compile, the tools will now look like this:

The design should complete with 0 errors. Notice that the TimeQuest Timing Analyzer is red,

meaning that there are timing problems. We will look at those shortly.

The flow summary gives you a quick summary of the design stats. Click on a few of the flow

reports just to get a feel for what information you get. All of this is also located in the report file

MAX10_TOP.flow.rpt in the output_files directory.

Page | 14

Step 2.7

Now we’re going to take a quick look at the messages to make sure things are clean other than

the timing issues. Let’s first look at the critical warnings. Click on the critical warnings filter in

the message window.

The first critical warning is telling us that one pin is not placed and is thus floating. Since this is

a real design on a real board, pins moving around is not a good thing. We need to look into this.

To do that, we’ll go to the Input Pins in Resource Section of the fitter report. In there you will

see this:

The very last column in the right window is “location assigned by” – at this stage they should all

be user, however it is fitter in this case. If you check the pinout TCL file that you ran, you’ll

notice that this assignment was commented out (the leading #). You can fix that by adding the

assignment manually (as we did in step 2.3a above for MAX10_CLK2_50, but using SW[4] and

PIN_A12) or you can un-comment the line and run the script again. You can also do this by

simply copying that particular tcl command and executing it in the Tcl console in Quartus.

The data is sortable by column. Thus, if you clock on the column header (in this

case, “location assigned by,” you’ll get a sorted list and fitter assignments will

rise to the top. That way you don’t need to look through a long list for them.

Page | 15

You can edit the file by opening it in the Quartus editor (file open...) or you’re free to use

your own editor.

Step 2.8

Now lets see what we get when we re-run the design. The timing problems are still there, but the

floating pin has been resolved. Now lets move on to the warnings.

As you can see, we have around 32 warnings. There are four warnings about a conditional

statement inside the SDRAM controller IP core generated by Quartus. It’s telling us that a

conditional statement is resolving to a constant. This isn’t a big surprise since unused functions

are often tied off in an IP core, so we can ignore that for now.

After that is a connectivity warning. If we check the report, we see that the first warning in the

report is that the reset on a module is tied high. In this case, we wanted this since it is used by

the reset logic and cannot be reset itself.

We won’t take the time to go through all the rest of this but at this point you should get the idea

what the process looks like.

You will also notice that the TimeQuest Timing Analyzer report is colored red, indicating that

we have timing issues. We will deal with that in the next lab.


Which logic block is the largest – SRAM_CTRL, RT_DGEN or RAM_TEST? Hint: Fitter

report, resource section.

Step 2.10 Extra Credit II

Set all the available C7 speed grade migration devices (there should be two) and re-compile the

design. Are there any devices in this package that we cannot just drop in?

You are done with Lab 2

Page | 16

Lab 3: Basic timing analysis

Summary

In this lab we will correct the timing of the design. To do this, we will perform more detailed

timing analysis and make incremental changes to the SDC file and recompile the design to close

timing and get a clean design.

Lab Instructions

Step 3.1

First, we need to see what is wrong. So where to start? Expand the TimeQuest Timing Analyzer

report and you’ll notice that we have several failing reports. All three corners are failing and the

unconstrained path report is also red, indicating we have some paths without constraints:

If we open the Multicorner Timing Analysis Summary report, we see that the failures are setup

and hold timing on two of our clocks:

Expand here

Failing Corners

Unconstrained Paths

Page | 17

Step 3.2

To find out exactly what the timing issues are and what paths are unconstrained, we will use the

TimeQuest Timing Analyzer. To open TimeQuest, select: Tools -> TimeQuest Timing

Analyzer

Or click the stopwatch icon on the toolbar.

You should now see this:

Step 3.3

First, we need to load the timing information. You need to create the timing netlist, read in the

SDC and update the timing netlist with the SDC constraints.

You can perform all three by simply double clicking the following in the netlist setup flow:

- Create Timing Netlist

- Read SDC file

- Update Timing Netlist

You can also just double click the last one (update timing netlist) and it will do all three.

Step 3.4

Once we’re ready to look at the timing, we’ll start with the unconstrained paths since more issues

may show up once these are corrected. Double click on the report entitled Report

Unconstrained Paths in Diagnostics Folder in the Tasks pane.

Page | 18

You’re now looking at the Unconstrained Paths Summary and as you can see, there are

unconstrained inputs and outputs. This summary is run automatically when you compile the

design so we could have checked it in the normal summary report to see this information.

However, you have to run the full report in TimeQuest to find out what pins/paths they are.

If you ever want to get back to a report, click on it in the top report browser

window in the top left. Double clicking on the report generation task will not

bring you back to the report display if it has already been run.

So, let’s find out what pins we are talking about. Expand the setup analysis and then pick the

“Unconstrained Input Ports” report. You should now see this:

Page | 19

As you can see, the ports in question are the switches and pushbuttons. These are asynchronous

inputs by definiton and are debounced inside the design. Thus we can fix this with a false path

constraint that essentially ignores the path. If you repeat the process for the output paths, you

will see that it is the LEDs and HEXs that are causing the issue. Again, the timing here really

doesn’t matter so false path constraints would be the obvious choice to correct that. To do that,

we can add this to the SDC file:

set_false_path -from [get_ports SW*]

set_false_path -from [get_ports KEY*]

set_false_path -to [get_ports LEDR*]

set_false_path -to [get_ports HEX*]

This is already in the max10_top_v2.sdc file, so we will just use that file instead. To load in the

new constraints and recheck this, perform the following operations in TimeQuest:

Constraints -> Reset design

Constraints -> Read SDC file… (and select the max10_top_v2.sdc in the src folder)

Netlist -> Update timing netlist (you could also double click this in the tasks window)

Now if you re-run the Unconstrained Paths Summary you should see that there are none. So

the design is now fully constrained. Now we can move on to more detailed analysis of the

timing failure on the SRAM.

Remove the max10_top_v1.sdc file and add the max10_top_v2.sdc file to the main design (by

Add/Remove file option in the Project Navigator). Recompile the design.

Remember to replace the SDC file used by the design with the one you actually

settle on. At this point, we’ve read in the updated one but this will not be used the

next time the design is run unless we change the file list or update the original.

Step 3.6

Start by running all the summary reports. You can do this quickly by scrolling to the bottom of

the Tasks window to the Macros at the bottom and double clicking Report All Summaries. All

the summary reports will be generated and those with failing paths will be highlighted with red.

In this case, we see that we have two reports that contain errors – the setup and hold reports.

Page | 20

This is what we expected as this is the same information we saw in the multi-corner analysis that

Quartus ran as part of the compilation process. As you can see, the hold report is really

negligible, so we’ll start with the setup errors.

TimeQuest defaults to the slow corner. If you’re design has issues limited to other

corners (like hold time issues at the fast corner) then you need to set the operating

conditions. Select Netlist -> Set operating conditions…

If we click on the hold report, we see above that the failing clock is sdram_clk_int. This report

has two items

- Slack – This is the timing slack for the single worst net. In this case it is negative, indicating we have negative slack and are missing timing.

- End Point TNS – this is the Total Negative Slack. It is the sum of the negative slack for each individual failing path. For example, if you had five failing paths that each missed

by -1.5nS, the TNS would be -7.5nS.

Page | 21

Now, click on “Summary (Setup)” in the “Reports” window. We need to see what paths are

failing. To do this, we could run a custom report and fill in the specifics of the paths we are

looking for. A shortcut is to right click on the failing line in the report and select Report

Timing… from the pop-up menu. This will pre-populate a custom timing report with the

information needed to get the failing paths listed. Click Report Timing.

In our case, it will put in the clock we’re interested in, the fact that it is a setup report, and put in

a default description for the report name. Note this also gives you a template for the tcl scripting

command needed to generate the report if you wanted to make this part of a script.

When you run the report, you should see this:

As expected, the issue is in the SDRAM data pins to the read data capture register. If we click

on the top path (the one with the worst slack), the tables below list the details of the path.

Page | 22

If we collapse the delay tables, we see that the net is really quite tight. The clock delay off the

chip is 2.785nS, the access time of the DRAM is 6.0nS and the setup back to the device is

1.455nS. Let’s see if there are any candidates for improvement due to placement/routing.

Step 3.7

To check that, we’ll find this net in the chip planner. Right click anywhere on the row in the

summary of paths at the top of the window and select Locate path -> Locate in Chip Planner.

Page | 23

The net is highlighted, but in this case it is so short it is not easy to spot. Thus, double click on

the net (listed in the “located paths” in the lower right) to zoom in on just this net.

When you do that, you see this:

Page | 24

As it turns out, the FF is in the IO cell so there is no improvement that can be had here. If you

expand the clock path in the “Data Arrival Path” in TimeQuest, you’ll also see that there is little

that can be improved there.

When you run the TimeQuest tool a new section shows up in the Quartus Report

viewer called TimeQuest GUI… This contains all the reports you generated while

inside TimeQuest for reference. This is deleted when you re-compile the design.

As such, we will have to look elsewhere. As we consider the path, the most likely candidate is

the clock path. This was why we separated sdram_clk_int from clk_int – just in case we needed

to move the phase to adjust the timing. It look like we will need to do just that, since the ~3nS

delay for the clock leaving the chip is the most likely candidate for improvement. Any

movement of phase will reduce hold time slack, but that can automatically be adjusted for by

Quartus in the delay line settings for the IO cell.

To do this, we need to modify the SDC file to adjust the phase back in time on the sdram_clk_int

while leaving the clk_int untouched. This can be done one of two ways. You can look at the

SDC reference manual and see what the switch is for moving the phase on the generated clock

command and then make that change to the SDC file. The other method is to actually change the

PLL and repeat the steps outlined in the class materials to transfer those changes to the SDC file.

In summary:

- Run the design once with the derive_pll_clocks command in the SDC - Copy the generated clock commands with names modified for readability and remove the

derive_pll_clocks command and re-run the design.

Making changes to the phase in the SDC file will NOT change the design. When

you have determined the proper phase setting, you need to go back and change the

PLL. You will get an “inconsistent pll settings” warning if you do it wrong.

In our case, we’ll just change the SDC and then change the PLL later. Since the setup is missing

by -0.237nS, that would require a phase shift of at least -40 degrees to get us to zero margin. To

cover all the delay (2.785nS on the clock and 1.455nS on the input path would require around -

100 degrees. However, there is no minimum on the SDRAM access specified, so that would be

pushing the hold time hard. As a first guess, let’s try a value near the middle, or -63 degrees.

This change is made in the max10_top_v3.sdc file. Examine the settings for the sdram_clk_int.

Let’s try that without re-compiling the design to see if we are even close. The delay lines will

not be adjusted, but we should see if the setup time is OK.

Step 3.8

To try the modified SDC, do this again, only with the v3.sdc file:

Page | 25

In TimeQuest:


Constraints -> Read SDC file… (and select the max10_top_v3.sdc from the src folder)


Then hit report all summaries in Tasks window and check the results. You should see this:

OK, looks like we made things worse. Let’s check and see what happened. Right click on the

clk_int slack number (-8.597 above) and select Report Timing…

As you can see, the default latch edge is the next logical edge so we’ve actually shortened the

time, not made it longer. That is not what we wanted. We want to capture on the following

edge, so we need to add a multi-cycle 2 constraint so it is picking the right edge.

That has been added to the max10_top_v4.sdc file. Examine that and make sure it makes sense

to you.

Page | 26

In this case, we are shifting the window, not expanding it (i.e. we want to transfer

data on every clock). Thus, we don’t add the matching ‘hold multi-cycle’ to open

the window. See the class materials for a full discussion.

Now let’s reset the constraints and try this again.

In TimeQuest:


Constraints -> Read SDC file… (and select the max10_top_v4.sdc from the src folder)


Now when you report all summaries (from Tasks window), you should see this:

So we are in the clear – no violations. However, if you look in the warnings in the console in

TimeQuest, you will see this:

That is telling us that while the SDC file has changed and that is what is being used for analysis,

that is not what the actual PLL is set to and thus the real design will not reflect this new, clean

timing.

We should also note that this is only at one corner. Unless the design is re-run, the fast corner

may have hold issues. So, let’s go back and update the design and compile it again.

Page | 27

Step 3.10 Correct design

First, let’s replace the SDC file with the corrected one. To do that, go to the files tab in Project

Navigator in the main Quartus window, select the SDC file and delete it:

Then, double click the files folder icon, browse to src, select script files in the filter and add the

max10_top_v4.sdc file. It should now be at the top of the file list. Next, we need to fix the PLL.

In the Project Navigator, select IP components in the drop down menu and double click the

max10_pll:

This will open up the MegaWizard. Go to the output clocks tab and select the c1 output, and

change the phase to -63 deg:

Page | 28

Then click Finish (click finish if the Summary shows up) and re-run the entire design. You

should get clean timing and no inconsistent PLL warnings. If you get a “Launch IP Upgrade

Tool” option in the Project Navigator and select “Perform Automatic Upgrade”. Once the

upgrade completes, click close. Then compile the entire design.

Step 3.10 Extra Credit I

How tight can you make the FPGA clock to output constraint on the SRAM controls (ADDR,

CE, etc) before it fails timing?


Try cross-probing on other paths to locate the elements in both the chip planner and source code.

How easy is it to locate the elements in your source?

Step 3.12 Extra Credit III

Re-create the updated generate clock statements using the derive_pll_clocks first path method.


Page | 29

Lab 4: Power Analysis

Summary

In this short lab we will do a quick vector-less power calculation for the chip.

Lab Instructions

Step 4.1

Open the PowerPlay tool from the GUI:

Select: Processing -> PowerPlay Power Analyzer Tool

Since we don’t have any simulation vectors to refine the power analysis, there isn’t much to

configure. The output files will tell you what toggle rate was used in the analysis for the various

nodes in the design. Any known signals (such as the clock) should have the correct toggle rate,

no matter what.

Hit start and in roughly a minute, it should complete and the total power calculated will be

displayed in the message window. In this case, ~237mW.

Page | 30

In the report browser, there is a new selection for the PowerPlay Power Analyzer. Take a quick

look at the reports to get an idea of how the information is presented. As indicated by the report

files, the confidence level of the estimate is “low” since we did not provide any vectors. If we

had provided simulation vectors, we would get a more accurate analysis. However, this estimate

is still better than the one generated by the Early Power Estimator spreadsheet since the actual

resource counts and net loading is used.

To keep the report to a manageable size, a couple of the report panes are

“hidden” by default. For example, the Signal Activities report is empty unless

you ask for it. As you can imagine, this would be quite long for a large design.

Step 4.2 Extra Credit:

Which top level block uses the most power? Were you surprised by the module that came in

second?


Page | 31

Lab 5: Hardware Download

Summary

In this lab, we will setup the hardware and download the completed design into the device.

Lab Instructions

Step 5.1

First, we need to setup the DE10-Lite board.

Plug in the USB cable to the computer and connect it to the USB-Blaster port on the board. The

board receives power from this connection so there is nothing else to connect.

The board will power-up as soon as you connect the USB-Blaster port and if the factory default

design is loaded into the device, you will see a binary counting pattern on the green LEDs.

Page | 32

Step 5.2

Start the programmer via the GUI using the button bar or the menus:

Select: Tools -> Programmer

It should look like this:

If the Hardware Setup doesn’t say USB-Blaster, click on the Hardware Setup… button and

select the USB-Blaster. Natively, the FPGA is configured from the JTAG pins. The USB Blaster

circuitry bridges the USB protocol to the JTAG protocol so you can download configuration

information from your PC. This bridging circuit is either integrated into your dev kit, or you use

a special USB-Blaster cable which has a USB connector on one side and a JTAG header

connector on the other. If the USB-Blaster is not recognized, it’s most likely that the USB device

driver is not installed. Please refer to the appropriate cable document for downloading the device

driver at http://www.altera.com/literature/lit-cables.jsp.

Now we have to discover the JTAG chain. Click Auto Detect and after a couple seconds, you

will see a part selection box pop up. This is because several devices share the same JTAG ID so

you need to tell the programmer which device you are using (10M50DA). In truth, since we are

going to program our design to this device, it doesn’t matter what we pick because when we pick

the configuration file it will overwrite our selection with the part we used in Quartus.

http://www.altera.com/literature/lit-cables.jsp

Page | 33

Now we need to select the file for programming the device with our design. Right click on

device line (under file, device, checksum, etc and not the graphic of the device) and select

change file from the pop-up menu.

Browse to output_files and select MAX10_TOP.sof and click open.

Click the Program/Configure radio button and click the Start button. When the download

completes, make sure SW0 is toggled up toward the middle of the board (enabled) and the

LEDR0 should be blinking in a slow heartbeat (~ 1 second). If you get the heartbeat, the design

is loaded successfully and you can run tests.

Step 5.3

Now we’ll run a few tests. The tests in the code as supplied with the lab are defined as follows:

SW[3:1] Test Name Data Pattern Address range tested

000 Address tag Location address 0x000000-0x03FFFC

001 Random Data LFSR8 Polynomial 0x000000-0x001FFC



100 Custom 0 Start at 0, increment by 4 0x000000-0x00003C

101 Custom 1 Start at 0, increment by 4 0x000000-0x0003FC

110 Custom 2 Start at 0, increment by 4 0x000000-0x003FFC

111 Custom 3 Start at 0, increment by 4 0x000000-0x3FFFFC

Page | 34

The seven segment display will display one of three possible status indicators – PASS, FAIL,

and run with a rotating circle to show activity. The status of the test is also indicated by the

LEDs. They are defined as follows:

LED Definition

LEDs

LEDR[0] Heartbeat – this will blink at a low rate to

indicate that the design is loaded and out of

reset.

LEDR[3:1] Indicate the test ID of the test, as defined in

the table above.

LEDR[4] Test running – will be lit while test is

running. This is pulse stretched so you can

see it for even short tests.

LEDR[5] Test fail – will blink rapidly if the test fails.

LEDR[6] Test pass – will be lit if test passes. Will

stay lit until new test is run.

LEDR[7] Test complete – will be lit when test

completes. Will stay lit until new test is run.

SW0 enables the functionality of the design, and will trigger a heartbeat on LEDR0 when it is

enabled (switched toward the middle of the board). To start a test, make sure SW0 is enabled,

select the desired test using the switches SW[3:1], and then press the pushbutton labeled KEY1.

The status is written to the 7 segment display and is also indicated by the LEDs.

The design can be reset by pressing the pushbutton labeled KEY0, or by toggling the switch

labeled SW0. This will turn off all the displays except the heartbeat on LEDR0 until a test is

run.

Step 5.4

Before we quit, we’ll save this programming setup so we don’t have to configure it each time we

want to load the device. In the programmer, select File -> Save as… and pick any name you

want. You’ll see that by default, “add file to project” is selected. Click save and then close the

programmer.

If you go back to Quartus and in the Project Navigator you select the “files” tab, you’ll see your

new file in the list as a .cdf file (Chain Definition File). In the future if you wanted to

program this device, all you need to do it double click this file and it will open the programmer

with the setup restored.


Do any of the tests fail?


Page | 35

Lab 6: Hardware Debug

Summary

In this lab, we will insert a SignalTap module into the design and do a few simple data captures

of signals in the design.

Lab Instructions

Step 6.1

To setup SignalTap, you need to do three things:

1) Select the sample clock. 2) Configure the Analyzer depth and mode. 3) Select signals that you want to capture.

Open SignalTap by selecting Tools SignalTap II Logic Analyzer… from the main Quartus

menu. You should see this:

Step 6.2

First, we are going to set the clock, located in the red box above. We will be using the pre-

synthesis netlist for SignalTap so we can pick the clock at any convenient logic point. In this

case, we’ll find it at the input to the SDRAM control block.

Click on the […] at the end of the clock window to bring up the node finder. Once in the node

finder, change the filter to SignalTap II: pre-synthesis. You now have two choices. You can set

the “look in” to just the SDRAM controller or just scroll down the list in the hierarchy view and

Page | 36

find the clock input that way. To look at a list of all possible nodes, you must first click on List

in the top right corner.

Make sure you have the “include subentities” and “hierarchy view” clicked if you

want to browse the entire design. For larger designs it may be easier to set the

“look in” to the block of interest first.

In this case, since we are looking for the first MAX10 50MHz clock, we will put

*MAX10_CLK1_50* in the named filter at the top to filter out most of the nodes. Now if we

hit Lis, we see the clock input. If we click on [>], we move the node from the found list to the

selected list.

Page | 37

Now click OK and we have the clock selected. This is the sample clock for the analyzer. Now,

set the Sample Depth (right below the clock) to 2K.

Step 6.2

Now it’s time to add signals to capture. Double click in the signal display area (in the Data pane,

toward the lower left area of the SignalTap window) and it will bring up the node finder. Using

the same process as we did for the clock, select these signals. Note, some of these are busses, so

add the entire bus and not the individual bits of the bus. We’ll start in the SDRAM_CTRL block

by adding: chipselect, read_n, readdatavalid, waitrequest, write_n, address, readdata, writedata.

Page | 38

Then, in the RAM_TEST block, add: test_complete, test_error, test_fail, test_pass, test_running,

test_start, data_error and data_error_cnt.

Page | 39

The final thing we need to do is take some of these signals out of the Trigger Enable. This isn’t

mandatory, but if you trigger on every possible signal, the analyzer has to be built with an

identity comparator that is as wide as the number of bits you have selected. In this case, it’s 82

signals, so that is not too bad but it is good to get in the practice of eliminating ones that won’t be

used. Thus, we’re going to turn off the trigger enable on the data busses, for example, as it is

unlikely we’re going to trigger on a specific data pattern. In this case, we can likely shut off all

the busses (uncheck the trigger enable checkbox for all signals that have x’s (undefined) under

trigger conditions) and end up with this as a final setup:

Page | 40

+

Now save the file in the directory above src and call it whatever you want. Note that there is a

radio button at the bottom that says Add file to current project. By default it is on. This will

enable this SignalTap file for the current project. If asked to “enable the file for this project” –

click yes.

Once the file is saved, recompile the entire project.

If you want to turn the SignalTap off, go into Assignments -> Settings, select

SignalTap on the left and uncheck the Enable SignalTap II Logic Analyzer. This

doesn’t remove the file name, it just disables it so it isn’t included in the design.

Step 6.3

Once the compile finishes, open the programmer and program the device with the newly

compiled design. You should see the LED Heartbeat just like before. Ignore if the TimeQuest

Timing Analyzer fails. This happens due to the addition of debug signals.

To quickly open the programmer, just double click on the .cdf file you

saved earlier and added to the project.

Now open the SignalTap II analyzer. Select: Tools -> SignalTap II Logic Analyzer

Page | 41

You should see this in the SignalTap window:

Itr should say “ready to acquire.” If you don’t get that, likely the USB cable was not detected.

Next to the Hardware setting click the drop down and select the USB_Blaster. The yellow and

red bars should now be gone and it should be ready to acquire.

To get a baseline trace, click the run analysis button . This will run the analyzer and acquire

data from a single trigger event – in this case, all don’t cares so it’s just a real-time data capture

of what’s going on in the chip. As you can see when the data comes back, nothing is running

and it is all flat line data. Now let’s make it more interesting.

Go back to the Setup Tab (from the Data tab) to setup the new capture. We’re going to trigger

on the end of the test. Set trigger condition 1 to trigger on rising edge (or “1”) of the signal

SDRAM_CTRL/test_complete – you do this by right clicking on the trigger condition and

selecting what you want. Your choices are High, Low, Rising Edge, Falling Edge, Either Edge

or Don’t Care. If it were a bus, you could also put in a bus value.

Page | 42

Set the trigger position (right side pane, you may have to scroll down) to Post Trigger Position

and click the run analysis again. Click button again. Now you will see an indication of

Waiting for trigger in the top status bar. Toggle SW[1] to run a test and you should get a trigger.

This is a short test and the entire trace fits in the buffer.

Make sure you zoom all the way out and you should see this.

Spend some time zooming in on the data and answering a few questions.

How many clocks from Write to Write?

How many clocks from Read to Read?

What was the first Address tested? The last?

Remembering that the accesses are 32 bits and the memory is 16, can you verify the pattern

based on the test ID in the table ?

How many clocks from the start of the test to the end? First write to first read? (Hint – use time

bars – right click above sample numbers...)

Step 6.4 Extra Credit I

There is a bug in the test generation state machine that goes undetected by the checker. What is

it? (Hint: Look at the write side of a short test)

Writes to memory Reads from memory

Test start Test end

Page | 43


The test with the test ID = 111 fails. Why is that?


Congratulations, you have completed all of the labs.

Documents

Intel FPGA Tools Introduction Quartus Prime 17.0 Lab Manual … · 2020. 10. 10. · Click on browse (“…”) and navigate to demo/cores to add the tool generated IP Now we will