Quartus II Handbook Volume 1: Design and Synthesis

Quartus II Handbook Volume 1: Design and Synthesis
Subscribe
Send Feedback
QII5V1
2015.05.04
101 Innovation Drive
San Jose, CA 95134
www.altera.com
Managing Quartus II Projects
1
2015.05.04
QII5V1
Subscribe
Send Feedback
The Quartus II software organizes and manages the elements of your design within a project. The project
encapsulates information about your design hierarchy, libraries, constraints, and project settings. Click
File > New Project Wizard to quickly create a new project and specify basic project settings
When you open a project, a unified GUI displays integrated project information. The Project Navigator
allows you to view and edit the elements of your project. The Messages window lists important informa‐
tion about project processing.
You can save multiple revisions of your project to experiment with settings that achieve your design goals.
Quartus II projects support team-based, distributed work flows and a scripting interface.
Quick Start
To quickly create a project and specify basic settings, click File > New Project Wizard.
New Project Wizard
© 2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos are
trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as
trademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance
of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any
products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information,
product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device
specifications before relying on any published information and before placing orders for products or services.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
ISO
9001:2008
Registered
1-2
QII5V1
2015.05.04
Understanding Quartus II Projects
Note: The New Project Wizard offers project templates based on fully functioning design examples.
Select the Project template option to choose a project template that is ready to compile. Altera
provides additional project templates as available.
Understanding Quartus II Projects
A single Quartus II Project File (.qpf) represents each project. The text-based . qpf references the Quartus
II Settings File (.qsf), that lists all project files and stores project and entity settings. When you make
project changes in the GUI, these text files automatically store the changes. The GUI helps to manage:
• Design, EDA, IP core, and Qsys system files
• Project settings and constraint files
• Project archive and migration files
Table 1-1: Quartus II Project Files
File Type
Contains
To Edit
Format
Project file
Project and revision name
File > New Project
Wizard
Quartus II Project File (.qpf)
Project
settings
Lists design files, entity
settings, target device,
synthesis directives,
placement constraints
Assignments > Settings
Quartus II Settings File (.qsf)
Project
database
Compilation results
Project > Export
Database
Exported Partition File (.qxp)
Timing
constraints
Clock properties,
exceptions, setup/hold
Tools > TimeQuest
Timing Analyzer
Synopsys Design Constraints File
(.sdc)
Logic design RTL and other design
files
source files
File > New
All supported HDL files
Program‐
ming files
Device programming
image and information
Tools > Programmer
SRAM Object File (.sof)
Programmer Object File (.pof)
Project
library
Project and global library
information
Tools > Options >
Libraries
.qsf(project)
IP core files IP core logic, synthesis,
and simulation
information
Tools > IP Catalog
All supported HDL files
Qsys system Qsys system and IP core
files
files
Tools > Qsys
Altera Corporation
quartus2.ini (global)
Quartus II IP File (.qip)
Qsys System File (.qsys)
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Viewing Basic Project Information
File Type
EDA tool
files
Contains
Generated for third-party
EDA tools
To Edit
Tools > Options > EDA
Tool Options
1-3
Format
Verilog Output File (.vo)
VHDL Output File (.vho)
Verilog Quartus Mapping File
(.vqm)
Archive files Complete project as single Project > Archive Project Quartus II Archive File (.qar)
compressed file
Viewing Basic Project Information
View basic information about your project in the Project Navigator, Report panel, and Messages window.
View project elements in the Project Navigator ( View > Utility Windows > Project Navigator). The
Project Navigator displays key project information, including design files, IP components, and revisions
of your project. Use the Project Navigator to:
•
•
•
•
View and modify the design hierarchy (right-click > Set as Top-Level Entity)
Set the project revision (right-click > Set Current Revision)
View and update logic design files and constraint files (right-click > Open)
Update IP component version information (right-click > Upgrade IP Component)
Figure 1-1: Project Navigator Hierarchy, Files, Revisions, and IP
Viewing Project Reports
The Report panel (Processing > Compilation Report) displays detailed reports after project processing,
including the following:
•
•
•
•
•
Analysis & Synthesis reports
Fitter reports
Timing analysis reports
Power analysis reports
Signal integrity reports
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-4
Viewing Project Messages
QII5V1
2015.05.04
Analyze the detailed project information in these reports to determine correct implementation. Rightclick report data to locate and edit the source in project files.
Figure 1-2: Report Panel
Related Information
List of Compilation Reports
Viewing Project Messages
The Messages window (View > Utility Windows > Messages) displays information, warning, and error
messages about Quartus II processes. Right-click messages to locate the source or get message help.
• Processing tab—displays messages from the most recent process
• System tab—displays messages unrelated to design processing
• Search—locates specific messages
Messages are written to stdout when you use command-line executables.
Figure 1-3: Messages Window
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Suppressing Messages
1-5
You can suppress display of unimportant messages so they do not obscure valid messages.
Figure 1-4: Message Suppression by Message ID Number
Suppressing Messages
To supress messages, right-click a message and choose any of the following:
• Suppress Message—suppresses all messages matching exact text
• Suppress Messages with Matching ID—suppresses all messages matching the message ID number,
ignoring variables
• Suppress Messages with Matching Keyword—suppresses all messages matching keyword or
hierarchy
Message Suppression Guidelines
•
•
•
•
You cannot suppress error or Altera legal agreement messages.
Suppressing a message also suppresses any submessages.
Message suppression is revision-specific. Derivative revisions inherit any suppression.
You cannot edit messages or suppression rules during compilation.
Managing Project Settings
The New Project Wizard helps you initially assign basic project settings. Optimizing project settings
enables the Compiler to generate programming files that meet or exceed your specifications.
The .qsf stores each revision’s project settings.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-6
Managing Project Settings
QII5V1
2015.05.04
Click Assignments > Settings to access global project settings, including:
•
•
•
•
•
•
•
•
Project files list
Synthesis directives and constraints
Logic options and compiler effort levels
Placement constraints
Timing constraint files
Operating temperature limits and conditions
File generation for other EDA tools
Target device (click Assignments > Device)
The Quartus II Default Settings File (<revision name>_assignment_defaults.qdf) stores initial settings
and constraints for each new project revision.
Figure 1-5: Settings Dialog Box for Global Project Settings
The Assignment Editor (Tools > Assignment Editor) provides a spreadsheet-like interface for assigning
all instance-specific settings and constraints.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Optimizing Project Settings
1-7
Figure 1-6: Assignment Editor Spreadsheet
Optimizing Project Settings
Optimize project settings to meet your design goals. The Quartus II Design Space Explorer II iteratively
compiles your project with various setting combinations to find the optimal setting for your goals.
Alternatively, you can create a project revision or project copy to manually compare various project
settings and design combinations.
Optimizing with Design Space Explorer II
Use Design Space Explorer II (Tools > Launch Design Space Explorer II) to find optimal project settings
for resource, performance, or power optimization goals. Design Space Explorer II (DSE II) processes your
design using various setting and constraint combinations, and reports the best settings for your design.
DSE II attempts multiple seeds to identify one meeting your requirements. DSE II can run different
compilations on multiple computers in parallel to streamline timing closure.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-8
Optimizing with Project Revisions
QII5V1
2015.05.04
Figure 1-7: Design Space Explorer II
Optimizing with Project Revisions
You can save multiple, named project revisions within your Quartus II project (Project > Revisions).
Each revision captures a unique set of project settings and constraints, but does not capture any logic
design file changes. Use revisions to experiment with different settings while preserving the original.You
can compare revisions to determine the best combination, or optimize different revisions for various
applications. Use revisions for the following:
• Create a unique revision to optimize a design for different criteria, such as by area in one revision and
by fMAX in another revision.
• When you create a new revision the default Quartus II settings initially apply.
• Create a revision of a revision to experiment with settings and constraints. The child revision includes
all the assignments and settings of the parent revision.
You create, delete, specify current, and compare revisions in the Revisions dialog box. Each time you
create a new project revision, the Quartus II software creates a new .qsf using the revision name.
To compare each revision’s synthesis, fitting, and timing analysis results side-by-side, click Project >
Revisions and then click Compare.
In addition to viewing the compilation results of each revision, you can also compare the assignments for
each revision. This comparison reveals how different optimization options affect your design.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Copying Your Project
1-9
Figure 1-8: Comparing Project Revisions
Copying Your Project
Click Project > Copy Project to create a separate copy of your project, rather than just a revision within
the same project.
The project copy includes all design files, .qsf(s), and project revisions. Use this technique to optimize
project copies for different applications. For example, optimize one project to interface with a 32-bit data
bus, and optimize a project copy to interface with a 64-bit data bus.
Managing Logic Design Files
The Quartus II software helps you create and manage the logic design files in your project. Logic design
files contain the logic that implements your design. When you add a logic design file to the project, the
Compiler automatically compiles that file as part of the project. The Compiler synthesizes your logic
design files to generate programming files for your target device.
The Quartus II software includes full-featured schematic and text editors, as well as HDL templates to
accelerate your design work. The Quartus II software supports VHDL Design Files (.vhd), Verilog HDL
Design Files (.v), SystemVerilog (. sv) and schematic Block Design Files (. bdf). The Quartus II software
also supports Verilog Quartus Mapping (.vqm) design files generated by other design entry and synthesis
tools. In addition, you can combine your logic design files with Altera and third-party IP core design files,
including combining components into a Qsys system (. qsys).
The New Project Wizard prompts you to identify logic design files. Add or remove project files by clicking
Project > Add/Remove Files in Project. View the project’s logic design files in the Project Navigator.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-10
QII5V1
2015.05.04
Including Design Libraries
Figure 1-9: Design and IP Files in Project Navigator
Right-click files in the Project Navigator to:
•
•
•
•
•
Open and edit the file
Remove File from Project
Set as Top-Level Entity for the project revision
Create a Symbol File for Current File for display in schematic editors
Edit file Properties
Including Design Libraries
You can include design files libraries in your project. Specify libraries for a single project, or for all
Quartus II projects. The.qsf stores project library information.
The quartus2.ini file stores global library information.
Related Information
Design Library Migration Guidelines on page 1-41
Specifying Design Libraries
To specify project libraries from the GUI:
1. Click Assignment > Settings.
2. Click Libraries andspecify the Project Library name or Global Library name.Alternatively, you can
specify project libraries with SEARCH_PATH in the .qsf, and global libraries in the quartus2.ini file.
Related Information
• Recommended Design Practices on page 11-1
• Recommended HDL Coding Styles on page 12-1
Managing Timing Constraints
View basic information about your project in the Project Navigator, Report panel, and Messages window.
Apply appropriate timing constraints to correctly optimize fitting and analyze timing for your design. The
Fitter optimizes the placement of logic in the device to meet your specified timing and routing
constraints.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Introduction to Altera IP Cores
1-11
Specify timing constraints in the TimeQuest Timing Analyzer (Tools > TimeQuest Timing Analyzer), or
in an .sdc file. Specify constraints for clock characteristics, timing exceptions, and external signal setup
and hold times before running analysis. TimeQuest reports the detailed information about the perform‐
ance of your design compared with constraints in the Compilation Report panel.
Save the constraints you specify in the GUI in an industry-standard Synopsys Design Constraints File
(.sdc). You can subsequently edit the text-based .sdc file directly.
Figure 1-10: TimeQuest Timing Analyzer and SDC Syntax Example
Related Information
Quartus II TimeQuest Timing Analyzer
Introduction to Altera IP Cores
Altera® and strategic IP partners offer a broad portfolio of off-the-shelf, configurable IP cores optimized
for Altera devices. The Quartus® II software installation includes the Altera IP library. You can integrate
optimized and verified Altera IP cores into your design to shorten design cycles and maximize
performance. You can evaluate any Altera IP core in simulation and compilation in the Quartus II
software. The Quartus II software also supports integration of IP cores from other sources. Use the IP
Catalog to efficiently parameterize and generate synthesis and simulation files for a custom IP variation.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-12
QII5V1
2015.05.04
Installing and Licensing IP Cores
The Altera IP library includes the following categories of IP cores:
•
•
•
•
•
•
Basic functions
DSP functions
Interface protocols
Low power functions
Memory interfaces and controllers
Processors and peripherals
Note: The IP Catalog (Tools > IP Catalog) and parameter editor replace the MegaWizard Plug-In
Manager for IP selection and parameterization, beginning in Quartus II software version 14.0. Use
the IP Catalog and parameter editor to locate and paramaterize Altera and other supported IP
cores.
™
Related Information
• IP User Guide Documentation
• Altera IP Release Notes
Installing and Licensing IP Cores
The Altera IP Library provides many useful IP core functions for your production use without purchasing
an additional license. Some Altera MegaCore® IP functions require that you purchase a separate license
for production use. However, the OpenCore® feature allows evaluation of any Altera IP core in simulation
and compilation in the Quartus II software. After you are satisfied with functionality and perfformance,
visit the Self Service Licensing Center to obtain a license number for any Altera product.
Figure 1-11: IP Core Installation Path
acds
quartus - Contains the Quartus II software
ip - Contains the Altera IP Library and third-party IP cores
altera - Contains the Altera IP Library source code
<IP core name> - Contains the IP core source files
Note: The default IP installation directory on Windows is <drive>:\altera\<version number>; on Linux it is
<home directory>/altera/ <version number>.
Related Information
• Altera Licensing Site
• Altera Software Installation and Licensing Manual
OpenCore Plus IP Evaluation
Altera's free OpenCore Plus feature allows you to evaluate licensed MegaCore IP cores in simulation and
hardware before purchase. You need only purchase a license for MegaCore IP cores if you decide to take
your design to production. OpenCore Plus supports the following evaluations:
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
IP Catalog and Parameter Editor
•
•
•
•
1-13
Simulate the behavior of a licensed IP core in your system.
Verify the functionality, size, and speed of the IP core quickly and easily.
Generate time-limited device programming files for designs that include IP cores.
Program a device with your IP core and verify your design in hardware.
OpenCore Plus evaluation supports the following two operation modes:
• Untethered—run the design containing the licensed IP for a limited time.
• Tethered—run the design containing the licensed IP for a longer time or indefinitely. This requires a
connection between your board and the host computer.
Note: All IP cores that use OpenCore Plus time out simultaneously when any IP core in the design times
out.
IP Catalog and Parameter Editor
The Quartus II IP Catalog (Tools > IP Catalog) and parameter editor help you easily customize and
integrate IP cores into your project. You can use the IP Catalog and parameter editor to select, customize,
and generate files representing your custom IP variation.
Note: The IP Catalog (Tools > IP Catalog) and parameter editor replace the MegaWizard Plug-In
Manager for IP selection and parameterization, beginning in Quartus II software version 14.0. Use
the IP Catalog and parameter editor to locate and paramaterize Altera IP cores.
™
The IP Catalog lists installed IP cores available for your design. Double-click any IP core to launch the
parameter editor and generate files representing your IP variation. The parameter editor prompts you to
specify an IP variation name, optional ports, and output file generation options. The parameter editor
generates a top-level Qsys system file (.qsys) or Quartus II IP file (.qip) representing the IP core in your
project. You can also parameterize an IP variation without an open project.
Use the following features to help you quickly locate and select an IP core:
• Filter IP Catalog to Show IP for active device family or Show IP for all device families. If you have no
project open, select the Device Family in IP Catalog.
• Type in the Search field to locate any full or partial IP core name in IP Catalog.
• Right-click an IP core name in IP Catalog to display details about supported devices, open the IP core's
installation folder, and view links to documentation.
• Click Search for Partner IP, to access partner IP information on the Altera website.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-14
QII5V1
2015.05.04
Using the Parameter Editor
Figure 1-12: Quartus II IP Catalog
Show IP only for target device
Search for installed IP cores
Double-click to customize, right-click for
detailed information
Note: The IP Catalog is also available in Qsys (View > IP Catalog). The Qsys IP Catalog includes
exclusive system interconnect, video and image processing, and other system-level IP that are not
available in the Quartus II IP Catalog. For more information about using the Qsys IP Catalog, refer
to Creating a System with Qsys in the Quartus II Handbook.
Related Information
Creating a System With Qsys on page 5-1
Using the Parameter Editor
The parameter editor helps you to configure IP core ports, parameters, and output file generation options.
• Use preset settings in the parameter editor (where provided) to instantly apply preset parameter values
for specific applications.
• View port and parameter descriptions, and links to documentation.
• Generate testbench systems or example designs (where provided).
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Adding IP Cores to IP Catalog
1-15
Figure 1-13: IP Parameter Editors
View IP port
and parameter
details
Legacy parameter
editors
Specify your IP variation
name and target device
Apply preset parameters for
specific applications
Adding IP Cores to IP Catalog
The IP Catalog automatically displays Altera IP cores found in the project directory, in the Altera
installation directory, and in the defined IP search path. The IP Catalog can include Altera-provided IP
components, third-party IP components, custom IP components that you provide, and previously
generated Qsys systems.
You can use the IP Search Path option (Tools > Options) to include custom and third-party IP
components in the IP Catalog. The IP Catalog displays all IP cores in the IP search path. The Quartus II
software searches the directories listed in the IP search path for the following IP core files:
• Component Description File (_hw.tcl)—Defines a single IP core.
• IP Index File (.ipx)—Each .ipx file indexes a collection of available IP cores, or a reference to other
directories to search. In general, .ipx files facilitate faster searches.
The Quartus II software searches some directories recursively and other directories only to a specific
depth. When the search is recursive, the search stops at any directory that contains an _hw.tcl or .ipx file.
In the following list of search locations, a recursive descent is annotated by **. A single * signifies any file.
Table 1-2: IP Search Locations
Location
Description
PROJECT_DIR/*
Finds IP components and index files in the Quartus II project
directory.
PROJECT_DIR/ip/**/*
Finds IP components and index files in any subdirectory of the /ip
subdirectory of the Quartus II project directory.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-16
QII5V1
2015.05.04
General Settings for IP
Figure 1-14: Specifying IP Search Locations
Adds new global IP search paths
Changes search path order
Lists current project and global search paths
Adds new project-specific IP search paths
If the Quartus II software recognizes two IP cores with the same name, the following search path
precedence rules determine the resolution of files:
1. Project directory.
2. Project database directory.
3. Project IP search path specified in IP Search Locations, or with the SEARCH_PATH assignment in the
Quartus II Settings File (.qsf) for the current project revision.
4. Global IP search path specified in IP Search Locations, or with the SEARCH_PATH assignment in the
quartus2.ini file.
5. Quartus software libraries directory, such as <Quartus Installation>\libraries.
Note: If you add a component to the search path, you must refresh your system by clicking File > Refresh
to update the IP Catalog.
General Settings for IP
You can use the following settings to control how the Quartus II software manages IP cores in your
project.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Specifying IP Core Parameters and Options
1-17
Table 1-3: IP Core General Setting Locations
Setting Location
Tools > Options > IP
Settings
Or
Assignments > Settings >
IP Settings (only enabled
with open project)
Tools > Options > IP
Catalog Search Locations
Or
Description
• Specify your IP generation HDL preference. The parameter editor
generates IP files in your preferred HDL by default.
• Increase Maximum Qsys memory usage size if you experience slow
processing for large systems, or if Qsys reports an Out of Memory error.
• Specify whether to Automatically add Quartus II IP files to all projects.
Disable this option to control addition of IP files manually. You may
want to experiment with IP before adding to a project.
• Use the IP Regeneration Policy setting to control when synthesis files
are regenerated for each IP variation. Typically you Always regenerate
synthesis files for IP cores after making changes to an IP variation.
• Specify project and global IP search locations. The Quartus II software
searches for IP cores in the project directory, in the Altera installation
directory, and in the IP search path.
Assignments > Settings >
IP Catalog Search
Locations
Assignments > Settings >
Simulation
• NativeLink Settings allow you to automatically compile testbenches for
supported simulators. You can also specify a script to compile the
testbench, and a script to set up the simulation.
Specifying IP Core Parameters and Options
You can quickly configure a custom IP variation in the parameter editor. Use the following steps to
specify IP core options and parameters in the parameter editor. Refer to Specifying IP Core Parameters
and Options (Legacy Parameter Editors) for configuration of IP cores using the legacy parameter editor.
1. In the IP Catalog (Tools > IP Catalog), locate and double-click the name of the IP core to customize.
The parameter editor appears.
2. Specify a top-level name for your custom IP variation. The parameter editor saves the IP variation
settings in a file named <your_ip>.qsys. Click OK.
3. Specify the parameters and options for your IP variation in the parameter editor, including one or
more of the following. Refer to your IP core user guide for information about specific IP core
parameters.
• Optionally select preset parameter values if provided for your IP core. Presets specify initial
parameter values for specific applications.
• Specify parameters defining the IP core functionality, port configurations, and device-specific
features.
• Specify options for processing the IP core files in other EDA tools.
4. Click Generate HDL, the Generation dialog box appears.
5. Specify output file generation options, and then click Generate. The IP variation files generate
according to your specifications.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-18
QII5V1
2015.05.04
Files Generated for Altera IP Cores
6. To generate a simulation testbench, click Generate > Generate Testbench System.
7. To generate an HDL instantiation template that you can copy and paste into your text editor, click
Generate > HDL Example.
8. Click Finish. The parameter editor adds the top-level .qsys file to the current project automatically. If
you are prompted to manually add the .qsys file to the project, click Project > Add/Remove Files in
Project to add the file.
9. After generating and instantiating your IP variation, make appropriate pin assignments to connect
ports.
Figure 1-15: IP Parameter Editor
View IP port
and parameter
details
Specify your IP variation name
and target device
Apply preset parameters for
specific applications
Files Generated for Altera IP Cores
The Quartus II software generates the following IP core output file structure:
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Files Generated for Altera IP Cores
1-19
Figure 1-16: IP Core Generated Files
<project directory>
<your_ip>.qsys - System or IP integration file
<your_ip>.sopcinfo - Software tool-chain integration file
<your_ip>
<your_ip> n
<testbench>_tb
IP variation files
IP variation files
testbench system
<your_ip>_tb.qsys
Testbench system file
<your_ip>.cmp - VHDL component declaration file
<your_ip>_bb.v - Verilog HDL black box EDA synthesis file
<your_ip>_inst.v or .vhd - Sample instantiation template
<your_ip>.ppf - XML I/O pin information file
<testbench>_tb
testbench files
<your_ip>.qip - Lists IP synthesis files
<your_testbench>_tb.csv
<your_ip>.sip - Contains assingments for IP simulation files
<your_testbench>_tb.spd
<your_ip>_generation.rpt - IP generation report
<your_ip>.debuginfo - Contains post-generation information
<your_ip>.html - Connection and memory map data
sim
simulation files
<your_ip>.bsf - Block symbol schematic
<your_ip>.spd - Combines simulation scripts for multiple cores
<EDA tool setup
scripts>
sim
synth
Simulation files
IP synthesis files
<your_ip>.v or .vhd
Top-level simulation file
<EDA tool name>
Simulator scripts
<simulator_setup_scripts>
<ip subcores> n
Subcore libraries
<your_ip>.v or .vhd
Top-level IP synthesis file
synth
Subcore
synthesis files
sim
Subcore
Simulation files
<HDL files>
<HDL files>
Table 1-4: IP Core Generated Files
File Name
Description
<my_ip>.qsys
The Qsys system or top-level IP variation file. <my_ip> is the name
that you give your IP variation.
<system>.sopcinfo
Describes the connections and IP component parameterizations in
your Qsys system. You can parse its contents to get requirements
when you develop software drivers for IP components.
Downstream tools such as the Nios II tool chain use this file.
The .sopcinfo file and the system.h file generated for the Nios II tool
chain include address map information for each slave relative to each
master that accesses the slave. Different masters may have a different
address map to access a particular slave component.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-20
QII5V1
2015.05.04
Files Generated for Altera IP Cores
File Name
Description
<my_ip>.cmp
The VHDL Component Declaration (.cmp) file is a text file that
contains local generic and port definitions that you can use in VHDL
design files.
<my_ip>.html
A report that contains connection information, a memory map
showing the address of each slave with respect to each master to
which it is connected, and parameter assignments.
<my_ip>_generation.rpt
IP or Qsys generation log file. A summary of the messages during IP
generation.
<my_ip>.debuginfo
Contains post-generation information. Used to pass System Console
and Bus Analyzer Toolkit information about the Qsys interconnect.
The Bus Analysis Toolkit uses this file to identify debug components
in the Qsys interconnect.
<my_ip>.qip
Contains all the required information about the IP component to
integrate and compile the IP component in the Quartus II software.
<my_ip>.csv
Contains information about the upgrade status of the IP component.
<my_ip>.bsf
A Block Symbol File (.bsf) representation of the IP variation for use
in Quartus II Block Diagram Files (.bdf).
<my_ip>.spd
Required input file for ip-make-simscript to generate simulation
scripts for supported simulators. The .spd file contains a list of files
generated for simulation, along with information about memories
that you can initialize.
<my_ip>.ppf
The Pin Planner File (.ppf) stores the port and node assignments for
IP components created for use with the Pin Planner.
<my_ip>_bb.v
You can use the Verilog black-box (_bb.v) file as an empty module
declaration for use as a black box.
<my_ip>.sip
Contains information required for NativeLink simulation of IP
components. You must add the .sip file to your Quartus project.
<my_ip>_inst.v or _inst.vhd
HDL example instantiation template. You can copy and paste the
contents of this file into your HDL file to instantiate the IP variation.
<my_ip>.regmap
If the IP contains register information, the .regmap file generates.
The .regmap file describes the register map information of master
and slave interfaces. This file complements the .sopcinfo file by
providing more detailed register information about the system. This
enables register display views and user customizable statistics in
System Console.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Specifying IP Core Parameters and Options (Legacy Parameter Editors)
File Name
<my_ip>.svd
1-21
Description
Allows HPS System Debug tools to view the register maps of
peripherals connected to HPS within a Qsys system.
During synthesis, the .svd files for slave interfaces visible to System
Console masters are stored in the .sof file in the debug section.
System Console reads this section, which Qsys can query for register
map information. For system slaves, Qsys can access the registers by
name.
<my_ip>.v
or
HDL files that instantiate each submodule or child IP core for
synthesis or simulation.
<my_ip>.vhd
mentor/
Contains a ModelSim® script msim_setup.tcl to set up and run a
simulation.
aldec/
Contains a Riviera-PRO script rivierapro_setup.tcl to setup and run a
simulation.
/synopsys/vcs
Contains a shell script vcs_setup.sh to set up and run a VCS®
simulation.
/synopsys/vcsmx
Contains a shell script vcsmx_setup.sh and synopsys_ sim.setup file to
set up and run a VCS MX® simulation.
/cadence
Contains a shell script ncsim_setup.sh and other setup files to set up
and run an NCSIM simulation.
/submodules
Contains HDL files for the IP core submodule.
<child IP cores>/
For each generated child IP core directory, Qsys generates /synth and /
sim sub-directories.
Specifying IP Core Parameters and Options (Legacy Parameter Editors)
Some IP cores use a legacy version of the parameter editor for configuration and generation. Use the
following steps to configure and generate an IP variation using a legacy parameter editor.
Note: The legacy parameter editor generates a different output file structure than the latest parameter
editor. Refer to Specifying IP Core Parameters and Options for configuration of IP cores that use the
latest parameter editor.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-22
Files Generated for Altera IP Cores (Legacy Parameter Editors)
QII5V1
2015.05.04
Figure 1-17: Legacy Parameter Editors
Legacy parameter
editors
1. In the IP Catalog (Tools > IP Catalog), locate and double-click the name of the IP core to customize.
The parameter editor appears.
2. Specify a top-level name and output HDL file type for your IP variation. This name identifies the IP
core variation files in your project. Click OK.
3. Specify the parameters and options for your IP variation in the parameter editor. Refer to your IP core
user guide for information about specific IP core parameters.
4. Click Finish or Generate (depending on the parameter editor version). The parameter editor generates
the files for your IP variation according to your specifications. Click Exit if prompted when generation
is complete. The parameter editor adds the top-level .qip file to the current project automatically.
Note: To manually add an IP variation generated with legacy parameter editor to a project, click
Project > Add/Remove Files in Project and add the IP variation .qip file.
Files Generated for Altera IP Cores (Legacy Parameter Editors)
The Quartus II software generates one of the following output file structures for Altera IP cores that use a
legacy parameter editor.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Scripting IP Core Generation
1-23
Figure 1-18: IP Core Generated Files (Legacy Parameter Editor)
Generated IP File Output A
<Project Directory>
Generated IP File Output B
<Project Directory>
<your_ip>.qip - Quartus II IP integration file
<your_ip>.qip - Quartus II IP integration file
<your_ip>.v or .vhd - Top-level IP synthesis file
<your_ip>.v or .vhd - Top-level HDL IP variation definition
<your_ip>_bb.v - Verilog HDL black box EDA synthesis file
<your_ip>.bsf - Block symbol schematic file
<your_ip>_syn.v or .vhd - Timing & resource estimation netlist 1
<your_ip>.vo or .vho - IP functional simulation model 2
<your_ip>_inst.v or .vhd - Sample instantiation template
<your_ip>.cmp - VHDL component declaration file
greybox_tmp 3
<your_ip>_bb - Verilog HDL black box EDA synthesis file
<your_ip>_syn.v or .vhd - Timing & resource estimation netlist 1
<your_ip>.vo or .vho - IP functional simulation model 2
<your_ip>.bsf - Block symbol schematic file
<your_ip>.html - IP core generation report
<your_ip>_testbench.v or .vhd - Testbench file 1
<your_ip>_block_period_stim.txt - Testbench simulation data 1
<your_ip>-library - Contains IP subcomponent synthesis libraries
Generated IP File Output C
<Project Directory>
<your_ip>.qip - Quartus II IP integration file
<your_ip>.v, .sv. or .vhd - Top-level IP synthesis file
<your_ip> - IP core synthesis files
<your_ip>.sv, .v, or .vhd - HDL synthesis files
<your_ip>.sdc - Timing constraints file
<your_ip>.bsf - Block symbol schematic file
<your_ip>.cmp - VHDL component declaration file
<your_ip>_syn.v or .vhd - Timing & resource estimation netlist 1
<your_ip>.sip - Lists files for simulation
<your_ip>.ppf - XML I/O pin information file
<your_ip>.spd - Combines individual simulation scripts 1
<your_ip>_sim.f - Refers to simulation models and scripts 1
<your_ip>_sim 1
<AlteraIP_name>_instance
<Altera IP>_instance.vo - IPFS model 2
<simulator_vendor>
<simulator setup scripts>
<your_ip>_testbench or _example - Testbench or example 1
Notes:
1. If supported and enabled for your IP variation
2. If functional simulation models are generated
3. Ignore this directory
Generated IP File Output D
<Project Directory>
<your_ip>.qip or .qsys - System or IP integration file
<your_ip>.sopcinfo - Software tool-chain integration file
<your_ip> - IP core variation files
<your_ip>_bb.v - Verilog HDL black box EDA synthesis file
<your_ip>_inst.v or .vhd - Sample instantiation template
<your_ip>_generation.rpt - IP generation report
<your_ip>.bsf - Block symbol schematic file
<your_ip>.ppf - XML I/O pin information file
<your_ip>.spd - Combines individual simulation startup scripts 1
<your_ip>_syn.v or .vhd - Timing & resource estimation netlist 1
<your_ip>.html - Contains memory map
simulation - IP simulation files
<your_ip>.sip - NativeLink simulation integration file
<your_ip>.v, .vhd, .vo, .vho - HDL or IPFS models2
<simulator vendor> - Simulator setup scripts
<simulator_setup_scripts>
synthesis - IP synthesis files
<your_ip>.qip - Lists files for synthesis
<your_ip>.debuginfo - Lists files for synthesis
<your_ip>.v or .vhd - Top-level IP variation synthesis file
testbench - Simulation testbench files 1
<testbench_hdl_files>
<simulator_vendor> - Testbench for supported simulators
<simulation_testbench_files>
<your_ip>_tb - Testbench for supported simulators
<your_ip>_tb.v or .vhd - Top-level HDL testbench file
Note: To manually add an IP variation to a Quartus II project, click Project > Add/Remove Files in
Project and add only the IP variation .qip or .qsys file, but not both, to the project. Do not
manually add the top-level HDL file to the project.
Scripting IP Core Generation
You can alternatively use command-line utilities to define and generate an IP core variation outside of the
Quartus II GUI.Use qsys-script to run a Tcl file that parameterizes an IP variation you define in a
script. Then, use qsys-generate to generate a .qsys file representing your parameterized IP variation.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-24
QII5V1
2015.05.04
Scripting IP Core Generation
The qsys-generate command is the same as when generating using the Qsys GUI. For command-line
help listing all options for these executables, type <executable name> --help
To create a instance of a parameterizable Altera IP core at the command line, rather than using the GUI,
follow these steps:
1. Run qsys-script to execute a Tcl script, similar to the example, that instantiates the IP and sets the IP
parameters defined by the script:
qsys-script --script=<script_file>.tcl
2. Run qsys-generate to generate the RTL for the IP variation:
qsys-generate <IP variation file>.qsys
Note: Creating an IP generation script is an advanced feature that requires access to special IP core
parameters. For more information about creating an IP generation script, contact your Altera sales
representative.
Table 1-5: qsys-generate Command-Line Options
Option
Usage
Description
<1st arg file>
Required
The name of the .qsys system file to
generate.
--synthesis=<VERILOG|VHDL>
Optional
Creates synthesis HDL files that Qsys uses
to compile the system in a Quartus II
project. You must specify the preferred
generation language for the top-level RTL
file for the generated Qsys system.
--block-symbol-file
Optional
Creates a Block Symbol File (.bsf) for the
Qsys system.
--simulation=<VERILOG|VHDL>
Optional
Creates a simulation model for the Qsys
system. The simulation model contains
generated HDL files for the simulator, and
may include simulation-only features. You
must specify the preferred simulation
language.
--testbench=<SIMPLE|STANDARD>
Optional
Creates a testbench system that instantiates
the original system, adding bus functional
models (BFMs) to drive the top-level
interfaces. When you generate the system,
the BFMs interact with the system in the
simulator.
--testbench-simulation=<VERILOG|VHDL>
Optional
After you create the testbench system, you
can create a simulation model for the
testbench system.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Modifying an IP Variation
Option
Usage
1-25
Description
--search-path=<value>
Optional
If you omit this command, Qsys uses a
standard default path. If you provide this
command, Qsys searches a commaseparated list of paths. To include the
standard path in your replacement, use "$",
for example, "/extra/dir,$".
--jvm-max-heap-size=<value>
Optional
The maximum memory size that Qsys uses
for allocations when running qsysgenerate. You specify the value as <size>
<unit>, where unit is m (or M) for
multiples of megabytes or g (or G) for
multiples of gigabytes. The default value is
512m.
--family=<value>
Optional
Specifies the device family.
--part=<value>
Optional
Specifies the device part number. If set, this
option overrides the --family option.
--allow-mixed-language-simulation
Optional
Enables a mixed language simulation
model generation. If true, if a preferred
simulation language is set, Qsys uses a
fileset of the component for the
simulation model generation. When false,
which is the default, Qsys uses the
language specified with --fileset=<value> for all components for
simulation model generation. The current
version of the ModelSim-Altera simulator
supports mixed language simulation.
Modifying an IP Variation
You can easily modify the parameters of any Altera IP core variation in the parameter editor to match
your design requirements. Use any of the following methods to modify an IP variation in the parameter
editor.
Table 1-6: Modifying an IP Variation
Menu Command
Action
File > Open
Select the top-level HDL (.v, or .vhd) IP variation file to
launch the parameter editor and modify the IP variation.
Regenerate the IP variation to implement your changes.
View > Utility Windows > Project
Navigator > IP Components
Double-click the IP variation to launch the parameter
editor and modify the IP variation. Regenerate the IP
variation to implement your changes.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-26
QII5V1
2015.05.04
Upgrading IP Cores
Menu Command
Project > Upgrade IP Components
Action
Select the IP variation and click Upgrade in Editor to
launch the parameter editor and modify the IP variation.
Regenerate the IP variation to implement your changes.
Upgrading IP Cores
IP core variants generated with a previous version of the Quartus II software may require upgrading
before use in the current version of the Quartus II software. Click Project > Upgrade IP Components to
identify and upgrade outdated IP core variants.
Icons in the Upgrade IP Components dialog box indicate when IP upgrade is required, optional, or
unsupported for IP cores in your design. This dialog box may open automatically when you open a
project containing upgradeable IP variations. You must upgrade IP cores that require upgrade before you
can compile the IP variation in the current version of the Quartus II software.
The upgrade process preserves the original IP variation file in the project directory as <my_variant>_
BAK.qsys for IP targeting Arria 10 and later devices, and as <my_variant>_BAK.v, .sv, or .vhd for legacy IP
targeting 28nm devices and greater.
Note: Upgrading IP cores for Arria 10 and later devices may append a unique identifier to the original IP
core entity name(s), without similarly modifying the IP instance name. There is no requirement to
update these entity references in any supporting Quartus II file; such as the Quartus II Settings File
(.qsf), Synopsys Design Constraints File (.sdc), or SignalTap File (.stp), if these files contain instance
names. The Quartus II software reads only the instance name and ignores the entity name in paths
that specify both names. Use only instance names in assignments.
Table 1-7: IP Core Upgrade Status
IP Core Status
Description
IP Upgraded
Your IP variation uses the lastest version of the IP core.
IP Upgrade Optional
Upgrade is optional for this IP variation in the current version of the Quartus
II software. You can upgrade this IP variation to take advantage of the latest
development of this IP core. Alternatively you can retain previous IP core
characteristics by declining to upgrade. Refer to the Description for details
about IP core version differences. If you do not upgrade the IP, the IP variation
synthesis and simulation files are unchanged and you cannot modify
parameters until upgrading.
IP Upgrade Mismatch
Warning
Warning of non-critical IP core differences in migrating IP to another device
family.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Upgrading IP Cores
IP Core Status
1-27
Description
IP Upgrade Required
You must upgrade the IP variation before compiling in the current version of
the Quartus II software. Refer to the Description for details about IP core
version differences.
IP Upgrade Unspported
Upgrade of the IP variation is not supported in the current version of the
Quartus II software due to incompatibility with the current version of the
Quartus II software. You are prompted to replace the unsupported IP core
with a supported equivalent IP core from the IP Catalog. Refer to the Descrip‐
tion for details about IP core version differences and links to Release Notes.
IP End of Life
Altera designates the IP core as end-of-life status. You may or may not be able
to edit the IP core in the parameter editor. Support for this IP core
discontinues in future releases of the Quartus II software.
Encrypted IP Core
The IP variation is encrypted.
Follow these steps to upgrade IP cores:
1. In the latest version of the Quartus II software, open the Quartus II project containing an outdated IP
core variation. The Upgrade IP Components dialog automatically displays the status of IP cores in
your project, along with instructions for upgrading each core. Click Project > Upgrade IP
Components to access this dialog box manually.
2. To upgrade one or more IP cores that support automatic upgrade, ensure that the Auto Upgrade
option is turned on for the IP core(s), and then click Perform Automatic Upgrade. The Status and
Version columns update when upgrade is complete. Example designs provided with any Altera IP core
regenerate automatically whenever you upgrade an IP core.
3. To manually upgrade an individual IP core, select the IP core and then click Upgrade in Editor (or
simply double-click the IP core name. The parameter editor opens, allowing you to adjust parameters
and regenerate the latest version of the IP core.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-28
Migrating IP Cores to a Different Device
QII5V1
2015.05.04
Figure 1-19: Upgrading IP Cores
“Auto Upgrade”
supported
“Auto Upgrade”
successful
Upgrade required
Upgrade details
Upgrade
optional
Runs “Auto Upgrade” on all supported outdated cores
Opens editor for manual IP upgrade
Note: IP cores older than Quartus II software version 12.0 do not support upgrade. Altera verifies that
the current version of the Quartus II software compiles the previous version of each IP core.
The Altera IP Release Notes reports any verification exceptions for Altera IP cores. Altera does
not verify compilation for IP cores older than the previous two releases.
Related Information
Altera IP Release Notes
Migrating IP Cores to a Different Device
IP migration allows you to target the latest device families with IP originally generated for a different
device. Some Altera IP cores migrate automatically, some IP cores require manual IP regeneration, and
some do not support device migration and must be replaced in your design.
The text and icons in the Upgrade IP Components dialog box identifies the migration support for each
IP core in the design.
Note: Migration of some IP cores requires installed support for the original and migration device
families. For example, migration from a Stratix V device to an Arria 10 device requires installation
of Stratix V and Arria 10 device families with the Quartus II software.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Migrating IP Cores to a Different Device
1-29
Figure 1-20: Upgrading IP Cores
Supports Auto
upgrade
Migration details
Upgrade required
Upgrade success
Double-click to
upgrade in editor
(no auto upgrade)
1. Click File > Open Project and open the Quartus II project containing IP for migration to another
device in the original version of the Quartus II software.
2. To specify a different target device for migration, click Assignments > Device and select the target
device family.
3. To display IP cores requiring migration, click Project > Upgrade IP Components. The Description
field prompts you to run auto update or double-click IP cores for migration.
4. To migrate one or more IP cores that support automatic upgrade, ensure that the Auto Upgrade
option is turned on for the IP core(s), and then click Perform Automatic Upgrade. The Status and
Version columns update when upgrade is complete.
5. To migrate an IP core that does not support automatic upgrade, double-click the IP core name, and
then click OK. The parameter editor appears.
a. If the parameter editor specifies a Currently selected device family, turn off Match project/
default, and then select the new target device family.
b. Click Finish to migrate the IP variation using best-effort mapping to new parameters and settings.
A new parameter editor opens displaying best-effort mapped parameters.
c. Click Generate HDL, and then confirm the Synthesis and Simulation file options. Verilog HDL is
the defauilt output file format specified. If your original IP core was generated for VHDL, select
VHDL to retain the original output format.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-30
Simulating Altera IP Cores in other EDA Tools
QII5V1
2015.05.04
6. To regenerate the new IP variation for the new target device, click Generate. When generation is
complete, click Close.
7. Click Finish to complete migration of the IP core. Click OK if you are prompted to overwrite IP core
files. The Device Family column displays the new target device name when migration is complete. The
migration process replaces <my_ip>.qip with the <my_ip>.qsys top-level IP file in your project.
Note: If migration does not replace <my_ip>.qip with <my_ip>.qsys, click Project > Add/Remove
Files in Project to replace the file in your project.
8. Review the latest parameters in the parameter editor or generated HDL for correctness. IP migration
may change ports, parameters, or functionality of the IP core. During migration, the IP core's HDL
generates into a library that is different from the original output location of the IP core. Update any
assignments that reference outdated locations. If your upgraded IP core is represented by a symbol in a
supporting Block Design File schematic, replace the symbol with the newly generated <my_ip>.bsf
after migration.
Note: The migration process may change the IP variation interface, parameters, and functionality.
This may require you to change your design or to re-parameterize your variant after the
Upgrade IP Components dialog box indicates that migration is complete. The Description
field identifies IP cores that require design or parameter changes.
Related Information
Altera IP Release Notes
Simulating Altera IP Cores in other EDA Tools
The Quartus II software supports RTL and gate-level design simulation of Altera IP cores in supported
EDA simulators. Simulation involves setting up your simulator working environment, compiling
simulation model libraries, and running your simulation.
You can use the functional simulation model and the testbench or example design generated with your IP
core for simulation. The functional simulation model and testbench files are generated in a project
subdirectory. This directory may also include scripts to compile and run the testbench. For a complete list
of models or libraries required to simulate your IP core, refer to the scripts generated with the testbench.
You can use the Quartus II NativeLink feature to automatically generate simulation files and scripts.
NativeLink launches your preferred simulator from within the Quartus II software.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Generating Simulation Scripts
1-31
Figure 1-21: Simulation in Quartus II Design Flow
Design Entry
(HDL, Qsys, DSP Builder)
Altera Simulation
Models
Quartus II
Design Flow
Gate-Level Simulation
Analysis & Synthesis
Fitter
(place-and-route)
TimeQuest Timing Analyzer
RTL Simulation
EDA
Netlist
Writer
Post-synthesis functional
simulation netlist
Post-synthesis
functional
simulation
Post-fit functional
simulation netlist
Post-fit functional
simulation
Post-fit timing
simulation netlist
(Optional)
Post-fit
Post-fit timing
timing
simulation
simulation
(3)
Device Programmer
Note: Post-fit timing simulation is supported only for Stratix IV and Cyclone IV devices in the current
version of the Quartus II software. Altera IP supports a variety of simulation models, including
simulation-specific IP functional simulation models and encrypted RTL models, and plain text
RTL models. These are all cycle-accurate models. The models support fast functional simulation of
your IP core instance using industry-standard VHDL or Verilog HDL simulators. For some cores,
only the plain text RTL model is generated, and you can simulate that model. Use the simulation
models only for simulation and not for synthesis or any other purposes. Using these models for
synthesis creates a nonfunctional design.
Related Information
Simulating Altera Designs
Generating Simulation Scripts
You can automatically generate simulation scripts to set up supported simulators. These scripts compile
the required device libraries and system design files in the correct order, and then elaborate or load the
top-level design for simulation. You can also use scripts to modify the top-level simulation environment,
independent of IP simulation files that are replaced during regeneration. You can modify the scripts to set
up supported simulators.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-32
QII5V1
2015.05.04
Generating Custom Simulation Scripts with ip-make-simscript
Use the NativeLink feature to generate simulation scripts to automate simulation steps. You can reuse
these generated files and simulation scripts in a custom simulation flow. NativeLink optionally generates
scripts for your simulator in the project subdirectory.
1.
2.
3.
4.
5.
Click Assignments > Settings.
Under EDA Tool Settings, click Simulation.
Select the Tool name of your simulator.
Click More NativeLink Settings.
Turn on Generate third-party EDA tool command scripts without running the EDA tool.
Table 1-8: NativeLink Generated Scripts for RTL Simulation
Simulator(s)
Mentor Graphics
ModelSim
QuestaSim
Simulation File
Use
/simulation/modelsim/<my_ip>.do
Source directly with your simulator.
Aldec Riviera Pro /simulation/modelsim/<my_ip>.do
Source directly with your simulator.
Synopsys VCS
/simulation/modelsim/<revision name>
_<rtl or gate>.vcs
Add your testbench file name to this options file
to pass the file to VCS using the -file option.
If you specify a testbench file to NativeLink,
NativeLink generates an .sh script that runs
VCS.
Synopsys
VCS MX
/simulation/scsim/<revision name>_
vcsmx_<rtl or gate>_<verilog or vhdl>
.tcl
Run this script at the command line using the
command:
quartus_sh -t <script>
Any testbench you specify with NativeLink is
included in this script.
Cadence Incisive
(NC SIM)
/simulation/ncsim/<revision name>_
ncsim_<rtl or gate>_<verilog or vhdl>
.tcl
Run this script at the command line using the
command:
quartus_sh -t <script>.
Any testbench you specify with NativeLink is
included in this script.
You can use the following script variables:
• TOP_LEVEL_NAME—The top-level entity of your simulation is often a testbench that instantiates your
design, and then your design instantiates IP cores and/or Qsys systems. Set the value of
TOP_LEVEL_NAME to the top-level entity.
• QSYS_SIMDIR—Specifies the top-level directory containing the simulation files.
• Other variables control the compilation, elaboration, and simulation process.
Generating Custom Simulation Scripts with ip-make-simscript
Use the ip-make-simscript utility to generate simulation command scripts for multiple IP cores or Qsys
systems. Specify all Simulation Package Descriptor files (.spd), each of which lists the required simulation
files for the corresponding IP core or Qsys system. The IP parameter editor generates the .spd files.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Synthesizing Altera IP Cores in Other EDA Tools
1-33
ip-make-simscript compiles IP simulation models into various simulation libraries. Use the compileto-work option to compile all simulation files into a single work library. Use this option only if you
require a simplified library structure.
When you specify multiple .spd files, the ip-make-simscript utility generates a single simulation script
containing all required simulation information. The default value of TOP_LEVEL_NAME is the
TOP_LEVEL_NAME defined in the IP core or Qsys .spd file.
Set appropriate variables in the script, or edit the variable assignment directly in the script. If the
simulation script is a Tcl file that is sourced in the simulator, set the variables before sourcing the script. If
the simulation script is a shell script, pass in the variables as command-line arguments to the shell script.
• Type ip-make-simscript at the command prompt to run.
• Type ip-make-simscript --help for help on command options and syntax.
Table 1-9: ip-make-simscript Examples
Option
--spd=<file>
Description
Status
Describes the list of compiled files Required
and memory model hierarchy. If
your design includes multiple IP
cores or Qsys systems that
include .spd files, use this option for
each file. You can specify
multiple .spd files as a commaseparated list. For example:
ip-make-simscript -spd=,ip1.spd, ip2.spd,
--output-directory=<directory>
--compile-to-work
--use-relative-paths
Specifies the location of output files. Optional
If unspecified, the default setting is
the directory from which ip-makesimscript is run.
Compiles all design files to the
Optional
default work library. Use this option
only if you encounter problems
managing your simulation with
multiple libraries.
Uses relative paths whenever
possible.
Optional
Synthesizing Altera IP Cores in Other EDA Tools
You can use supported EDA tools to synthesize a design that includes Altera IP cores. When you generate
the IP core synthesis files for use with third-party EDA synthesis tools, you can optionally create an area
and timing estimation netlist. To enable generation, turn on Create timing and resource estimates for
third-party EDA synthesis tools when customizing your IP variation.
The area and timing estimation netlist describes the IP core connectivity and architecture, but does not
include details about the true functionality. This information enables certain third-party synthesis tools to
better report area and timing estimates. In addition, synthesis tools can use the timing information to
achieve timing-driven optimizations and improve the quality of results.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-34
QII5V1
2015.05.04
Instantiating IP Cores in HDL
The Quartus II software generates the <variant name>_syn.v netlist file in Verilog HDL format regardless of
the output file format you specify. If you use this netlist for synthesis, you must include the IP core
wrapper file <variant name>.v or <variant name>.vhd in your Quartus II project.
Related Information
Quartus II Integrated Synthesis
Instantiating IP Cores in HDL
You can instantiate an IP core directly in your HDL code by calling the IP core name and declaring its
parameters, in the same manner as any other module, component, or subdesign. When instantiating an IP
core in VHDL, you must include the associated libraries.
Example Top-Level Verilog HDL Module
Verilog HDL ALTFP_MULT in Top-Level Module with One Input Connected to Multiplexer.
module MF_top (a, b, sel, datab, clock, result);
input [31:0] a, b, datab;
input clock, sel;
output [31:0] result;
wire [31:0] wire_dataa;
assign wire_dataa = (sel)? a : b;
altfp_mult inst1
(.dataa(wire_dataa), .datab(datab), .clock(clock), .result(result));
defparam
inst1.pipeline = 11,
inst1.width_exp = 8,
inst1.width_man = 23,
inst1.exception_handling = "no";
endmodule
Example Top-Level VHDL Module
VHDL ALTFP_MULT in Top-Level Module with One Input Connected to Multiplexer.
library ieee;
use ieee.std_logic_1164.all;
library altera_mf;
use altera_mf.altera_mf_components.all;
entity MF_top is
port (clock, sel : in std_logic;
a, b, datab : in std_logic_vector(31 downto 0);
result
: out std_logic_vector(31 downto 0));
end entity;
architecture arch_MF_top of MF_top is
signal wire_dataa : std_logic_vector(31 downto 0);
begin
wire_dataa <= a when (sel = '1') else b;
inst1 : altfp_mult
generic map
(
pipeline => 11,
width_exp => 8,
width_man => 23,
exception_handling => "no")
port map (
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Integrating Other EDA Tools
1-35
dataa => wire_dataa,
datab => datab,
clock => clock,
result => result);
end arch_MF_top;
Integrating Other EDA Tools
You can integrate supported EDA design entry, synthesis, simulation, physical synthesis, and formal
verification tools into the Quartus II design flow. The Quartus II software supports netlist files from other
EDA design entry and synthesis tools. The Quartus II software optionally generates various files for use in
other EDA tools.
The Quartus II software manages EDA tool files and provides the following integration capabilities:
• Automatically generate files for synthesis and simulation and automatically launch other EDA tools
(Assignments > Settings > EDA Tool Settings > NativeLink Settings ).
• Compile all RTL and gate-level simulation model libraries for your device, simulator, and design
language automatically (Tools > Launch Simulation Library Compiler).
• Include files (.edf, .vqm) generated by other EDA design entry or synthesis tools in your project as
synthesized design files (Project > Add/Remove File from Project) .
• Automatically generate optional filesfor board-level verification (Assignments > Settings > EDA Tool
Settings).
Figure 1-22: EDA Tool Settings
Related Information
Mentor Graphics Precision Synthesis SupportGraphics on page 18-1
Simulating Altera Designs
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-36
Managing Team-based Projects
QII5V1
2015.05.04
Managing Team-based Projects
The Quartus II software supports multiple designers, design iterations, and platforms. You can use the
following techniques to preserve and track project changes in a team-based environment. These
techniques may also be helpful for individual designers.
Related Information
•
•
•
•
Preserving Compilation Results on page 1-36
Archiving Projects on page 1-38
Using External Revision Control on page 1-39
Migrating Projects Across Operating Systems on page 1-40
Preserving Compilation Results
The Quartus II software maintains a database of compilation results for each project revision. The
databases files store results of incremental or full compilation. Do not edit these files directly. However,
you can use the database files in the following ways:
• Preserve compilation results for migration to a new version of the Quartus II software. Export a postsynthesis or post-fit, version-compatible database (Project > Export Database), and then import it
into a newer version of the Quartus II software (Project > Import Database), or into another project.
• Optimize and lock down the compilation results for individual blocks. Export the post-synthesis or
post-fit netlist as a Quartus II Exported Partition File (.qxp) (Project > Export Design Partition). You
can then import the partition as a new project design file.
• Purge the content of the project database (Project > Clean Project) to remove unwanted previous
compilation results at any time.
Factors Affecting Compilation Results
Changes to any of the following factors can impact compilation results:
• Project Files—project settings (. qsf), design files, and timing constraints (.sdc).
• Hardware—CPU architecture, not including hard disk or memory size differences. Windows XP x32
results are not identical to Windows XP x64 results. Linux x86 results is not identical to Linux x86_64.
• Quartus II Software Version—including build number and installed patches. Click Help > About to
obtain this information.
• Operating System—Windows or Linux operating system, excluding version updates. For example,
Windows XP, Windows Vista, and Windows 7 results are identical. Similarly, Linux RHEL, CentOS 4,
and CentOS 5 results are identical.
Related Information
• Quartus II Incremental Compilation for Hierarchical and Team-Based Design on page 3-1
• Design Planning for Partial Reconfiguration on page 4-1
The Partial Reconfiguration (PR) feature in the Quartus II software allows you to reconfigure a portion of
the FPGA dynamically, while the remainder of the device continues to operate. The Quartus II software
®
supports the PR feature for the Altera® Stratix V device family.
Migrating Results Across Quartus II Software Versions
View basic information about your project in the Project Navigator, Report panel, and Messages window.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Exporting and Importing the Results Database
1-37
To preserve compilation results for migration to a later version of the Quartus II software, export a
version-compatible database file, and then import it into the later version of the Quartus II software. A
few device families do not support version-compatible database generation, as indicated by project
messages.
Exporting and Importing the Results Database
To save the compilation results in a version-compatible format for migration to a later version of the
Quartus II software, follow these steps:
1. Open the project for migration in the original version of the Quartus II software.
2. Generate the project database and netlist with one of the following:
• Click Processing > Start > Start Analysis & Synthesis to generate a post-synthesis netlist.
• Click Processing > Start Compilation to generate a post-fit netlist.
3. Click Project > Export Database and specify the Export directory.
4. In a later version of the Quartus II software, click New Project Wizard and create a new project with
the same top-level design entity name as the migrated project.
5. Click Project > Import Database and select the <project directory> /export_db/exported database
directory. The Quartus II software opens the compiled project and displays compilation results.
Note: You can turn on Assignments > Settings > Compilation Process Settings > Export versioncompatible database if you want to always export the database following compilation.
Figure 1-23: Quartus II Version-Compatible Database Structure
Cleaning the Project Database
To clean the project database and remove all prior compilation results, follow these steps:
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-38
QII5V1
2015.05.04
Archiving Projects
1. Click Project > Clean Project.
2. Select All revisions to remove the databases for all revisions of the current project, or specify a
Revision name to remove only that revision’s database.
3. Click OK. A message indicates when the database is clean.
Archiving Projects
You can save the elements of a project in a single, compressed Quartus II Archive File (. qar) by clicking
Project > Archive Project.
The .qar captures logic design, project, and settings files required to restore the project.
Use this technique to share projects between designers, or to transfer your project to a new version of the
Quartus II software, or to Altera support. You can optionally add compilation results, Qsys system files,
and third-party EDA tool files to the archive. If you restore the archive in a different version of the
Quartus II software, you must include the original .qdf in the archive to preserve original compilation
results.
Manually Adding Files To Archives
To manually add files to an archive:
1.
2.
3.
4.
5.
Click Project > Archive Project and specify the archive file name.
Click Advanced.
Select the File set for archive or select Custom. Turn on File subsets for archive.
Click Add and select Qsys system or EDA tool files. Click OK.
Click Archive.
Archiving Compilation Results
You can include compilation results in a project archive to avoid recompilation and preserve original
results in the restored project. To archive compilation results, export the post-synthesis or post-fit version
compatible database and include this file in the archive.
1.
2.
3.
4.
5.
Export the project database.
Click Project > Archive Project and specify the archive file name.
Click Advanced.
Under File subsets, turn on Version-compatible database files and click OK.
Click Archive.
To restore an archive containing a version-compatible database, follow these steps:
1. Click Project > Restore Archived Project.
2. Select the archive name and destination folder and click OK.
3. After restoring the archived project, click Project > Import Database and import the versioncompatible database.
Related Information
Exporting and Importing the Results Database on page 1-37
Archiving Projects for Altera Service Requests
When archiving projects for an Altera service request, include all of the following file types for proper
debugging by Altera Support:
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Using External Revision Control
1-39
To quickly identify and include appropriate archive files for an Altera service request:
1. Click Project > Archive Project and specify the archive file name.
2. Click Advanced.
3. In File set, select Service Request to include files for Altera Support.
• Project source and setting files (.v, .vhd, .vqm, .qsf, .sdc, .qip, .qpf, .cmp, .sip)
• Automatically detected source files (various)
• Programming output files (. jdi, .sof, .pof)
• Report files (.rpt, .pin, .summary, .smsg)
• Qsys system and IP files (.qsys, . qip)
4. Click OK, and then click Archive.
Figure 1-24: Archiving Project for Service Request
Using External Revision Control
Your project may involve different team members with distributed responsibilities, such as sub-module
design, device and system integration, simulation, and timing closure. In such cases, it may be useful to
track and protect file revisions in an external revision control system.
While Quartus II project revisions preserve various project setting and constraint combinations, external
revision control systems can also track and merge RTL source code, simulation testbenches, and build
scripts. External revision control supports design file version experimentation through branching and
merging different versions of source code from multiple designers. Refer to your external revision control
documentation for setup information.
Files to Include In External Revision Control
Include the following Quartus project file types in external revision control systems:
•
•
•
•
•
•
Logic design files (.v, .vdh, .bdf, edf, .vqm)
Timing constraint files (.sdc)
Quartus project settings and constraints (.qdf, .qpf, .qsf)
IP files (.v, .sv, .vhd, .qip, .sip, .qsys)
Qsys-generated files (.qsys, .qip, .sip)
EDA tool files (.vo, .vho )
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-40
QII5V1
2015.05.04
Migrating Projects Across Operating Systems
You can generate or modify these files manually if you use a scripted design flow. If you use an external
source code control system, you can check-in project files anytime you modify assignments and settings
in the Quartus software.
Migrating Projects Across Operating Systems
Consider the following cross-platform issues when moving your project from one operating system to
another (for example, from Windows to Linux).
Migrating Design Files and Libraries
Consider the following file naming differences when migrating projects across operating systems:
• Use appropriate case for your platform in file path references.
• Use a character set common to both platforms.
• Do not change the forward-slash (/) and back-slash (\) path separators in the .qsf. The Quartus II
software automatically changes all back-slash (\) path separators to forward-slashes (/ )in the .qsf.
• Observe the target platform’s file name length limit.
• Use underscore instead of spaces in file and directory names.
• Change library absolute path references to relative paths in the .qsf.
• Ensure that any external project library exists in the new platform’s file system.
• Specify file and directory paths as relative to the project directory. For example, for a project titled
foo_design , specify the source files as: top.v, foo_folder /foo1.v, foo_folder /foo2.v, and foo_folder/
bar_folder/bar1.vhdl.
• Ensure that all the subdirectories are in the same hierarchical structure and relative path as in the
original platform.
Figure 1-25: All Inclusive Project Directory Structure
Use Relative Paths
Express file paths using relative path notation (.. /).
For example, in the directory structure shown you can specify top.v as ../source/top.v and foo1.v as ../
source/foo_folder/foo1.v.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Design Library Migration Guidelines
1-41
Figure 1-26: Quartus II Project Directory Separate from Design Files
Design Library Migration Guidelines
The following guidelines apply to library migration across computing platforms:
1. The project directory takes precedence over the project libraries.
2. For Linux, the Quartus II software creates the file in the altera.quartus directory under the <home>
directory.
3. All library files are relative to the libraries. For example, if you specify the user_lib1 directory as a
project library and you want to add the /user_lib1/foo1.v file to the library, you can specify the foo1.v
file in the .qsf as foo1.v. The Quartus II software includes files in specified libraries.
4. If the directory is outside of the project directory, an absolute path is created by default. Change the
absolute path to a relative path before migration.
5. When copying projects that include libraries, you must either copy your project library files along with
the project directory or ensure that your project library files exist in the target platform.
• On Windows, the Quartus II software searches for the quartus2.ini file in the following directories
and order:
• USERPROFILE, for example, C:\Documents and Settings\ <user name>
• Directory specified by the TMP environmental variable
• Directory specified by the TEMP environmental variable
• Root directory, for example, C:\
Scripting API
You can use command-line executables or scripts to execute project commands, rather than using the
GUI. The following commands are available for scripting project management.
Scripting Project Settings
You can use a Tcl script to specify settings and constraints, rather than using the GUI. This can be helpful
if you have many settings and wish to track them in a single file or spreadsheet for iterative comparison.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-42
QII5V1
2015.05.04
Project Revision Commands
The .qsf supports only a limited subset of Tcl commands. Therefore, pass settings and constraints using a
Tcl script:
1. Create a text file with the extension.tcl that contains your assignments in Tcl format.
2. Source the Tcl script file by adding the following line to the .qsf: set_global_assignment -name
SOURCE_TCL_SCR IPT_FILE <file name>.
Project Revision Commands
Use the following commands for scripting project revisions.
Create Revision Command on page 1-42
Set Current Revision Command on page 1-42
Get Project Revisions Command on page 1-42
Delete Revision Command on page 1-42
Create Revision Command
create_revision <name> -based_on <revision_name> -copy_results -set_current
Option
based_on (optional)
Description
Specifies the revision name on which the new revision bases
its settings.
copy_results
Copies the results from the "based_on" revision.
set_current (optional)
Sets the new revision as the current revision.
Set Current Revision Command
The -force option enables you to open the revision that you specify under revision name and overwrite
the compilation database if the database version is incompatible.
set_current_revision -force <revision name>
Get Project Revisions Command
get_project_revisions <project_name>
Delete Revision Command
delete_revision <revision name>
Project Archive Commands
You can use Tcl commands and the quartus_sh executable to create and manage archives of a Quartus
project.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Creating a Project Archive
1-43
Creating a Project Archive
in a Tcl script or from a Tcl prompt, you can use the following command to create a Quartus archive:
project_archive <name>.qar
You can specify the following other options:
•
•
•
•
•
•
•
-all_revisions - Includes all revisions of the current project in the archive.
-auto_common_directory - Preserves original project directory structure in archive
-common_directory /<name> - Preserves original project directory structure in specified subdirectory
-include_libraries - Includes libraries in archive
-include_outputs - Includes output files in archive
-use_file_set <file_set> Includes specified fileset in archive
-version_compatible_database - Includes version-compatible database files in archive
Note: Version-compatible databases are not available for some device families. If you require the
database files to reproduce the compilation results in the same Quartus software version, use the use_file_set full_db option to archive the complete database.
Restoring an Archived Project
Use the following Tcl command to restore a Quartus project:
project_restore <name>.qar -destination restored -overwrite
This example restores to a destination directory named "restored".
Project Database Commands
Use the following commands for managing Quartus project databases:
Import and Export Version-Compatible Databases on page 1-43
Import and Export Version-Compatible Databases from a Flow Package on page 1-43
Generate Version-Compatible Database After Compilation on page 1-44
quartus_cdb and quartus_sh Executables to Manage Version-Compatible Databases on page 1-44
Import and Export Version‑Compatible Databases
Use the following commands to import or export a version-compatible database:
• import_database <directory>
• export_database <directory>
Import and Export Version-Compatible Databases from a Flow Package
The following are Tcl commands from the flow package to import or export version-compatible
databases. If you use the flow package, you must specify the database directory variable name. flow and
database_manager packages contain commands to manage version-compatible databases.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-44
QII5V1
2015.05.04
Generate Version-Compatible Database After Compilation
• set_global_assignment -name VER_COMPATIBLE_DB_DIR <directory>
• execute_flow –flow export_database
• execute_flow –flow import_database
Generate Version-Compatible Database After Compilation
Use the following commands to generate a version-compatible database after compilation:
• set_global_assignment -name AUTO_EXPORT_VER_COMPATIBLE_DB ON
• set_global_assignment-name VER_COMPATIBLE_DB_DIR <directory>
quartus_cdb and quartus_sh Executables to Manage Version-Compatible Databases
Use the following commands to manage version-compatible databases:
•
•
•
•
quartus_cdb <project> -c <revision>--export_database=<directory>
quartus_cdb <project> -c <revision> --import_database=<directory>
quartus_sh –flow export_database <project> -c \ <revision>
quartus_sh –flow import_database <project> -c \ <revision>
Project Library Commands
Use the following commands to script project library changes.
Specify Project Libraries With SEARCH_PATH Assignment on page 1-44
Report Specified Project Libraries Commands on page 1-44
Related Information
• Tcl Scripting
• CommandLine Scripting
• Quartus Settings File Manual
Specify Project Libraries With SEARCH_PATH Assignment
In Tcl, use commands in the :: quartus ::project package to specify project libraries, and the
set_global_assignment command.
Use the following commands to script project library changes:
• set_global_assignment -name SEARCH_PATH "../other_dir/library1"
• set_global_assignment -name SEARCH_PATH "../other_dir/library2"
• set_global_assignment -name SEARCH_PATH "../other_dir/library3"
Report Specified Project Libraries Commands
To report any project libraries specified for a project and any global libraries specified for the current
installation of the Quartus software, use the get_global_assignment and get_user_option Tcl
commands.
Use the following commands to report specified project libraries:
• get_global_assignment -name SEARCH_PATH
• get_user_option -name SEARCH_PATH
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2015.05.04
Document Revision History
1-45
Document Revision History
Table 1-10: Document Revision History
Date
Version
Changes
2015.05.04
15.0.0
•
•
•
•
2014.12.15
14.1.0
• Updated content for DSE II GUI and optimizations.
• Added information about new Assignments > Settings >
IP Settings that control frequency of synthesis file regener‐
ation and automatic addtion of IP files to the project.
2014.08.18
14.0a10.0
• Added information about specifying parameters for IP
cores targeting Arria 10 devices.
• Added information about the latest IP output for Quartus
II version 14.0a10 targeting Arria 10 devices.
• Added information about individual migration of IP cores
to the latest devices.
• Added information about editing existing IP variations.
2014.06.30
14.0.0
• Replaced MegaWizard Plug-In Manager information with
IP Catalog.
• Added standard information about upgrading IP cores.
• Added standard installation and licensing information.
• Removed outdated device support level information. IP
core device support is now available in IP Catalog and
parameter editor.
November 2013
13.1.0
• Conversion to DITA format
May 2013
13.0.0
• Overhaul for improved usability and updated information.
June 2012
12.0.0
• Removed survey link.
• Updated information about VERILOG_INCLUDE_FILE.
November 2011
10.1.1
Template update.
Managing Quartus II Projects
Send Feedback
Added description of design templates feature.
Updated screenshot for DSE II GUI.
Added qsys_script IP core instantiation information.
Described changes to generating and processing of
instance and entity names.
• Added description of upgrading IP cores at the command
line.
• Updated procedures for upgrading and migrating IP cores.
• Gate level timing simulation supported only for Cyclone
IV and Stratix IV devices.
Altera Corporation
1-46
QII5V1
2015.05.04
Document Revision History
Date
December 2010
Version
10.1.0
Changes
•
•
•
•
Changed to new document template.
Removed Figure 4–1, Figure 4–6, Table 4–2.
Moved “Hiding Messages” to Help.
Removed references about the set_user_option
command.
• Removed Classic Timing Analyzer references.
Related Information
Quartus II Handbook Archive
Altera Corporation
Managing Quartus II Projects
Send Feedback
2
Design Planning with the Quartus II Software
2015.05.04
QII5V1
Subscribe
Send Feedback
Design Planning with the Quartus II Software
Because of the significant increase in FPGA device densities, designs are complex and can sometimes
involve multiple designers. System architects must also resolve design issues when integrating design
blocks. However, you can solve potential problems early in the design cycle by following the design
planning considerations in this chapter.This chapter provides only an introduction to various design
®
planning features in the Quartus II software.
Before reading the design planning guidelines discussed in this chapter, consider your design priorities.
More device features, density, or performance requirements can increase system cost. Signal integrity and
board issues can impact I/O pin locations. Power, timing performance, and area utilization all affect each
other, and compilation time is affected when optimizing these priorities.
The Quartus II software optimizes designs for the best overall results; however, you can change the
settings to better optimize one aspect of your design, such as power utilization. Certain tools or debugging
options can lead to restrictions in your design flow. Your design priorities help you choose the tools,
features, and methodologies to use for your design.
After you select a device family, to check if additional guidelines are available, refer to the design
guidelines section of the appropriate device handbook.
Creating Design Specifications
Before you create your design logic or complete your system design, create detailed design specifications
that define the system, specify the I/O interfaces for the FPGA, identify the different clock domains, and
include a block diagram of basic design functions.
In addition, creating a test plan helps you to design for verification and ease of manufacture. For example,
you might need to validate interfaces incorporated in your design. To perform any built-in self-test
®
functions to drive interfaces, you can use a UART interface with a Nios II processor inside the FPGA
device.
If more than one designer works on your design, you must consider a common design directory structure
or source control system to make design integration easier. Consider whether you want to standardize on
an interface protocol for each design block.
© 2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos are
trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as
trademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance
of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any
products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information,
product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device
specifications before relying on any published information and before placing orders for products or services.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
ISO
9001:2008
Registered
2-2
QII5V1
2015.05.04
Selecting Intellectual Property
Related Information
• Planning for On-Chip Debugging Tools on page 2-8
For guidelines related to analyzing and debugging the device after it is in the system.
• Planning for Hierarchical and Team-Based Design on page 2-11
For more suggestions on team-based designs.
• Using Qsys and Standard Interfaces in System Design on page 2-2
For improved reusability and ease of integration.
Selecting Intellectual Property
Altera and its third-party intellectual property (IP) partners offer a large selection of standardized IP cores
optimized for Altera devices. The IP you select often affects system design, especially if the FPGA
interfaces with other devices in the system. Consider which I/O interfaces or other blocks in your system
design are implemented using IP cores, and plan to incorporate these cores in your FPGA design.
The OpenCore Plus feature, which is available for many IP cores, allows you to program the FPGA to
verify your design in the hardware before you purchase the IP license. The evaluation supports the
following modes:
• Untethered—the design runs for a limited time.
• Tethered—the design requires an Altera serial JTAG cable connected between the JTAG port on your
board and a host computer running the Quartus II Programmer for the duration of the hardware
evaluation period.
Related Information
Intellectual Property
For descriptions of available IP cores.
Using Qsys and Standard Interfaces in System Design
You can use the Quartus II Qsys system integration tool to create your design with fast and easy systemlevel integration. With Qsys, you can specify system components in a GUI and generate the required
interconnect logic automatically, along with adapters for clock crossing and width differences.
Because system design tools change the design entry methodology, you must plan to start developing your
design within the tool. Ensure all design blocks use appropriate standard interfaces from the beginning of
the design cycle so that you do not need to make changes later.
Qsys components use Avalon standard interfaces for the physical connection of components, and you
can connect any logical device (either on-chip or off-chip) that has an Avalon interface. The Avalon
Memory-Mapped interface allows a component to use an address mapped read or write protocol that
enables flexible topologies for connecting master components to any slave components. The Avalon
Streaming interface enables point-to-point connections between streaming components that send and
receive data using a high-speed, unidirectional system interconnect between source and sink ports.
®
In addition to enabling the use of a system integration tool such as Qsys, using standard interfaces ensures
compatibility between design blocks from different design teams or vendors. Standard interfaces simplify
the interface logic to each design block and enable individual team members to test their individual design
blocks against the specification for the interface protocol to ease system integration.
Altera Corporation
Design Planning with the Quartus II Software
Send Feedback
QII5V1
2015.05.04
Device Selection
2-3
Related Information
• System Design with Qsys
For more information about using Qsys to improve your productivity.
• SOPC Builder User Guide
For more information about SOPC Builder.
Device Selection
The device you choose affects board specification and layout. This section provides guidelines in the
device selection process.
Choose the device family that best suits your design requirements. Families differ in cost, performance,
logic and memory density, I/O density, power utilization, and packaging. You must also consider feature
requirements, such as I/O standards support, high-speed transceivers, global or regional clock networks,
and the number of phase-locked loops (PLLs) available in the device.
Each device family also has a device handbook, including a data sheet, which documents device features in
detail. You can also see a summary of the resources for each device in the Device dialog box in the
Quartus II software.
Carefully study the device density requirements for your design. Devices with more logic resources and
higher I/O counts can implement larger and more complex designs, but at a higher cost. Smaller devices
use lower static power. Select a device larger than what your design requires if you want to add more logic
later in the design cycle to upgrade or expand your design, and reserve logic and memory for on-chip
debugging. Consider requirements for types of dedicated logic blocks, such as memory blocks of different
sizes, or digital signal processing (DSP) blocks to implement certain arithmetic functions.
If you have older designs that target an Altera device, you can use their resources as an estimate for your
design. Compile existing designs in the Quartus II software with the Auto device selected by the Fitter
option in the Settings dialog box. Review the resource utilization to learn which device density fits your
design. Consider coding style, device architecture, and the optimization options used in the Quartus II
software, which can significantly affect the resource utilization and timing performance of your design.
Related Information
• Planning for On-Chip Debugging Tools on page 2-8
For information about on-chip debugging.
• Altera Product Selector
For You can refer to the Altera website to help you choose your device.
• Selector Guides
You can review important features of each device family in the refer to the Altera website.
• Devices and Adapters
For a list of device selection guides.
• IP and Megafunctions
For information on how to obtain resource utilization estimates for certain configurations of Altera’s
IP, refer to the user guides for Altera megafunctions and IP MegaCores on the literature page of the
Altera website.
Device Migration Planning
Determine whether you want to migrate your design to another device density to allow flexibility when
your design nears completion. You may want to target a smaller (and less expensive) device and then
Design Planning with the Quartus II Software
Send Feedback
Altera Corporation
2-4
QII5V1
2015.05.04
Planning for Device Programming or Configuration
move to a larger device if necessary to meet your design requirements. Other designers may prototype
their design in a larger device to reduce optimization time and achieve timing closure more quickly, and
then migrate to a smaller device after prototyping. If you want the flexibility to migrate your design, you
must specify these migration options in the Quartus II software at the beginning of your design cycle.
Selecting a migration device impacts pin placement because some pins may serve different functions in
different device densities or package sizes. If you make pin assignments in the Quartus II software, the Pin
Migration View in the Pin Planner highlights pins that change function between your migration devices.
Related Information
• Early Pin Planning and I/O Analysis on page 2-5
• Specifying Devices for Device Migration
For more information about specifying the target migration devices in Quartus II Help.
Planning for Device Programming or Configuration
Planning how to program or configure the device in your system allows system and board designers to
determine what companion devices, if any, your system requires. Your board layout also depends on the
type of programming or configuration method you plan to use for programmable devices. Many
programming options require a JTAG interface to connect to the devices, so you might have to set up a
JTAG chain on the board. Additionally, the Quartus II software uses the settings for the configuration
scheme, configuration device, and configuration device voltage to enable the appropriate dual purpose
pins as regular I/O pins after you complete configuration. The Quartus II software performs voltage
compatibility checks of those pins during I/O assignment analysis and compilation of your design. You
can use the Configuration tab of the Device and Pin Options dialog box to select your configuration
scheme.
The device family handbooks describe the configuration options available for a device family. For
information about programming CPLD devices, refer to your device data sheet or handbook.
Related Information
Configuration Handbook
For more details about configuration options.
Estimating Power
You can use the Quartus II power estimation and analysis tools to provide information to PCB board and
system designers. Power consumption in FPGA devices depends on the design logic, which can make
planning difficult. You can estimate power before you create any source code, or when you have a
preliminary version of the design source code, and then perform the most accurate analysis with the
PowerPlay Power Analyzer when you complete your design.
You must accurately estimate device power consumption to develop an appropriate power budget and to
design the power supplies, voltage regulators, heat sink, and cooling system. Power estimation and
analysis helps you satisfy two important planning requirements:
• Thermal—ensure that the cooling solution is sufficient to dissipate the heat generated by the device.
The computed junction temperature must fall within normal device specifications.
• Power supply—ensure that the power supplies provide adequate current to support device operation.
Altera Corporation
Design Planning with the Quartus II Software
Send Feedback
QII5V1
2015.05.04
Early Pin Planning and I/O Analysis
2-5
The PowerPlay Early Power Estimator (EPE) spreadsheet allows you to estimate power utilization for
your design.
You can manually enter data into the EPE spreadsheet, or use the Quartus II software to generate device
resource information for your design.
To manually enter data into the EPE spreadsheet, enter the device resources, operating frequency, toggle
rates, and other parameters for your design. If you do not have an existing design, estimate the number of
device resources used in your design, and then enter the data into the EPE spreadsheet manually.
If you have an existing design or a partially completed design, you can use the Quartus II software to
generate the PowerPlay Early Power Estimator File (.txt, .csv) to assist you in completing the PowerPlay
EPE spreadsheet.
The PowerPlay EPE spreadsheet includes the Import Data macro that parses the information in the
PowerPlay EPE File and transfers the information into the spreadsheet. If you do not want to use the
macro, you can manually transfer the data into the EPE spreadsheet. For example, after importing the
PowerPlay EPE File information into the PowerPlay EPE spreadsheet, you can add device resource
information. If the existing Quartus II project represents only a portion of your full design, manually
enter the additional device resources you use in the final design.
Estimating power consumption early in the design cycle allows planning of power budgets and avoids
unexpected results when designing the PCB.
When you complete your design, perform a complete power analysis to check the power consumption
more accurately. The PowerPlay Power Analyzer tool in the Quartus II software provides an accurate
estimation of power, ensuring that thermal and supply limitations are met.
Related Information
• PowerPlay Power Analysis
For more information about power estimation and analysis.
• Performing an Early Power Estimate Using the PowerPlay Early Power Estimator
For more information about generating the PowerPlay EPE File, refer to Quartus II Help.
• PowerPlay Early Power Estimator and Power Analyzer
The PowerPlay EPE spreadsheets for each supported device family are available on the Altera website.
Early Pin Planning and I/O Analysis
In many design environments, FPGA designers want to plan the top-level FPGA I/O pins early to help
board designers begin the PCB design and layout. The I/O capabilities and board layout guidelines of the
FPGA device influence pin locations and other types of assignments. If the board design team specifies an
FPGA pin-out, the pin locations must be verified in the FPGA placement and routing software to avoid
board design changes.
You can create a preliminary pin-out for an Altera FPGA with the Quartus II Pin Planner before you
develop the source code, based on standard I/O interfaces (such as memory and bus interfaces) and any
other I/O requirements for your system. The Quartus II I/O Assignment Analysis checks that the pin
locations and assignments are supported in the target FPGA architecture. You can then use I/O
Assignment Analysis to validate I/O-related assignments that you create or modify throughout the design
process. When you compile your design in the Quartus II software, I/O Assignment Analysis runs
automatically in the Fitter to validate that the assignments meet all the device requirements and generates
error messages.
Design Planning with the Quartus II Software
Send Feedback
Altera Corporation
2-6
Early Pin Planning and I/O Analysis
QII5V1
2015.05.04
Early in the design process, before creating the source code, the system architect has information about
the standard I/O interfaces (such as memory and bus interfaces), the IP cores in your design, and any
other I/O-related assignments defined by system requirements. You can use this information with the
Early Pin Planning feature in the Pin Planner to specify details about the design I/O interfaces. You can
then create a top-level design file that includes all I/O information.
The Pin Planner interfaces with the IP core parameter editor, which allows you to create or import
custom IP cores that use I/O interfaces. You can configure how to connect the functions and cores to each
other by specifying matching node names for selected ports. You can create other I/O-related assignments
for these interfaces or other design I/O pins in the Pin Planner, as described in this section. The Pin
Planner creates virtual pin assignments for internal nodes, so internal nodes are not assigned to device
pins during compilation. After analysis and synthesis of the newly generated top-level wrapper file, use
the generated netlist to perform I/O Analysis with the Start I/O Assignment Analysis command.
You can use the I/O analysis results to change pin assignments or IP parameters even before you create
your design, and repeat the checking process until the I/O interface meets your design requirements and
passes the pin checks in the Quartus II software. When you complete initial pin planning, you can create a
revision based on the Quartus II-generated netlist. You can then use the generated netlist to develop the
top-level design file for your design, or disregard the generated netlist and use the generated Quartus II
Settings File (.qsf) with your design.
During this early pin planning, after you have generated a top-level design file, or when you have
developed your design source code, you can assign pin locations and assignments with the Pin Planner.
With the Pin Planner, you can identify I/O banks, voltage reference (VREF) groups, and differential pin
pairings to help you through the I/O planning process. If you selected a migration device, the Pin
Migration View highlights the pins that have changed functions in the migration device when compared
to the currently selected device. Selecting the pins in the Device Migration view cross-probes to the rest of
the Pin Planner, so that you can use device migration information when planning your pin assignments.
You can also configure board trace models of selected pins for use in “board-aware” signal integrity
reports generated with the Enable Advanced I/O Timing option . This option ensures that you get
accurate I/O timing analysis. You can use a Microsoft Excel spreadsheet to start the I/O planning process
if you normally use a spreadsheet in your design flow, and you can export a Comma-Separated Value File
(.csv) containing your I/O assignments for spreadsheet use when you assign all pins.
When you complete your pin planning, you can pass pin location information to PCB designers. The Pin
Planner is tightly integrated with certain PCB design EDA tools, and can read pin location changes from
these tools to check suggested changes. Your pin assignments must match between the Quartus II
software and your schematic and board layout tools to ensure the FPGA works correctly on the board,
especially if you must make changes to the pin-out. The system architect uses the Quartus II software to
pass pin information to team members designing individual logic blocks, allowing them to achieve better
timing closure when they compile their design.
Start FPGA planning before you complete the HDL for your design to improve the confidence in early
board layouts, reduce the chance of error, and improve the overall time to market of the design. When
you complete your design, use the Fitter reports for the final sign-off of pin assignments. After compila‐
tion, the Quartus II software generates the Pin-Out File (.pin), and you can use this file to verify that each
pin is correctly connected in board schematics.
Related Information
• Device Migration Planning on page 2-3
Altera Corporation
Design Planning with the Quartus II Software
Send Feedback
QII5V1
2015.05.04
Simultaneous Switching Noise Analysis
2-7
• Set Up Top-Level Design File Window (Edit Menu
For more information about setting up the nodes in your design, refer to Quartus II Help.
• I/O Management
For more information about I/O assignment and analysis.
• Mentor Graphics PCB Design Tools Support
• Cadence PCB Design Tools Support
For more information about passing I/O information between the Quartus II software and third-party
EDA tools.
Simultaneous Switching Noise Analysis
Simultaneous switching noise (SSN) is a noise voltage inducted onto a victim I/O pin of a device due to
the switching behavior of other aggressor I/O pins in the device.
Altera provides tools for SSN analysis and estimation, including SSN characterization reports, an Early
SSN Estimator (ESE) spreadsheet tool, and the SSN Analyzer in the Quartus II software. SSN often leads
to the degradation of signal integrity by causing signal distortion, thereby reducing the noise margin of a
system. You must address SSN with estimation early in your system design, to minimize later board
design changes. When your design is complete, verify your board design by performing a complete SSN
analysis of your FPGA in the Quartus II software.
Related Information
• Altera’s Signal Integrity Center
For more information and device support for the ESE spreadsheet tool on the Altera website.
• Simultaneous Switching Noise (SSN
For more information about the SSN Analyzer.
Selecting Third-Party EDA Tools
Your complete FPGA design flow may include third-party EDA tools in addition to the Quartus II
software. Determine which tools you want to use with the Quartus II software to ensure that they are
supported and set up properly, and that you are aware of their capabilities.
Synthesis Tool
The Quartus II software includes integrated synthesis that supports Verilog HDL, VHDL, Altera
Hardware Description Language (AHDL), and schematic design entry.
You can also use supported standard third-party EDA synthesis tools to synthesize your Verilog HDL or
VHDL design, and then compile the resulting output netlist file in the Quartus II software. Different
synthesis tools may give different results for each design. To determine the best tool for your application,
you can experiment by synthesizing typical designs for your application and coding style. Perform
placement and routing in the Quartus II software to get accurate timing analysis and logic utilization
results.
The synthesis tool you choose may allow you to create a Quartus II project and pass constraints, such as
the EDA tool setting, device selection, and timing requirements that you specified in your synthesis
project. You can save time when setting up your Quartus II project for placement and routing.
Tool vendors frequently add new features, fix tool issues, and enhance performance for Altera devices,
you must use the most recent version of third-party synthesis tools.
Design Planning with the Quartus II Software
Send Feedback
Altera Corporation
2-8
QII5V1
2015.05.04
Simulation Tool
Related Information
• Incremental Compilation with Design Partitions on page 2-12
For more information on how to use incremental compilation with design partitions.
• Volume 1: Design and Synthesis
For more information about synthesis tool flows.
• Quartus II Software and Device Support Release Notes
For more information about the supported versions of synthesis tools in your version of the Quartus II
Help.
Simulation Tool
Altera provides the Mentor Graphics ModelSim -Altera Starter Edition with the Quartus II software. You
can also purchase the ModelSim-Altera Edition or a full license of the ModelSim software to support large
designs and achieve faster simulation performance. The Quartus II software can generate both functional
and timing netlist files for ModelSim and other third-party simulators.
®
Use the simulator version that your Quartus II software version supports for best results. You must also
use the model libraries provided with your Quartus II software version. Libraries can change between
versions, which might cause a mismatch with your simulation netlist.
Related Information
• Quartus II Software and Device Support Release Notes
For a list of the version of each simulation tool that is supported with a given version of the Quartus II
software.
• Simulation
For more information about simulation tool flows.
Formal Verification Tools
Consider whether the Quartus II software supports the formal verification tool that you want to use, and
whether the flow impacts your design and compilation stages of your design.
Using a formal verification tool can impact performance results because performing formal verification
requires turning off certain logic optimizations, such as register retiming, and forces you to preserve
hierarchy blocks, which can restrict optimization. Formal verification treats memory blocks as black
boxes. Therefore, you must keep memory in a separate hierarchy block so other logic does not get
incorporated into the black box for verification. If formal verification is important to your design, plan for
limitations and restrictions at the beginning of the design cycle rather than make changes later.
Related Information
Volume 3: Verification
For more information about formal verification flows and the supported tools
Planning for On-Chip Debugging Tools
In-system debugging tools offer different advantages and trade-offs. A particular debugging tool may
work better for different systems and designers.
You must evaluate on-chip debugging tools early in your design process, to ensure that your system
board, Quartus II project, and design can support the appropriate tools. You can reduce debugging time
and avoid making changes to accommodate your preferred debugging tools later.
Altera Corporation
Design Planning with the Quartus II Software
Send Feedback
QII5V1
2015.05.04
Design Practices and HDL Coding Styles
2-9
If you intend to use any of these tools, you may have to plan for the tools when developing your system
board, Quartus II project, and design. Consider the following debugging requirements when you plan
your design:
• JTAG connections—required to perform in-system debugging with JTAG tools. Plan your system and
board with JTAG ports that are available for debugging.
• Additional logic resources—required to implement JTAG hub logic. If you set up the appropriate tool
early in your design cycle, you can include these device resources in your early resource estimations to
ensure that you do not overload the device with logic.
• Reserve device memory—required if your tool uses device memory to capture data during system
operation. To ensure that you have enough memory resources to take advantage of this debugging
technique, consider reserving device memory to use during debugging.
• Reserve I/O pins—required if you use the Logic Analyzer Interface (LAI) or SignalProbe tools, which
require I/O pins for debugging. If you reserve I/O pins for debugging, you do not have to later change
your design or board. The LAI can multiplex signals with design I/O pins if required. Ensure that your
board supports a debugging mode, in which debugging signals do not affect system operation.
• Instantiate an IP core in your HDL code—required if your debugging tool uses an Altera IP core.
• Instantiate the SignalTap II Logic Analyzer IP core—required if you want to manually connect the
SignalTap II Logic Analyzer to nodes in your design and ensure that the tapped node names do not
change during synthesis. You can add the analyzer as a separate design partition for incremental
compilation to minimize recompilation times.
Table 2-1: Factors to Consider When Using Debugging Tools During Design Planning Stages
Design Planning Factor
SignapT System
ap II
Console
Logic
Analyze
r
InLogic
SignalP‐
System Analyze
robe
Memory
r
Interfac
Content
e
Editor
(LAI)
InSystem
Sources
Virtual
JTAG IP
Core
and
Probes
JTAG connections
Yes
Yes
Yes
Yes
—
Yes
Yes
Additional logic resources
—
Yes
—
—
—
—
Yes
Reserve device memory
Yes
Yes
—
—
—
—
—
Reserve I/O pins
—
—
—
Yes
Yes
—
—
Instantiate IP core in your
HDL code
—
—
—
—
—
Yes
Yes
Related Information
• System Debugging Tools Overview
For an overview of debugging tools that can help you decide which tools to use.
• Design Debugging Using the SignalTap II Logic Analyzer
For more information on using the SignalTap II Logic Analyzer.
Design Practices and HDL Coding Styles
When you develop complex FPGA designs, design practices and coding styles have an enormous impact
on the timing performance, logic utilization, and system reliability of your device.
Design Planning with the Quartus II Software
Send Feedback
Altera Corporation
2-10
Design Recommendations
QII5V1
2015.05.04
Design Recommendations
Use synchronous design practices to consistently meet your design goals. Problems with asynchronous
design techniques include reliance on propagation delays in a device, incomplete timing analysis, and
possible glitches.
In a synchronous design, a clock signal triggers all events. When you meet all register timing require‐
ments, a synchronous design behaves in a predictable and reliable manner for all process, voltage, and
temperature (PVT) conditions. You can easily target synchronous designs to different device families or
speed grades.
Clock signals have a large effect on the timing accuracy, performance, and reliability of your design.
Problems with clock signals can cause functional and timing problems in your design. Use dedicated clock
pins and clock routing for best results, and if you have PLLs in your target device, use the PLLs for clock
inversion, multiplication, and division. For clock multiplexing and gating, use the dedicated clock control
block or PLL clock switchover feature instead of combinational logic, if these features are available in your
device. If you must use internally-generated clock signals, register the output of any combinational logic
used as a clock signal to reduce glitches.
The Design Assistant in the Quartus II software is a design-rule checking tool that enables you to verify
design issues. The Design Assistant checks your design for adherence to Altera-recommended design
guidelines. You can also use third-party lint tools to check your coding style.
Consider the architecture of the device you choose so that you can use specific features in your design. For
example, the control signals should use the dedicated control signals in the device architecture.
Sometimes, you might need to limit the number of different control signals used in your design to achieve
the best results.
Related Information
• About the Design Assistant
For more information about running the Design Assistant, refer to Quartus II Help.
• Recommended Design Practices on page 11-1
For more information about design recommendations and using the Design Assistant.
• www.sunburst-design.com
You can also refer to industry papers for more information about multiple clock design. For a good
analysis, refer to Synthesis and Scripting Techniques for Designing Multi-Asynchronous Clock Designs
under Papers.
Recommended HDL Coding Styles
HDL coding styles can have a significant effect on the quality of results for programmable logic designs.
If you design memory and DSP functions, you must understand the target architecture of your device so
you can use the dedicated logic block sizes and configurations. Follow the coding guidelines for inferring
megafunctions and targeting dedicated device hardware, such as memory and DSP blocks.
Related Information
• Recommended HDL Coding Styles on page 12-1
For HDL coding examples and recommendations, refer to the Recommended HDL Coding Styles
chapter in volume 1 of the Quartus II Handbook. For additional tool-specific guidelines
Altera Corporation
Design Planning with the Quartus II Software
Send Feedback
QII5V1
2015.05.04
Managing Metastability
2-11
Managing Metastability
Metastability problems can occur in digital design when a signal is transferred between circuitry in
unrelated or asynchronous clock domains, because the designer cannot guarantee that the signal meets
the setup and hold time requirements during the signal transfer.
Designers commonly use a synchronization chain to minimize the occurrence of metastable events.
Ensure that your design accounts for synchronization between any asynchronous clock domains.
Consider using a synchronizer chain of more than two registers for high-frequency clocks and frequentlytoggling data signals to reduce the chance of a metastability failure.
You can use the Quartus II software to analyze the average mean time between failures (MTBF) due to
metastability when a design synchronizes asynchronous signals, and optimize your design to improve the
metastability MTBF. The MTBF due to metastability is an estimate of the average time between instances
when metastability could cause a design failure. A high MTBF (such as hundreds or thousands of years
between metastability failures) indicates a more robust design. Determine an acceptable target MTBF
given the context of your entire system and the fact that MTBF calculations are statistical estimates.
The Quartus II software can help you determine whether you have enough synchronization registers in
your design to produce a high enough MTBF at your clock and data frequencies.
Related Information
• Managing Metastability with the Quartus II Software on page 13-1
For information about metastability analysis, reporting, and optimization features in the Quartus II
software
Planning for Hierarchical and Team-Based Design
To create a hierarchical design so that you can use compilation-time savings and performance
preservation with the Quartus II software incremental compilation feature, plan for an incremental
compilation flow from the beginning of your design cycle. The following subsections describe the flat
compilation flow, in which the design hierarchy is flattened without design partitions, and then the
incremental compilation flow that uses design partitions. Incremental compilation flows offer several
advantages, but require more design planning to ensure effective results. The last subsections discuss
planning an incremental compilation flow, planning design partitions, and optionally creating a design
floorplan.
Related Information
• Quartus II Incremental Compilation for Hierarchical and Team-Based Design on page 3-1
For information about using the incremental compilation flow methodology in the Quartus II
software.
Flat Compilation Flow with No Design Partitions
In the flat compilation flow with no design partitions in the Quartus II software, the Quartus II software
compiles the entire design in a “flat” netlist.
Your source code can have hierarchy, but the Quartus II software flattens your design during compilation
and synthesizes all the design source code and fits in the target device whenever the software recompile
your design after any change in your design. By processing the entire design, the software performs all
available logic and placement optimizations on the entire design to improve area and performance. You
Design Planning with the Quartus II Software
Send Feedback
Altera Corporation
2-12
QII5V1
2015.05.04
Incremental Compilation with Design Partitions
can use debugging tools in an incremental design flow, such as the SignalTap II Logic Analyzer, but you
do not specify any design partitions to preserve design hierarchy during compilation.
The flat compilation flow is easy to use; you do not have to plan any design partitions. However, because
the Quartus II software recompiles the entire design whenever you change your design, compilation times
can be slow for large devices. Additionally, you may find that the results for one part of the design change
when you change a different part of your design. You run Rapid Recompile to preserve portions of
previous placement and routing in subsequent compilations. This option can reduce your compilation
time in a flat or partitioned design when you make small changes to your design.
Incremental Compilation with Design Partitions
In an incremental compilation flow, the system architect splits a large design into partitions. When
hierarchical design partitions are well chosen and placed in the device floorplan, you can speed up your
design compilation time while maintaining the quality of results.
Incremental compilation preserves the compilation results and performance of unchanged partitions in
the design, greatly reducing design iteration time by focusing new compilations on changed design
partitions only. Incremental compilation then merges new compilation results with the previous compila‐
tion results from unchanged design partitions. Additionally, you can target optimization techniques, such
as physical synthesis, to specific design partitions while leaving other partitions unchanged. You can also
use empty partitions to indicate that parts of your design are incomplete or missing, while you compile
the rest of your design.
Third-party IP designers can also export logic blocks to be integrated into the top-level design. Team
members can work on partitions independently, which can simplify the design process and reduce
compilation time. With exported partitions, the system architect must provide guidance to designers or IP
providers to ensure that each partition uses the appropriate device resources. Because the designs may be
developed independently, each designer has no information about the overall design or how their
partition connects with other partitions. This lack of information can lead to problems during system
integration. The top-level project information, including pin locations, physical constraints, and timing
requirements, must be communicated to the designers of lower-level partitions before they start their
design.
The system architect plans design partitions at the top level and allows third-party designs to access the
top-level project framework. By designing in a copy of the top-level project (or by checking out the project
files in a source control environment), the designers of the lower-level block have full information about
the entire project, which helps to ensure optimal results.
When you plan your design code and hierarchy, ensure that each design entity is created in a separate file
so that the entities remain independent when you make source code changes in the file. If you use a thirdparty synthesis tool, create separate Verilog Quartus Mapping or EDIF netlists for each design partition in
your synthesis tool. You may have to create separate projects in your synthesis tool, so that the tool
synthesizes each partition separately and generates separate output netlist files. The netlists are then
considered the source files for incremental compilation.
Related Information
• Quartus II Incremental Compilation for Hierarchical and Team-Based Design on page 3-1
For more information about support for Quartus II incremental compilation.
Planning Design Partitions and Floorplan Location Assignments
Partitioning a design for an FPGA requires planning to ensure optimal results when you integrate the
partitions. Following Altera’s recommendations for creating design partitions should improve the overall
quality of results. For example, registering partition I/O boundaries keeps critical timing paths inside one
Altera Corporation
Design Planning with the Quartus II Software
Send Feedback
QII5V1
2015.05.04
Running Fast Synthesis
2-13
partition that can be optimized independently. When you specify the design partitions, you can use the
Incremental Compilation Advisor to ensure that partitions meet Altera’s recommendations.
If you have timing-critical partitions that are changing through the design flow, or partitions exported
from another Quartus II project, you can create design floorplan assignments to constrain the placement
of the affected partitions. Good partition and floorplan design helps partitions meet top-level design
requirements when integrated with the rest of your design, reducing time you spend integrating and
verifying the timing of the top-level design.
Related Information
Best Practices for Incremental Compilation Partitions and Floorplan Assignments on page 14-1
For detailed guidelines about creating design partitions and organizing your source code, as well as
information about when and how to create floorplan assignments .
Analyzing and Optimizing the Design Floorplan
For more information about creating floorplan assignments in the Chip Planner .
Running Fast Synthesis
You save time when you find design issues early in the design cycle rather than in the final timing closure
stages. When the first version of the design source code is complete, you might want to perform a quick
compilation to create a kind of silicon virtual prototype (SVP) that you can use to perform timing
analysis.
If you synthesize with the Quartus II software, you can choose to perform a Fast synthesis, which reduces
the compilation time, but may give reduced quality of results.
If you design individual design blocks or partitions separately, you can use the Fast synthesis and early
timing estimate features as you develop your design. Any issues highlighted in the lower-level design
blocks are communicated to the system architect. Resolving these issues might require allocating
additional device resources to the individual partition, or changing the timing budget of the partition.
Expert designers can also use fast synthesis to prototype the entire design. Incomplete partitions are
marked as empty in an incremental compilation flow, while the rest of the design is compiled to detect
any problems with design integration.
Related Information
Synthesis Effort logic option
For more information about Fast synthesis, refer to Quartus II Help.
Document Revision History
Table 2-2: Document Revision History
Date
Version
Changes
2015.05.04 15.0.0
Remove support for Early Timing Estimate feature.
2014.06.30 14.0.0
Updated document format.
November
2013
Removed HardCopy device information.
13.1.0
Design Planning with the Quartus II Software
Send Feedback
Altera Corporation
2-14
QII5V1
2015.05.04
Document Revision History
Date
Version
Changes
November, 12.1.0
2012
Update for changes to early pin planning feature
June 2012
12.0.0
Editorial update.
November
2011
11.0.1
Template update.
May 2011
11.0.0
• Added link to System Design with Qsys in “Creating Design Specifica‐
tions” on page 1–2
• Updated “Simultaneous Switching Noise Analysis” on page 1–8
• Updated “Planning for On-Chip Debugging Tools” on page 1–10
• Removed information from “Planning Design Partitions and
Floorplan Location Assignments” on page 1–15
December
2010
10.1.0
• Changed to new document template
• Updated “System Design and Standard Interfaces” on page 1–3 to
include information about the Qsys system integration tool
• Added link to the Altera Product Selector in “Device Selection” on
page 1–3
• Converted information into new table (Table 1–1) in “Planning for
On-Chip Debugging Options” on page 1–10
• Simplified description of incremental compilation usages in
“Incremental Compilation with Design Partitions” on page 1–14
• Added information about the Rapid Recompile option in “Flat
Compilation Flow with No Design Partitions” on page 1–14
• Removed details and linked to Quartus II Help in “Fast Synthesis and
Early Timing Estimation” on page 1–16
July 2010
10.0.0
• Added new section “System Design” on page 1–3
• Removed details about debugging tools from “Planning for On-Chip
Debugging Options” on page 1–10 and referred to other handbook
chapters for more information
• Updated information on recommended design flows in “Incremental
Compilation with Design Partitions” on page 1–14 and removed
“Single-Project Versus Multiple-Project Incremental Flows” heading
• Merged the “Planning Design Partitions” section with the “Creating a
Design Floorplan” section. Changed heading title to “Planning Design
Partitions and Floorplan Location Assignments” on page 1–15
• Removed “Creating a Design Floorplan” section
• Removed “Referenced Documents” section
• Minor updates throughout chapter
Altera Corporation
Design Planning with the Quartus II Software
Send Feedback
QII5V1
2015.05.04
Document Revision History
Date
November
2009
Version
9.1.0
2-15
Changes
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Added details to “Creating Design Specifications” on page 1–2
Added details to “Intellectual Property Selection” on page 1–2
Updated information on “Device Selection” on page 1–3
Added reference to “Device Migration Planning” on page 1–4
Removed information from “Planning for Device Programming or
Configuration” on page 1–4
Added details to “Early Power Estimation” on page 1–5
Updated information on “Early Pin Planning and I/O Analysis” on
page 1–6
Updated information on “Creating a Top-Level Design File for I/O
Analysis” on page 1–8
Added new “Simultaneous Switching Noise Analysis” section
Updated information on “Synthesis Tools” on page 1–9
Updated information on “Simulation Tools” on page 1–9
Updated information on “Planning for On-Chip Debugging Options”
on page 1–10
Added new “Managing Metastability” section
Changed heading title “Top-Down Versus Bottom-Up Incremental
Flows” to “Single-Project Versus Multiple-Project Incremental Flows”
Updated information on “Creating a Design Floorplan” on page 1–18
Removed information from “Fast Synthesis and Early Timing
Estimation” on page 1–18
March
2009
9.0.0
• No change to content
November
2008
8.1.0
• Changed to 8-1/2 x 11 page size. No change to content.
May 2008
8.0.0
• Organization changes
• Added “Creating Design Specifications” section
• Added reference to new details in the In-System Design Debugging
section of volume 3
• Added more details to the “Design Practices and HDL Coding Styles”
section
• Added references to the new Best Practices for Incremental Compila‐
tion and Floorplan Assignments chapter
• Added reference to the Quartus II Language Templates
Related Information
Quartus II Handbook Archive
For previous versions of the Quartus II Handbook
Design Planning with the Quartus II Software
Send Feedback
Altera Corporation
3
Quartus II Incremental Compilation for
Hierarchical and Team-Based Design
2015.05.04
QII5V1
Subscribe
Send Feedback
About Quartus II Incremental Compilation
This manual provides information and design scenarios to help you partition your design to take
®
advantage of the Quartus II incremental compilation feature.
The ability to iterate rapidly through FPGA design and debugging stages is critical. The Quartus II
software introduced the FPGA industry’s first true incremental design and compilation flow, with the
following benefits:
• Preserves the results and performance for unchanged logic in your design as you make changes
elsewhere.
• Reduces design iteration time by an average of 75% for small changes in large designs, so that you can
perform more design iterations per day and achieve timing closure efficiently.
• Facilitates modular hierarchical and team-based design flows, as well as design reuse and intellectual
property (IP) delivery.
Quartus II incremental compilation supports the Arria , Stratix , and Cyclone series of devices.
®
®
®
Deciding Whether to Use an Incremental Compilation Flow
The Quartus II incremental compilation feature enhances the standard Quartus II design flow by allowing
you to preserve satisfactory compilation results and performance of unchanged blocks of your design.
Flat Compilation Flow with No Design Partitions
In the flat compilation flow with no design partitions, all the source code is processed and mapped during
the Analysis and Synthesis stage, and placed and routed during the Fitter stage whenever the design is
recompiled after a change in any part of the design. One reason for this behavior is to ensure optimal
push-button quality of results. By processing the entire design, the Compiler can perform global
optimizations to improve area and performance.
You can use a flat compilation flow for small designs, such as designs in CPLD devices or low-density
FPGA devices, when the timing requirements are met easily with a single compilation. A flat design is
satisfactory when compilation time and preserving results for timing closure are not concerns.
© 2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos are
trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as
trademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance
of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any
products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information,
product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device
specifications before relying on any published information and before placing orders for products or services.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
ISO
9001:2008
Registered
3-2
Incremental Capabilities Available When A Design Has No Partitions
QII5V1
2015.05.04
Related Information
Reducing Compilation Time documentation
Incremental Capabilities Available When A Design Has No Partitions
The Quartus II software has incremental compilation features available even when you do not partition
your design, including Smart Compilation, Rapid Recompile, and incremental debugging. These features
work in either an incremental or flat compilation flow.
With Smart Compilation
In any Quartus II compilation flow, you can use Smart Compilation to allow the Compiler to determine
which compilation stages are required, based on the changes made to the design since the last smart
compilation, and then skip any stages that are not required.
For example, when Smart Compilation is turned on, the Compiler skips the Analysis and Synthesis stage
if all the design source files are unchanged. When Smart Compilation is turned on, if you make any
changes to the logic of a design, the Compiler does not skip any compilation stage. You can turn on Smart
Compilation on the Compilation Process Settings page of the Setting dialog box.
Note: Arria 10 devices do not support the smart compilation feature.
Related Information
Smart Compilation online help
With Rapid Recompile
The Quartus II software also includes a Rapid Recompile feature that instructs the Compiler to reuse the
compatible compilation results if most of the design has not changed since the last compilation. This
feature reduces compilation times for small and isolated design changes. You do not have control over
which parts of the design are recompiled using this option; the Compiler determines which parts of the
design must be recompiled. The Rapid Recompile feature preserves performance and can save
compilation time by reducing the amount of changed logic that must be recompiled.
Related Information
About Rapid Recompile online help
With SignalTap II Logic Analyzer
®
During the debugging stage of the design cycle, you can add the SignalTap II Logic Analyzer to your
design, even if the design does not have partitions. To preserve the compilation netlist for the entire
design, instruct the software to reuse the compilation results for the automatically-created "Top" partition
that contains the entire design.
Related Information
About SignalTap II Logic Analyzer online help
Incremental Compilation Flow With Design Partitions
In the standard incremental compilation design flow, the top-level design is divided into design partitions,
which can be compiled and optimized together in the top-level Quartus II project. You can preserve
fitting results and performance for completed partitions while other parts of the design are changing,
which reduces the compilation times for each design iteration.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Impact of Using Incremental Compilation with Design Partitions
3-3
If you use the incremental compilation feature at any point in your design flow, it is easier to accommo‐
date the guidelines for partitioning a design and creating a floorplan if you start planning for incremental
compilation at the beginning of your design cycle.
Incremental compilation is recommended for large designs and high resource densities when preserving
results is important to achieve timing closure. The incremental compilation feature also facilitates teambased design flows that allow designers to create and optimize design blocks independently, when
necessary.
To take advantage of incremental compilation, start by splitting your design along any of its hierarchical
boundaries into design blocks to be compiled incrementally, and set each block as a design partition. The
Quartus II software synthesizes each individual hierarchical design partition separately, and then merges
the partitions into a complete netlist for subsequent stages of the compilation flow. When recompiling
your design, you can use source code, post-synthesis results, or post-fitting results to preserve satisfactory
results for each partition.
In a team-based environment, part of your design may be incomplete, or it may have been developed by
another designer or IP provider. In this scenario, you can add the completed partitions to the design
incrementally. Alternatively, other designers or IP providers can develop and optimize partitions
independently and the project lead can later integrate the partitions into the top-level design.
Related Information
• Team-Based Design Flows and IP Delivery on page 3-6
• Incremental Compilation Summary on page 3-7
• Best Practices for Incremental Compilation Partitions and Floorplan Assignments documentation
on page 14-1
Impact of Using Incremental Compilation with Design Partitions
Table 3-1: Impact Summary of Using Incremental Compilation
Characteristic
(1)
Impact of Incremental Compilation with Design Partitions
Compilation Time Savings
Typically saves an average of 75% of compilation time for small design
changes in large designs when post-fit netlists are preserved; there are
savings in both Quartus II Integrated Synthesis and the Fitter. (1)
Performance Preservation
Excellent performance preservation when timing critical paths are
contained within a partition, because you can preserve post-fitting
information for unchanged partitions.
Node Name Preservation
Preserves post-fitting node names for unchanged partitions.
Quartus II incremental compilation does not reduce processing time for the early "pre-fitter" operations,
such as determining pin locations and clock routing, so the feature cannot reduce compilation time if
runtime is dominated by those operations.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-4
QII5V1
2015.05.04
Impact of Using Incremental Compilation with Design Partitions
Characteristic
Impact of Incremental Compilation with Design Partitions
Area Changes
The area (logic resource utilization) might increase because crossboundary optimizations are limited, and placement and register packing
are restricted.
fMAX Changes
The design’s maximum frequency might be reduced because
cross-boundary optimizations are limited. If the design is partitioned
and the floorplan location assignments are created appropriately, there
might be no negative impact on fMAX.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Quartus II Design Stages for Incremental Compilation
3-5
Quartus II Design Stages for Incremental Compilation
Figure 3-1: Design Stages for Incremental Compilation
System
Verilog
HDL
(.sv)
VHDL
(.vhd)
Block
Design File
(.bdf)
AHDL
(.tdf)
EDIF
Netlist
(.edf)
VQM
Netlist
(.vqm)
Partition Top
Design Partition
Assignments
Partition 1
Partition 2
(1)
Analysis & Synthesis
Synthesize Changed Partitions,
Preserve Others
Settings &
Assignments
One Post-Synthesis
Netlist per Partition
Partition Merge
Create Complete Netlist Using Appropriate Source Netlists for Each
Partition (Post-Fit, Post-Synthesis, or Imported Netlist)
One Post-Fit
Netlist per
Partition
Single Netlist for
Complete Design
Fitter
Place-and-Route Changed Partitions,
Preserve Others
Create Individual Netlists and
Complete Netlists
Single Post-Fit
Netlist for
Complete Design
Assembler
in parallel
Floorplan
Location
Assignments
Settings &
Assignments
Timing
Analyzer
Requirements
Satisfied?
No
Make Design &
Assignment Modifications
Yes
Program/Configure Device
Note: When you use EDIF or VQM netlists created by third-party EDA synthesis tools, Analysis and
Synthesis creates the design database, but logic synthesis and technology mapping are performed
only for black boxes.
Analysis and Synthesis Stage
The figure above shows a top-level partition and two lower-level partitions. If any part of the design
changes, Analysis and Synthesis processes the changed partitions and keeps the existing netlists for the
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-6
QII5V1
2015.05.04
Partition Merge Stage
unchanged partitions. After completion of Analysis and Synthesis, there is one post-synthesis netlist for
each partition.
Partition Merge Stage
The Partition Merge step creates a single, complete netlist that consists of post-synthesis netlists, post-fit
netlists, and netlists exported from other Quartus II projects, depending on the netlist type that you
specify for each partition.
Fitter Stage
The Fitter then processes the merged netlist, preserves the placement and routing of unchanged
partitions, and refits only those partitions that have changed. The Fitter generates the complete netlist for
use in future stages of the compilation flow, including timing analysis and programming file generation,
which can take place in parallel if more than one processor is enabled for use in the Quartus II software.
The Fitter also generates individual netlists for each partition so that the Partition Merge stage can use the
post-fit netlist to preserve the placement and routing of a partition, if specified, for future compilations.
How to Compare Incremental Compilation Results with Flat Design Results
If you define partitions, but want to check your compilation results without partitions in a “what if”
scenario, you can direct the Compiler to ignore all partitions assignments in your project and compile the
design as a "flat" netlist. When you turn on the Ignore partitions assignments during compilation
option on the Incremental Compilation page, the Quartus II software disables all design partition
assignments in your project and runs a full compilation ignoring all partition boundaries and netlists.
Turning off the Ignore partitions assignments during compilation option restores all partition
assignments and netlists for subsequent compilations.
Related Information
• Incremental Compilation Page online help
• Design Partition Properties Dialog Box online help
Team-Based Design Flows and IP Delivery
The Quartus II software supports various design flows to enable team-based design and third-party IP
delivery. A top-level design can include one or more partitions that are designed or optimized by different
designers or IP providers, as well as partitions that will be developed as part of a standard incremental
methodology.
With a Single Quartus II Project
In a team-based environment, part of your design may be incomplete because it is being developed
elsewhere. The project lead or system architect can create empty placeholders in the top-level design for
partitions that are not yet complete. Designers or IP providers can create and verify HDL code separately,
and then the project lead later integrates the code into the single top-level Quartus II project. In this
scenario, you can add the completed partitions to the design incrementally, however, the design flow
allows all design optimization to occur in the top-level design for easiest design integration. Altera
recommends using a single Quartus II project whenever possible because using multiple projects can add
significant up-front and debugging time to the development cycle.
With Multiple Quartus II Projects
Alternatively, partition designers can design their partition in a copy of the top-level design or in a
separate Quartus II project. Designers export their completed partition as either a post-synthesis netlist or
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Additional Planning Needed
3-7
optimized placed and routed netlist, or both, along with assignments such as LogicLock™ regions, as
appropriate. The project lead then integrates each design block as a design partition into the top-level
design. Altera recommends that designers export and reuse post-synthesis netlists, unless optimized postfit results are required in the top-level design, to simplify design optimization.
Additional Planning Needed
Teams with a bottom-up design approach often want to optimize placement and routing of design
partitions independently and may want to create separate Quartus II projects for each partition. However,
optimizing design partitions in separate Quartus II projects, and then later integrating the results into a
top-level design, can have the following potential drawbacks that require careful planning:
• Achieving timing closure for the full design may be more difficult if you compile partitions independ‐
ently without information about other partitions in the design. This problem may be avoided by
careful timing budgeting and special design rules, such as always registering the ports at the module
boundaries.
• Resource budgeting and allocation may be required to avoid resource conflicts and overuse. Creating a
floorplan with LogicLock regions is recommended when design partitions are developed independ‐
ently in separate Quartus II projects.
• Maintaining consistency of assignments and timing constraints can be more difficult if there are
separate Quartus II projects. The project lead must ensure that the top-level design and the separate
projects are consistent in their assignments.
Collaboration on a Team-Based Design
A unique challenge of team-based design and IP delivery for FPGAs is the fact that the partitions being
developed independently must share a common set of resources. To minimize issues that might arise from
sharing a common set of resources, you can design partitions within a single Quartus II project or a copy
of the top-level design. A common project ensures that designers have a consistent view of the top-level
project framework.
For timing-critical partitions being developed and optimized by another designer, it is important that
each designer has complete information about the top-level design in order to maintain timing closure
during integration, and to obtain the best results. When you want to integrate partitions from separate
Quartus II projects, the project lead can perform most of the design planning, and then pass the top-level
design constraints to the partition designers. Preferably, partition designers can obtain a copy of the toplevel design by checking out the required files from a source control system. Alternatively, the project lead
can provide a copy of the top-level project framework, or pass design information using Quartus IIgenerated design partition scripts. In the case that a third-party designer has no information about the
top-level design, developers can export their partition from an independent project if required.
Related Information
• Exporting Design Partitions from Separate Quartus II Projects on page 3-31
• Project Management— Making the Top-Level Design Available to Other Designers on page 3-33
Incremental Compilation Summary
Incremental Compilation Single Quartus II Project Flow
The figure illustrates the incremental compilation design flow when all partitions are contained in one
top-level design.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-8
QII5V1
2015.05.04
Steps for Incremental Compilation
Figure 3-2: Top-Down Design Flow
Perform Elaboration
Prepare Design for Incremental Compilation
(Optional) Create Floorplan Location
Assignments using LogicLock Regions
Perform Complete Compilation
(All Partitions are Compiled)
Make Changes to Design
Set Netlist Type for Each Partition
Repeat as Needed
During Design, Verification,
& Debugging Stages
Perform Incremental Compilation
(Partitions are Compiled if Required)
Steps for Incremental Compilation
For an interactive introduction to implementing an incremental compilation design flow, refer to the
Getting Started Tutorial on the Help menu in the Quartus II software.
Related Information
Using the Incremental Compilation Design Flow online help
Preparing a Design for Incremental Compilation
1. Elaborate your design, or run any compilation flow (such as a full compilation) that includes the
elaboration step. Elaboration is the part of the synthesis process that identifies your design’s hierarchy.
2. Designate specific instances in the design hierarchy as design partitions.
3. If required for your design flow, create a floorplan with LogicLock regions location assignments for
timing-critical partitions that change with future compilations. Assigning a partition to a physical
region on the device can help maintain quality of results and avoid conflicts in certain situations.
Related Information
• Creating Design Partitions on page 3-9
• Creating a Design Floorplan With LogicLock Regions on page 3-47
Compiling a Design Using Incremental Compilation
The first compilation after making partition assignments is a full compilation, and prepares the design for
subsequent incremental compilations. In subsequent compilations of your design, you can preserve
satisfactory compilation results and performance of unchanged partitions with the Netlist Type setting in
the Design Partitions window. The Netlist Type setting determines which type of netlist or source file the
Partition Merge stage uses in the next incremental compilation. You can choose the Source File, PostSynthesis netlist, or Post-Fit netlist.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Creating Design Partitions
3-9
Related Information
Specifying the Level of Results Preservation for Subsequent Compilations on page 3-25
Creating Design Partitions
There are several ways to designate a design instance as a design partition.
Related Information
Deciding Which Design Blocks Should Be Design Partitions on page 3-20
Creating Design Partitions in the Project Navigator
You can right-click an instance in the list under the Hierarchy tab in the Project Navigator and use the
sub-menu to create and delete design partitions.
Related Information
Creating Design Partitions online help
Creating Design Partitions in the Design Partitions Window
The Design Partitions window, available from the Assignments menu, allows you to create, delete, and
merge partitions, and is the main window for setting the netlist type to specify the level of results
preservation for each partition on subsequent compilations.
The Design Partitions window also lists recommendations at the bottom of the window with links to the
Incremental Compilation Advisor, where you can view additional recommendations about partitions. The
Color column indicates the color of each partition as it appears in the Design Partition Planner and Chip
Planner.
You can right-click a partition in the window to perform various common tasks, such as viewing property
information about a partition, including the time and date of the compilation netlists and the partition
statistics.
When you create a partition, the Quartus II software automatically generates a name based on the
instance name and hierarchy path. You can edit the partition name in the Design Partitions Window so
that you avoid referring to them by their hierarchy path, which can sometimes be long. This is especially
useful when using command-line commands or assignments, or when you merge partitions to give the
partition a meaningful name. Partition names can be from 1 to 1024 characters in length and must be
unique. The name can consist of alphanumeric characters and the pipe ( | ), colon ( : ), and underscore
( _ ) characters.
Related Information
• Netlist Type for Design Partitions on page 3-25
• Creating Design Partitions online help
Creating Design Partitions With the Design Partition Planner
The Design Partition Planner allows you to view design connectivity and hierarchy, and can assist you in
creating effective design partitions that follow Altera’s guidelines.
The Design Partition Planner displays a visual representation of design connectivity and hierarchy, as well
as partitions and entity relationships. You can explore the connectivity between entities in the design,
evaluate existing partitions with respect to connectivity between entities, and try new partitioning
schemes in "what if" scenarios.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-10
QII5V1
2015.05.04
Creating Design Partitions With Tcl Scripting
When you extract design blocks from the top-level design and drag them into the Design Partition
Planner, connection bundles are drawn between entities, showing the number of connections existing
between pairs of entities. In the Design Partition Planner, you can then set extracted design blocks as
design partitions.
The Design Partition Planner also has an Auto-Partition feature that creates partitions based on the size
and connectivity of the hierarchical design blocks.
Related Information
Using the Design Partition Planner online help
Best Practices for Incremental Compilation Partitions and Floorplan Assignments documentation on
page 14-1
Creating Design Partitions With Tcl Scripting
You can also create partitions with Tcl scripting commands.
Related Information
Scripting Support on page 3-54
Automatically-Generated Partitions
The Compiler creates some partitions automatically as part of the compilation process, which appear in
some post-compilation reports. For example, the sld_hub partition is created for tools that use JTAG hub
connections, such as the SignalTap II Logic Analyzer. The hard_block partition is created to contain
certain "hard" or dedicated logic blocks in the device that are implemented in a separate partition so that
they can be shared throughout the design.
Common Design Scenarios Using Incremental Compilation
Related Information
Steps for Incremental Compilation on page 3-8
Reducing Compilation Time When Changing Source Files for One Partition
Scenario background: You set up your design to include partitions for several of the major design blocks,
and now you have just performed a lengthy compilation of the entire design. An error is found in the
HDL source file for one partition and it is being fixed. Because the design is currently meeting timing
requirements, and the fix is not expected to affect timing performance, it makes sense to compile only the
affected partition and preserve the rest of the design.
Use the flow in this example to update the source file in one partition without having to recompile the
other parts of the design. To reduce the compilation time, instruct the software to reuse the post-fit
netlists for the unchanged partitions. This flow also preserves the performance of these blocks, which
reduces additional timing closure efforts.
Perform the following steps to update a single source file:
1. Apply and save the fix to the HDL source file.
2. On the Assignments menu, open the Design Partitions window.
3. Change the netlist type of each partition, including the top-level entity, to Post-Fit to preserve as much
as possible for the next compilation.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Optimizing a Timing-Critical Partition
3-11
• The Quartus II software recompiles partitions by default when changes are detected in a source file.
You can refer to the Partition Dependent Files table in the Analysis and Synthesis report to
determine which partitions were recompiled. If you change an assignment but do not change the
logic in a source file, you can set the netlist type to Source File for that partition to instruct the
software to recompile the partition's source design files and its assignments.
4. Click Start Compilation to incrementally compile the fixed HDL code. This compilation should take
much less time than the initial full compilation.
5. Simulate the design to ensure that the error is fixed, and use the TimeQuest Timing Analyzer report to
ensure that timing results have not degraded.
Related Information
List of Compilation and Simulation Reports online help
Optimizing a Timing-Critical Partition
Scenario background: You have just performed a lengthy full compilation of a design that consists of
multiple partitions. The TimeQuest Timing Analyzer reports that the clock timing requirement is not
met, and you have to optimize one particular partition. You want to try optimization techniques such as
raising the Placement Effort Multiplier, enabling Physical Synthesis, and running Design Space Explorer
II. Because these techniques all involve significant compilation time, you should apply them to only the
partition in question.
Use the flow in this example to optimize the results of one partition when the other partitions in the
design have already met their requirements. You can use this flow iteratively to lock down the perform‐
ance of one partition, and then move on to optimization of another partition.
Perform the following steps to preserve the results for partitions that meet their timing requirements, and
to recompile a timing-critical partition with new optimization settings:
1. Open the Design Partitions window.
2. For the partition in question, set the netlist type to Source File.
• If you change a setting that affects only the Fitter, you can save additional compilation time by
setting the netlist type to Post-Synthesis to reuse the synthesis results and refit the partition.
3. For the remaining partitions (including the top-level entity), set the netlist type to Post-Fit.
• You can optionally set the Fitter Preservation Level on the Advanced tab in the Design Partitions
Properties dialog box to Placement to allow for the most flexibility during routing.
4. Apply the desired optimization settings.
5. Click Start Compilation to perform incremental compilation on the design with the new settings.
During this compilation, the Partition Merge stage automatically merges the critical partition’s new
synthesis netlist with the post-fit netlists of the remaining partitions. The Fitter then refits only the
required partition. Because the effort is reduced as compared to the initial full compilation, the
compilation time is also reduced.
To use Design Space Explorer II, perform the following steps:
1. Repeat steps 1–3 of the previous procedure.
2. Save the project and run Design Space Explorer II.
Adding Design Logic Incrementally or Working With an Incomplete Design
Scenario background: You have one or more partitions that are known to be timing-critical in your full
design. You want to focus on developing and optimizing this subset of the design first, before adding the
rest of the design logic.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-12
Debugging Incrementally With the SignalTap II Logic Analyzer
QII5V1
2015.05.04
Use this flow to compile a timing-critical partition or partitions in isolation, optionally with extra
optimizations turned on. After timing closure is achieved for the critical logic, you can preserve its
content and placement and compile the remaining partitions with normal or reduced optimization levels.
For example, you may want to compile an IP block that comes with instructions to perform optimization
before you incorporate the rest of your custom logic.
To implement this design flow, perform the following steps:
1. Partition the design and create floorplan location assignments. For best results, ensure that the toplevel design includes the entire project framework, even if some parts of the design are incomplete and
are represented by an empty wrapper file.
2. For the partitions to be compiled first, in the Design Partitions window, set the netlist type to Source
File.
3. For the remaining partitions, set the netlist type to Empty.
4. To compile with the desired optimizations turned on, click Start Compilation.
5. Check the Timing Analyzer reports to ensure that timing requirements are met. If so, proceed to step
6. Otherwise, repeat steps 4 and 5 until the requirements are met.
6. In the Design Partitions window, set the netlist type to Post-Fit for the first partitions. You can set the
Fitter Preservation Level on the Advanced tab in the Design Partitions Properties dialog box to
Placement to allow more flexibility during routing if exact placement and routing preservation is not
required.
7. Change the netlist type from Empty to Source File for the remaining partitions, and ensure that the
completed source files are added to the project.
8. Set the appropriate level of optimizations and compile the design. Changing the optimizations at this
point does not affect any fitted partitions, because each partition has its netlist type set to Post-Fit.
9. Check the Timing Analyzer reports to ensure that timing requirements are met. If not, make design or
option changes and repeat step 8 and step 9 until the requirements are met.
The flow in this example is similar to design flows in which a module is implemented separately and is
later merged into the top-level. Generally, optimization in this flow works only if each critical path is
contained within a single partition. Ensure that if there are any partitions representing a design file that is
missing from the project, you create a placeholder wrapper file to define the port interface.
Related Information
• Designing in a Team-Based Environment on page 3-41
• Deciding Which Design Blocks Should Be Design Partitions on page 3-20
• Empty Partitions on page 3-33
Debugging Incrementally With the SignalTap II Logic Analyzer
Scenario background: Your design is not functioning as expected, and you want to debug the design using
the SignalTap II Logic Analyzer. To maintain reduced compilation times and to ensure that you do not
negatively affect the current version of your design, you want to preserve the synthesis and fitting results
and add the SignalTap II Logic Analyzer to your design without recompiling the source code.
Use this flow to reduce compilation times when you add the logic analyzer to debug your design, or when
you want to modify the configuration of the SignalTap II File without modifying your design logic or its
placement.
It is not necessary to create design partitions in order to use the SignalTap II incremental compilation
feature. The SignalTap II Logic Analyzer acts as its own separate design partition.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Functional Safety IP Implementation
3-13
Perform the following steps to use the SignalTap II Logic Analyzer in an incremental compilation flow:
1. Open the Design Partitions window.
2. Set the netlist type to Post-fit for all partitions to preserve their placement.
• The netlist type for the top-level partition defaults to Source File, so be sure to change this “Top”
partition in addition to any design partitions that you have created.
3. If you have not already compiled the design with the current set of partitions, perform a full compila‐
tion. If the design has already been compiled with the current set of partitions, the design is ready to
add the SignalTap II Logic Analyzer.
4. Set up your SignalTap II File using the post-fitting filter in the Node Finder to add signals for logic
analysis. This allows the Fitter to add the SignalTap II logic to the post-fit netlist without modifying the
design results.
To add signals from the pre-synthesis netlist, set the partition’s netlist type to Source File and use the
presynthesis filter in the Node Finder. This allows the software to resynthesize the partition and to tap
directly to the pre-synthesis node names that you choose. In this case, the partition is resynthesized and
refit, so the placement is typically different from previous fitting results.
Related Information
Design Debugging Using the SignalTap II Embedded Logic Analyzer documentation
Functional Safety IP Implementation
In functional safety designs, recertification is required when logic is modified in safety or standard areas
of the design. Recertification is required because the FPGA programming file has changed. You can
reduce the amount of required recertification if you use the functional safety separation flow in the
Quartus II software. By partitioning your safety IP (SIP) from standard logic, you ensure that the safety
critical areas of the design remain the same when the standard areas in your design are modified. The
safety-critical areas remain the same at the bit level.
The functional safety separation flow supports only Cyclone IV and Cyclone V device families.
Software Tool Impact on Safety
The Quartus II software can partition your design into safety partitions and standard partitions, but the
Quartus II software does not perform any online safety-related functionality. The Quartus II software
generates a bitstream that performs the safety functions. For the purpose of compliance with a functional
safety standard, the Quartus II software should be considered as an offline support tool.
Functional Safety Separation Flow
The functional safety separation flow consists of two separate work flows. The design creation flow and
the design modification flow both use incremental compilation, but the two flows have different use-case
scenarios.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-14
QII5V1
2015.05.04
Design Creation Flow
Figure 3-3: Functional Safety Separation Flow
Design activity
entry point
no
no
New Design?
yes
yes
Safety IP Change?
Design
Modification
Flow
Design
Creation
Flow
Design
Creation
Flow
Design Creation Flow
The design creation flow describes the necessary steps for initial design creation in a way that allows you
to modify your design. Some of the steps are architectural constraints and the remaining steps are steps
that you need to perform in the Quartus II software. Use the design creation flow for the first pass
certification of your product.
When you make modifications to the safety IP in your design, you must use the design creation flow.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Design Modification Flow
3-15
Figure 3-4: Design Creation Flow
Design Creation Flow
Tool Flow Stage
Altera FPGA Development
V-model Stage
Create Design Hierarchy
FPGA Architecture/Logical module design
Define Safety IP Partitions
Create Safety IP
LogicLock Region
Logical Module Integration
Compile the Design
Synthesis/Place and Route
Export Safety IP Partition
Generate Safety IP POF Partion
Verification
Create Safety IP POF Partion Hash
The design creation flow becomes active when you have a valid safety IP partition in your Quartus II
project and that safety IP partition does not have place and route data from a previous compile. In the
design creation flow, the Assembler generates a Partial Settings Mask (.psm) file for each safety IP
partition. Each .psm file contains a list of programming bits for its respective safety IP partition.
The Quartus II software determines whether to use the design creation flow or design modification flow
on a per partition basis. It is possible to have multiple safety IP partitions in a design where some are
running the design creation flow and others are running the design modification flow.
To reset the complete design to the design creation flow, remove the previous place and route data by
cleaning the project (removing the dbs). Alternatively, use the partition import flow, to selectively reset
the design. You can remove the netlists for the imported safety IP partitions individually using the Design
Partitions window.
Related Information
• Exporting and Importing Your Safety IP on page 3-19
• Design Partitions Window online help
Design Modification Flow
The design modification flow describes the necessary steps to make modifications to the standard IP in
your design. This flow ensures that the previously compiled safety IP that the project uses remains
unchanged when you change or compile standard IP.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-16
QII5V1
2015.05.04
Design Modification Flow
Use the design modification flow only after you qualify your design in the design creation flow.
Figure 3-5: Design Modification Flow
Modify Standard IP
Import Safety IP Partition
Compile the Design
Generate Safety IP POF Partition
Create Safety POF Partition Hash
Compare POF Partition Hash
Hardware Verification
(readback of POF)
When the design modification flow is active for a safety IP partition, the Fitter runs in Strict Preservation
mode for that partition. The Assembler performs run-time checks that compare the Partial Settings Mask
information matches the .psm file generated in the design creation flow. If the Assembler detects a
mismatch, a "Bad Mask!" or "ASM_STRICT_PRESERVA‐
TION_BITS_UTILITY::compare_masked_byte_array failed" internal error message is shown. If you see
either error message while compiling your design, contact Altera support for assistance.
When a change is made to any HDL source file that belongs to a safety IP, the default behavior of the
Quartus II software is to resynthesize and perform a clean place and route for that partition, which then
activates the design creation flow for that partition. To change this default behavior and keep the design
modification flow active, do the following:
• Use the partition export/import flow.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
How to Turn On the Functional Safety Separation Flow
3-17
or
• Use the Design Partitions window to modify the design partition properties and turn on Ignore
changes in source files and strictly use the specified netlist, if available.
The Fitter applies the same design flow to all partitions that belong to the same safety IP. If more than one
safety IP is used in the design, the Fitter may evoke different flows for different safety IPs.
Note: If your safety IP is a sub-block in a Qsys system, every time you regenerate HDL for the Qsys
system, the timestamp for the safety IP HDL changes. This results in resynthesis of the safety IP,
unless the default behavior (described above) is changed.
Related Information
• Exporting and Importing Your Safety IP on page 3-19
• Design Partitions Window online help
How to Turn On the Functional Safety Separation Flow
Every safety-related IP component in your design should be implemented in a partition(s) so the safety
IPs are protected from recompilation. The global assignment PARTITION_ENABLE_STRICT_PRESERVATION
is used to identify safety IP in your design.
set_global_assignment -name PARTITION_ENABLE_STRICT_PRESERVATION <ON/OFF> section_id <partition_name>
When this global assignment is designated as ON for a partition, the partition is protected from recompi‐
lation, exported as a safety IP, and included in the safety IP POF mask. Specifying the value as ON for any
partition turns on the functional safety separation flow.
When this global assignment is designated as OFF, the partition is considered as standard IP or as not
having a PARTITION_ENABLE_STRICT_PRESERVATION assignment at all. Logic that is not assigned to a
partition is considered as part of the top partition and treated as standard logic.
Note: Only partitions and I/O pins can be assigned to SIP.
A partition assigned to safety IP can contain safety logic only. If the parent partition is assigned to a safety
IP, then all the child partitions for this parent partition are considered as part of the safety IP. If you do
not explicitly specify a child partition as a safety IP, a critical warning notifies you that the child partition
is treated as part of a safety IP.
A design can contain several safety IPs. All the partitions containing logic that implements a single safety
IP function should belong with the same top-level parent partition.
You can also turn on the functional safety separation flow from the Design Partition Properties dialog
box. Click the Advanced tab and turn on Allow partition to be strictly preserved for safety.
When the functional safety separation flow is active, you can view which partitions in your design have
the Strict Preservation property turned on. The Design Partitions window displays a on or off value for
safety IP in your design (in the Strict Preservation column).
Related Information
• Design Partition Properties Dialog box online help
• Design Partitions Window online help
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-18
QII5V1
2015.05.04
Preservation of Device Resources
Preservation of Device Resources
The preservation of the partition’s netlist atoms and the atoms placement and routing, in the design
modification flow, is done by setting the netlist type to Post-fit with the Fitter preservation level set to
Placement and Routing Preserved.
Preservation of Placement in the Device with LogicLock
In order to fix the safety IP logic into specific areas of the device, you should define LogicLock regions. By
using preserved LogicLock regions, device placement is reserved for the safety IP to prevent standard logic
from being placed into the unused resources of the safety IP region. You establish a fixed size and origin
to ensure location preservation. You need to use LogicLock to ensure a valid safety IP POF mask is
generated when you turn on the functional safety separation flow. The POF comparison tool for
functional safety can check that the safety region is unchanged between compiles. A LogicLock region
assigned to a safety IP can only contain safety IP logic.
Assigning I/O Pins
You can use a global assignment to specify that a pin is assigned to a safety IP.
set_instance_assignment -name ENABLE_STRICT_PRESERVATION ON/OFF -to <hpath> section_id <region_name>
• <hpath> refers to an I/O pin (pad).
• <region_name> refers to the top-level safety IP partition name.
A value of ON indicates that the pin is a safety pin that should be preserved along with the safety IP. A
value of OFF indicates that the pin that connects up to the safety IP, should be treated as a standard pin,
and is not preserved along with the safety IP.
All the pins that connect up to a safety IP should have an explicit assignment.
An error is reported if a pin that connects up the safety IP does not have an assignment or a pin does not
connect up to the specified <region_name>.
If an IO_REG group contains a pin that is assigned to a safety IP, then all the pins in the IO_REG group
are reserved for this safety IP. All pins in the IO_REG group need to be assigned to the same safety IP and
none of the pins in the group can be assigned to standard signals.
General Guidelines for Implementation
• An internal clock source, such as a PLL, should be implemented in a safe partition.
• An I/O pin driving the external clock should be indicated as a safety pin.
• To export a safety IP containing several partitions, the top-level partition for the safety IP should be
exported. A safety IP containing several partitions is flattened and converted into a single partition
during export. This hierarchical safety IP is flattened to enure bit-level settings are preserved.
• Hard blocks implemented in a safe partition needs to stay with the safe partition.
Reports for Safety IP
When you have the functional safety separation flow turned on, the Quartus II software displays safety IP
and standard IP information in the Fitter report.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Fitter Report
3-19
Fitter Report
The Fitter report includes information for each safety IP and the respective partition and I/O usage. The
report contains the following information:
•
•
•
•
•
•
•
•
Safety IP name defined as the name of the top-level safety IP partition
Effective design flow for the safety IP
Names of all partitions that belong to the safety IP
Number of safety/standard inputs to the safety IP
Number of safety/standard outputs to the safety IP
LogicLock region names along with size and locations for the regions
I/O pins used for the respective safety IP in your design
Safety-related error messages
SIP Partial Bitstream Generation
The Programmer generates a bitstream file containing only the bits for a safety IP. This partial preserved
bitstream (.ppb) file is for the safety IP region mask. The command lines to generate the partial bitstream
file are the following:
• quartus_cpf --genppb safe1.psm design.sof safe1.rbf.ppb
• quartus_cpf -c safe1.psm safe1.rbf.ppb
The .ppb file is generated in two steps.
1. Generation of partial SOF.
2. Generation of .ppb file using the partial SOF.
The .psm file, .ppb file, and MD5 hash signature (.md5.sign) file created during partial bitstream generation
should be archived for use in future design modification flow compiles.
Exporting and Importing Your Safety IP
Safety IP Partition Export
After you have successfully compiled the safety IP(s) in the Quartus II software, save the safety partition
place and route information for use in any subsequent design modification flow. Saving the partition
information allows the safety IP to be imported to a clean Quartus II project where no previous compila‐
tion results have been removed (even if the version of the Quartus II software being used is newer than the
Quartus II software version with which the safety IP was originally compiled). Use the Design Partitions
window to export the design partition. Verify that only the post-fit netlist and export routing options are
turned on when you generate the .qxp file for each safety IP. The .qxp files should be archived along with
the partial bitstream files for use in later design modification flow compiles.
Safety IP Partition Import
You can import a previously exported safety IP partition into your Quartus II project. There are two usecases for this.
• (Optional) Import into the original project to ensure that any potential source code changes do not
trigger the design creation flow unintentionally.
• Import into a new or clean project where you want to use the design modification flow for the safety
IP. As the exported partition is independent of your Quartus II software version, you can import
the .qxp into a future Quartus II software release.
To import a previously exported design partition, use the Design Partitions window and import the .qxp.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-20
QII5V1
2015.05.04
POF Comparison Tool for Verification
Related Information
• Export Design Partition online help
• Import Design Partition online help
POF Comparison Tool for Verification
There is a separate safe/standard partitioning verification tool that is licensed to safety users. Along with
the .ppb file, a .md5.sign file is generated. The MD5 hash signature can be used for verification. For more
detailed verification, the POF comparison tool should be used. This POF comparison tool is available in
the Altera Functional Safety Data Package.
Deciding Which Design Blocks Should Be Design Partitions
The incremental compilation design flow requires more planning than flat compilations. For example,
you might have to structure your source code or design hierarchy to ensure that logic is grouped correctly
for optimization.
It is a common design practice to create modular or hierarchical designs in which you develop each
design entity separately, and then instantiate them in a higher-level entity, forming a complete design. The
Quartus II software does not automatically consider each design entity or instance to be a design partition
for incremental compilation; instead, you must designate one or more design hierarchies below the toplevel project as a design partition. Creating partitions might prevent the Compiler from performing
optimizations across partition boundaries. However, this allows for separate synthesis and placement for
each partition, making incremental compilation possible.
Partitions must have the same boundaries as hierarchical blocks in the design because a partition cannot
be a portion of the logic within a hierarchical entity. You can merge partitions that have the same
immediate parent partition to create a single partition that includes more than one hierarchical entity in
the design. When you declare a partition, every hierarchical instance within that partition becomes part of
the same partition. You can create new partitions for hierarchical instances within an existing partition, in
which case the instances within the new partition are no longer included in the higher-level partition, as
described in the following example.
In the figure below, a complete design is made up of instances A, B, C, D, E, F, and G. The shaded boxes
in Representation i indicate design partitions in a “tree” representation of the hierarchy. In Representa‐
tion ii, the lower-level instances are represented inside the higher-level instances, and the partitions are
illustrated with different colored shading. The top-level partition, called “Top”, automatically contains the
top-level entity in the design, and contains any logic not defined as part of another partition. The design
file for the top level may be just a wrapper for the hierarchical instances below it, or it may contain its own
logic. In this example, partition B contains the logic in instances B, D, and E. Entities F and G were first
identified as separate partitions, and then merged together to create a partition F-G. The partition for the
top-level entity A, called “Top”, includes the logic in one of its lower-level instances, C, because C was not
defined as part of any other partition.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Deciding Which Design Blocks Should Be Design Partitions
3-21
Figure 3-6: Partitions in a Hierarchical Design
Representation i
Partition Top
A
B
C
D
E
F
Partition B
G
Merged Partition F-G
Representation ii
A
C
B
D
E
F
G
You can create partition assignments to any design instance. The instance can be defined in HDL or
schematic design, or come from a third-party synthesis tool as a VQM or EDIF netlist instance.
To take advantage of incremental compilation when source files change, create separate design files for
each partition. If you define two different entities as separate partitions but they are in the same design
file, you cannot maintain incremental compilation because the software would have to recompile both
partitions if you changed either entity in the design file. Similarly, if two partitions rely on the same lowerlevel entity definition, changes in that lower-level affect both partitions.
The remainder of this section provides information to help you choose which design blocks you should
assign as partitions.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-22
Impact of Design Partitions on Design Optimization
QII5V1
2015.05.04
Impact of Design Partitions on Design Optimization
The boundaries of your design partitions can impact the design’s quality of results. Creating partitions
might prevent the Compiler from performing logic optimizations across partition boundaries, which
allows the software to synthesize and place each partition separately in an incremental flow. Therefore,
consider partitioning guidelines to help reduce the effect of partition boundaries.
Whenever possible, register all inputs and outputs of each partition. This helps avoid any delay penalty on
signals that cross partition boundaries and keeps each register-to-register timing path within one partition
for optimization. In addition, minimize the number of paths that cross partition boundaries. If there are
timing-critical paths that cross partition boundaries, rework the partitions to avoid these inter-partition
paths. Including as many of the timing-critical connections as possible inside a partition allows you to
effectively apply optimizations to that partition to improve timing, while leaving the rest of the design
unchanged.
Avoid constant partition inputs and outputs. You can also merge two or more partitions to allow crossboundary optimizations for paths that cross between the partitions, as long as the partitions have the same
parent partition. Merging related logic from different hierarchy blocks into one partition can be useful if
you cannot change the design hierarchy to accommodate partition assignments.
If critical timing paths cross partition boundaries, you can perform timing budgeting and make timing
assignments to constrain the logic in each partition so that the entire timing path meets its requirements.
In addition, because each partition is optimized independently during synthesis, you may have to perform
resource allocation to ensure that each partition uses an appropriate number of device resources. If design
partitions are compiled in separate Quartus II projects, there may be conflicts related to global routing
resources for clock signals when the design is integrated into the top-level design. You can use the Global
Signal logic option to specify which clocks should use global or regional routing, use the ALTCLK_CTRL
IP core to instantiate a clock control block and connect it appropriately in both the partitions being
developed in separate Quartus II projects, or find the compiler-generated clock control node in your
design and make clock control location assignments in the Assignment Editor.
Turning On Supported Cross-boundary Optimizations
You can improve the optimizations performed between design partitions by turning on supported crossboundary optimizations. These optimizations are turned on a per partition basis and you can select the
optimizations as individual assignments. This allows the cross-boundary optimization feature to give you
more control over the optimizations that work best for your design. You can turn on the cross-boundary
optimizations for your design partitions on the Advanced tab of the Design Partition Properties dialog
box. Once you change the optimization settings, the Quartus II software recompiles your partition from
source automatically. Cross-boundary optimizations include the following: propagate constants,
propagate inversions on partition inputs, merge inputs fed by a common source, merge electrically
equivalent bidirectional pins, absorb internal paths, and remove logic connected to dangling outputs.
Cross-boundary optimizations are implemented top-down from the parent partition into the child
partition, but not vice-versa. Also, cross-boundary optimizations cannot be enabled for partitions that
allow multiple personas (partial reconfiguration partitions).
Related Information
Design Partition Properties Dialog Box online help
Best Practices for Incremental Compilation Partitions and Floorplan Assignments documentation on
page 14-1
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Design Partition Assignments Compared to Physical Placement Assignments
3-23
Design Partition Assignments Compared to Physical Placement Assignments
Design partitions for incremental compilation are logical partitions, which is different from physical
placement assignments in the device floorplan. A logical design partition does not refer to a physical area
of the device and does not directly control the placement of instances. A logical design partition sets up a
virtual boundary between design hierarchies so that each is compiled separately, preventing logical
optimizations from occurring between them. When the software compiles the design source code, the
logic in each partition can be placed anywhere in the device unless you make additional placement
assignments.
If you preserve the compilation results using a Post-Fit netlist, it is not necessary for you to back-annotate
or make any location assignments for specific logic nodes. You should not use the incremental compila‐
tion and logic placement back-annotation features in the same Quartus II project. The incremental
compilation feature does not use placement “assignments” to preserve placement results; it simply reuses
the netlist database that includes the placement information.
You can assign design partitions to physical regions in the device floorplan using LogicLock region
assignments. In the Quartus II software, LogicLock regions are used to constrain blocks of a design to a
particular region of the device. Altera recommends using LogicLock regions for timing-critical design
blocks that will change in subsequent compilations, or to improve the quality of results and avoid
placement conflicts in some cases.
Related Information
Creating a Design Floorplan With LogicLock Regions on page 3-47
Best Practices for Incremental Compilation Partitions and Floorplan Assignments documentation on
page 14-1
Using Partitions With Third-Party Synthesis Tools
If you are using a third-party synthesis tool, set up your tool to create a separate VQM or EDIF netlist for
each hierarchical partition. In the Quartus II software, assign the top-level entity from each netlist to be a
design partition. The VQM or EDIF netlist file is treated as the source file for the partition in the Quartus
II software.
Synopsys Synplify Pro/Premier and Mentor Graphics Precision RTL Plus
The Synplify Pro and Synplify Premier software include the MultiPoint synthesis feature to perform
incremental synthesis for each design block assigned as a Compile Point in the user interface or a script.
The Precision RTL Plus software includes an incremental synthesis feature that performs block-based
synthesis based on Partition assignments in the source HDL code. These features provide automated
block-based incremental synthesis flows and create different output netlist files for each block when set up
for an Altera device.
Using incremental synthesis within your synthesis tool ensures that only those sections of a design that
have been updated are resynthesized when the design is compiled, reducing synthesis run time and
preserving the results for the unchanged blocks. You can change and resynthesize one section of a design
without affecting other sections of the design.
Related Information
• Synopsys Synplify Support documentation on page 17-1
• Mentor Graphics Precision Synthesis Support documentation on page 18-1
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-24
QII5V1
2015.05.04
Other Synthesis Tools
Other Synthesis Tools
You can also partition your design and create different netlist files manually with the basic Synplify
software (non-Pro/Premier), the basic Precision RTL software (non-Plus), or any other supported
synthesis tool by creating a separate project or implementation for each partition, including the top level.
Set up each higher-level project to instantiate the lower-level VQM/EDIF netlists as black boxes. Synplify,
Precision, and most synthesis tools automatically treat a design block as a black box if the logic definition
is missing from the project. Each tool also includes options or attributes to specify that the design block
should be treated as a black box, which you can use to avoid warnings about the missing logic.
Assessing Partition Quality
The Quartus II software provides various tools to assess the quality of your assigned design partitions.
You can take advantage of these tools to assess your partition quality, and use the information to improve
your design or assignments as required to achieve the best results.
Partition Statistics Reports
After compilation, you can view statistics about design partitions in the Partition Merge Partition
Statistics report, and on the Statistics tab in the Design Partitions Properties dialog box.
The Partition Merge Partition Statistics report lists statistics about each partition. The statistics for each
partition (each row in the table) include the number of logic cells it contains, as well as the number of
input and output pins it contains, and how many are registered or unconnected.
You can also view post-compilation statistics about the resource usage and port connections for a
particular partition on the Statistics tab in the Design Partition Properties dialog box.
Related Information
• Best Practices for Incremental Compilation Partitions and Floorplan Assignments documentation
on page 14-1
Partition Timing Reports
You can generate a Partition Timing Overview report and a Partition Timing Details report by clicking
Report Partitions in the Tasks pane in the TimeQuest Timing Analyzer, or using the
report_partitions Tcl command.
The Partition Timing Overview report shows the total number of failing paths for each partition and the
worst-case slack for any path involving the partition.
The Partition Timing Details report shows the number of failing partition-to-partition paths and worstcase slack for partition-to-partition paths, to provide a more detailed breakdown of where the critical
paths in the design are located with respect to design partitions.
Incremental Compilation Advisor
You can use the Incremental Compilation Advisor to check that your design follows Altera’s
recommendations for creating design partitions and floorplan location assignments.
Recommendations are split into General Recommendations, Timing Recommendations, and TeamBased Design Recommendations that apply to design flows in which partitions are compiled independ‐
ently in separate Quartus II projects before being integrated into the top-level design. Each recommenda‐
tion provides an explanation, describes the effect of the recommendation, and provides the action
required to make a suggested change. In some cases, there is a link to the appropriate Quartus II settings
page where you can make a suggested change to assignments or settings. For some items, if your design
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Specifying the Level of Results Preservation for Subsequent Compilations
3-25
does not follow the recommendation, the Check Recommendations operation creates a table that lists
any nodes or paths in your design that could be improved. The relevant timing-independent recommen‐
dations for the design are also listed in the Design Partitions window and the LogicLock Regions window.
To verify that your design follows the recommendations, go to the Timing Independent Recommenda‐
tions page or the Timing Dependent Recommendations page, and then click Check Recommendations.
For large designs, these operations can take a few minutes.
After you perform a check operation, symbols appear next to each recommendation to indicate whether
the design or project setting follows the recommendations, or if some or all of the design or project
settings do not follow the recommendations. Following these recommendations is not mandatory to use
the incremental compilation feature. The recommendations are most important to ensure good results for
timing-critical partitions.
For some items in the Advisor, if your design does not follow the recommendation, the Check
Recommendations operation lists any parts of the design that could be improved. For example, if not all
of the partition I/O ports follow the Register All Non-Global Ports recommendation, the advisor displays
a list of unregistered ports with the partition name and the node name associated with the port.
When the advisor provides a list of nodes, you can right-click a node, and then click Locate to cross-probe
to other Quartus II features, such as the RTL Viewer, Chip Planner, or the design source code in the text
editor.
Note: Opening a new TimeQuest report resets the Incremental Compilation Advisor results, so you must
rerun the Check Recommendations process.
Specifying the Level of Results Preservation for Subsequent
Compilations
The netlist type of each design partition allows you to specify the level of results preservation. The netlist
type determines which type of netlist or source file the Partition Merge stage uses in the next incremental
compilation.
When you choose to preserve a post-fit compilation netlist, the default level of Fitter preservation is the
highest degree of placement and routing preservation supported by the device family. The advanced Fitter
Preservation Level setting allows you to specify the amount of information that you want to preserve from
the post-fit netlist file.
Netlist Type for Design Partitions
Before starting a new compilation, ensure that the appropriate netlist type is set for each partition to
preserve the desired level of compilation results. The table below describes the settings for the netlist type,
explains the behavior of the Quartus II software for each setting, and provides guidance on when to use
each setting.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-26
QII5V1
2015.05.04
Netlist Type for Design Partitions
Table 3-2: Partition Netlist Type Settings
Netlist Type
Source File
Quartus II Software Behavior for Partition During Compilation
Always compiles the partition using the associated design source file(s). (2)
Use this netlist type to recompile a partition from the source code using new
synthesis or Fitter settings.
Post-Synthesis
Preserves post-synthesis results for the partition and reuses the post-synthesis
netlist when the following conditions are true:
• A post-synthesis netlist is available from a previous synthesis.
• No change that initiates an automatic resynthesis has been made to the
partition since the previous synthesis. (3)
Compiles the partition from the source files if resynthesis is initiated or if a
post-synthesis netlist is not available. (2)
Use this netlist type to preserve the synthesis results unless you make design
changes, but allow the Fitter to refit the partition using any new Fitter
settings.
Post-Fit
Preserves post-fit results for the partition and reuses the post-fit netlist when
the following conditions are true:
• A post-fit netlist is available from a previous fitting.
• No change that initiates an automatic resynthesis has been made to the
partition since the previous fitting. (3)
When a post-fit netlist is not available, the software reuses the post-synthesis
netlist if it is available, or otherwise compiles from the source files. Compiles
the partition from the source files if resynthesis is initiated. (2)
The Fitter Preservation Level specifies what level of information is preserved
from the post-fit netlist.
Assignment changes, such as Fitter optimization settings, do not cause a
partition set to Post-Fit to recompile.
(2)
(3)
If you use Rapid Recompile, the Quartus II software might not recompile the entire partition from the
source code as described in this table; it will reuse compatible results if there have been only small
changes to the logic in the partition.
You can turn on the Ignore changes in source files and strictly use the specified netlist, if available
option on the Advanced tab in the Design Partitions Properties dialog box to specify whether the
Compiler should ignore source file changes when deciding whether to recompile the partition.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Fitter Preservation Level for Design Partitions
Netlist Type
Empty
3-27
Quartus II Software Behavior for Partition During Compilation
Uses an empty placeholder netlist for the partition. The partition's port
interface information is required during Analysis and Synthesis to connect the
partition correctly to other logic and partitions in the design, and peripheral
nodes in the source file including pins and PLLs are preserved to help connect
the empty partition to the rest of the design and preserve timing of any lowerlevel non-empty partitions within empty partitions. If the source file is not
available, you can create a wrapper file that defines the design block and
specifies the input, output, and bidirectional ports. In Verilog HDL: a module
declaration, and in VHDL: an entity and architecture declaration.
You can use this netlist type to skip the compilation of a partition that is
incomplete or missing from the top-level design. You can also set an empty
partition if you want to compile only some partitions in the design, such as to
optimize the placement of a timing-critical block such as an IP core before
incorporating other design logic, or if the compilation time is large for one
partition and you want to exclude it.
If the project database includes a previously generated post-synthesis or postfit netlist for an unchanged Empty partition, you can set the netlist type from
Empty directly to Post-Synthesis or Post-Fit and the software reuses the
previous netlist information without recompiling from the source files.
Related Information
• What Changes Initiate the Automatic Resynthesis of a Partition? on page 3-29
• Fitter Preservation Level for Design Partitions on page 3-27
• Incremental Capabilities Available When A Design Has No Partitions on page 3-2
Fitter Preservation Level for Design Partitions
The default Fitter Preservation Level for partitions with a Post-Fit netlist type is the highest level of
preservation available for the target device family and provides the most compilation time reduction.
You can change the advanced Fitter Preservation Level setting to provide more flexibility in the Fitter
during placement and routing. You can set the Fitter Preservation Level on the Advanced tab in the
Design Partitions Properties dialog box.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-28
QII5V1
2015.05.04
Where Are the Netlist Databases Saved?
Table 3-3: Fitter Preservation Level Settings
Fitter Preservation Level
Quartus II Behavior for Partition During Compilation
Placement and Routing
Preserves the design partition’s netlist atoms and
their placement and routing.
This setting reduces compilation times compared to
Placement only, but provides less flexibility to the
router to make changes if there are changes in other
parts of the design.
By default, the Fitter preserves the usage of highspeed programmable power tiles contained within
the selected partition, for devices that support highspeed and low-power tiles. You can turn off the
Preserve high-speed tiles when preserving
placement and routing option on the Advanced
tab in the Design Partitions Properties dialog box.
Placement
Preserves the netlist atoms and their placement in
the design partition. Reroutes the design partition
and does not preserve high-speed power tile usage.
Netlist Only
Preserves the netlist atoms of the design partition,
but replaces and reroutes the design partition. A
post-fit netlist with the atoms preserved can be
different than the Post-Synthesis netlist because it
contains Fitter optimizations; for example, Physical
Synthesis changes made during a previous Fitting.
You can use this setting to:
• Preserve Fitter optimizations but allow the
software to perform placement and routing
again.
• Reapply certain Fitter optimizations that would
otherwise be impossible when the placement is
locked down.
• Resolve resource conflicts between two imported
partitions.
Related Information
Setting the Netlist Type and Fitter Preservation Level for Design Partitions online help
Where Are the Netlist Databases Saved?
The incremental compilation database folder (\incremental_db) includes all the netlist information from
previous compilations. To avoid unnecessary recompilations, these database files must not be altered or
deleted.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Deleting Netlists
3-29
If you archive or reproduce the project in another location, you can use a Quartus II Archive File (.qar).
Include the incremental compilation database files to preserve post-synthesis or post-fit compilation
results.
To manually create a project archive that preserves compilation results without keeping the incremental
compilation database, you can keep all source and settings files, and create and save a Quartus II Settings
File (.qxp) for each partition in the design that will be integrated into the top-level design.
Related Information
• Using Incremental Compilation With Quartus II Archive Files on page 3-49
• Exporting Design Partitions from Separate Quartus II Projects on page 3-31
Deleting Netlists
You can choose to abandon all levels of results preservation and remove all netlists that exist for a
particular partition with the Delete Netlists command in the Design Partitions window. When you delete
netlists for a partition, the partition is compiled using the associated design source file(s) in the next
compilation. Resetting the netlist type for a partition to Source would have the same effect, though the
netlists would not be permanently deleted and would be available for use in subsequent compilations. For
an imported partition, the Delete Netlists command also optionally allows you to remove the
imported .qxp.
What Changes Initiate the Automatic Resynthesis of a Partition?
A partition is synthesized from its source files if there is no post-synthesis netlist available from a previous
synthesis, or if the netlist type is set to Source File. Additionally, certain changes to a partition initiate an
automatic resynthesis of the partition when the netlist type is Post Synthesis or Post-Fit. The software
resynthesizes the partition in these cases to ensure that the design description matches the
post-place-and-route programming files.
The following list explains the changes that initiate a partition’s automatic resynthesis when the netlist
type is set to Post-Synthesis or Post-Fit:
• The device family setting has changed.
• Any dependent source design file has changed.
• The partition boundary was changed by an addition, removal, or change to the port boundaries of a
partition (for example, a new partition has been defined for a lower-level instance within this
partition).
• A dependent source file was compiled into a different library (so it has a different -library
argument).
• A dependent source file was added or removed; that is, the partition depends on a different set of
source files.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-30
QII5V1
2015.05.04
Resynthesis Due to Source Code Changes
• The partition’s root instance has a different entity binding. In VHDL, an instance may be bound to a
specific entity and architecture. If the target entity or architecture changes, it triggers resynthesis.
• The partition has different parameters on its root hierarchy or on an internal AHDL hierarchy (AHDL
automatically inherits parameters from its parent hierarchies). This occurs if you modified the
parameters on the hierarchy directly, or if you modified them indirectly by changing the parameters in
a parent design hierarchy.
• You have moved the project and compiled database between a Windows and Linux system. Due to the
differences in the way new line feeds are handled between the operating systems, the internal
checksum algorithm may detect a design file change in this case.
The software reuses the post-synthesis results but re-fits the design if you change the device setting within
the same device family. The software reuses the post-fitting netlist if you change only the device speed
grade.
Synthesis and Fitter assignments, such as optimization settings, timing assignments, or Fitter location
assignments including pin assignments, do not trigger automatic recompilation in the incremental
compilation flow. To recompile a partition with new assignments, change the netlist type for that partition
to one of the following:
• Source File to recompile with all new settings
• Post-Synthesis to recompile using existing synthesis results but new Fitter settings
• Post-Fit with the Fitter Preservation Level set to Placement to rerun routing using existing
placement results, but new routing settings (such as delay chain settings)
You can use the LogicLock Origin location assignment to change or fine-tune the previous Fitter results
from a Post-Fit netlist.
Related Information
Changing Partition Placement with LogicLock Changes on page 3-48
Resynthesis Due to Source Code Changes
The Quartus II software uses an internal checksum algorithm to determine whether the contents of a
source file have changed. Source files are the design description files used to create the design, and include
Memory Initialization Files (.mif) as well as .qxp from exported partitions. When design files in a
partition have dependencies on other files, changing one file may initiate an automatic recompilation of
another file. The Partition Dependent Files table in the Analysis and Synthesis report lists the design files
that contribute to each design partition. You can use this table to determine which partitions are
recompiled when a specific file is changed.
For example, if a design has file A.v that contains entity A, B.v that contains entity B, and C.v that
contains entity C, then the Partition Dependent Files table for the partition containing entity A lists file
A.v, the table for the partition containing entity B lists file B.v, and the table for the partition containing
entity C lists file C.v. Any dependencies are transitive, so if file A.v depends on B.v, and B.v depends on
C.v, the entities in file A.v depend on files B.v and C.v. In this case, files B.v and C.v are listed in the
report table as dependent files for the partition containing entity A.
Note: If you use Rapid Recompile, the Quartus II software might not recompile the entire partition from
the source code as described in this section; it will reuse compatible results if there have been only
small changes to the logic in the partition.
If you define module parameters in a higher-level module, the Quartus II software checks the parameter
values when determining which partitions require resynthesis. If you change a parameter in a higher-level
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Forcing Use of the Compilation Netlist When a Partition has Changed
3-31
module that affects a lower-level module, the lower-level module is resynthesized. Parameter dependen‐
cies are tracked separately from source file dependencies; therefore, parameter definitions are not listed in
the Partition Dependent Files list.
If a design contains common files, such as an includes.v file that is referenced in each entity by the
command include includes.v, all partitions are dependent on this file. A change to includes.v causes
the entire design to be recompiled. The VHDL statement use work.all also typically results in unneces‐
sary recompilations, because it makes all entities in the work library visible in the current entity, which
results in the current entity being dependent on all other entities in the design.
To avoid this type of problem, ensure that files common to all entities, such as a common include file,
contain only the set of information that is truly common to all entities. Remove use work.all statements
in your VHDL file or replace them by including only the specific design units needed for each entity.
Related Information
Incremental Capabilities Available When A Design Has No Partitions on page 3-2
Forcing Use of the Compilation Netlist When a Partition has Changed
Forcing the use of a post-compilation netlist when the contents of a source file has changed is
recommended only for advanced users who understand when a partition must be recompiled. You might
use this assignment, for example, if you are making source code changes but do not want to recompile the
partition until you finish debugging a different partition, or if you are adding simple comments to the
source file but you know the design logic itself is not being changed and you want to keep the previous
compilation results.
To force the Fitter to use a previously generated netlist even when there are changes to the source files,
right-click the partition in the Design Partitions window and then click Design Partition Properties. On
the Advanced tab, turn on the Ignore changes in source files and strictly use the specified netlist, if
available option.
Turning on this option can result in the generation of a functionally incorrect netlist when source design
files change, because source file updates will not be recompiled. Use caution when setting this option.
Exporting Design Partitions from Separate Quartus II Projects
Partitions that are developed by other designers or team members in the same company or third-party IP
providers can be exported as design partitions to a Quartus II Exported Partition File (.qxp), and then
integrated into a top-level design. A .qxp is a binary file that contains compilation results describing the
exported design partition and includes a post-synthesis netlist, a post-fit netlist, or both, and a set of
assignments, sometimes including LogicLock placement constraints. The .qxp does not contain the source
design files from the original Quartus II project.
To enable team-based development and third-party IP delivery, you can design and optimize partitions in
separate copies of the top-level Quartus II project framework, or even in isolation. If the designers have
access to the top-level project framework through a source control system, they can access project files as
read-only and develop their partition within the source control system. If designers do not have access to
a source control system, the project lead can provide the designer with a copy of the top-level project
framework to use as they develop their partitions. The project lead also has the option to generate design
partition scripts to manage resource and timing budgets in the top-level design when partitions are
developed outside the top-level project framework.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-32
Exporting Design Partitions from Separate Quartus II Projects
QII5V1
2015.05.04
The exported compilation results of completed partitions are given to the project lead, preferably using a
source control system, who is then responsible for integrating them into the top-level design to obtain a
fully functional design. This type of design flow is required only if partition designers want to optimize
their placement and routing independently, and pass their design to the project lead to reuse placement
and routing results. Otherwise, a project lead can integrate source HDL from several designers in a single
Quartus II project, and use the standard incremental compilation flow described previously.
The figure below illustrates the team-based incremental compilation design flow using a methodology in
which partitions are compiled in separate Quartus II projects before being integrated into the top-level
design. This flow can be used when partitions are developed by other designers or IP providers.
Figure 3-7: Team-Based Incremental Compilation Design Flow
Prepare Top-Level Design for
Incremental Compilation
Provide Project Framework or
Constraints to Designers
Design, Compile, and
Optimize Partition(s)
Export Lower-Level Partition(s)
Integrate Partition(s)
into Top-Level Design
Repeat as Needed
During Design, Verification,
& Debugging Stages
Perform Incremental Compilation
in Top-Level Design
Note: You cannot export or import partitions that have been merged.
Related Information
• Deciding Which Design Blocks Should Be Design Partitions on page 3-20
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Preparing the Top-Level Design
3-33
• Incremental Compilation Restrictions on page 3-49
Preparing the Top-Level Design
To prepare your design to incorporate exported partitions, first create the top-level project framework of
the design to define the hierarchy for the subdesigns that will be implemented by other team members,
designers, or IP providers.
In the top-level design, create project-wide settings, for example, device selection, global assignments for
clocks and device I/O ports, and any global signal constraints to specify which signals can use global
routing resources.
Next, create the appropriate design partition assignments and set the netlist type for each design partition
that will be developed in a separate Quartus II project to Empty. It may be necessary to constrain the
location of partitions with LogicLock region assignments if they are timing-critical and are expected to
change in future compilations, or if the designer or IP provider wants to place and route their design
partition independently, to avoid location conflicts.
Finally, provide the top-level project framework to the partition designers, preferably through a source
control system.
Related Information
Creating a Design Floorplan With LogicLock Regions on page 3-47
Empty Partitions
You can use a design flow in which some partitions are set to an Empty netlist type to develop pieces of
the design separately, and then integrate them into the top-level design at a later time. In a team-based
design environment, you can set the netlist type to Empty for partitions in your design that will be
developed by other designers or IP providers. The Empty setting directs the Compiler to skip the
compilation of a partition and use an empty placeholder netlist for the partition.
When a netlist type is set to Empty, peripheral nodes including pins and PLLs are preserved and all other
logic is removed. The peripheral nodes including pins help connect the empty partition to the design, and
the PLLs help preserve timing of non-empty partitions within empty partitions.
When you set a design partition to Empty, a design file is required during Analysis and Synthesis to
specify the port interface information so that it can connect the partition correctly to other logic and
partitions in the design. If a partition is exported from another project, the .qxp contains this information.
If there is no .qxp or design file to represent the design entity, you must create a wrapper file that defines
the design block and specifies the input, output, and bidirectional ports. For example, in Verilog HDL,
you should include a module declaration, and in VHDL, you should include an entity and architecture
declaration.
Project Management— Making the Top-Level Design Available to Other Designers
In team-based incremental compilation flows, whenever possible, all designers or IP providers should
work within the same top-level project framework. Using the same project framework among team
members ensures that designers have the settings and constraints needed for their partition, and makes
timing closure easier when integrating the partitions into the top-level design. If other designers do not
have access to the top-level project framework, the Quartus II software provides tools for passing project
information to partition designers.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-34
QII5V1
2015.05.04
Distributing the Top-Level Quartus II Project
Distributing the Top-Level Quartus II Project
There are several methods that the project lead can use to distribute the “skeleton” or top-level project
framework to other partition designers or IP providers.
• If partition designers have access to the top-level project framework, the project will already include all
the settings and constraints needed for the design. This framework should include PLLs and other
interface logic if this information is important to optimize partitions.
• If designers are part of the same design environment, they can check out the required project files
from the same source control system. This is the recommended way to share a set of project files.
• Otherwise, the project lead can provide a copy of the top-level project framework so that each
design develops their partition within the same project framework.
• If a partition designer does not have access to the top-level project framework, the project lead can give
the partition designer a Tcl script or other documentation to create the separate Quartus II project and
all the assignments from the top-level design.
If the partition designers provide the project lead with a post-synthesis .qxp and fitting is performed in
the top-level design, integrating the design partitions should be quite easy. If you plan to develop a
partition in a separate Quartus II project and integrate the optimized post-fitting results into the top-level
design, use the following guidelines to improve the integration process:
• Ensure that a LogicLock region constrains the partition placement and uses only the resources
allocated by the project lead.
• Ensure that you know which clocks should be allocated to global routing resources so that there are no
resource conflicts in the top-level design.
• Set the Global Signal assignment to On for the high fan-out signals that should be routed on global
routing lines.
• To avoid other signals being placed on global routing lines, turn off Auto Global Clock and Auto
Global Register Controls under More Settings on the Fitter page in the Settings dialog box.
Alternatively, you can set the Global Signal assignment to Off for signals that should not be placed
on global routing lines.
Placement for LABs depends on whether the inputs to the logic cells within the LAB use a global
clock. You may encounter problems if signals do not use global lines in the partition, but use global
routing in the top-level design.
• Use the Virtual Pin assignment to indicate pins of a partition that do not drive pins in the top-level
design. This is critical when a partition has more output ports than the number of pins available in the
target device. Using virtual pins also helps optimize cross-partition paths for a complete design by
enabling you to provide more information about the partition ports, such as location and timing
assignments.
• When partitions are compiled independently without any information about each other, you might
need to provide more information about the timing paths that may be affected by other partitions in
the top-level design. You can apply location assignments for each pin to indicate the port location after
incorporation in the top-level design. You can also apply timing assignments to the I/O ports of the
partition to perform timing budgeting.
Related Information
• Best Practices for Incremental Compilation Partitions and Floorplan Assignments documentation
on page 14-1
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Generating Design Partition Scripts
3-35
Generating Design Partition Scripts
If IP providers or designers on a team want to optimize their design blocks independently and do not have
access to a shared project framework, the project lead must perform some or all of the following tasks to
ensure successful integration of the design blocks:
• Determine which assignments should be propagated from the top-level design to the partitions. This
requires detailed knowledge of which assignments are required to set up low-level designs.
• Communicate the top-level assignments to the partitions. This requires detailed knowledge of Tcl or
other scripting languages to efficiently communicate project constraints.
• Determine appropriate timing and location assignments that help overcome the limitations of teambased design. This requires examination of the logic in the partitions to determine appropriate timing
constraints.
• Perform final timing closure and resource conflict avoidance in the top-level design. Because the
partitions have no information about each other, meeting constraints at the lower levels does not
guarantee they are met when integrated at the top-level. It then becomes the project lead’s responsi‐
bility to resolve the issues, even though information about the partition implementation may not be
available.
Design partition scripts automate the process of transferring the top-level project framework to partition
designers in a flow where each design block is developed in separate Quartus II projects before being
integrated into the top-level design. If the project lead cannot provide each designer with a copy of the
top-level project framework, the Quartus II software provides an interface for managing resources and
timing budgets in the top-level design. Design partition scripts make it easier for partition designers to
implement the instructions from the project lead, and avoid conflicts between projects when integrating
the partitions into the top-level design. This flow also helps to reduce the need to further optimize the
designs after integration.
You can use options in the Generate Design Partition Scripts dialog box to choose which types of
assignments you want to pass down and create in the partitions being developed in separate Quartus II
projects.
Related Information
• Enabling Designers on a Team to Optimize Independently on page 3-42
• Generating Design Partition Scripts for Project Management online help
• Generate Design Partition Scripts Dialog Box online help
Exporting Partitions
When partition designers achieve the design requirements in their separate Quartus II projects, each
designer can export their design as a partition so it can be integrated into the top-level design by the
project lead. The Export Design Partition dialog box, available from the Project menu, allows designers
to export a design partition to a Quartus II Exported Partition File (.qxp) with a post-synthesis netlist, a
post-fit netlist, or both. The project lead then adds the .qxp to the top-level design to integrate the
partition.
A designer developing a timing-critical partition or who wants to optimize their partition on their own
would opt to export their completed partition with a post-fit netlist, allowing for the partition to more
reliably meet timing requirements after integration. In this case, you must ensure that resources are
allocated appropriately to avoid conflicts. If the placement and routing optimization can be performed in
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-36
Viewing the Contents of a Quartus II Exported Partition File (.qxp)
QII5V1
2015.05.04
the top-level design, exporting a post-synthesis netlist allows the most flexibility in the top-level design
and avoids potential placement or routing conflicts with other partitions.
When designing the partition logic to be exported into another project, you can add logic around the
design block to be exported as a design partition. You can instantiate additional design components for
the Quartus II project so that it matches the top-level design environment, especially in cases where you
do not have access to the full top-level design project. For example, you can include a top-level PLL in the
project, outside of the partition to be exported, so that you can optimize the design with information
about the frequency multipliers, phase shifts, compensation delays, and any other PLL parameters. The
software then captures timing and resource requirements more accurately while ensuring that the timing
analysis in the partition is complete and accurate. You can export the partition for the top-level design
without any auxiliary components that are instantiated outside the partition being exported.
If your design team uses makefiles and design partition scripts, the project lead can use the make
command with the master_makefile command created by the scripts to export the partitions and
create .qxp files. When a partition has been compiled and is ready to be integrated into the top-level
design, you can export the partition with option on the Export Design Partition dialog box, available
from the Project menu.
Related Information
Using a Team-Based Incremental Compilation Design Flow online help
Viewing the Contents of a Quartus II Exported Partition File (.qxp)
The QXP report allows you to view a summary of the contents in a .qxp when you open the file in the
Quartus II software. The .qxp is a binary file that contains compilation results so the file cannot be read in
a text editor. The QXP report opens in the main Quartus II window and contains summary information
including a list of the I/O ports, resource usage summary, and a list of the assignments used for the
exported partition.
Integrating Partitions into the Top-Level Design
To integrate a partition developed in a separate Quartus II project into the top-level design, you can
simply add the .qxp as a source file in your top-level design (just like a Verilog or VHDL source file). You
can also use the Import Design Partition dialog box to import the partition.
The .qxp contains the design block exported from the partition and has the same name as the partition.
When you instantiate the design block into a top-level design and include the .qxp as a source file, the
software adds the exported netlist to the database for the top-level design. The .qxp port names are case
sensitive if the original HDL of the partition was case sensitive.
When you use a .qxp as a source file in this way, you can choose whether you want the .qxp to be a
partition in the top-level design. If you do not designate the .qxp instance as a partition, the software
reuses just the post-synthesis compilation results from the .qxp, removes unconnected ports and unused
logic just like a regular source file, and then performs placement and routing.
If you assigned the .qxp instance as a partition, you can set the netlist type in the Design Partitions
Window to choose the level of results to preserve from the .qxp. To preserve the placement and routing
results from the exported partition, set the netlist type to Post-Fit for the .qxp partition in the top-level
design. If you assign the instance as a design partition, the partition boundary is preserved.
Related Information
Impact of Design Partitions on Design Optimization on page 3-22
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Integrating Assignments from the .qxp
3-37
Integrating Assignments from the .qxp
The Quartus II software filters assignments from .qxp files to include appropriate assignments in the toplevel design. The assignments in the .qxp are treated like assignments made in an HDL source file, and are
not listed in the Quartus II Settings File (.qsf) for the top-level design. Most assignments from the .qxp
can be overridden by assignments in the top-level design.
Design Partition Assignments Within the Exported Partition
Design partition assignments defined within a separate Quartus II project are not added to the top-level
design. All logic under the exported partition in the project hierarchy is treated as single instance in
the .qxp.
Synopsys Design Constraint Files for the Quartus II TimeQuest Timing Analyzer
Timing assignments made for the Quartus II TimeQuest analyzer in a Synopsys Design Constraint File
(.sdc) in the lower-level partition project are not added to the top-level design. Ensure that the top-level
design includes all of the timing requirements for the entire project.
Related Information
• Best Practices for Incremental Compilation Partitions and Floorplan Assignments documentation
on page 14-1
Global Assignments
The project lead should make all global project-wide assignments in the top-level design. Global
assignments from the exported partition's project are not added to the top-level design. When it is
possible for a particular constraint, the global assignment is converted to an instance-specific assignment
for the exported design partition.
LogicLock Region Assignments
The project lead typically creates LogicLock region assignments in the top-level design for any lower-level
partition designs where designer or IP providers plan to export post-fit information to be used in the toplevel design, to help avoid placement conflicts between partitions. When you use the .qxp as a source file,
LogicLock constraints from the exported partition are applied in the top-level design, but will not appear
in your .qsf file or LogicLock Regions window for you to view or edit. The LogicLock region itself is not
required to constrain the partition placement in the top-level design if the netlist type is set to Post-Fit,
because the netlist contains all the placement information.
Integrating Encrypted IP Cores from .qxp Files
Proper license information is required to compile encrypted IP cores. If an IP core is exported as a .qxp
from another Quartus II project, the top-level designer instantiating the .qxp must have the correct
license. The software requires a full license to generate an unrestricted programming file. If you do not
have a license, but the IP in the .qxp was compiled with OpenCore Plus hardware evaluation support, you
can generate an evaluation programming file without a license. If the IP supports OpenCore simulation
only, you can fully compile the design and generate a simulation netlist, but you cannot create
programming files unless you have a full license.
Advanced Importing Options
You can use advanced options in the Import Design Partition dialog box to integrate a partition
developed in a separate Quartus II project into the top-level design. The import process adds more
control than using the .qxp as a source file, and is useful only in the following circumstances:
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-38
QII5V1
2015.05.04
Importing LogicLock Assignments
• If you want LogicLock regions in your top-level design (.qsf)—If you have regions in your partitions
that are not also in the top-level design, the regions will be added to your .qsf during the import
process.
• If you want different settings or placement for different instantiations of the same entity—You can
control the setting import process with the advanced import options, and specify different settings for
different instances of the same .qxp design block.
When you use the Import Design Partition dialog box to integrate a partition into the top-level design,
the import process sets the partition’s netlist type to Imported in the Design Partitions window.
After you compile the entire design, if you make changes to the place-and-route results (such as
movement of an imported LogicLock region), use the Post-Fit netlist type on subsequent compilations.
To discard an imported netlist and recompile from source code, you can compile the partition with the
netlist type set to Source File and be sure to include the relevant source code in the top-level design. The
import process sets the partition’s Fitter Preservation Level to the setting with the highest degree of
preservation supported by the imported netlist. For example, if a post-fit netlist is imported with
placement information, the Fitter Preservation Level is set to Placement, but you can change it to the
Netlist Only value.
When you import a partition from a .qxp, the .qxp itself is not part of the top-level design because the
netlists from the file have been imported into the project database. Therefore if a new version of a .qxp is
exported, the top-level designer must perform another import of the .qxp.
When you import a partition into a top-level design with the Import Design Partition dialog box, the
software imports relevant assignments from the partition into the top-level design. If required, you can
change the way some assignments are imported, as described in the following subsections.
Related Information
• Netlist Type for Design Partitions on page 3-25
• Fitter Preservation Level for Design Partitions on page 3-27
Importing LogicLock Assignments
LogicLock regions are set to a fixed size when imported. If you instantiate multiple instances of a
subdesign in the top-level design, the imported LogicLock regions are set to a Floating location.
Otherwise, they are set to a Fixed location. You can change the location of LogicLock regions after they
are imported, or change them to a Floating location to allow the software to place each region but keep the
relative locations of nodes within the region wherever possible. To preserve changes made to a partition
after compilation, use the Post-Fit netlist type.
The LogicLock Member State assignment is set to Locked to signify that it is a preserved region.
LogicLock back-annotation and node location data is not imported because the .qxp contains all of the
relevant placement information. Altera strongly recommends that you do not add to or delete members
from an imported LogicLock region.
Related Information
Changing Partition Placement with LogicLock Changes on page 3-48
Advanced Import Settings
The Advanced Import Settings dialog box allows you to disable assignment import and specify
additional options that control how assignments and regions are integrated when importing a partition
into a top-level design, including how to resolve assignment conflicts.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Team-Based Design Optimization and Third-Party IP Delivery Scenarios
3-39
Related Information
Advanced Import Settings Dialog Box online help
Team-Based Design Optimization and Third-Party IP Delivery Scenarios
Using an Exported Partition to Send to a Design Without Including Source Files
Scenario background: A designer wants to produce a design block and needs to send out their design, but
to preserve their IP, they prefer to send a synthesized netlist instead of providing the HDL source code to
the recipient. You can use this flow to implement a black box.
Use this flow to package a full design as a single source file to send to an end customer or another design
location.
As the sender in this scenario perform the following steps to export a design block:
1. Provide the device family name to the recipient. If you send placement information with the
synthesized netlist, also provide the exact device selection so they can set up their project to match.
2. Create a black box wrapper file that defines the port interface for the design block and provide it to the
recipient for instantiating the block as an empty partition in the top-level design.
3. Create a Quartus II project for the design block, and complete the design.
4. Export the level of hierarchy into a single .qxp. Following a successful compilation of the project, you
can generate a .qxp from the GUI, the command-line, or with Tcl commands, as described in the
following:
• If you are using the Quartus II GUI, use the Export Design Partition dialog box.
• If you are using command-line executables, run quartus_cdb with the --incremental_compilation_export option.
• If you are using Tcl commands, use the following command: execute_flow incremental_compilation_export.
5. Select the option to include just the Post-synthesis netlist if you do not have to send placement
information. If the recipient wants to reproduce your exact Fitter results, you can select the Postfitting netlist option, and optionally enable Export routing.
6. If a partition contains sub-partitions, then the sub-partitions are automatically flattened and merged
into the partition netlist before exporting. You can change this behavior and preserve the sub-partition
hierarchy by turning off the Flatten sub-partitions option on the Export Design Partition dialog box.
Optionally, you can use the -dont_flatten sub-option for the export_partition Tcl command.
7. Provide the .qxp to the recipient. Note that you do not have to send any of your design source code.
As the recipient in this example, first create a Quartus II project for your top-level design and ensure that
your project targets the same device (or at least the same device family if the .qxp does not include
placement information), as specified by the IP designer sending the design block. Instantiate the design
block using the port information provided, and then incorporate the design block into a top-level design.
Add the .qxp from the IP designer as a source file in your Quartus II project to replace any empty wrapper
file. If you want to use just the post-synthesis information, you can choose whether you want the file to be
a partition in the top-level design. To use the post-fit information from the .qxp, assign the instance as a
design partition and set the netlist type to Post-Fit.
Related Information
• Creating Design Partitions on page 3-9
• Netlist Type for Design Partitions on page 3-25
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-40
Creating Precompiled Design Blocks (or Hard-Wired Macros) for Reuse
QII5V1
2015.05.04
Creating Precompiled Design Blocks (or Hard-Wired Macros) for Reuse
Scenario background: An IP provider wants to produce and sell an IP core for a component to be used in
higher-level systems. The IP provider wants to optimize the placement of their block for maximum
performance in a specific Altera device and then deliver the placement information to their end customer.
To preserve their IP, they also prefer to send a compiled netlist instead of providing the HDL source code
to their customer.
Use this design flow to create a precompiled IP block (sometimes known as a hard-wired macro) that can
be instantiated in a top-level design. This flow provides the ability to export a design block with
post-synthesis or placement (and, optionally, routing) information and to import any number of copies of
this pre-compiled block into another design.
The customer first specifies which Altera device is being used for this project and provides the design
specifications.
As the IP provider in this example, perform the following steps to export a preplaced IP core (or hard
macro):
1. Create a black box wrapper file that defines the port interface for the IP core and provide the file to the
customer to instantiate as an empty partition in the top-level design.
2. Create a Quartus II project for the IP core.
3. Create a LogicLock region for the design hierarchy to be exported.
Using a LogicLock region for the IP core allows the customer to create an empty placeholder region to
reserve space for the IP in the design floorplan and ensures that there are no conflicts with the toplevel design logic. Reserved space also helps ensure the IP core does not affect the timing performance
of other logic in the top-level design. Additionally, with a LogicLock region, you can preserve
placement either absolutely or relative to the origin of the associated region. This is important when
a .qxp is imported for multiple partition hierarchies in the same project, because in this case, the
location of at least one instance in the top-level design does not match the location used by the IP
provider.
4. If required, add any logic (such as PLLs or other logic defined in the customer’s top-level design)
around the design hierarchy to be exported. If you do so, create a design partition for the design
hierarchy that will exported as an IP core.
5. Optimize the design and close timing to meet the design specifications.
6. Export the level of hierarchy for the IP core into a single .qxp.
7. Provide the .qxp to the customer. Note that you do not have to send any of your design source code to
the customer; the design netlist and placement and routing information is contained within the .qxp.
Related Information
• Creating Design Partitions on page 3-55
• Netlist Type for Design Partitions on page 3-25
• Changing Partition Placement with LogicLock Changes on page 3-48
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Incorporate IP Core
3-41
Incorporate IP Core
As the customer in this example, incorporate the IP core in your design by performing the following steps:
1. Create a Quartus II project for the top-level design that targets the same device and instantiate a copy
or multiple copies of the IP core. Use a black box wrapper file to define the port interface of the IP
core.
2. Perform Analysis and Elaboration to identify the design hierarchy.
3. Create a design partition for each instance of the IP core with the netlist type set to Empty.
4. You can now continue work on your part of the design and accept the IP core from the IP provider
when it is ready.
5. Include the .qxp from the IP provider in your project to replace the empty wrapper-file for the IP
instance. Or, if you are importing multiple copies of the design block and want to import relative
placement, follow these additional steps:
a. Use the Import command to select each appropriate partition hierarchy. You can import a .qxp
from the GUI, the command-line, or with Tcl commands:
• If you are using the Quartus II GUI, use the Import Design Partition command.
• If you are using command-line executables, run quartus_cdb with the incremental_compilation_import option.
• If you are using Tcl commands, use the following command:execute_flow incremental_compilation_import.
b. When you have multiple instances of the IP block, you can set the imported LogicLock regions to
floating, or move them to a new location, and the software preserves the relative placement for each
of the imported modules (relative to the origin of the LogicLock region). Routing information is
preserved whenever possible.
Note: The Fitter ignores relative placement assignments if the LogicLock region’s location in the
top-level design is not compatible with the locations exported in the .qxp.
6. You can control the level of results preservation with the Netlist Type setting.
If the IP provider did not define a LogicLock region in the exported partition, the software preserves
absolute placement locations and this leads to placement conflicts if the partition is imported for more
than one instance
Designing in a Team-Based Environment
Scenario background: A project includes several lower-level design blocks that are developed separately by
different designers and instantiated exactly once in the top-level design.
This scenario describes how to use incremental compilation in a team-based design environment where
each designer has access to the top-level project framework, but wants to optimize their design in a
separate Quartus II project before integrating their design block into the top-level design.
As the project lead in this scenario, perform the following steps to prepare the top-level design:
1. Create a new Quartus II project to ultimately contain the full implementation of the entire design and
include a "skeleton" or framework of the design that defines the hierarchy for the subdesigns
implemented by separate designers. The top-level design implements the top-level entity in the design
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-42
QII5V1
2015.05.04
Exporting Your Partition
2.
3.
4.
5.
and instantiates wrapper files that represent each subdesign by defining only the port interfaces, but
not the implementation.
Make project-wide settings. Select the device, make global assignments such as device I/O ports, define
the top-level timing constraints, and make any global signal allocation constraints to specify which
signals can use global routing resources.
Make design partition assignments for each subdesign and set the netlist type for each design partition
to be imported to Empty in the Design Partitions window.
Create LogicLock regions to create a design floorplan for each of the partitions that will be developed
separately. This floorplan should consider the connectivity between partitions and estimates of the size
of each partition based on any initial implementation numbers and knowledge of the design specifica‐
tions.
Provide the top-level project framework to partition designers using one of the following procedures:
• Allow access to the full project for all designers through a source control system. Each designer can
check out the projects files as read-only and work on their blocks independently. This design flow
provides each designer with the most information about the full design, which helps avoid resource
conflicts and makes design integration easy.
• Provide a copy of the top-level Quartus II project framework for each designer. You can use the
Copy Project command on the Project menu or create a project archive.
Exporting Your Partition
As the designer of a lower-level design block in this scenario, design and optimize your partition in your
copy of the top-level design, and then follow these steps when you have achieved the desired compilation
results:
1. On the Project menu, click Export Design Partition.
2. In the Export Design Partition dialog box, choose the netlist(s) to export. You can export a Postsynthesis netlist if placement or performance preservation is not required, to provide the most
flexibility for the Fitter in the top-level design. Select Post-fit netlist to preserve the placement and
performance of the lower-level design block, and turn on Export routing to include the routing
information, if required. One .qxp can include both post-synthesis and post-fitting netlists.
3. Provide the .qxp to the project lead.
Integrating Your Partitions
Finally, as the project lead in this scenario, perform these steps to integrate the .qxp files received from
designers of each partition:
1. Add the .qxp as a source file in the Quartus II project, to replace any empty wrapper file for the
previously Empty partition.
2. Change the netlist type for the partition from Empty to the required level of results preservation.
Enabling Designers on a Team to Optimize Independently
Scenario background: A project consists of several lower-level design blocks that are developed separately
by different designers who do not have access to a shared top-level project framework. This scenario is
similar to creating precompiled design blocks for resuse, but assumes that there are several design blocks
being developed independently (instead of just one IP block), and the project lead can provide some
information about the design to the individual designers. If the designers have shared access to the toplevel design, use the instructions for designing in a team-based environment.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Preparing Your Top-level Design
3-43
This scenario assumes that there are several design blocks being developed independently (instead of just
one IP block), and the project lead can provide some information about the design to the individual
designers.
This scenario describes how to use incremental compilation in a team-based design environment where
designers or IP developers want to fully optimize the placement and routing of their design independently
in a separate Quartus II project before sending the design to the project lead. This design flow requires
more planning and careful resource allocation because design blocks are developed independently.
Related Information
• Creating Precompiled Design Blocks (or Hard-Wired Macros) for Reuse on page 3-40
• Designing in a Team-Based Environment on page 3-41
Preparing Your Top-level Design
As the project lead in this scenario, perform the following steps to prepare the top-level design:
1. Create a new Quartus II project to ultimately contain the full implementation of the entire design and
include a “skeleton” or framework of the design that defines the hierarchy for the subdesigns
implemented by separate designers. The top-level design implements the top-level entity in the design
and instantiates wrapper files that represent each subdesign by defining only the port interfaces but not
the implementation.
2. Make project-wide settings. Select the device, make global assignments such as device I/O ports, define
the top-level timing constraints, and make any global signal constraints to specify which signals can
use global routing resources.
3. Make design partition assignments for each subdesign and set the netlist type for each design partition
to be imported to Empty in the Design Partitions window.
4. Create LogicLock regions. This floorplan should consider the connectivity between partitions and
estimates of the size of each partition based on any initial implementation numbers and knowledge of
the design specifications.
5. Provide the constraints from the top-level design to partition designers using one of the following
procedures.
• Use design partition scripts to pass constraints and generate separate Quartus II projects. On the
Project menu, use the Generate Design Partition Scripts command, or run the script generator
from a Tcl or command prompt. Make changes to the default script options as required for your
project. Altera recommends that you pass all the default constraints, including LogicLock regions,
for all partitions and virtual pin location assignments. If partitions have not already been created by
the other designers, use the partition script to set up the projects so that you can easily take
advantage of makefiles. Provide each partition designer with the Tcl file to create their project with
the appropriate constraints. If you are using makefiles, provide the makefile for each partition.
• Use documentation or manually-created scripts to pass all constraints and assignments to each
partition designer.
Exporting Your Design
As the designer of a lower-level design block in this scenario, perform the appropriate set of steps to
successfully export your design, whether the design team is using makefiles or exporting and importing
the design manually.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-44
QII5V1
2015.05.04
Exporting Without Makefiles
If you are using makefiles with the design partition scripts, perform the following steps:
1. Use the make command and the makefile provided by the project lead to create a Quartus II project
with all design constraints, and compile the project.
2. The information about which source file should be associated with which partition is not available to
the software automatically, so you must specify this information in the makefile. You must specify the
dependencies before the software rebuilds the project after the initial call to the makefile.
3. When you have achieved the desired compilation results and the design is ready to be imported into
the top-level design, the project lead can use the master_makefile command to export this partition
and create a .qxp, and then import it into the top-level design.
Exporting Without Makefiles
If you are not using makefiles, perform the following steps:
1. If you are using design partition scripts, source the Tcl script provided by the Project Lead to create a
project with the required settings:
• To source the Tcl script in the Quartus II software, on the Tools menu, click Utility Windows to
open the Tcl console. Navigate to the script’s directory, and type the following command: source
<filename>.
• To source the Tcl script at the system command prompt, type the following command:
quartus_cdb -t <filename>.tcl
2. If you are not using design partition scripts, create a new Quartus II project for the subdesign, and
then apply the following settings and constraints to ensure successful integration:
3.
4.
5.
6.
• Make LogicLock region assignments and global assignments (including clock settings) as specified
by the project lead.
• Make Virtual Pin assignments for ports which represent connections to core logic instead of
external device pins in the top-level design.
• Make floorplan location assignments to the Virtual Pins so they are placed in their corresponding
regions as determined by the top-level design. This provides the Fitter with more information about
the timing constraints between modules. Alternatively, you can apply timing I/O constraints to the
paths that connect to virtual pins.
Proceed to compile and optimize the design as needed.
When you have achieved the desired compilation results, on the Project menu, click Export Design
Partition.
In the Export Design Partition dialog box, choose the netlist(s) to export. You can export a Postsynthesis netlist instead if placement or performance preservation is not required, to provide the most
flexibility for the Fitter in the top-level design. Select Post-fit to preserve the placement and perform‐
ance of the lower-level design block, and turn on Export routing to include the routing information, if
required. One .qxp can include both post-synthesis and post-fitting netlists.
Provide the .qxp to the project lead.
Importing Your Design
Finally, as the project lead in this scenario, perform the appropriate set of steps to import the .qxp files
received from designers of each partition.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Importing Without Makefiles
3-45
If you are using makefiles with the design partition scripts, perform the following steps:
1. Use the master_makefile command to export each partition and create .qxp files, and then import
them into the top-level design.
2. The software does not have all the information about which source files should be associated with
which partition, so you must specify this information in the makefile. The software cannot rebuild the
project if source files change unless you specify the dependencies.
Importing Without Makefiles
If you are not using makefiles, perform the following steps:
1. Add the .qxp as a source file in the Quartus II project, to replace any empty wrapper file for the
previously Empty partition.
2. Change the netlist type for the partition from Empty to the required level of results preservation.
Resolving Assignment Conflicts During Integration
When integrating lower-level design blocks, the project lead may notice some assignment conflicts. This
can occur, for example, if the lower-level design block designers changed their LogicLock regions to
account for additional logic or placement constraints, or if the designers applied I/O port timing
constraints that differ from constraints added to the top-level design by the project lead. The project lead
can address these conflicts by explicitly importing the partitions into the top-level design, and using
options in the Advanced Import Settings dialog box. After the project lead obtains the .qxp for each
lower-level design block from the other designers, use the Import Design Partition command on the
Project menu and specify the partition in the top-level design that is represented by the lower-level design
block .qxp. Repeat this import process for each partition in the design. After you have imported each
partition once, you can select all the design partitions and use the Reimport using latest import files at
previous locations option to import all the files from their previous locations at one time. To address
assignment conflicts, the project lead can take one or both of the following actions:
• Allow new assignments to be imported
• Allow existing assignments to be replaced or updated
When LogicLock region assignment conflicts occur, the project lead may take one of the following
actions:
• Allow the imported region to replace the existing region
• Allow the imported region to update the existing region
• Skip assignment import for regions with conflicts
If the placement of different lower-level design blocks conflict, the project lead can also set the set the
partition’s Fitter Preservation Level to Netlist Only, which allows the software to re-perform placement
and routing with the imported netlist.
Importing a Partition to be Instantiated Multiple Times
In this variation of the design scenario, one of the lower-level design blocks is instantiated more than once
in the top-level design. The designer of the lower-level design block may want to compile and optimize
the entity once under a partition, and then import the results as multiple partitions in the top-level design.
If you import multiple instances of a lower-level design block into the top-level design, the imported
LogicLock regions are automatically set to Floating status.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-46
Performing Design Iterations With Lower-Level Partitions
QII5V1
2015.05.04
If you resolve conflicts manually, you can use the import options and manual LogicLock assignments to
specify the placement of each instance in the top-level design.
Performing Design Iterations With Lower-Level Partitions
Scenario background: A project consists of several lower-level subdesigns that have been exported from
separate Quartus II projects and imported into the top-level design. In this example, integration at the top
level has failed because the timing requirements are not met. The timing requirements might have been
met in each individual lower-level project, but critical inter-partition paths in the top-level design are
causing timing requirements to fail.
After trying various optimizations in the top-level design, the project lead determines that the design
cannot meet the timing requirements given the current partition placements that were imported. The
project lead decides to pass additional information to the lower-level partitions to improve the placement.
Use this flow if you re-optimize partitions exported from separate Quartus II projects by incorporating
additional constraints from the integrated top-level design.
Providing the Complete Top-Level Project Framework
The best way to provide top-level design information to designers of lower-level partitions is to provide
the complete top-level project framework using the following steps:
1. For all partitions other than the one(s) being optimized by a designer(s) in a separate Quartus II
project(s), set the netlist type to Post-Fit.
2. Make the top-level design directory available in a shared source control system, if possible. Otherwise,
copy the entire top-level design project directory (including database files), or create a project archive
including the post-compilation database.
3. Provide each partition designer with a checked-out version or copy of the top-level design.
4. The partition designers recompile their designs within the new project framework that includes the
rest of the design's placement and routing information as well top-level resource allocations and
assignments, and optimize as needed.
5. When the results are satisfactory and the timing requirements are met, export the updated partition as
a .qxp.
Providing Information About the Top-Level Framework
If this design flow is not possible, you can generate partition-specific scripts for individual designs to
provide information about the top-level project framework with these steps:
1. In the top-level design, on the Project menu, click Generate Design Partition Scripts, or launch the
script generator from Tcl or the command line.
2. If lower-level projects have already been created for each partition, you can turn off the Create lowerlevel project if one does not exist option.
3. Make additional changes to the default script options, as necessary. Altera recommends that you pass
all the default constraints, including LogicLock regions, for all partitions and virtual pin location
assignments. Altera also recommends that you add a maximum delay timing constraint for the virtual
I/O connections in each partition.
4. The Quartus II software generates Tcl scripts for all partitions, but in this scenario, you would focus on
the partitions that make up the cross-partition critical paths. The following assignments are important
in the script:
• Virtual pin assignments for module pins not connected to device I/O ports in the top-level design.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Creating a Design Floorplan With LogicLock Regions
3-47
• Location constraints for the virtual pins that reflect the initial top-level placement of the pin’s
source or destination. These help make the lower-level placement “aware” of its surroundings in the
top-level design, leading to a greater chance of timing closure during integration at the top level.
• INPUT_MAX_DELAY and OUTPUT_MAX_DELAY timing constraints on the paths to and from the I/O
pins of the partition. These constrain the pins to optimize the timing paths to and from the pins.
5. The partition designers source the file provided by the project lead.
• To source the Tcl script from the Quartus II GUI, on the Tools menu, click Utility Windows and
open the Tcl console. Navigate to the script’s directory, and type the following command:
source <filename>
• To source the Tcl script at the system command prompt, type the following command:
quartus_cdb -t <filename>.tcl
6. The partition designers recompile their designs with the new project information or assignments and
optimize as needed. When the results are satisfactory and the timing requirements are met, export the
updated partition as a .qxp.
The project lead obtains the updated .qxp files from the partition designers and adds them to the toplevel design. When a new .qxp is added to the files list, the software will detect the change in the
“source file” and use the new .qxp results during the next compilation. If the project uses the advanced
import flow, the project lead must perform another import of the new .qxp.
You can now analyze the design to determine whether the timing requirements have been achieved.
Because the partitions were compiled with more information about connectivity at the top level, it is
more likely that the inter-partition paths have improved placement which helps to meet the timing
requirements.
Creating a Design Floorplan With LogicLock Regions
A floorplan represents the layout of the physical resources on the device. Creating a design floorplan, or
floorplanning, describe the process of mapping the logical design hierarchy onto physical regions in the
device floorplan. After you have partitioned the design, you can create floorplan location assignments for
the design to improve the quality of results when using the incremental compilation design flow. Creating
a design floorplan is not a requirement to use an incremental compilation flow, but it is recommended in
certain cases. Floorplan location planning can be important for a design that uses incremental
compilation for the following reasons:
• To avoid resource conflicts between partitions, predominantly when partitions are imported from
another Quartus II project
• To ensure a good quality of results when recompiling individual timing-critical partitions
Design floorplan assignments prevent the situation in which the Fitter must place a partition in an area of
the device where most resources are already used by other partitions. A physical region assignment
provides a reasonable region to re-place logic after a change, so the Fitter does not have to scatter logic
throughout the available space in the device.
Floorplan assignments are not required for non-critical partitions compiled as part of the top-level design.
The logic for partitions that are not timing-critical (such as simple top-level glue logic) can be placed
anywhere in the device on each recompilation, if that is best for your design.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-48
Creating and Manipulating LogicLock Regions
QII5V1
2015.05.04
The simplest way to create a floorplan for a partitioned design is to create one LogicLock region per
partition (including the top-level partition). If you have a compilation result for a partitioned design with
no LogicLock regions, you can use the Chip Planner with the Design Partition Planner to view the
partition placement in the device floorplan. You can draw regions in the floorplan that match the general
location and size of the logic in each partition. Or, initially, you can set each region with the default
settings of Auto size and Floating location to allow the Quartus II software to determine the preliminary
size and location for the regions. Then, after compilation, use the Fitter-determined size and origin
location as a starting point for your design floorplan. Check the quality of results obtained for your
floorplan location assignments and make changes to the regions as needed. Alternatively, you can
perform synthesis, and then set the regions to the required size based on resource estimates. In this case,
use your knowledge of the connections between partitions to place the regions in the floorplan.
Once you have created an initial floorplan, you can refine the region using tools in the Quartus II
software. You can also use advanced techniques such as creating non-rectangular regions by merging
LogicLock regions.
You can use the Incremental Compilation Advisor to check that your LogicLock regions meet Altera’s
guidelines.
Related Information
Incremental Compilation Advisor on page 3-24
Best Practices for Incremental Compilation Partitions and Floorplan Assignments documentation on
page 14-1
Creating and Manipulating LogicLock Regions
Options in the LogicLock Regions Properties dialog box, available from the Assignments menu, allow
you to enter specific sizing and location requirements for a region. You can also view and refine the size
and location of LogicLock regions in the Quartus II Chip Planner. You can select a region in the graphical
interface in the Chip Planner and use handles to move or resize the region.
Options in the Layer Settings panel in the Chip Planner allow you to create, delete, and modify tasks to
determine which objects, including LogicLock regions and design partitions, to display in the Chip
Planner.
Related Information
Creating and Manipulating LogicLock Regions online help
Changing Partition Placement with LogicLock Changes
When a partition is assigned to a LogicLock region as part of a design floorplan, you can modify the
placement of a post-fit partition by moving the LogicLock region. Most assignment changes do not
initiate a recompilation of a partition if the netlist type specifies that Fitter results should be preserved. For
example, changing a pin assignment does not initiate a recompilation; therefore, the design does not use
the new pin assignment unless you change the netlist type to Post Synthesis or Source File.
Similarly, if a partition’s placement is preserved, and the partition is assigned to a LogicLock region, the
Fitter always reuses the corresponding LogicLock region size specified in the post-fit netlist. That is,
changes to the LogicLock Size setting do not initiate refitting if a partition’s placement is preserved with
the Post-Fit netlist type, or with .qxp that includes post-fit information.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Incremental Compilation Restrictions
3-49
However, you can use the LogicLock Origin location assignment to change or fine-tune the previous
Fitter results. When you change the Origin setting for a region, the Fitter can move the region in the
following manner, depending upon how the placement is preserved for that region's members:
• When you set a new region Origin, the Fitter uses the new origin and replaces the logic, preserving the
relative placement of the member logic.
• When you set the region Origin to Floating, the following conditions apply:
• If the region’s member placement is preserved with an imported partition, the Fitter chooses a new
Origin and re-places the logic, preserving the relative placement of the member logic within the
region.
• If the region’s member placement is preserved with a Post-Fit netlist type, the Fitter does not
change the Origin location, and reuses the previous placement results.
Related Information
What Changes Initiate the Automatic Resynthesis of a Partition? on page 3-29
Incremental Compilation Restrictions
When Timing Performance May Not Be Preserved Exactly
Timing performance might change slightly in a partition with placement and routing preserved when
other partitions are incorporated or re-placed and routed. Timing changes are due to changes in parasitic
loading or crosstalk introduced by the other (changed) partitions. These timing changes are very small,
typically less than 30 ps on a timing path. Additional fan-out on routing lines when partitions are added
can also degrade timing performance.
To ensure that a partition continues to meet its timing requirements when other partitions change, a very
small timing margin might be required. The Fitter automatically works to achieve such margin when
compiling any design, so you do not need to take any action.
When Placement and Routing May Not Be Preserved Exactly
The Fitter may have to refit affected nodes if the two nodes are assigned to the same location, due to
imported netlists or empty partitions set to re-use a previous post-fit netlist. There are two cases in which
routing information cannot be preserved exactly. First, when multiple partitions are imported, there
might be routing conflicts because two lower-level blocks could be using the same routing wire, even if the
floorplan assignments of the lower-level blocks do not overlap. These routing conflicts are automatically
resolved by the Quartus II Fitter re-routing on the affected nets. Second, if an imported LogicLock region
is moved in the top-level design, the relative placement of the nodes is preserved but the routing cannot
be preserved, because the routing connectivity is not perfectly uniform throughout a device.
Using Incremental Compilation With Quartus II Archive Files
The post-synthesis and post-fitting netlist information for each design partition is stored in the project
database, the incremental_db directory. When you archive a project, the database information is not
included in the archive unless you include the compilation database in the .qar file.
If you want to re-use post-synthesis or post-fitting results, include the database files in the Archive
Project dialog box so compilation results are preserved. Click Advanced, and choose a file set that
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-50
QII5V1
2015.05.04
Formal Verification Support
includes the compilation database, or turn on Incremental compilation database files to create a Custom
file set.
When you include the database, the file size of the .qar archive file may be significantly larger than an
archive without the database.
The netlist information for imported partitions is already saved in the corresponding .qxp. Imported .qxp
files are automatically saved in a subdirectory called imported_partitions, so you do not need to archive
the project database to keep the results for imported partitions. When you restore a project archive, the
partition is automatically reimported from the .qxp in this directory if it is available.
For new device families with advanced support, a version-compatible database might not be available. In
this case, the archive will not include the compilation database. If you require the database files to
reproduce the compilation results in the same Quartus II version, you can use the following commandline option to archive a full database:
quartus_sh --archive -use_file_set full_db [-revision <revision name>]<project name>
Formal Verification Support
You cannot use design partitions for incremental compilation if you are creating a netlist for a formal
verification tool.
SignalProbe Pins and Engineering Change Orders
ECO and SignalProbe changes are performed only during ECO and SignalProbe compilations. Other
compilation flows do not preserve these netlist changes.
When incremental compilation is turned on and your design contains one or more design partitions,
partition boundaries are ignored while making ECO changes and SignalProbe signal settings. However,
the presence of ECO and/or SignalProbe changes does not affect partition boundaries for incremental
compilation. During subsequent compilations, ECO and SignalProbe changes are not preserved regardless
of the Netlist Type or Fitter Preservation Level settings. To recover ECO changes and SignalProbe
signals, you must use the Change Manager to re-apply the ECOs after compilation.
For partitions developed independently in separate Quartus II projects, the exported netlist includes all
currently saved ECO changes and SignalProbe signals. If you make any ECO or SignalProbe changes that
affect the interface to the lower-level partition, the software issues a warning message during the export
process that this netlist does not work in the top-level design without modifying the top-level HDL code
to reflect the lower-level change. After integrating the .qxp partition into the top-level design, the ECO
changes will not appear in the Change Manager.
Related Information
• Quick Design Debugging Using SignalProbe documentation
• Engineering Change Management with the Chip Planner documentation
SignalTap II Logic Analyzer in Exported Partitions
You can use the SignalTap II Embedded Logic Analyzer in any project that you can compile and program
into an Altera device.
When incremental compilation is turned on, debugging logic is added to your design incrementally and
you can tap post-fitting nodes and modify triggers and configuration without recompiling the full design.
Use the appropriate filter in the Node Finder to find your node names. Use SignalTap II: post-fitting if
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
External Logic Analyzer Interface in Exported Partitions
3-51
the netlist type is Post-Fit to incrementally tap node names in the post-fit netlist database. Use SignalTap
II: pre-synthesis if the netlist type is Source File to make connections to the source file (pre-synthesis)
node names when you synthesize the partition from the source code.
If incremental compilation is turned off, the debugging logic is added to the design during Analysis and
Elaboration, and you cannot tap post-fitting nodes or modify debug settings without fully compiling the
design.
For design partitions that are being developed independently in separate Quartus II projects and contain
the logic analyzer, when you export the partition, the Quartus II software automatically removes the
SignalTap II logic analyzer and related SLD_HUB logic. You can tap any nodes in a Quartus II project,
including nodes within .qxp partitions. Therefore, you can use the logic analyzer within the full top-level
design to tap signals from the .qxp partition.
You can also instantiate the SignalTap II IP core directly in your lower-level design (instead of using
an .stp file) and export the entire design to the top level to include the logic analyzer in the top-level
design.
Related Information
Design Debugging Using the SignalTap II Embedded Logic Analyzer documentation
External Logic Analyzer Interface in Exported Partitions
You can use the Logic Analyzer Interface in any project that you can compile and program into an Altera
device. You cannot export a partition that uses the Logic Analyzer Interface. You must disable the Logic
Analyzer Interface feature and recompile the design before you export the design as a partition.
Related Information
In-System Debugging Using External Logic Analyzers documentation
Assignments Made in HDL Source Code in Exported Partitions
Assignments made with I/O primitives or the altera_attribute HDL synthesis attribute in lower-level
partitions are passed to the top-level design, but do not appear in the top-level .qsf file or Assignment
Editor. These assignments are considered part of the source netlist files. You can override assignments
made in these source files by changing the value with an assignment in the top-level design.
Design Partition Script Limitations
Related Information
Generating Design Partition Scripts on page 3-35
Warnings About Extra Clocks Due to Design Partition Scripts
The generated scripts include applicable clock information for all clock signals in the top-level design.
Some of those clocks may not exist in the lower-level projects, so you may see warning messages related to
clocks that do not exist in the project. You can ignore these warnings or edit your constraints so the
messages are not generated.
Synopsys Design Constraint Files for the TimeQuest Timing Analyzer in Design Partition Scripts
After you have compiled a design using TimeQuest constraints, and the timing assignments option is
turned on in the scripts, a separate Tcl script is generated to create an .sdc file for each lower-level project.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-52
QII5V1
2015.05.04
Wildcard Support in Design Partition Scripts
This script includes only clock constraints and minimum and maximum delay settings for the TimeQuest
Timing Analyzer.
Note: PLL settings and timing exceptions are not passed to lower-level designs in the scripts.
Related Information
• Best Practices for Incremental Compilation Partitions and Floorplan Assignments documentation
on page 14-1
Wildcard Support in Design Partition Scripts
When applying constraints with wildcards, note that wildcards are not analyzed across hierarchical
boundaries. For example, an assignment could be made to these nodes: Top|A:inst|B:inst|*, where A
and B are lower-level partitions, and hierarchy B is a child of A, that is B is instantiated in hierarchy A. This
assignment is applied to modules A, B, and all children instances of B. However, the assignment Top|
A:inst|B:inst* is applied to hierarchy A, but is not applied to the B instances because the single level of
hierarchy represented by B:inst* is not expanded into multiple levels of hierarchy. To avoid this issue,
ensure that you apply the wildcard to the hierarchical boundary if it should represent multiple levels of
hierarchy.
When using the wildcard to represent a level of hierarchy, only single wildcards are supported. This
means assignments such as Top|A:inst|*|B:inst|* are not supported. The Quartus II software issues a
warning in these cases.
Derived Clocks and PLLs in Design Partition Scripts
If a clock in the top level is not directly connected to a pin of a lower-level partition, the lower-level
partition does not receive assignments and constraints from the top-level pin in the design partition
scripts.
This issue is of particular importance for clock pins that require timing constraints and clock group
settings. Problems can occur if your design uses logic or inversion to derive a new clock from a clock
input pin. Make appropriate timing assignments in your lower-level Quartus II project to ensure that
clocks are not unconstrained.
If the lower-level design uses the top-level project framework from the project lead, the design will have
all the required information about the clock and PLL settings. Otherwise, if you use a PLL in your toplevel design and connect it to lower-level partitions, the lower-level partitions do not have information
about the multiplication or phase shift factors in the PLL. Make appropriate timing assignments in your
lower-level Quartus II project to ensure that clocks are not unconstrained or constrained with the
incorrect frequency. Alternatively, you can manually duplicate the top-level derived clock logic or PLL in
the lower-level design file to ensure that you have the correct multiplication or phase-shift factors,
compensation delays and other PLL parameters for complete and accurate timing analysis. Create a
design partition for the rest of the lower-level design logic for export to the top level. When the lower-level
design is complete, export only the partition that contains the relevant logic.
Pin Assignments for GXB and LVDS Blocks in Design Partition Scripts
Pin assignments for high-speed GXB transceivers and hard LVDS blocks are not written in the scripts.
You must add the pin assignments for these hard IP blocks in the lower-level projects manually.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Virtual Pin Timing Assignments in Design Partition Scripts
3-53
Virtual Pin Timing Assignments in Design Partition Scripts
Design partition scripts use INPUT_MAX_DELAY and OUTPUT_MAX_DELAY assignments to specify interpartition delays associated with input and output pins, which would not otherwise be visible to the
project. These assignments require that the software specify the clock domain for the assignment and set
this clock domain to ” * ”.
This clock domain assignment means that there may be some paths constrained and reported by the
timing analysis engine that are not required.
To restrict which clock domains are included in these assignments, edit the generated scripts or change
the assignments in your lower-level Quartus II project. In addition, because there is no known clock
associated with the delay assignments, the software assumes the worst-case skew, which makes the paths
seem more timing critical than they are in the top-level design. To make the paths appear less
timing-critical, lower the delay values from the scripts. If required, enter negative numbers for input and
output delay values.
Top-Level Ports that Feed Multiple Lower-Level Pins in Design Partition Scripts
When a single top-level I/O port drives multiple pins on a lower-level module, it unnecessarily restricts
the quality of the synthesis and placement at the lower-level. This occurs because in the lower-level
design, the software must maintain the hierarchical boundary and cannot use any information about pins
being logically equivalent at the top level. In addition, because I/O constraints are passed from the toplevel pin to each of the children, it is possible to have more pins in the lower level than at the top level.
These pins use top-level I/O constraints and placement options that might make them impossible to place
at the lower level. The software avoids this situation whenever possible, but it is best to avoid this design
practice to avoid these potential problems. Restructure your design so that the single I/O port feeds the
design partition boundary and the single connection is split into multiple signals within the lower-level
partition.
Restrictions on IP Core Partitions
The Quartus II software does not support partitions for IP core instantiations. If you use the parameter
editor to customize an IP core variation, the IP core generated wrapper file instantiates the IP core. You
can create a partition for the IP core generated wrapper file.
The Quartus II software does not support creating a partition for inferred IP cores (that is, where the
software infers an IP core to implement logic in your design). If you have a module or entity for the logic
that is inferred, you can create a partition for that hierarchy level in the design.
The Quartus II software does not support creating a partition for any Quartus II internal hierarchy that is
dynamically generated during compilation to implement the contents of an IP core.
Register Packing and Partition Boundaries
The Quartus II software performs register packing during compilation automatically. However, when
incremental compilation is enabled, logic in different partitions cannot be packed together because
partition boundaries might prevent cross-boundary optimization. This restriction applies to all types of
register packing, including I/O cells, DSP blocks, sequential logic, and unrelated logic. Similarly, logic
from two partitions cannot be packed into the same ALM.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-54
QII5V1
2015.05.04
I/O Register Packing
I/O Register Packing
Cross-partition register packing of I/O registers is allowed in certain cases where your input and output
pins exist in the top-level hierarchy (and the Top partition), but the corresponding I/O registers exist in
other partitions.
The following specific circumstances are required for input pin cross-partition register packing:
• The input pin feeds exactly one register.
• The path between the input pin and register includes only input ports of partitions that have one fanout each.
The following specific circumstances are required for output register cross-partition register packing:
• The register feeds exactly one output pin.
• The output pin is fed by only one signal.
• The path between the register and output pin includes only output ports of partitions that have one
fan-out each.
Output pins with an output enable signal cannot be packed into the device I/O cell if the output enable
logic is part of a different partition from the output register. To allow register packing for output pins with
an output enable signal, structure your HDL code or design partition assignments so that the register and
tri-state logic are defined in the same partition.
Bidirectional pins are handled in the same way as output pins with an output enable signal. If the registers
that need to be packed are in the same partition as the tri-state logic, you can perform register packing.
The restrictions on tri-state logic exist because the I/O atom (device primitive) is created as part of the
partition that contains tri-state logic. If an I/O register and its tri-state logic are contained in the same
partition, the register can always be packed with tri-state logic into the I/O atom. The same cross-partition
register packing restrictions also apply to I/O atoms for input and output pins. The I/O atom must feed
the I/O pin directly with exactly one signal. The path between the I/O atom and the I/O pin must include
only ports of partitions that have one fan-out each.
Related Information
• Best Practices for Incremental Compilation Partitions and Floorplan Assignments documentation
on page 14-1
Scripting Support
You can run procedures and make settings described in this chapter in a Tcl script or at a command-line
prompt.
Tcl Scripting and Command-Line Examples
The ::quartus::incremental_compilation Tcl package contains a set of functions for manipulating
design partitions and settings related to the incremental compilation feature.
Related Information
• ::quartus::incremental_compilation online help
• Quartus II Software Scripting Support website
Scripting support information, design examples, and training
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Creating Design Partitions
3-55
• Tcl Scripting documentation
• Command-Line Scripting documentation
Creating Design Partitions
To create a design partition to a specified hierarchy name, use the following command:
Example 3-1: Create Design Partition
create_partition [-h | -help] [-long_help] -contents
<hierarchy name> -partition <partition name>
Table 3-4: Tcl Script Command: create_partition
Argument
Description
Short help
-h | -help
-long_help
Long help with examples and possible return
values
-contents <hierarchy name>
Partition contents (hierarchy assigned to
Partition)
-partition <partition name>
Partition name
Enabling or Disabling Design Partition Assignments During Compilation
To direct the Quartus II Compiler to enable or disable design partition assignments during compilation,
use the following command:
Example 3-2: Enable or Disable Partition Assignments During Compilation
set_global_assignment -name IGNORE_PARTITIONS <value>
Table 3-5: Tcl Script Command: set_global_assignment
Value
OFF
Description
The Quartus II software recognizes the design
partitions assignments set in the current
Quartus II project and recompiles the partition
in subsequent compilations depending on their
netlist status.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-56
QII5V1
2015.05.04
Setting the Netlist Type
Value
Description
The Quartus II software does not recognize
design partitions assignments set in the current
Quartus II project and performs a compilation
without regard to partition boundaries or
netlists.
ON
Setting the Netlist Type
To set the partition netlist type, use the following command:
Example 3-3: Set Partition Netlist Type
set_global_assignment -name PARTITION_NETLIST_TYPE <value>
-section_id <partition name>
Note: The PARTITION_NETLIST_TYPE command accepts the following values: SOURCE,
POST_SYNTH, POST_FIT, and EMPTY.
Setting the Fitter Preservation Level for a Post-fit or Imported Netlist
To set the Fitter Preservation Level for a post-fit or imported netlist, use the following command:
Example 3-4: Set Fitter Preservation Level
set_global_assignment -name PARTITION_FITTER_PRESERVATION_LEVEL
<value> -section_id <partition name>
Note: The PARTITION_FITTER_PRESERVATION command accepts the following values:
NETLIST_ONLY, PLACEMENT, and PLACEMENT_AND_ROUTING.
Preserving High-Speed Optimization
To preserve high-speed optimization for tiles contained within the selected partition, use the following
command:
Example 3-5: Preserve High-Speed Optimization
set_global_assignment -name PARTITION_PRESERVE_HIGH_SPEED_TILES_ON
Specifying the Software Should Use the Specified Netlist and Ignore Source File Changes
To specify that the software should use the specified netlist and ignore source file changes, even if the
source file has changed since the netlist was created, use the following command:
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Reducing Opening a Project, Creating Design Partitions, andPerforming an Initial
Compilation
3-57
Example 3-6: Specify Netlist and Ignore Source File Changes
set_global_assignment -name PARTITION_IGNORE_SOURCE_FILE_CHANGES ON
-section_id "<partition name>"
Reducing Opening a Project, Creating Design Partitions, andPerforming an Initial Compilation
Scenario background: You open a project called AB_project, set up two design partitions, entities A and
B, and then perform an initial full compilation.
Example 3-7: Set Up and Compile AB_project
set project AB_project
load_package incremental_compilation
load_package flow
project_open $project
# Ensure that design partition assignments are not ignored
set_global_assignment -name IGNORE_PARTITIONS \ OFF
# Set up the partitions
create_partition -contents A -name "Partition_A"
create_partition -contents B -name "Partition_B"
# Set the netlist types to post-fit for subsequent
# compilations (all partitions are compiled during the
# initial compilation since there are no post-fit netlists)
set_partition -partition "Partition_A" -netlist_type POST_FIT
set_partition -partition "Partition_B" -netlist_type POST_FIT
# Run initial compilation
export_assignments
execute_flow -full_compile
project_close
Optimizing the Placement for a Timing-Critical Partition
Scenario background: You have run the initial compilation shown in the example script below. You would
like to apply Fitter optimizations, such as physical synthesis, only to partition A. No changes have been
made to the HDL files. To ensure the previous compilation result for partition B is preserved, and to
ensure that Fitter optimizations are applied to the post-synthesis netlist of partition A, set the netlist type
of B to Post-Fit (which was already done in the initial compilation, but is repeated here for safety), and
the netlist type of A to Post-Synthesis, as shown in the following example:
Example 3-8: Fitter Optimization for AB_project
set project AB_project
load_package
load_package
load_package
project_open
flow
incremental_compilation
project
$project
# Turn on Physical Synthesis Optimization
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-58
QII5V1
2015.05.04
Generating Design Partition Scripts
set_high_effort_fmax_optimization_assignments
# For A, set the netlist type to post-synthesis
set_partition -partition "Partition_A" -netlist_type POST_SYNTH
# For B, set the netlist type to post-fit
set_partition -partition "Partition_B" -netlist_type POST_FIT
# Also set Top to post-fit
set_partition -partition "Top" -netlist_type POST_FIT
# Run incremental compilation
export_assignments
execute_flow -full_compile
project_close
Generating Design Partition Scripts
To generate design partition scripts, use the following script:
Example 3-9: Generate Partition Script
# load required package
load_package database_manager
# name and open the project
set project <project_path/project_name>
project_open $project
# generate the design partition scripts
generate_bottom_up_scripts <options>
#close project
project_close
Related Information
Generate Design Partition Scripts Dialog Box online help
Exporting a Partition
To open a project and load the::quartus::incremental_compilation package before you use the Tcl
commands to export a partition to a .qxp that contains both a post-synthesis and post-fit netlist, with
routing, use the following script:
Example 3-10: Export .qxp
# load required package
load_package incremental_compilation
# open project
project_open <project name>
# export partition to the .qxp and set preservation level
export_partition -partition <partition name>
-qxp <.qxp file name> -<options>
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Importing a Partition into the Top-Level Design
3-59
#close project
project_close
Importing a Partition into the Top-Level Design
To import a .qxp into a top-level design, use the following script:
Example 3-11: Import .qxp into Top-Level Design
# load required packages
load_package incremental_compilation
load_package project
load_package flow
# open project
project_open <project name>
#import partition
import_partition -partition <partition name> -qxp <.qxp file>
<-options>
#close project
project_close
Makefiles
For an example of how to use incremental compilation with a makefile as part of the team-based
incremental compilation design flow, refer to the read_me.txt file that accompanies the incr_comp
example located in the /qdesigns/incr_comp_makefile subdirectory.
When using a team-based incremental compilation design flow, the Generate Design Partition Scripts
dialog box can write makefiles that automatically export lower-level design partitions and import them
into the top-level design whenever design files change.
Related Information
Generate Design Partition Scripts Dialog Box online help
Document Revision History
Table 3-6: Document Revision History
Date
Version
Changes
2015.05.04
15.0.0
Removed Early Timing Estimate feature support.
2014.12.15
14.1.0
• Updated location of Fitter Settings, Analysis & Synthesis Settings,
and Physical Optimization Settings to Compiler Settings.
• Updated DSE II content.
2014.08.18
14.0a10.0
Added restriction about smart compilation in Arria 10 devices.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-60
QII5V1
2015.05.04
Document Revision History
Date
Version
Changes
June 2014
14.0.0
• Dita conversion.
• Replaced MegaWizard Plug-In Manager content with IP Catalog
and Parameter Editor content.
• Revised functional safety section. Added export and import
sections.
November 2013
13.1.0
Removed HardCopy device information. Revised information about
Rapid Recompile. Added information about functional safety. Added
information about flattening sub-partition hierarchies.
November 2012
12.1.0
Added Turning On Supported Cross-boundary Optimizations.
June 2012
12.0.0
Removed survey link.
November 2011
11.0.1
Template update.
May 2011
11.0.0
• Updated “Tcl Scripting and Command-Line Examples”.
December 2010
10.1.0
• Changed to new document template.
• Reorganized Tcl scripting section. Added description for new
feature: Ignore partitions assignments during compilation
option.
• Reorganized “Incremental Compilation Summary” section.
July 2010
10.0.0
• Removed the explanation of the “bottom-up design flow” where
designers work completely independently, and replaced with
Altera’s recommendations for team-based environments where
partitions are developed in the same top-level project framework,
plus an explanation of the bottom-up process for including
independent partitions from third-party IP designers.
• Expanded the Merge command explanation to explain how it now
accommodates cross-partition boundary optimizations.
• Restructured Altera recommendations for when to use a
floorplan.
• Added “Viewing the Contents of a Quartus II Exported Partition
File (.qxp)” section.
• Reorganized chapter to make design flow scenarios more visible;
integrated into various sections rather than at the end of the
chapter.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2015.05.04
Document Revision History
Date
Version
3-61
Changes
October 2009
9.1.0
• Redefined the bottom-up design flow as team-based and reorgan‐
ized previous design flow examples to include steps on how to
pass top-level design information to lower-level designers.
• Moved SDC Constraints from Lower-Level Partitions section to
the Best Practices for Incremental Compilation Partitions and
Floorplan Assignments chapter in volume 1 of the Quartus II
Handbook.
• Reorganized the “Conclusion” section.
• Removed HardCopy APEX and HardCopy Stratix Devices
section.
March 2009
9.0.0
• Split up netlist types table
• Moved “Team-Based Incremental Compilation Design Flow” into
the “Including or Integrating partitions into the Top-Level
Design” section.
• Added new section “Including or Integrating Partitions into the
Top-Level Design”.
• Removed “Exporting a Lower-Level Partition that Uses a JTAG
Feature” restriction
• Other edits throughout chapter
November 2008
8.1.0
• Added new section “Importing SDC Constraints from LowerLevel Partitions” on page 2–44
• Removed the Incremental Synthesis Only option
• Removed section “OpenCore Plus Feature for MegaCore
Functions in Bottom-Up Flows”
• Removed section “Compilation Time with Physical Synthesis
Optimizations”
• Added information about using a .qxp as a source design file
without importing
• Reorganized several sections
• Updated Figure 2–10
Related Information
Quartus II Handbook Archive
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
4
Design Planning for Partial Reconfiguration
2015.05.04
QII5V1
Subscribe
Send Feedback
The Partial Reconfiguration (PR) feature in the Quartus II software allows you to reconfigure a portion of
the FPGA dynamically, while the remainder of the device continues to operate. The Quartus II software
®
supports the PR feature for the Altera® Stratix V device family.
This chapter assumes a basic knowledge of Altera’s FPGA design flow, incremental compilation, and
LogicLock™ region features available in the Quartus II software. It also assumes knowledge of the internal
FPGA resources such as logic array blocks (LABs), memory logic array blocks (MLABs), memory types
(RAM and ROM), DSP blocks, clock networks.
Note: For assistance with support for partial reconfiguration with the Arria V or Cyclone V device
families, file a service request at mySupport using the link below.
®
®
Related Information
•
•
•
•
•
•
•
•
•
•
Terminology on page 4-1
An Example of a Partial Reconfiguration Design on page 4-4
Partial Reconfiguration Design Flow on page 4-8
Implementation Details for Partial Reconfiguration on page 4-19
Partial Reconfiguration with an External Host on page 4-26
Partial Reconfiguration with an Internal Host on page 4-28
Partial Reconfiguration Project Management on page 4-29
Programming Files for a Partial Reconfiguration Project on page 4-31
Partial Reconfiguration Known Limitations on page 4-38
mySupport
Terminology
The following terms are commonly used in this chapter.
project: A Quartus II project contains the design files, settings, and constraints files required for the
compilation of your design.
revision: In the Quartus II software, a revision is a set of assignments and settings for one version of your
design. A Quartus II project can have several revisions, and each revision has its own set of assignments
and settings. A revision helps you to organize several versions of your design into a single project.
© 2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos are
trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as
trademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance
of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any
products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information,
product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device
specifications before relying on any published information and before placing orders for products or services.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
ISO
9001:2008
Registered
4-2
QII5V1
2015.05.04
Determining Resources for Partial Reconfiguration
incremental compilation: This is a feature of the Quartus II software that allows you to preserve results of
previous compilations of unchanged parts of the design, while changing the implementation of the parts
of your design that you have modified since your previous compilation of the project. The key benefits
include timing preservation and compile time reduction by only compiling the logic that has changed.
partition: You can partition your design along logical hierarchical boundaries. Each design partition is
independently synthesized and then merged into a complete netlist for further stages of compilation.
With the Quartus II incremental compilation flow, you can preserve results of unchanged partitions at
specific preservation levels. For example, you can set the preservation levels at post-synthesis or post-fit,
for iterative compilations in which some part of the design is changed. A partition is only a logical
partition of the design, and does not necessarily refer to a physical location on the device. However, you
may associate a partition with a specific area of the FPGA by using a floorplan assignment.
For more information on design partitions, refer to the Best Practices for Incremental Compilation
Partitions andFloorplan Assignments chapter in the Quartus II Handbook.
LogicLock region: A LogicLock region constrains the placement of logic in your design. You can
associate a design partition with a LogicLock region to constrain the placement of the logic in the
partition to a specific physical area of the FPGA.
For more information about LogicLock regions, refer to the Analyzing and Optimizing the Design
Floorplan with the Chip Planner chapter in the Quartus II Handbook.
PR project: Any Quartus II design project that uses the PR feature.
PR region: A design partition with an associated contiguous LogicLock region in a PR project. A PR
project can have one or more PR regions that can be partially reconfigured independently. A PR region
may also be referred to as a PR partition.
static region: The region outside of all the PR regions in a PR project that cannot be reprogrammed with
partial reconfiguration (unless you reprogram the entire FPGA). This region is called the static region, or
fixed region.
persona: A PR region has multiple implementations. Each implementation is called a persona. PR regions
can have multiple personas. In contrast, static regions have a single implementation or persona.
PR control block: Dedicated block in the FPGA that processes the PR requests, handshake protocols, and
verifies the CRC.
Related Information
Best Practices for Incremental Compilation Partitions and Floorplan Assignments on page 14-1
Analyzing and Optimizing the Design Floorplan with the Chip Planner
Determining Resources for Partial Reconfiguration
You can use partial reconfiguration to configure only the resources such as LABs, embedded memory
blocks, and DSP blocks in the FPGA core fabric that are controlled by configuration RAM (CRAM).
The functions in the periphery, such as GPIOs or I/O Registers, are controlled by I/O configuration bits
and therefore cannot be partially reconfigured. Clock multiplexers for GCLK and QCLK are also not partially
reconfigurable because they are controlled by I/O periphery bits.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Determining Resources for Partial Reconfiguration
4-3
Figure 4-1: Partially Reconfigurable Resources
These are the types of resource blocks in a Stratix V device.
I/O, I/O Registers & Part-Hard Memory PHY
PLL
CLK
Core
Fabric
Transceivers,
PCIe HIP
Transceivers,
PCIe HIP
PLL
CLK
I/O, I/O Registers & Part-Hard Memory PHY
Periphery
Core Fabric
Table 4-1: Reconfiguration Modes of the FPGA Resource Block
The following table describes the reconfiguration type supported by each FPGA resource block, which are shown
in the figure.
Hardware Resource Block
Reconfiguration Mode
Logic Block
Partial Reconfiguration
Digital Signal Processing
Partial Reconfiguration
Memory Block
Partial Reconfiguration
Transceivers
Dynamic Reconfiguration ALTGX_Reconfig
PLL
Dynamic Reconfiguration ALTGX_Reconfig
Core Routing
Partial Reconfiguration
Clock Networks
Clock network sources cannot be changed, but a
PLL driving a clock network can be dynamically
reconfigured
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-4
QII5V1
2015.05.04
An Example of a Partial Reconfiguration Design
Hardware Resource Block
Reconfiguration Mode
I/O Blocks and Other Periphery
Not supported
The transceivers and PLLs in Altera FPGAs can be reconfigured using dynamic reconfiguration. For more
information on dynamic reconfiguration, refer to the Dynamic Reconfiguration in Stratix V Devices
chapter in the Stratix V Handbook.
Related Information
Dynamic Reconfiguration in Stratix V Devices
An Example of a Partial Reconfiguration Design
A PR design is divided into two parts. The static region where the design logic does not change, and one
or more PR regions.
Each PR region can have different design personas, that change with partial reconfiguration.
PR Region A has three personas associated with it; A1, A2, and A3. PR Region B has two personas; B1 and
B2. Each persona for the two PR regions can implement different application specific logic, and using
partial reconfiguration, the persona for each PR region can be modified without interrupting the
operation of the device in the static or other PR region.
When a region can access more than one persona, you must create control logic to swap between personas
for a PR region.
Figure 4-2: Partial Reconfiguration Project Structure
The following figure shows the top-level of a PR design, which includes a static region and two PR
regions.
PR Module A1
Chip_top
PR Region A
PR Module A2
PR Module A3
Static
Region
PR Region B
PR Module B1
PR Module B2
Partial Reconfiguration Modes
When you implement a design on an Altera FPGA device, your design implementation is controlled by
bits stored in CRAM inside the FPGA.
You can use partial reconfiguration in the SCRUB mode or the AND/OR mode. The mode you select
affects your PR flow in ways detailed later in this chapter.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
SCRUB Mode
4-5
The CRAM bits control individual LABs, MLABs, M20K memory blocks, DSP blocks, and routing
multiplexers in a design. The CRAM bits are organized into a frame structure representing vertical areas
that correspond to specific locations on the FPGA. If you change a design and reconfigure the FPGA in a
non-PR flow, the process reloads all the CRAM bits to a new functionality.
Configuration bitstreams used in a non-PR flow are different than those used in a PR flow. In addition to
standard data and CRC check bits, configuration bitstreams for partial reconfiguration also include
instructions that direct the PR control block to process the data for partial reconfiguration.
The configuration bitstream written into the CRAM is organized into configuration frames. If a LAB
column passes through multiple PR regions, those regions share some programming frames.
SCRUB Mode
In the SCRUB mode, the unchanging CRAM bits from the static region are "scrubbed" back to their
original values.
The static regions controlled by the CRAM bits from the same programming frame as the PR region
continue to operate. All the CRAM bits corresponding to a PR region are overwritten with new data,
regardless of what was previously contained in the region.
The SCRUB mode of partial reconfiguration involves re-writing all the bits in an entire LAB column of
the CRAM, including bits controlling any part of the static region above and below the PR region
boundary being reconfigured. You can choose to scrub the values of the CRAM bits to 0, and then rewrite
them by turning on the Use clear/set method along with Enable SCRUB mode. The Use clear/set
method is the more reliable option, but can increase the size of your bitstream. You can also choose to
simply Enable SCRUB mode.
Note: You must turn on Enable SCRUB mode to use Use clear/set method.
Figure 4-3: Enable SCRUB mode and Use clear/set method
If there are more than one PR regions along a LAB column, and you are trying to reconfigure one of the
PR regions, it is not not possible to correctly determine the bits associated with the PR region that is not
changing. For this reason, you can not use the SCRUB mode when you have two PR regions that have a
vertically overlapping column in the device. This restriction does not apply to the static bits because they
never change and you can rewrite them with the same value of the configuration bit.
If you turn on Enable SCRUB mode and do not turn on Use clear/set method, then the scrub is done in a
single pass, writing new values of the CRAM without clearing all the bits first. The advantage of using the
SCRUB mode is that the programming file size is much smaller than the AND/OR mode.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-6
QII5V1
2015.05.04
AND/OR Mode
Figure 4-4: SCRUB Mode
This is the floorplan of a FPGA using SCRUB mode, with two PR regions, whose columns do not overlap.
Programming Frame(s)
(No Vertical Overlap)
PR1
Region
PR2
Region
AND/OR Mode
The AND/OR mode refers to how the bits are rewritten. Partial reconfiguration with AND/OR uses a
two-pass method.
Simplistically, this can be compared to bits being ANDed with a MASK, and ORed with new values,
allowing multiple PR regions to vertically overlap a single column. In the first pass, all the bits in the
CRAM frame for a column passing through a PR region are ANDed with 0's while those outside the PR
region are ANDed with 1's. After the first pass, all the CRAM bits corresponding to the PR region are reset
without modifying the static region. In the second pass for each CRAM frame, new data is ORed with the
current value of 0 inside the PR region, and in the static region, the bits are ORed with 0's so they remain
unchanged. The programming file size of a PR region using the AND/OR mode could be twice the
programming file size of the same PR region using SCRUB mode.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Programming File Sizes for a Partial Reconfiguration Project
4-7
Figure 4-5: AND/OR Mode
This is the floorplan of a FPGA using AND/OR mode, with two PR regions, with columns that overlap.
Programming Frame(s)
(Vertical Overlap)
PR1
Region
PR2
Region
Note: If you have overlapping PR regions in your design, you must use AND/OR mode to program all PR
regions, including PR regions with no overlap. The Quartus II software will not permit the use of
SCRUB mode when there are overlapping regions. If none of your regions overlap, you can use
AND/OR, SCRUB, or a mixture of both.
Programming File Sizes for a Partial Reconfiguration Project
The programming file size for a partial reconfiguration is proportional to the area of the PR region.
A partial reconfiguration programming bitstream for AND/OR mode makes two passes on the PR region;
the first pass clears all relevant bits, and the second pass sets the necessary bits. Due to this two-pass
sequence, the size of a partial bitstream can be larger than a full FPGA programming bitstream depending
on the size of the PR region.
When using the AND/OR mode for partial reconfiguration, the formula which describes the approximate
file size within ten percent is:
PR bitstream size = ((Size of region in the horizontal direction) /(full horizontal
dimension of the part)) * 2 * (size of full bitstream)
The way the Fitter reserves routing for partial reconfiguration increases the effective size for small PR
regions from a bitstream perspective. PR bitstream sizes in designs with a single small PR region will not
match the file size computed by this equation.
Note: The PR bitstream size is approximately half of the size computed above when using single-pass
SCRUB mode. When you use the SCRUB mode with Use clear/set method turned on, the
bitstream size is comparable to the size calculated for the AND/OR mode.
You can control expansion of the routing regions by adding the following two assignments to your
Quartus II Settings file (.qsf):
set_global_assignment -name LL_ROUTING_REGION Expanded -section_id <region name>
set_global_assignment -name LL_ROUTING_REGION_EXPANSION_SIZE 0 -section_id <region
name>
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-8
QII5V1
2015.05.04
Partial Reconfiguration Design Flow
Adding these to your .qsf disables expansion and minimizes the bitstream size.
Partial Reconfiguration Design Flow
Partial reconfiguration is based on the revision feature in the Quartus II software. Your initial design is
the base revision, where you define the boundaries of the static region and reconfigurable regions on the
FPGA. From the base revision, you create multiple revisions, which contain the static region and describe
the differences in the reconfigurable regions.
Two types of revisions are specific to partial reconfiguration: reconfigurable and aggregate. Both import
the persona for the static region from the base revision. A reconfigurable revision generates personas for
PR regions. An aggregate revision is used to combine personas from multiple reconfigurable revisions to
create a complete design suitable for timing analysis.
The design flow for partial reconfiguration also utilizes the Quartus II incremental compilation flow. To
take advantage of incremental compilation for partial reconfiguration, you must organize your design into
logical and physical partitions for synthesis and fitting. For the PR flow, these partitions are treated as PR
regions that must also have associated LogicLock assignments.
Revisions make use of personas, which are subsidiary archives describing the characteristics of both static
and reconfigurable regions, that contain unique logic which implements a specific set of functions to
reconfigure a PR region of the FPGA. Partial reconfiguration uses personas to pass this logic from one
revision to another.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Partial Reconfiguration Design Flow
4-9
Figure 4-6: Partial Reconfiguration Design Flow
Designate All Partial Block(s) as Design
Partition(s) for the Use with Incremental Compilation
Plan Your System for Partial
Reconfiguration
Assign All PR Partition(s) to
LogicLock Regions
Identify the Design Blocks Designated
to be Partially Reconfigured
Create Revisions and
Compile the Design
for Each Revision
Code the Design Using HDL
Develop the Personas for the
Partial Blocks
Debug the Timing Failure
& Revise the Appropriate Step
no
Is Timing Met
for Each Revision?
yes
Simulate the Design Functionality
no
Functionality is
Verified?
yes
Generate
Configuration Files
Program the Device
The PR design flow requires more initial planning than a standard design flow. Planning requires setting
up the design logic for partitioning, and determining placement assignments to create a floorplan. Wellplanned partitions can help improve design area utilization and performance, and make timing closure
easier. You should also decide whether your system requires partial reconfiguration to originate from the
FPGA pins or internally, and which mode you are using; the AND/OR mode or the SCRUB mode,
because this influences some of the planning steps described in this section.
You must structure your source code or design hierarchy to ensure that logic is grouped correctly for
optimization. Implementing the correct logic grouping early in the design cycle is more efficient than
restructuring the code later. The PR flow requires you to be more rigorous about following good design
practices. The guidelines for creating partitions for incremental compilation also include creating
partitions for partial reconfiguration.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-10
QII5V1
2015.05.04
Design Partitions for Partial Reconfiguration
Use the following best practice guidelines for designing in the PR flow, which are described in detail in
this section:
•
•
•
•
•
•
•
•
Determining resources for partial reconfiguration
Partitioning the design for partial reconfiguration
Creating incremental compilation partitions for partial reconfiguration
Instantiating the PR controller in the design
Creating wrapper logic for PR regions
Creating freeze logic for PR regions
Planning clocks and other global signals for the PR design
Creating floorplan assignments for the PR design
Design Partitions for Partial Reconfiguration
You must create design partitions for each PR region that you want to partially reconfigure. Optionally,
you can also create partitions for the static parts of the design for timing preservation and/or for reducing
compilation time.
There is no limit on the number of independent partitions or PR regions you can create in your design.
You can designate any partition as a PR partition by enabling that feature in the LogicLock Regions
window in the Quartus II software.
Partial reconfiguration regions do not support the following IP blocks that require a connection to the
JTAG controller:
•
•
•
•
•
In-System Memory Content EditorI
In-System Signals & Probes
Virtual JTAG
Nios II with debug module
SignalTap II tap or trigger sources
Note: PR partitions can contain only core resources, they cannot contain I/O or periphery elements.
Incremental Compilation Partitions for Partial Reconfiguration
Use the following best practices guidelines when creating partitions for PR regions in your design:
• Register all partition boundaries; register all inputs and outputs of each partition when possible. This
practice prevents any delay penalties on signals that cross partition boundaries and keeps each registerto-register timing path within one partition for optimization.
• Minimize the number of paths that cross partition boundaries.
• Minimize the timing-critical paths passing in or out of PR regions. If there are timing-critical paths
that cross PR region boundaries, rework the PR regions to avoid these paths.
• The Quartus II software can optimize some types of paths between design partitions for non-PR
designs. However, for PR designs, such inter-partition paths are strictly not optimized.
For more information about incremental compilation, refer to the following chapter in the Quartus II
Handbook.
Related Information
• Quartus II Incremental Compilation for Hierarchical and Team-Based Design on page 3-1
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Partial Reconfiguration Controller Instantiation in the Design
4-11
Partial Reconfiguration Controller Instantiation in the Design
This section deal ing with instantiation of the partial reconfiguration controller applies only if your design
requires partial reconfiguration in external host mode. Please refer to the Partial Reconfiguration with an
External Host topic for more details. If you perform PR in internal host mode, you do not have to
instantiate the PR control block and the CRC block, since they are are instantiated for you by the PR IP
core.
You must instantiate the Stratix V PR control block and the Stratix V CRC block in your design in order
to use the PR feature in Stratix V devices. You may find that adding the PR control block and CRC block
at the top level of the design offers the most convenience.
For example, in a design named Core_Top, all the logic is contained under the Core_Top module
hierarchy. Create a wrapper (Chip_Top) at the top-level of the hierarchy that instantiates this Core_Top
module, the Stratix V PR control block, and the Stratix V CRC check modules.
If you are performing partial reconfiguration from pins, then the required pins should be on the I/O list
for the top-level (Chip_Top) of the project, as shown in the code in the following examples. If you are
performing partial reconfiguration from within the core, you may choose another configuration scheme,
such as Active Serial, to transmit the reconfiguration data into the core, and then assemble it to 16-bit
wide data inside the FPGA within your logic. In such cases, the PR pins are not part of the FPGA I/O.
Note: Verilog HDL does not require a component declaration. You can instantiate the PR control block
as shown in the following example.
Related Information
Partial Reconfiguration with an External Host on page 4-26
For more information about using partial reconfiguration with and external host.
Component Declaration of the PR Control Block and CRC Block in VHDL
This code sample has the component declaration in VHDL, showing the ports of the Stratix V PR control
block and the Stratix V CRC block. In the following example, the PR function is performed from within
the core (code located in Core_Top) and you must add additional ports to Core_Top to connect to both
components.
-- The Stratix V control block interface
component stratixv_prblock is
port(
corectl: in STD_LOGIC ;
prrequest: in STD_LOGIC ;
data: in STD_LOGIC_VECTOR(15 downto 0);
error: out STD_LOGIC ;
ready: out STD_LOGIC ;
done: out STD_LOGIC
) ;
end component ;
-- The Stratix V CRC block for diagnosing CRC errors
component stratixv_crcblock is
port(
shiftnld: in STD_LOGIC ;
clk: in STD_LOGIC ;
crcerror: out STD_LOGIC
) ;
end component ;
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-12
QII5V1
2015.05.04
Instantiating the PR Control Block and CRC Block in VHDL
The following rules apply when connecting the PR control block to the rest of your design:
• The corectl signal must be set to ‘1’ (when using partial reconfiguration from core) or to ‘0’ (when
using partial reconfiguration from pins).
• The corectl signal has to match the Enable PR pins option setting in the Device and Pin Options
dialog box on the Setting page; if you have turned on Enable PR pins, then the corectl signal on the
PR control block instantiation must be toggled to ‘0’.
• When performing partial reconfiguration from pins the Quartus II software automatically assigns the
PR unassigned pins. If you so choose, you can make pin assignments to all the dedicated PR pins in
Pin Planner or Assignment Editor.
• When performing partial reconfiguration from core, you can connect the prblock signals to either
core logic or I/O pins, excluding the dedicated programming pin such as DCLK.
Instantiating the PR Control Block and CRC Block in VHDL
This code example instantiates a PR control block in VHDL, inside your top-level project, Chip_Top:
module Chip_Top (
//User I/O signals (excluding PR related signals)
..
..
//PR interface & configuration signals
pr_request,
pr_ready,
pr_done,
crc_error,
dclk,
pr_data,
init_done
);
//user I/O signal declaration
..
..
//PR interface and configuration signals declaration
input pr_request;
output pr_ready;
output pr_done;
output crc_error;
input dclk;
input [15:0] pr_data;
output init_done
// Following shows the connectivity within the Chip_Top module
Core_Top : Core_Top
port_map (
..
..
);
m_pr : stratixv_prblock
port map(
clk => dclk,
corectl
=> '0', //1 - when using PR from inside
//0 - for PR from pins; You must also enable
// the appropriate option in Quartus II settings
prrequest
=> pr_request,
data
=> pr_data,
error
=> pr_error,
ready
=> pr_ready,
done
=> pr_done
);
m_crc : stratixv_crcblock
port map(
shiftnld=> '1', //If you want to read the EMR register when
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Instantiating the PR Control Block and CRC Block in Verilog HDL
clk=>
crcerror
);
dummy_clk,
=>
4-13
//error occurrs, refer to AN539 for the
//connectivity forthis signal. If you only want
//to detect CRC errors, but plan to take no
//further action, you can tie the shiftnld
//signal to logical high.
crc_error
For more information on port connectivity for reading the Error Message Register (EMR), refer to the
following application note.
Related Information
AN539: Test Methodology of Error Detection and Recovery using CRC in Altera FPGA Devices
Instantiating the PR Control Block and CRC Block in Verilog HDL
The following example instantiates a PR control block in Verlilog HDL, inside your top-level project,
Chip_Top:
module Chip_Top (
//User I/O signals (excluding PR related signals)
..
..
//PR interface & configuration signals
pr_request,
pr_ready,
pr_done,
crc_error,
dclk,
pr_data,
init_done
);
//user I/O signal declaration
..
..
//PR interface and configuration signals declaration
input pr_request;
output pr_ready;
output pr_done;
output crc_error;
input dclk;
input [15:0] pr_data;
output init_done
stratixv_prblock stratixv_prblock_inst
(
.clk(dclk),
.corectl(1'b0),
.prrequest(pr_request),
.data(pr_data),
.error(pr_error),
.ready(pr_ready),
.done(pr_done)
);
stratixv_crcblock stratixv_crcblock_inst
(
.clk(clk),
.shiftnld(1'b1),
.crcerror(crc_error)
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-14
QII5V1
2015.05.04
Wrapper Logic for PR Regions
);
endmodule
For more information on port connectivity for reading the Error Message Register (EMR), refer to the
following application note.
Related Information
AN539: Test Methodology of Error Detection and Recovery using CRC in Altera FPGA Devices
Wrapper Logic for PR Regions
Each persona of a PR region must implement the same input and output boundary ports. These ports act
as the boundary between static and reconfigurable logic.
Implementing the same boundary ports ensures that all ports of a PR region remain stationary regardless
of the underlying persona, so that the routing from the static logic does not change with different PR
persona implementations.
Figure 4-7: Wire-LUTs at PR Region Boundary
The Quartus II software automatically instantiates a wire-LUT for each port of the PR region to lock
down the same location for all instances of the PR persona.
Partial 1
Static Region
If one persona of your PR region has a different number of ports than others, then you must create a
wrapper so that the static region always communicates with this wrapper. In this wrapper, you can create
dummy ports to ensure that all of the PR personas of a PR region have the same connection to the static
region.
The sample code below each create two personas; persona_1 and persona_2 are different functions of
one PR region. Note that one persona has a few dummy ports. The first example creates partial reconfigu‐
ration wrapper logic in Verilog HDL:
// Partial Reconfiguration Wrapper in Verilog HDL
module persona_1
(
input reset,
input [2:0] a,
input [2:0] b,
input [2:0] c,
output [3:0] p,
output [7:0] q
);
reg [3:0] p, q;
always@(a or b) begin
p = a + b ;
end
always@(a or b or c or p)begin
q = (p*a - b*c )
end
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Wrapper Logic for PR Regions
4-15
endmodule
module persona_2
(
input reset,
input [2:0] a,
input [2:0] b,
input [2:0] c, //never used in this persona
output [3:0] p,
output [7:0] q //never assigned in this persona
);
reg [3:0] p, q;
always@(a or b) begin
p = a * b;
// note q is not assigned value in this persona
end
endmodule
The following example creates partial reconfiguration wrapper logic in VHDL.
-- Partial Reconfiguration Wrapper in VHDL
entity persona_1 is
port( a:in STD_LOGIC_VECTOR (2 downto 0);
b:in STD_LOGIC_VECTOR (2 downto 0);
c:in STD_LOGIC_VECTOR (2 downto 0);
p: out STD_LOGIC_VECTOR (3 downto 0);
q: out STD_LOGIC_VECTOR (7 downto 0));
end persona_1;
architecture synth of persona_1 is
begin
process(a,b)
begin
p <= a + b;
end process;
process (a, b, c, p)
begin
q <= (p*a - b*c);
end process;
end synth;
entity persona_2 is
port( a:in STD_LOGIC_VECTOR (2 downto 0);
b:in STD_LOGIC_VECTOR (2 downto 0);
c:in STD_LOGIC_VECTOR (2 downto 0); --never used in this persona
p:out STD_LOGIC_VECTOR (3 downto 0);
q:out STD_LOGIC_VECTOR (7 downto 0)); --never used in this persona
end persona_2;
architecture synth of persona_2 is
begin
process(a, b)
begin
p <= a *b; --note q is not assigned a value in this persona
end process;
end synth;
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-16
QII5V1
2015.05.04
Freeze Logic for PR Regions
Freeze Logic for PR Regions
When you use partial reconfiguration, you must freeze all non-global inputs of a PR region except global
clocks. Locally routed signals are not considered global signals, and must also be frozen during partial
reconfiguration. Freezing refers to driving a '1' on those PR region inputs. When you start a partial
reconfiguration process, the chip is in user mode, with the device still running.
Freezing all non-global inputs for the PR region ensures there is no contention between current values
that may result in unexpected behavior of the design after partial reconfiguration is complete. Global
signals going into the PR region should not be frozen to high. The Quartus II software freezes the outputs
from the PR region; therefore the logic outside of the PR region is not affected.
Figure 4-8: Freezing at PR Region Boundary
Hardware-Generated
Freeze
Data1
User PR_in_freeze
Data2
“1”
PR Region
Global
Clocks
During partial reconfiguration, the static region logic should not depend on the outputs from PR regions
to be at a specific logic level for the continued operation of the static region.
The easiest way to control the inputs to PR regions is by creating a wrapper around the PR region in RTL.
In addition to freezing all inputs high, you can also drive the outputs from the PR block to a specific value,
if required by your design. For example, if the output drives a signal that is active high, then your wrapper
could freeze the output to GND.
The following example implements a freeze wrapper in Verilog HDL, on a module named pr_module.
module freeze_wrapper
(
input reset,
input freeze, //PR process active, generated by user logic
input clk1, //global clock signal
input clk2, // non-global clock signal
input [3:0] control_mode,
input [3:0] framer_ctl,
output [15:0] data_out
);
wire [3:0]control_mode_wr, framer_ctl_wr;
wire clk2_to_wr;
//instantiate pr_module
pr_module pr_module
(
.reset (reset), //input
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Freeze Logic for PR Regions
4-17
.clk1 (clk1), //input, global clock
.clk2 (clk2_to_wr), // input, non-global clock
.control_mode (control_mode_wr), //input
.framer_ctl (framer_ctl_wr), //input
.pr_module_out (data_out)// collection of outputs from pr_module
);
// Freeze all inputs
assign control_mode_wr = freeze ? 4'hF: control_mode;
assign framer_ctl_wr = freeze ? 4'hF: framer_ctl;
assign clk2_to_wr = freeze ? 1'b1 : clk2;
endmodule
The following example implements a freeze wrapper in VHDL, on a module named pr_module.
entity freeze_wrapper is
port( reset:in STD_LOGIC;
freeze:in STD_LOGIC;
clk1: in STD_LOGIC; --global signal
clk2: in STD_LOGIC; --non-global signal
control_mode: in STD_LOGIC_VECTOR (3 downto 0);
framer_ctl: in STD_LOGIC_VECTOR (3 downto 0);
data_out: out STD_LOGIC_VECTOR (15 downto 0));
end freeze_wrapper;
architecture behv of freeze_wrapper is
component pr_module
port(reset:in STD_LOGIC;
clk1:in STD_LOGIC;
clk2:in STD_LOGIC;
control_mode:in STD_LOGIC_VECTOR (3 downto 0);
framer_ctl:in STD_LOGIC_VECTOR (3 downto 0);
pr_module_out:out STD_LOGIC_VECTOR (15 downto 0));
end component
signal
signal
signal
signal
signal
control_mode_wr: in STD_LOGIC_VECTOR (3 downto 0);
framer_ctl_wr : in STD_LOGIC_VECTOR (3 downto 0);
clk2_to_wr : STD_LOGIC;
data_out_temp : STD_LOGIC_VECTOR (15 downto 0);
logic_high : STD_LOGIC_VECTOR (3 downto 0):="1111";
begin
data_out(15 downto 0) <= data_out_temp(15 downto 0);
m_pr_module: pr_module
port map (
reset => reset,
clk1 => clk1,
clk2 => clk2_to_wr,
control_mode =>control_mode_wr,
framer_ctl => framer_ctl_wr,
pr_module_out => data_out_temp);
-- freeze all inputs
control_mode_wr <= logic_high when (freeze ='1') else control_mode;
framer_ctl_wr <= logic_high when (freeze ='1') else framer_ctl;
clk2_to_wr <= logic_high(0) when (freeze ='1') else clk2;
end architecture;
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-18
QII5V1
2015.05.04
Clocks and Other Global Signals for a PR Design
Clocks and Other Global Signals for a PR Design
For non-PR designs, the Quartus II software automatically promotes high fan-out signals onto dedicated
clocks or other forms of global signals during the pre-fitter stage of design compilation using a process
called global promotion. For PR designs, however, automatic global promotion is disabled by default for
PR regions, and you must assign the global clock resources necessary for PR partitions. Clock resources
can be assigned by making Global Signal assignments in the Quartus II Assignment Editor, or by adding
Clock Control Block (altclkctrl) Megafunction blocks in the design that drive the desired global signals.
There are 16 global clock networks in a Stratix V device. However, only six unique clocks can drive a row
clock region limiting you to a maximum of six global signals in each PR region. The Quartus II software
must ensure that any global clock can feed every location in the PR region.
The limit of six global signals to a PR region includes the GCLK, QCLK and PCLKs used inside of the PR
region. Make QSF assignments for global signals in your project's Quartus II Settings File (.qsf), based on
the clocking requirements for your design. In designs with multiple clocks that are external to the PR
region, it may be beneficial to align the PR region boundaries to be within the global clock boundary
(such as QCLK or PCLK).
If your PR region requires more than six global signals, modify the region architecture to reduce the
number of global signals within this to six or fewer. For example, you can split a PR region into multiple
regions, each of which uses only a subset of the clock domains, so that each region does not use more than
six.
Every instance of a PR region that uses the global signals (for example, PCLK, QCLK, GCLK, ACLR) must use a
global signal for that input.
Global signals can only be used to route certain secondary signals into a PR region and the restrictions for
each block are listed in the following table. Data signals and other secondary signals not listed in the table,
such as synchronous clears and clock enables are not supported.
Table 4-2: Supported Signal Types for Driving Clock Networks in a PR Region
Block Types
Supported Signals for Global/Periphery/Quadrant Clock
Networks
LAB
Clock, ACLR
RAM
Clock, ACLR, Write Enable(WE), Read
Enable(RE)
DSP
Clock, ACLR
Note: PR regions are allowed to contain output ports that are used outside of the PR region as global
signals.
• If a global signal feeds both static and reconfigurable logic, the restrictions in the table also
apply to destinations in the static region. For example, the same global signal cannot be used as
an SCLR in the static region and an ACLR in the PR region.
• A global signal used for a PR region should only feed core blocks inside and outside the PR
region. In particular you should not use a clock source for a PR region and additionally connect
the signal to an I/O register on the top or bottom of the device. Doing so may cause the
Assembler to give an error because it is unable to create valid programming mask files.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Floorplan Assignments for PR Designs
4-19
Floorplan Assignments for PR Designs
You must create a LogicLock region so the interface of the PR region with the static region is the same for
any persona you implement. If different personas of a PR region have different area requirements, you
must make a LogicLock region assignment that contains enough resources to fit the largest persona for
the region. The static regions in your project do not necessarily require a floorplan, but depending on any
other design requirement, you may choose to create a floorplan for a specific static region. If you create
multiple PR regions, and are using SCRUB mode, make sure you have one column or row of static region
between each PR region.
There is no minimum or maximum size for the LogicLock region assigned for a PR region. Because wireLUTs are added on the periphery of a PR region by the Quartus II software, the LogicLock region for a PR
region must be slightly larger than an equivalent non-PR region. Make sure the PR regions include only
the resources that can be partially reconfigured; LogicLock regions for PR can only contain only LABs,
DSPs, and RAM blocks. When creating multiple PR regions, make sure there is at least one static region
column between each PR region. When multiple PR regions are present in a design, the shape and
alignment of the region determines whether you use the SCRUB or AND/OR PR mode.
You can use the default Auto size and Floating location LogicLock region properties to estimate the
preliminary size and location for the PR region.
You can also define regions in the floorplan that match the general location and size of the logic in each
partition. You may choose to create a LogicLock region assignment that is non-rectangular, depending on
the design requirements, but disjoint LogicLock regions are not allowed for PR regions.
After compilation, use the Fitter-determined size and origin location as a starting point for your design
floorplan. Check the quality of results obtained for your floorplan location assignments and make changes
to the regions as needed.
Alternatively, you can perform Analysis and Synthesis, and then set the regions to the required size based
on resource estimates. In this case, use your knowledge of the connections between partitions to place the
regions in the floorplan.
For more information on making design partitions and using an incremental design flow, refer to the
Quartus II Incremental Compilation for Hierarchical and Team-Based Floorplan Design chapter in the
Quartus II Handbook. For more design guidelines to ensure good quality of results, and suggestions on
making design floorplan assignments with LogicLock regions, refer to the Best Practices for Incremental
Compilation Partitions and Floorplan Floorplan Assignments chapter in the Quartus II Handbook.
Related Information
• Quartus II Incremental Compilation for Hierarchical and Team-Based Floorplan on page 3-1
• Best Practices for Incremental Compilation Partitions and Floorplan on page 14-1
Implementation Details for Partial Reconfiguration
This section describes implementation details that help you create your PR design.
Partial Reconfiguration Pins
Partial reconfiguration can be performed through external pins or from inside the core of the FPGA.
When using PR from pins, some of the I/O pins are dedicated for implementing partial reconfiguration
functionality. If you perform partial reconfiguration from pins, then you must use the passive parallel
with 16 data bits (FPPx16) configuration mode. All dual-purpose pins should also be specified to Use as
regular I/O.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-20
QII5V1
2015.05.04
Partial Reconfiguration Pins
To enable partial reconfiguration from pins in the Quartus II software, perform the following steps:
1. From the Assignments menu, click Device, then click Device and Pin Options.
2. In the Device and Pin Options dialog box, select General in the Category list and turn on Enable PR
pins from the Options list.
3. Click Configuration in the Category list and select Passive Parallel x16 from the Configuration
scheme list.
4. Click Dual-Purpose Pins in the Category list and verify that all pins are set to Use as regular I/O
rather than Use as input tri-stated.
5. Click OK, or continue to modify other settings in the Device and Pin Options dialog box.
6. Click OK.
Note: You can enable open drain on PR pins from the Device and Pin Options dialog box in the Settings
page of the Quartus II software.
Table 4-3: Partial Reconfiguration Dedicated Pins Description
Pin Name
PR_REQUEST
Pin Type
Input
Pin Description
Dedicated input when Enable
PR pins is turned on; otherwise,
available as user I/O.
Logic high on pin indicates the
PR host is requesting partial
reconfiguration.
PR_READY
Output
Dedicated output when Enable
PR pins is turned on; otherwise,
available as user I/O.
Logic high on this pin indicates
the Stratix V control block is
ready to begin partial reconfigu‐
ration.
PR_DONE
Output
Dedicated output when Enable
PR pins is turned on; otherwise,
available as user I/O.
Logic high on this pin indicates
that partial reconfiguration is
complete.
PR_ERROR
Output
Dedicated output when Enable
PR pins is turned on; otherwise,
available as user I/O.
Logic high on this pin indicates
the device has encountered an
error during partial reconfigura‐
tion.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Interface with the PR Control Block through a PR Host
Pin Name
Pin Type
Pin Description
Dedicated input when Enable
PR pins is turned on; otherwise
available as user I/O.
Input
DATA[15:0]
4-21
These pins provide connectivity
for PR_DATA when Enable PR
pins is turned on.
Dedicated input when Enable
PR pins is turned on; PR_DATA is
sent synchronous to this clock.
Bidirectional
DCLK
This is a dedicated programming
pin, and is not available as user I/
O even if Enable PR pins is
turned off.
For more information on different configuration modes for Stratix V devices, and specifically about
FPPx16 mode, refer to the Configuration, Design Security, and Remote System Upgrades in Stratix V
Devices chapter of the Stratix V Handbook.
Related Information
Configuration, Design Security, and Remote System Upgrades in Stratix V Devices
Interface with the PR Control Block through a PR Host
You communicate between your PR control IP and the PR Control Block (CB) via control signals, while
executing partial reconfiguration.
You can communicate with the PR control block via an internal host which communicates with the CB
through internal control signals. You can also use an external host with handshake signals accessed via
external pins. The internal PR host can be user logic or a Nios® II processor.
Figure 4-9: Managing Partial Reconfiguration with an Internal or External Host
The figure shows how these blocks should be connected to the PR control block (CB). In your system, you
will have either the External Host or the Internal Host, but not both.
PR Bitstream
file (.rbf) in
external memory
PR Bitstream
file (.rbf) in
external memory
PR
IP Core
PR
Region
Design Planning for Partial Reconfiguration
Send Feedback
External
Host
PR Control
Block (CB)
PR
Region
Altera Corporation
4-22
QII5V1
2015.05.04
PR Control Signals Interface
The PR mode is independent of the full chip programming mode. For example, you can configure the full
chip using a JTAG download cable, or other supported configuration modes. When configuring PR
regions, you must use the FPPx16 interface to the PR control block whether you choose to partially
reconfigure the chip from an external or internal host.
When using an external host, you must implement the control logic for managing system aspects of
partial reconfiguration on an external device. By using an internal host, you can implement all of your
logic necessary for partial reconfiguration in the FPGA, therefore external devices are not required to
support partial reconfiguration. When using an internal host, you can use any interface to load the PR
bitstream data to the FPGA, for example, from a serial or a parallel flash device, and then format the PR
bitstream data to fit the FPPx16 interface on the PR Control Block.
To use the external host for your design, turn on the Enable PR Pins option in the Device and Pin
Options dialog box in the Quartus II software when you compile your design. If this setting is turned off,
then you must use an internal host. Also, you must tie the corectl port on the PR control block instance
in the top-level of the design to the appropriate level for the selected mode.
Related Information
Partial Reconfiguration Pins on page 4-19
Partial Reconfiguration Dedicated Pins Table
PR Control Signals Interface
The Quartus II Programmer allows you to generate the different bit-streams necessary for full chip
configuration and for partial reconfiguration. The programming bit-stream for partial reconfiguration
contains the instructions (opcodes) as well as the configuration bits, necessary for reconfiguring each of
the partial regions. When using an external host, the interface ports on the control block are mapped to
FPGA pins. When using an internal host, these signals are within the core of the FPGA.
Figure 4-10: Partial Reconfiguration Interface Signals
These handshaking control signals are used for partial reconfiguration.
From Pins or
FPGA Core
PR_Data[15:0]
PR_done
PR_ready
CRC_error
PR_error
PR_request
Clk
PR Control Block (CB)
corectl
• PR_DATA: The configuration bitstream is sent on PR_ DATA[ 15:0], synchronous to the Clk.
• PR_DONE: Sent from CB to control logic indicating the PR process is complete.
• PR_READY: Sent from CB to control logic indicating the CB is ready to accept PR data from the control
logic.
• CRC_Error: The CRC_Error generated from the device’s CRC block, is used to determine whether to
partially reconfigure a region again, when encountering a CRC_Error.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Reconfiguring a PR Region
4-23
• PR_ERROR: Sent from CB to control logic indicating an error during partial reconfiguration.
• PR_REQUEST: Sent from your control logic to CB indicating readiness to begin the PR process.
• corectl: Determines whether partial reconfiguration is performed internally or through pins.
Reconfiguring a PR Region
The figure below shows a system in which your PR Control logic is implemented inside the FPGA.
However, this section is also applicable for partial reconfiguration with an external host.
The PR control block (CB) represents the Stratix V PR controller inside the FPGA. PR1 and PR2 are two
PR regions in a user design. In addition to the four control signals (PR_REQUEST, PR_READY, PR_DONE, PR
_ERROR) and the data/clock signals interfacing with the PR control block, your PR Control IP should also
send a control signal (PR_CONTROL) to each PR region. This signal implements the freezing and unfreezing
of the PR Interface signals. This is necessary to avoid contention on the FPGA routing fabric.
Figure 4-11: Example of a PR System with Two PR Regions
Implementation of PR Control logic in the FPGA.
Static Region
PR1
Region
PR2
Region
PR1_Control
PR Control
Block (CB)
PR_Request
PR_Ready, PR_Error,
PR_Done, CRC_Error
PR2_Control
PR Control Logic
Partial Reconfiguration
Data/Clock via FPPx16
After the FPGA device has been configured with a full chip configuration at least once, the INIT_DONE
signal is released, and the signal is asserted high due to the external resistor on this pin. The INIT_DONE
signal must be assigned to a pin to monitor it externally. When a full chip configuration is complete, and
the device is in user mode, the following steps describe the PR sequence:
1. Begin a partial reconfiguration process from your PR Control logic, which initiates the PR process for
one or more of the PR regions (asserting PR1_Control or PR2_Control in the figure). The wrapper
HDL described earlier freezes (pulls high) all non-global inputs of the PR region before the PR process.
2. Send PR_REQUEST signal from your control logic to the PR Control Block (CB). If your design uses an
external controller, monitor INIT_DONE to verify that the chip is in user mode before asserting the
PR_REQUEST signal. The CB initializes itself to accept the PR data and clock stream. After that, the CB
asserts a PR_READY signal to indicate it can accept PR data. Exactly four clock cycles must occur before
sending the PR data to make sure the PR process progresses correctly. Data and clock signals are sent
to the PR control block to partially reconfigure the PR region interface.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-24
QII5V1
2015.05.04
Partial Reconfiguration Cycle Waveform
3.
4.
5.
6.
• If there are multiple PR personas for the PR region, your PR Control IP must determine the
programming file data for partial reconfiguration.
• When there are multiple PR regions in the design, then the same PR control IP determines which
regions require reconfiguration based on system requirements.
• At the end of the PR process, the PR control block asserts a PR_DONE signal and de-asserts the
PR_READY signal.
• If you want to suspend sending data, you can implement logic to pause the clock at any point.
Your PR control logic must de-assert the PR_REQUEST signal within eight clock cycles after the PR_DONE
signal goes high. If your logic does not de-assert the PR_REQUEST signal within eight clock cycles, a new
PR cycle starts.
If your design includes additional PR regions, repeat steps 2 – 3 for each region. Otherwise, proceed to
step 5.
Your PR Control logic de-asserts the PR_CONTROL signal(s) to the PR region. The freeze wrapper
releases all input signals of the PR region, thus the PR region is ready for normal user operation.
You must perform a reset cycle to the PR region to bring all logic in the region to a known state. After
partial reconfiguration is complete for a PR region, the states in which the logic in the region come up
is unknown.
The PR event is now complete, and you can resume operation of the FPGA with the newly configured PR
region.
At any time after the start of a partial reconfiguration cycle, the PR host can suspend sending the PR_DATA,
but the host must suspend sending the PR_CLK at the same time. If the PR_CLK is suspended after a PR
process, there must be at least 20 clock cycles after the PR_DONE or PR_ERROR signal is asserted to prevent
incorrect behavior.
For an overview of different reset schemes in Altera devices, refer to the Recommended Design Practices
chapter in the Quartus II Handbook.
Related Information
Partial Reconfiguration Cycle Waveform on page 4-24
For more information on clock requirements for partial reconfiguration.
Recommended Design Practices on page 11-1
Partial Reconfiguration Cycle Waveform
The PR host initiates the PR request, transfers the data to the FPGA device when it is ready, and monitors
the PR process for any errors or until it is done.
Note: If you are using the PR IP core in the internal host mode, the IP core takes care of all the timing
relationships mentioned below. As a user you do not have to do anything else. If you are using the
PR IP core in external host mode, then you must pay attention to the timing relationships.
A PR cycle is initiated by the host (internal or external) by asserting the PR_REQUEST signal high. When
the FPGA device is ready to begin partial reconfiguration, it responds by asserting the PR_READY signal
high. The PR host responds by sending configuration data on DATA [15:0]. The data is sent synchronous
to PR_CLK. When the FPGA device receives all PR data successfully, it asserts the PR_DONE high, and deasserts PR_READY to indicate the completion of the PR cycle.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Partial Reconfiguration Cycle Waveform
4-25
Figure 4-12: Partial Reconfiguration Timing Diagram
The partial reconfiguration cycle waveform with a hand-shaking protocol.
DONE_to_REQ_low
PR_REQUEST
PR_CLK
READY_to_FIRST_DATA
PR_DATA[15:0]
D0LSW D0MSW D1LSW D1MSW
PR_READY
Dn-1MSW DnLSW DnLSW
DONE_to_LAST_CLK
PR_DONE
PR_ERROR
CRC_ERROR
If there is an error encountered during partial reconfiguration, the FPGA device asserts the PR_ERROR
signal high and de-asserts the PR_READY signal low.
The PR host must continuously monitor the PR_DONE and PR_ERROR signals status. Whenever either of
these two signals are asserted, the host must de-assert PR_REQUEST within eight PR_CLK cycles. As a
response to PR_ERROR error, the host can optionally request another partial reconfiguration or perform a
full FPGA configuration.
To prevent incorrect behavior, the PR_CLK signal must be active a minimum of twenty clock cycles after
PR_DONE or PR_ERROR signal is asserted high. Once PR_DONE is asserted, PR_REQUEST must be de-asserted
within eight clock cycles. PR_DONE is de-asserted by the device within twenty PR_CLK cycles. The host can
assert PR_REQUEST again after the 20 clocks after PR_DONE is de-asserted.
Table 4-4: Partial Reconfiguration Clock Requirements
Signal timing requirements for partial reconfiguration.
Timing Parameters
Value (clock cycles)
PR_READY to first data
4 (exact)
PR_ERROR to last clock
20 (minimum)
PR_DONE to last clock
20 (minimum)
DONE_to_REQ_low
8 (maximum)
Compressed PR_READY to first data
4 (exact)
Encrypted PR_READY to first data (when using
double PR)
8 (exact)
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-26
QII5V1
2015.05.04
Partial Reconfiguration with an External Host
Timing Parameters
Encrypted and Compressed PR_READY to first data
(when using double PR)
Value (clock cycles)
12 (exact)
At any time during partial reconfiguration, to pause sending PR_DATA, the PR host can stop toggling
PR_CLK. The clock can be stopped either high or low.
At any time during partial reconfiguration, the PR host can terminate the process by de-asserting the PR
request. A partially completed PR process results in a PR error. You can have the PR host restart the PR
process after a failed process by sending out a new PR request 20 cycles later.
If you terminate a PR process before completion, and follow it up with a full FPGA configuration by
asserting nConfig, then you must toggle PR_CLK for an additional 20 clock cycles prior to asserting
nConfig to flush the PR_CONTROL_BLOCK and avoid lock up.
During these steps, the PR control block might assert a PR_ERROR or a CRC_ERROR signal to indicate that
there was an error during the partial reconfiguration process. Assertion of PR_ERROR indicates that the PR
bitstream data was corrupt, and the assertion of CRC error indicates a CRAM CRC error either during or
after completion of PR process. If the PR_ERROR or CRC_ERROR signals are asserted, you must plan whether
to reconfigure the PR region or reconfigure the whole FPGA, or leave it unconfigured.
Important: The PR_CLK signal has different a nominal maximum frequency for each device. Most Stratix
V devices have a nominal maximum frequency of at least 62.5 MHz.
Partial Reconfiguration with an External Host
For partial reconfiguration using an external host, you must set the MSEL [4:0] pins for FPPx16
configuration scheme.
You can use a microcontroller, another FPGA, or a CPLD such as a MAX V device, to implement the
configuration and PR controller. In this setup, the Stratix V device configures in FPPx16 mode during
power-up. Alternatively, you can use a JTAG interface to configure the Stratix V device.
At any time during user-mode, the external host can initiate partial reconfiguration and monitor the
status using the external PR dedicated pins: PR_REQUEST, PR_READY, PR_DONE, and PR_ERROR. In this
mode, the external host must respond appropriately to the hand-shaking signals for a successful partial
reconfiguration. This includes acquiring the data from the flash memory and loading it into the Stratix V
device on DATA[ 15:0].
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Using an External Host with Multiple Devices
4-27
Figure 4-13: Connecting to an External Host
The connection setup for partial reconfiguration with an external host in the FPPx16 configuration
scheme.
Memory
V CCPGM
V CCPGM
V CCPGM
ADDR DATA[15:0]
10 K W
10 K W
10 K W
Stratix V Device
External Host
(MAX V Device or
Microprocessor)
CONF_DONE
nSTATUS
nCONFIG
nCE
MSEL[4:0]
DATA[15:0]
DCLK
PR_REQUEST
PR_DONE
PR_READY
PR_ERROR
PR_CONTROL
PR_RESET
CRC_ERROR
Note: If you don't care to write an external host controller, you implement an external host with the
Partial Reconfiguration IP core on a MAX 10 or other FPGA device.
Related Information
Partial Reconfiguration IP Core User Guide
Using an External Host with Multiple Devices
You must design the external host to accommodate the arbitration scheme that is required for your
system, as well as the partial reconfiguration interface requirement for each device.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-28
QII5V1
2015.05.04
Partial Reconfiguration with an Internal Host
Figure 4-14: Connecting Multiple FPGAs to an External Host
An example of an external host controlling multiple Stratix V devices on a board.
DATA[15:0]
nCE
Memory
Address
DATA[7:0]
External
DATA[15:0]
Host
PR_REQUEST1
PR_DONE1
PR_READY1
PR_ERROR1
PR_REQUEST
PR_DONE
PR_READY
PR_ERROR
FPGA1
DATA[15:0]
nCE
PR_REQUEST
PR_DONE
PR_READY
PR_ERROR
PR_REQUEST2
PR_DONE2
PR_READY2
PR_ERROR2
FPGA2
DATA[15:0]
nCE
PR_REQUEST5
PR_DONE5
PR_READY5
PR_ERROR5
PR_REQUEST
PR_DONE
PR_READY
PR_ERROR
FPGA5
Partial Reconfiguration with an Internal Host
You can create PR internal host logic with the PR IP core. If your design uses an internal host, the PR IP
core handles the required hand-shaking protocol with the PR control block.
For example, PR programming bitstream(s) stored in an external flash device can be routed through the
regular I/Os of the FPGA device, or received through the high speed transceiver channel (PCI Express,
SRIO or Gigabit Ethernet), for processing by the internal logic.
The PR dedicated pins (PR_REQUEST, PR_READY, PR_DONE, and PR_ERROR) can be used as regular I/Os
when performing partial reconfiguration with an internal host. For the full FPGA configuration upon
power-up, you can set the MSEL[4:0] pins to match the configuration scheme, for example, AS, PS,
FPPx8, FPPx16, or FPPx32. Alternatively, you can use the JTAG interface to configure the FPGA device.
At any time during user-mode, you can initiate partial reconfiguration through the FPGA core fabric
using the PR internal host.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Partial Reconfiguration Project Management
4-29
In the following figure, the programming bitstream for partial reconfiguration is received through the PCI
Express link, and your logic converts the data to the FPPx16 mode.
Figure 4-15: Connecting to an Internal Host
An example of the configuration setup when performing partial reconfiguration using the internal host.
VCCPGM
VCCPGM
10 KW
10 KW
VCCPGM
10 KW
Stratix V Device
nSTATUS
CONF_DONE
nCONFIG
nCE
MSEL[4:0]
EPCS
DATA
DCLK
nCS
ASDI
AS_DATA1
DCLK
nCSO
ASDO
PR
IP Core
Partial Reconfiguration Data
Received through PCI Express Link
Partial Reconfiguration Project Management
When compiling your PR project, you must create a base revision, and one or more reconfigurable
revisions. The project revision you start out is termed the base revision.
Create Reconfigurable Revisions
To create a reconfigurable revision, use the Revisions tab of the Project Navigator window in the
Quartus II software. When you create a reconfigurable revision, the Quartus II software adds the required
assignments to associate the reconfigurable revision with the base revision of the PR project. You can add
the necessary files to each revision with the Add/Remove Files option in the Project option under the
Project menu in the Quartus II software. With this step, you can associate the right implementation files
for each revision of the PR project.
Important: You must use the Revisions tab of the Project Navigator window in the Quartus II software
when creating revisions for partial reconfiguration. Revisions created using Project >
Revisions cannot be reconfigured.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-30
QII5V1
2015.05.04
Compiling Reconfigurable Revisions
Compiling Reconfigurable Revisions
Altera recommends that you use the largest persona of the PR region for the base compilation so that the
Quartus II software can automatically budget sufficient routing.
Here are the typical steps involved in a PR design flow.
1. Compile the base revision with the largest persona for each PR region.
2. Create reconfigurable revisions for other personas of the PR regions by right-clicking in the Revisions
tab in the Project Navigator.
3. Compile your reconfigurable revisions.
4. Analyze timing on each reconfigurable revision to make sure the design performs correctly to specifi‐
cations.
5. Create aggregate revisions as needed.
6. Create programming files.
For more information on compiling a partial reconfiguration project, refer to Performing Partial
Reconfiguration in Quartus II Help.
Related Information
Performing Partial Reconfiguration
Timing Closure for a Partial Reconfiguration Project
As with any other FPGA design project, simulate the functionality of various PR personas to make sure
they perform to your system specifications. You must also make sure there are no timing violations in the
implementation of any of the personas for every PR region in your design project.
In the Quartus II software, this process is manual, and you must run multiple timing analyses, on the base,
reconfigurable, and aggregate revisions. The different timing requirements for each PR persona can be
met by using different SDC constraints for each of the personas.
The interface between the partial and static partitions remains identical for each reconfigurable and
aggregate revision in the PR flow. If all the interface signals between the static and the PR regions are
registered, and there are no timing violations within the static region as well as within the PR regions, the
reconfigurable and aggregate revisions should not have any timing violations.
However, you should perform timing analysis on the reconfigurable and aggregate revisions, in case you
have any unregistered signals on the interface between partial reconfiguration and static regions.
Bitstream Compression and Encryption for PR Designs
You can choose to independently compress and encrypt the base bitstream as well as the PR bitstream for
your PR project using options available in the Quartus II software.
When you choose to compress the bitstreams, you can compress the base and PR programming
bitstreams independently, based on your design requirements. However, if you want to encrypt only the
base image, you can choose wether or not to encrypt the PR images.
• When you want to encrypt the bitstreams, you can encrypt the PR images only when the base image is
encrypted.
• The Encryption Key Programming ( .ekp) file generated when encrypting the base image must be used
for encrypting PR bitstream.
• When you compress the bitstream, you must present each PR_DATA[15:0] word for exactly four clock
cycles.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Programming Files for a Partial Reconfiguration Project
4-31
Table 4-5: Partial Reconfiguration Clock Requirements for Bitstream Compression
Timing Parameters
Value (clock cycles)
PR_READY to first data
4 (exact)
PR_ERROR to last clock
80 (minimum)
PR_DONE to last clock
80 (minimum)
DONE_to_REQ_low
8 (maximum)
Related Information
• Enable Partial Reconfiguration Bitstream Decompression when Configuring Base Design SOF file
in JTAG mode on page 4-36
• Enable Bitstream Decryption Option on page 4-37
• Generate PR Programming Files with the Convert Programming Files Dialog Box on page 4-34
Programming Files for a Partial Reconfiguration Project
You must generate PR bitstream(s) based on the designs and send them to the control block for partial
reconfiguration.
Compile the PR project, including the base revision and at least one reconfigurable revision before
generating the PR bitstreams. The Quartus II Programmer generates PR bitstreams. This generated
bitstream can be sent to the PR ports on the control block for partial reconfiguration.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-32
QII5V1
2015.05.04
Programming Files for a Partial Reconfiguration Project
Figure 4-16: PR Project with Three Revisions
Consider a partial reconfiguration design that has three revisions and one PR region, a base revision with
persona a, one PR revision with persona b, and a second PR revision with persona c.
Base
Revision with
Persona a
Partial
Reconfiguration
Design
pr_region.msf
static.msf
base.sof
Revision b
Revision c
b.sof
b.msf
c.sof
c.msf
When these individual revisions are compiled in the Quartus II software, the assembler produces Masked
SRAM Object Files (.msf) and the SRAM Object Files ( .sof) for each revision. The .sof files are created as
before (for non-PR designs). Additionally, .msf files are created specifically for partial reconfiguration, one
for each revision. The pr_region.mfsf file is the one of interest for generating the PR bitstream. It contains
the mask bits for the PR region. Similarly, the static.msf file has the mask bits for the static region. The .sof
files have the information on how to configure the static region as well as the corresponding PR region.
The pr_region.msf file is used to mask out the static region so that the bitstream can be computed for the
PR region. The default file name of the pr region .msf corresponds to the LogicLock region name, unless
the name is not alphanumeric. In the case of a non-alphanumeric region name, the .msf file is named after
the location of the lower left most coordinate of the region.
Note: Altera recommends naming all LogicLock regions to enhance documenting your design.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Programming Files for a Partial Reconfiguration Project
4-33
Figure 4-17: Generation of Partial-Masked SRAM Object Files (.pmsf)
You can convert files in the Convert Programming Files window or run the quartus_cpf -p command
to process the pr_region.msf and .sof files to generate the Partial-Masked SRAM Object File (.pmsf).
b_pr_region
.msf
pr_region.msf
+
+
a.pmsf
c_pr_region
.msf
b.pmsf
b.sof
base.sof
+
c.pmsf
c.sof
The .msf file helps determine the PR region from each of the .sof files during the PR bitstream computa‐
tion.
Once all the .pmsf files are created, process the PR bitstreams by running the quartus_cpf -o command
to produce the raw binary .rbf files for reconfiguration.
If one wishes to partially reconfigure the PR region with persona a, use the a.rbf bitstream file, and so on
for the other personas.
Figure 4-18: Generating PR Bitstreams
This figure shows how three bitstreams can be created to partially reconfigure the region with persona a,
persona b, or persona c as desired.
a.rbf
a.pmsf
b.pmsf
b.rbf
c.pmsf
c.rbf
In the Quartus II software, the Convert Programming Files window supports the generation of the
required programming bitstreams. When using the quartus_cpf from the command line, the following
options for generating the programming files are read from an option text file, for example, option.txt.
• If you want to use SCRUB mode, before generating the bitstreams create an option text file, with the
following line:
use_scrub=on
• If you have initialized M20K blocks in the PR region (ROM/Initialized RAM), then add the following
line in the option text file, before generating the bitstreams:
write_block_memory_contents=on
• If you want to compress the programming bitstream files, add the following line in the option text file.
This option is available when converting base .sof to any supported programming file types, such
as .rbf, .pof and JTAG Indirect Configuration File (. jic).
bitstream_compression=on
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-34
QII5V1
2015.05.04
Generating Required Programming Files
Related Information
Generate PR Programming Files with the Convert Programming Files Dialog Box on page 4-34
Generating Required Programming Files
1. Generate .sof and .msf files (part of a full compilation of the base and PR revisions).
2. Generate a Partial-Masked SRAM Object File (.pmsf) using the following commands:
quartus_cpf -p <pr_revision>.msf <pr_revision>.sof <new_filename>.pmsf
for example:
quartus_cpf -p x7y48.msf switchPRBS.sof x7y48_new.pmsf
3. Convert the .pmsf file for every PR region in your design to .rbf file format. The .rbf format is used to
store the bitstream in an external flash memory. This command should be run in the same directory
where the files are located:
quartus_cpf -o scrub.txt -c <pr_revision >.pmsf <pr_revision>.rbf
for example:
quartus_cpf -o scrub.txt -c x7y48_new.pmsf x7y48.rbf
When you do not have an option text file such as scrub.txt, the files generated would be for AND/OR
mode of PR, rather than SCRUB mode.
Generate PR Programming Files with the Convert Programming Files Dialog Box
In the Quartus II software, the flow to generate PR programming files is supported in the Convert
Programming Files dialog box. You can specify how the Quartus II software processes file types such
as .msf, .pmsf, and .sof to create .rbf and merged .msf and .pmsf files.
You can create
•
•
•
•
A .pmsf output file, from .msf and .sof input files
A .rbf output file from a .pmsf input file
A merged .msf file from two or more .msf input files
A merged .pmsf file from two or more .pmsf input files
Convert Programming Files dialog box also allows you to enable the option bit for bitstream decompres‐
sion during partial reconfiguration, when converting the base .sof (full design .sof) to any supported file
type.
For additional details, refer to the Quartus II Programmer chapter in the Quartus II Handbook.
Related Information
Quartus II Programmer
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Generating a .pmsf File from a .msf and .sof Input File
4-35
Generating a .pmsf File from a .msf and .sof Input File
Perform the following steps in the Quartus II software to generate the .pmsf file in the Convert Program‐
ming Files dialog box.
1.
2.
3.
4.
5.
Open the Convert Programming Files dialog box.
Specify the programming file type as Partial-Masked SRAM Object File (.pmsf).
Specify the output file name.
Select input files to convert (only a single .msf and .sof file are allowed). Click Add.
Click Generate to generate the .pmsf file.
Generating a .rbf File from a .pmsf Input File
Perform the following steps in the Quartus II software to generate the partial reconfiguration .rbf file in
the Convert Programming Files dialog box.
1.
2.
3.
4.
5.
6.
From the File menu, click Convert Programming Files.
Specify the programming file type as Raw Binary File for Partial Reconfiguration (.rbf).
Specify the output file name.
Select input file to convert. Only a single .pmsf input file is allowed. Click Add.
Select the new .pmsf and click Properties.
Turn the Compression, Enable SCRUB mode, Write memory contents, and Generate encrypted
bitstream options on or off depending on the requirements of your design. Click Generate to generate
the .rbf file for partial reconfiguration.
• Compression: Enables compression on the PR bitstream.
• Enable SCRUB mode: Default is based on AND/OR mode. This option is valid only when your design
does not contain vertically overlapped PR masks. The .rbf generation fails otherwise.
• Write memory contents: Turn this on when you have a .mif that was used during compilation.
Otherwise, turning this option on forces you to use double PR in AND/OR mode.
• Generate encrypted bitstream: If this option is enabled, you must specify the Encrypted Key
Programming ( .ekp) file, which generated when converting a base .sof to an encrypted bitstream. The
same .ekp must be used to encrypt the PR bitstream.
When you turn on Compression, you must present each PR_DATA[15:0] word for exactly four clock
cycles.
Turn on the Write memory contents option only if you are using AND/OR mode and have M20K blocks
in your PR design that need to be initialized. When you check this box, you must to perform double PR
for regions with initialized M20K blocks.
Related Information
• Initializing M20K Blocks with a Double PR Cycle on page 4-43
• Initializing M20K Blocks with a Double PR Cycle on page 4-43
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-36
QII5V1
2015.05.04
Create a Merged .msf File from Multiple .msf Files
Create a Merged .msf File from Multiple .msf Files
You can merge two or more .msf files in the Convert Programming Files window.
1.
2.
3.
4.
5.
6.
Open the Convert Programming Files window.
Specify the programming file type as Merged Mask Settings File (.msf).
Specify the output file name.
Select MSF Data in the Input files to convert window.
Click Add File to add input files. You must specify two or more files for merging.
Click Generateto generate the merged file.
To merge two or more .msf files from the command line, type:
quartus_cpf --merge_msf=<number of merged files> <msf_input_file_1>
<msf_input_file_2> <msf_input_file_etc> <msf_output_file>
For example, to merge two .msf files, type:
quartus_cpf --merge_msf=<2> <msf_input_file_1> <msf_input_file_2>
<msf_output_file>
Generating a Merged .pmsf File from Multiple .pmsf Files
You can merge two or more .pmsf files in the Convert Programming Files window.
1.
2.
3.
4.
5.
6.
Open the Convert Programming Files window.
Specify the programming file type as Merged Partial-Mask SRAM Object File (.pmsf).
Specify the output file name.
Select PMSF Data in the Input files to convert window.
Click Add File to add input files. You must specify two or more files for merging.
Click Generate to generate the merged file.
To merge two or more .pmsf files from the command line, type:
quartus_cpf --merge_pmsf=<number of merged files> <pmsf_input_file_1>
<pmsf_input_file_2> <pmsf_input_file_etc> <pmsf_output_file>
For example, to merge two .pmsf files, type:
quartus_cpf --merge_pmsf=<2> <pmsf_input_file_1> <pmsf_input_file_2>
<pmsf_output_file>
The merge operation checks for any bit conflict on the input files, and the operation fails with error
message if a bit conflict is detected. In most cases, a successful file merge operation indicates input files do
not have any bit conflict.
Enable Partial Reconfiguration Bitstream Decompression when Configuring Base Design SOF file
in JTAG mode
In the Quartus II software, the Convert Programming Files window provides the option in the .sof file
properties to enable bitstream decompression during partial reconfiguration.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Enable Bitstream Decryption Option
4-37
This option is available when converting base .sof to any supported programming file types, such
as .rbf, .pof, and .jic.
In order to view this option, the base .sof must be targeted on Stratix V devices in the .sof File Properties.
This option must be turned on if you turned on the Compression option during .pmsf to .rbf file
generation.
Enable Bitstream Decryption Option
The Convert Programming Files window provides the option in the .sof file properties to enable
bitstream decryption during partial reconfiguration.
This option is available when converting base .sof to any supported programming file types, such
as .rbf, .pof, and .jic.
The base .sof must have partial reconfiguration enabled and the base .sof generated from a design that has
a PR Control Block instantiated, to view this option in the .sof File Properties. This option must be
turned on if you wants to turn on the Generate encrypted bitstream option during .pmsf to .rbf file
generation.
On-Chip Debug for PR Designs
You cannot instantiate a SignalTap II block inside a PR region. If you must monitor signals within a PR
region for debug purposes, bring those signals to the ports of the PR region.
The Quartus II software does not support the Incremental SignalTap feature for PR designs. After you
instantiate the SignalTap II block inside the static region, you must recompile your design. When you
recompile your design, the static region may have a modified implementation and you must also
recompile your PR revisions. If you modify an existing SignalTap II instance you must also recompile
your entire design; base revision and reconfigurable revisions.
Figure 4-19: Using SignalTap II with a PR Design
You can instantiate the SignalTap II block in the static region of the design and probe the signals you want
to monitor.
Static Region
SignalTap II
Module
PR Region
with Signals to
Be Probed
Brought Out
on the Ports
You can use other on-chip debug features in the Quartus II software, such as the In-System Sources and
Probes or SignalProbe, to debug a PR design. As in the case of SignalTap, In-System Sources and Probes
can only be instantiated within the static region of a PR design. If you have to probe any signal inside the
PR region, you must bring those signals to the ports of the PR region in order to monitor them within the
static region of the design.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-38
QII5V1
2015.05.04
Partial Reconfiguration Known Limitations
Partial Reconfiguration Known Limitations
There are restrictions that derive from hardware limitations in specific Stratix V devices.
The restrictions in the following sections apply only if your design uses M20K blocks as RAMs or ROMs
in your PR project.
Memory Blocks Initialization Requirement for PR Designs
For a non-PR design, the power up value for the contents of a M20K RAM or a MLAB RAM are all set at
zero. However, at the end of performing a partial reconfiguration, the contents of a M20K or MLAB
memory block are unknown. You must intentionally initialize the contents of all the memory to zero, if
required by the functionality of the design, and not rely upon the power on values.
M20K RAM Blocks in PR Designs
When your PR design uses M20K RAM blocks in Stratix V devices, there are some restrictions which
limit how you utilize the respective memory blocks as ROMs or as RAMs with initial content.
Related Information
Implementing Memories with Initialized Content on page 4-41
If your design requires initialized memory content either as a ROM or a RAM inside a PR region, you
must follow these guidelines.
Limitations When Using Stratix V Production Devices
These workarounds allow your design to use M20K blocks with PR.
Figure 4-20: Limitations for Using M20Ks in PR Regions
If you implement a M20K block in your PR region as a ROM or a RAM with initialized content, when the
PR region is reconfigured, any data read from the memory blocks in static regions in columns that cross
the PR region is incorrect.
Stratix V Device
PR
Region
Static
Region
No Restrictions for RAM/ROM
Implementation in These M20K Columns
RAM/ROM Implementation in These M20K
Columns Has Restrictions
If the functionality of the static region depends on any data read out from M20K RAMs in the static
region, the design will malfunction.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Limitations When Using Stratix V Production Devices
4-39
Use one of the following workarounds, which are applicable to both AND/OR and SCRUB modes of
partial reconfiguration:
• Do not use ROMs or RAMs with initialized content inside PR regions.
• If this is not possible for your design, you can program the memory content for M20K blocks with
a .mif using the suggested workarounds.
• Make sure your PR region extends vertically all the way through the device, in such a way that the
M20K column lies entirely inside a PR region.
Figure 4-21: Workaround for Using M20Ks in PR Regions
This figure shows the LogicLock region extended as a rectangle reducing the area available for the static
region. However, you can create non-rectangular LogicLock regions to allocate the resources required for
the partition more optimally. If saving area is a concern, extend the LogicLock region to include M20K
columns entirely.
Stratix V Device
M20K as Uninitialized RAM
PR
Region
Static
Region
M20K as Initialized RAM/ROM
Workaround: Extend the LogicLock Region
to Include the Entire M20K Column
•
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-40
QII5V1
2015.05.04
MLAB Blocks in PR designs
Figure 4-22: Alternative Workaround for Using M20Ks in PR Region
Using Reserved LogicLock Regions, block all the M20K columns that are not inside a PR region, but that
are in columns above or below a PR region. In this case, you may choose to under-utilize M20K resources,
in order to gain ROM functionality within the PR region.
Stratix V Device
M20K as Uninitialized RAM
Static
Region
PR
Region
M20K as Initialized RAM/ROM
Workaround:Reserved LogicLock Region
No RAM/ROM In These Areas
For more information including a list of the Stratix V production devices, refer to the Errata Sheet for
Stratix V Devices.
Related Information
Errata Sheet for Stratix V Devices
MLAB Blocks in PR designs
Stratix V devices include dual-purpose blocks called MLABs, which can be used to implement RAMs or
LABs for user logic.
This section describes the restrictions while using MLAB blocks (sometimes also referred to as LUTRAM) in Stratix V devices for your PR designs.
If your design uses MLABS as LUT RAM, you must use all available MLAB bits within the region.
Table 4-6: RAM Implementation Restrictions Summary
The following table shows a summary of the LUT-RAM Restrictions.
PR Mode
SCRUB mode
Altera Corporation
Type of memory in PR region
Stratix V Production
LUT RAM (no initial content)
OK
LUT ROM and LUT RAM with
your initial content
OK
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Implementing Memories with Initialized Content
PR Mode
Type of memory in PR region
LUT RAM (no initial content)
4-41
Stratix V Production
While design is running: Write 1s
to all locations before partial
reconfiguration
At compile time: Explicitly
initialize all memory locations in
each new persona to 1 via initial‐
ization file (. mif).
AND/OR mode
LUT ROM and LUT RAM with
your initial content
No
If your design does not use any MLAB blocks as RAMs, the following discussion does not apply. The
restrictions listed below are the result of hardware limitations in specific devices.
Limitations with Stratix V Production Devices
When using SCRUB mode:
• LUT-RAMs without initialized content, LUT-RAMs with initialized content, and LUT-ROMs can be
implemented in MLABs within PR regions without any restriction.
When using AND/OR mode:
• LUT-RAMs with initialized content or LUT-ROMs cannot be implemented in a PR region.
• LUT-RAMs without initialized content in MLABs inside PR regions are supported with the following
restrictions.
• MLAB blocks contain 640 bits of memory. The LUT RAMs in PR regions in your design must occupy
all MLAB bits, you should not use partial MLABs.
• You must include control logic in your design with which you can write to all MLAB locations used
inside PR region.
• Using this control logic, write '1' at each MLAB RAM bit location in the PR region before starting the
PR process. This is to work around a false EDCRC error during partial reconfiguration.
• You must also specify a .mif that sets all MLAB RAM bits to '1' immediately after PR is complete.
• ROMs cannot be implemented in MLABs (LUT-ROMs).
• There are no restrictions to using MLABs in the static region of your PR design.
For more information, refer to the following documents in the Stratix V Handbook:
Related Information
Errata Sheet for Stratix V Devices
Implementing Memories with Initialized Content
If your Stratix V PR design implements ROMs, RAMs with initialization, or ROMs within the PR regions,
using either M20K blocks or LUT-RAMs, then you must follow the following design guidelines to
determine what is applicable in your case.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-42
QII5V1
2015.05.04
Implementing Memories with Initialized Content
Table 4-7: Implementing Memory with Initialized Content in PR Designs
Production Devices
Mode
AND/OR
Suggested Method
SCRUB
While design is running:
No special method
Write ‘1’ to all locations
required
before partial reconfigura‐
tion.
At compile time: Explicitly
initialize all memory
locations in each new
persona to ‘1’ via initializa‐
tion file (.mif)
LUT-RAM without
initialization
Make sure no spurious
write on PR entry (4)
Without Suggested
Method
CRC Error
Suggested Method
LUT-RAM with
initialization
Without Suggested
Method
Suggested Method
M20K without initiali‐
zation
Without Suggested
Method
Suggested Method
Without Suggested
Method
(5)
Make sure no spurious
write on PR exit (4)
Incorrect results
No special method required
No special method required
Use double PR cycle (5)
Make sure no spurious
write on PR exit (4)
M20K with initializa‐
tion
(4)
Not supported
No special method
required
Incorrect results
No special method
required
No special method
required
Use the circuit shown in the M20K/LUTRAM figure to create clock enable logic to safely exit partial
reconfiguration without spurious writes.
Double partial reconfiguration is described in Initializing M20K Blocks with a Double PR Cycle
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2015.05.04
Initializing M20K Blocks with a Double PR Cycle
4-43
Figure 4-23: M20K/LUTRAM
To avoid spurious writes during PR entry and exit, implement the following clock enable circuit in the
same PR region as the RAM.
M20K/LUTRAM
D SET Q
Clock Enable
Logic
CE
CLR Q
1
D SET Q
D SET Q
CLR Q
CLR Q
Clear Signal to
Safely Exit PR
The circuit depends on an active- high clear signal from the static region. Before entering PR, freeze this
signal in the same manner as all PR inputs. Your host control logic should de-assert the clear signal as the
final step in the PR process.
Related Information
Initializing M20K Blocks with a Double PR Cycle on page 4-43
Initializing M20K Blocks with a Double PR Cycle
When a PR region in your PR design contains an initialized M20K block and is reconfigured via AND/OR
mode, your host logic must complete a double PR cycle, instead of a single PR cycle.
The PR IP has a double_pr input port, that must be asserted high when your PR region contains RAM
blocks that must be initialized. The PR IP core handles the timing relations between the first and the
second PR cycles of a Double PR operation. From your user logic, assert the double_pr signal when you
assert the pr_start signal, and you deassert the double_pr signal when the freeze signal is deasserted by
the PR IP. This method is also applicable in cases when the programming bitstream is compressed or
encryted.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-44
QII5V1
2015.05.04
Document Revision History
Document Revision History
Table 4-8: Document Revision History
Date
Version
Changes
2015.05.04
15.0.0
• Correct Verilog HDL partial
reconfiguration instantiation
code example.
• Added clear/set method to
SCRUB mode option.
2015.12.15
14.1.0
Minor revisions to some topics
to resolve design refinements:
• Implementing Memories
with Initialized Content
• Instantiating the PR Control
Block and CRC Block in
Verilog HDL
• Partial Reconfiguration Pins
June 2014
14.0.0
Minor updates to "Programming
File Sizes for a Partial Reconfigu‐
ration Project" and code samples
in "Freeze Logic for PR Regions"
sections.
November 2013
13.1.0
Added support for merging
multiple .msf and .pmsf files.
Added support for PR
Megafunction.
Updated for revisions on timing
requirements.
May 2013
13.0.0
Added support for encrypted
bitstreams.
Updated support for double PR.
November 2012
12.1.0
Initial release.
Related Information
Quartus II Handbook Archive
For previous versions of the Quartus II Handbook.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
Creating a System With Qsys
5
2015.05.04
QII5V1
Subscribe
Send Feedback
Qsys is a system integration tool included as part of the Quartus II software. Qsys captures system-level
hardware designs at a high level of abstraction and simplifies the task of defining and integrating
customized IP components.
Qsys omponents include verification IP cores, and other design modules. Qsys facilitates design reuse by
packaging and integrating your custom IP components with AlteraAltera and third-party IP components.
Qsys automatically creates interconnect logic from the high-level connectivity that you specify, thereby
eliminating the error-prone and time-consuming task of writing HDL to specify system-level connections.
Qsys is more powerful if you design your custom IP components using standard interfaces. By using
standard interfaces, your custom IP components inter-operate with the Altera IP components in the IP
Catalog. In addition, you can take advantage of bus functional models (BFMs), monitors, and other
verification IP to verify your system.
Qsys supports Avalon®, AMBA® AXI3™ (version 1.0), AMBA AXI4™ (version 2.0), AMBA AXI4-Lite™
(version 2.0), AMBA AXI4-Stream (version 1.0), and AMBA APB™3 (version 1.0) interface specifications.
Qsys provides the following advantages:
•
•
•
•
•
•
•
•
•
Simplifies the process of customizing and integrating IP components into systems
Generates an IP core variation for use in your Quartus II software projects
Supports up to 64-bit addressing
Supports modular system design
Supports visualization of systems
Supports optimization of interconnect and pipelining within the system
Supports auto-adaptation of different data widths and burst characteristics
Supports inter-operation between standard protocols, such as Avalon and AXI
Fully integrated with the Quartus II software
Note: For information on how to define and generate single IP cores for use in your Quartus II software
projects, refer to Introduction to Altera IP Cores and Managing Quartus II Projects.
Related Information
•
•
•
•
Introduction to Altera IP Cores
Managing Quartus II Projects on page 1-1
Avalon Interface Specifications
AMBA Protocol Specifications
© 2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos are
trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as
trademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance
of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any
products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information,
product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device
specifications before relying on any published information and before placing orders for products or services.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
ISO
9001:2008
Registered
5-2
QII5V1
2015.05.04
IP Component Interface Support in Qsys
IP Component Interface Support in Qsys
IP components can have any number of interfaces in any combination. Each interface represents a set of
signals that you can connect within a Qsys system, or export outside of a Qsys system.
Qsys IP components can include the following interface types:
Table 5-1: IP Component Interface Types
Interface Type
Description
Memory-Mapped
Connects memory-referencing master devices with slave memory devices. Master
devices may be processors and DMAs, while slave memory devices may be RAMs,
ROMs, and control registers. Data transfers between master and slave may be unidirectional (read only or write only), or bi-directional (read and write).
Streaming
Connects Avalon Streaming (Avalon-ST) sources and sinks that stream unidirec‐
tional data, as well as high-bandwidth, low-latency IP components. Streaming
creates datapaths for unidirectional traffic, including multichannel streams, packets,
and DSP data. The Avalon-ST interconnect is flexible and can implement on-chip
interfaces for industry standard telecommunications and data communications
cores, such as Ethernet, Interlaken, and video. You can define bus widths, packets,
and error conditions.
Interrupts
Connects interrupt senders to interrupt receivers. Qsys supports individual,
single-bit interrupt requests (IRQs). In the event that multiple senders assert their
IRQs simultaneously, the receiver logic (typically under software control)
determines which IRQ has highest priority, then responds appropriately
Clocks
Connects clock output interfaces with clock input interfaces. Clock outputs can fanout without the use of a bridge. A bridge is required only when a clock from an
external (exported) source connects internally to more than one source.
Resets
Connects reset sources with reset input interfaces. If your system requires a
particular positive-edge or negative-edge synchronized reset, Qsys inserts a reset
controller to create the appropriate reset signal. If you design a system with multiple
reset inputs, the reset controller ORs all reset inputs and generates a single reset
output.
Conduits
Connects point-to-point conduit interfaces, or represent signals that are exported
from the Qsys system. Qsys uses conduits for component I/O signals that are not
part of any supported standard interface. You can connect two conduits directly
within a Qsys system as a point-to-point connection, or conduit interfaces can be
exported and brought to the top-level of the system as top-level system I/O. You can
use conduits to connect to external devices, for example external DDR SDRAM
memory, and to FPGA logic defined outside of the Qsys system.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Create a Qsys System
5-3
Create a Qsys System
Click Tools > Qsys in the Quartus II software to open Qsys. A .qsys or .qip file represents your Qsys
system in your Quartus II software project.
Related Information
• Creating Qsys Components on page 6-1
• Component Interface Tcl Reference on page 9-1
Start a New Project or Open a Recent Project in Qsys
1. To start a new Qsys project, save the default system that appears when you open Qsys (File > Save), or
click File > New System, and then save your new project.
Qsys saves the new project in the Quartus II project directory. To alternatively save your Qsys project
in a different directory, click File > Save As.
2. To open a recent Qsys project, click File > Open to browse for the project, or locate a recent project
with the File > Recent Projects command.
3. To revert the project currently open in Qsys to the saved version, click the first item in the Recent
Projects list.
Note: You can edit the directory path information in the recent_projects.ini file to reflect a new location
for items that appear in the Recent Projects list.
Specify the Target Device
In Qsys, the Device Family tab allows you to select the device family and device for your Qsys system. IP
components, parameters, and output options that appear with your Qsys system vary according to the
device type. Qsys saves device settings in the .qsys file.
When you generate your Qsys system, the generated output is for the Qsys-selected device, which may be
different than your Quartus II project device settings.
The Quartus II software always uses the device specified in the Quartus II project settings, even if you
have already generated your Qsys system with the Qsys-selected device.
Note: Qsys generates a warning message if the Qsys device family and device do not match the Quartus II
project settings. Also, when you open Qsys from within the Quartus II software, the Quartus II
project device settings apply.
Add IP Components to your Qsys System
In Qsys, the IP Catalog displays IP components available for your target device. Double-click any
component to launch the parameter editor. The parameter editor allows you to create a custom IP
variation of the selected component. A Qsys system can contain a single instance of an IP component, or
multiple, individually parameterized variations of the same IP component.
Some components have preset settings, which allow you to instantly apply preset parameter values
appropriate for a specific application. When you complete your customization and click Finish, the
component displays in the System Contents tab.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-4
Connect IP Components in Your Qsys System
QII5V1
2015.05.04
Right-click any IP component name in IP Catalog to display details about device support, installation
location, version, and links to documentation. The IP Catalog maintains multiple versions of a
component.
To locate a specific type of component, type some or all of the component’s name in the IP Catalog search
box. For example, you can type memory to locate memory-mapped IP components, or axi to locate AXI
IP. You can also filter the IP Catalog display with options on the right-click menu.
Figure 5-1: IP Catalog
Connect IP Components in Your Qsys System
The System Contents tab is the primary interface that you use to connect and configure components.
You connect interfaces of compatible types and opposite directions. For example, you can connect a
memory-mapped master interface to a slave interface, and an interrupt sender interface to an interrupt
receiver interface. You can connect any interfaces exported from a Qsys system within a parent Qsys
system.
Possible connections between interfaces appear as gray lines and open circles. To make a connection, click
the open circle at the intersection of the interfaces. When you make a connection, Qsys draws the
connection line in black and fills the connection circle. Clicking a filled-in circle removes a connection.
Qsys interconnect connects interface signals during system generation.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Create Connections Between Masters and Slaves
5-5
The Connections tab (View > Connections) shows a list of current and possible connections for selected
instances or interfaces in the Hierarchy or System Contents tabs. You can add and remove connections
by clicking the check box for each connection. Reporting columns provide information about each
connection. For example, Clock Crossing, Data Width, and Burst columns provide information after
system generation when the Qsys interconnect adds adapters that could possible result in slower fMax, or
larger area.
Figure 5-2: Connections Column in the System Contents Tab
When you finish adding connections, you can deselect Allow Connection Editing in the right-click
menu. This option sets the Connections column to read-only and hides the possible connections.
Related Information
Connecting Components
Create Connections Between Masters and Slaves
The Address Map tab provides the address range that each memory-mapped master must use to connect
to each slave in your system.
Qsys shows the slaves on the left, the masters across the top, and the address span of the connection in
each cell. If there is no connection between a master and a slave, the table cell is empty.
You can design a system where two masters access a slave at different addresses. If you use this feature,
Qsys labels the Base and End address columns in the System Contents tab as "mixed" rather than
providing the address range.
Follow these steps to change or create a connection between master and slave IP components:
1. In Qsys, click or open the Address Map tab.
2. Locate the table cell that represents the connection between the master and slave component pair.
3. Either type in a base address, or update the current base address in the cell.
Note: The base address of a slave component must be a multiple of the address span of the component.
This restriction is a requirement of the Qsys interconnect. The result is an efficient address
decoding logic, which allows Qsys to achieve the best possible fMAX.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-6
View Your Qsys System
QII5V1
2015.05.04
View Your Qsys System
Qsys allows you to change the display of your system to match your design development. Each tab on
View menu allows you to view your design with a unique perspective. Multiple tabs open in your
workspace allow you to focus on a selected element in your system under different perspectives.
Qsys GUI supports global selection and edit. When you make a selection or apply an edit in the
Hierarchy tab, Qsys updates all other open tabs to reflect your action. For example, when you select
cpu_0 in the Hierarchy tab, Qsys updates the Parameters tab to show the parameters for cpu_0.
By default, when you open Qsys, the IP Catalog and Hierarchy tab display to the left of the main frame.
The System Contents, Address Map, Interconnect Requirements, and Device Family tabs display in the
main frame.
The Messages tab displays in the lower portion of Qsys. Double-clicking a message in the Messages tab
changes focus to the associated element in the relevant tab to facilitate debugging. When the Messages tab
is closed or not open in your workspace, error and warning message counts continue to display in the
status bar of the Qsys window.
You can dock tabs in the main frame as a group, or individually by clicking the tab control in the upperright corner of the main frame. You can arrange your workspace by dragging and dropping, and then
grouping tabs in an order appropriate to your design development, or close or dock tabs that you are not
using. Tool tips on the upper-right corner of the tab describe possible workspace arrangements, for
example, restoring or disconnecting a tab to or from your workspace. When you save your system, Qsys
also saves the current workspace configuration. When you re-open a saved system, Qsys restores the last
saved workspace.
The Reset to System Layout command on the View menu restores the workspace to its default configura‐
tion for Qsys system design. The Reset to IP Layout command restores the workspace to its default
configuration for defining and generating single IP cores.
Note: Qsys contains some tabs which are not documented and appear on the View menu as "Beta". The
purpose in presenting these tabs is to allow designers to explore their usefulness in Qsys system
development.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Manage Qsys Window Views with Layouts
5-7
Figure 5-3: View Your Qsys System
Manage Qsys Window Views with Layouts
Qsys Layout controls what tabs are open in your Qsys design window. When you create a Qsys window
configuration that you want to keep, Qsys allows you to save that configuration as a custom layout. By
default, Qsys contains a layout suitable for Qsys system design, as well as a layout that allows you to easily
define and generate single IP cores for use in your Quartus II software projects.
1. To configure your Qsys window with a layout suitable for Qsys system design, click View > Reset to
System Layout.
The System Contents, Address Map, Interconnect Requirements, and Messages tabs open in the
main pane, and the IP Catalog and Hierarchy tabs along the left pane.
2. To configure your Qsys window with a layout suitable for single IP core design, click View > Reset to
IP Layout.
The Parameters and Messages tabs open in the main pane, and the Details, Block Symbol and
Presets tabs along the right pane.
3. To save your current Qsys window configuration as a custom layout, click View > Custom Layouts >
Save.
Qsys saves your custom layout in your project directory, and adds the layout to the custom layouts list,
and the layouts.ini file. The layouts.ini file controls the order in which the layouts appear in the list.
4. To reset your Qsys window configuration to a previously saved configuration, click View > Custom
Layouts, and then select the custom layout in the list.
The Qsys windows opens with your previously saved Qsys window configuration.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-8
Manage Qsys Window Views with Layouts
QII5V1
2015.05.04
Figure 5-4: Save Your Qsys Window Views and Layouts
5. To manage your saved custom layouts, click View > Custom Layouts.
The Manage Custom Layouts dialog box opens and allows you to apply a variety of functions that
facilitate custom layout management, including the ability to import or export a layout from or to a
different directory.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Filter the Display of the System Contents tab
5-9
Figure 5-5: Manage Custom Layouts
The shortcut, Ctrl-3, for example, allows you to quickly change your Qsys window view with a quick
keystroke.
Filter the Display of the System Contents tab
You can use the Filters dialog box in the to filter the display of your system by interface type, instance
name, or by using custom tags.
For example, in the System Contents tab, you can show only instances that include memory-mapped
interfaces, instances that are connected to a particular Nios II processor, or temporarily hide clock and
reset interfaces to simplify the display.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-10
QII5V1
2015.05.04
Display Details About a Component or Parameter
Figure 5-6: Filter Icon in the System Contents Tab
Related Information
Filters Dialog Box
Display Details About a Component or Parameter
The Details tab provides information for a selected component or parameter. Qsys updates the
information in the Details tab as you select different components.
As you click through the parameters for a component in the parameter editor, Qsys displays the descrip‐
tion of the parameter in the Details tab. To return to the complete description for the component, click
the header in the Parameters tab.
Display a Graphical Representation of a Component
In the Block Symbol tab, Qsys displays a graphical representation of the element that you select in the
Hierarchy or System Contents tabs. You can view the selected component's port interfaces and signals.
The Show signals option allows you to turn on or off signal graphics.
The Block Symbol tab appears by default in the parameter editor when you add a component to your
system. When the Block Symbol tab is open in your workspace, it reflects changes that you make in other
tabs.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
View a Schematic of Your Qsys System
5-11
View a Schematic of Your Qsys System
The Schematic tab displays a schematic representation of your Qsys system. Tab controls allow you to
zoom into a component or connection, or to obtain tooltip details for your selection. You can use the
image handles in the right panel to resize the schematic image.
If your selection is a subsystem, use the Hierarchy tool to navigate to the parent subsystem, move up one
level, or to drill into the currently open subsystem.
Figure 5-7: Qsys Schematic Tab
Related Information
Edit a Qsys Subsystem on page 5-32
View Assignments and Connections in Your Qsys System
On the Assignments tab (View > Assignments), you can view assignments for a module or element that
you select in the System Contents tab. The Connections tab displays a lists of connections in your Qsys
system. On the Connections tab (View > Connections), you can choose to connect or un-connect a
module in your system, and then view the results in the System Contents tab.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-12
Navigate Your Qsys System
QII5V1
2015.05.04
Figure 5-8: Assignments and Connections tabs in Qsys
Navigate Your Qsys System
The Hierarchy tab is a full system hierarchical navigator that expands the Qsys system contents to show
all elements in your system, including, subsystems, components, interfaces, signals, and connections.
You can use the Hierarchy tab to browse, connect, parameterize IP, and drive changes in other open tabs.
Expanding each interface in the Hierarchy tab allows you to view sub-components, associated elements,
and signals for the interface. You can focus on a particular area of your system by coordinating selections
in the Hierarchy tab with other open tabs in your workspace.
Navigating your system using the Hierarchy tab in conjunction with relevant tabs is useful during the
debugging phase because you can contain and focus your debugging efforts to a single element in your
system.
The Hierarchy tab provides the following information and functionality:
•
•
•
•
Altera Corporation
Connections between signals.
Names of signals in exported interfaces.
Right-click menu to connect, edit, add, remove, or duplicate elements in the hierarchy.
Internal connections of Qsys subsystems that are included as IP components. In contrast, the System
Contents tab displays only the exported interfaces of Qsys subsystems.
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Specify IP Component Parameters
5-13
Figure 5-9: Expanding System Contents in the Hierarchy Tab
The Hierarchy tab displays a unique icon for each element in the system. Context sensitivity between tabs
facilitates design development and debugging. For example, when you select an element in the Hierarchy
tab, Qsys selects the same element in other open tabs. This allows you to interact with your system in
more detail. In the example below, the ram_master selection appears selected in both the System
Contents and Hierarchy tabs.
Related Information
Create and Manage Hierarchical Qsys Systems on page 5-30
Specify IP Component Parameters
The Parameters tab allows you to specify parameters that define the IP component's functionality.
When you add a component to your system, or when you double-click a component in an open tab, the
parameter editor appears. Many IP components in the IP Catalog have parameters that you can configure.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-14
QII5V1
2015.05.04
Specify IP Component Parameters
If you create your own IP components, use the Hardware Component Description File (_hw.tcl) to
specify configurable parameters.
With the Parameters tab open, when you select an element in the Hierarchy tab, Qsys shows the same
element in the Parameters tab. You can then make changes to the parameters that appear in the
parameter editor, including changing the name for top-level instance that appears in the System Contents
tab. Changes that you make in the Parameters tab affect your entire system and appear dynamically in
other open tabs in your workspace.
In the parameter editor, the Documentation button provides information about a component's
parameters, including the version.
At the top of the parameter editor, Qsys shows the hierarchical path for the component and its elements.
This feature is useful when you navigate deep within your system with the Hierarchy tab.
Figure 5-10: Avalon-MM Write Master Timing Waveforms in the Parameters Tab
When you select an interface in the Hierarchy tab, the Parameters tab also allows you to review the
timing for that interface. Qsys displays the read and write waveforms at the bottom of the Parameters tab.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Configure Your IP Component with a Pre-Defined Set of Parameters
5-15
Configure Your IP Component with a Pre-Defined Set of Parameters
The Presets tab allows you to apply a pre-defined set of parameter values to your IP component. The
Presets tab opens the preset editor and allows you to create, modify, and save custom component
parameter values as a preset file. Not all IP components have preset files.
When you add a new component to your system, if there are preset values available for the component,
the preset editor appears in the parameter editor window and lists preset files that you can apply the
component. The name of each preset file describes a particular protocol and contains the required
parameter values for that protocol.
You can search for text to filter the Presets list. For example, if you add the DDR3 SDRAM Controller
with UniPHY component to your system, and type 1g micron 256 in the search box, the Presets list
shows only those parameter values that apply to the 1g micron 256 filter request. Presets whose parameter
values match the current parameter settings appear in bold.
If the available preset files do not meet the requirements of your design, you can create a new preset file.
In the presets editor, click New to open the New Preset dialog box. Specify the new custom preset name,
component version, description of the preset, and which parameters to include in the preset. You can also
specify where you want to save the preset file. If the file location that you specify is not already in the IP
search path, Qsys adds the location of the new preset file to the IP search path.
In the preset editor, click Update to update parameter values for a custom preset. The Update Preset
dialog box displays the default values, which you can edit, and the current value, which are static. Click
Delete to remove a custom preset from the Presets list.
When you access the presets editor by clicking View > Presets, you can apply the available presets to the
currently selected component.
Define Qsys Instance Parameters
You can use instance parameters to test the functionality of your Qsys system when you use another
system as a sub-component. A higher-level Qsys system can assign values to instance parameters, and
then test those values in the lower-level system.
The Instance Script on the Instance Parameters tab defines how the specified values for the instance
parameters affect the sub-components in your Qsys system. The instance script allows you to create
queries for the instance parameters and set the values of the parameters for the lower-level system
components.
When you click Preview Instance, Qsys creates a preview of the current Qsys system with the specified
parameters and instance script and opens the parameter editor. This command allows you to see how an
instance of a system appears when you use it in another system. The preview instance does not affect your
saved system.
To use instance parameters, the IP components or subsystems in your Qsys system must have parameters
that can be set when they are instantiated in a higher-level system.
If you create hierarchical Qsys systems, each Qsys system in the hierarchy can include instance
parameters to pass parameter values through multiple levels of hierarchy.
Related Information
Working with Instance Parameters in Qsys
Creating a System With Qsys
Send Feedback
Altera Corporation
5-16
QII5V1
2015.05.04
Create an Instance Parameter Script in Qsys
Create an Instance Parameter Script in Qsys
The first command in an instance parameter script must specify the Tcl command version. The version
command ensures the Tcl commands behave identically in future versions of the tool. Use the following
command to specify the version of the Tcl commands, where <version> is the Quartus II software version
number, such as 14.1:
package require -exact qsys <version>
To use Tcl commands that work with instance parameters in the instance script, you must specify the
commands within a Tcl composition callback. In the instance script, you specify the name for the
composition callback with the following command:
set_module_property COMPOSITION_CALLBACK <name of callback procedure>
Specify the appropriate Tcl commands inside the Tcl procedure with the following syntax:
proc <name of procedure defined in previous command> {}
{#Tcl commands to query and set parameters go here}
Example 5-1: Instance Parameter Script Example
In this example, an instance script uses the pio_width parameter to set the width parameter of a
parallel I/O (PIO) component. The script combines the get_parameter_value and
set_instance_parameter_value commands using brackets.
# Request a specific version of the scripting API
package require -exact qsys 13.1
# Set the name of the procedure to manipulate parameters:
set_module_property COMPOSITION_CALLBACK compose
proc compose {} {
# Get the pio_width parameter value from this Qsys system and
# pass the value to the width parameter of the pio_0 instance
set_instance_parameter_value pio_0 width \
[get_parameter_value pio_width]
}
Related Information
• Component Interface Tcl Reference on page 9-1
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Supported Tcl Commands for Qsys Instance Parameter Scripts
5-17
Supported Tcl Commands for Qsys Instance Parameter Scripts
You can use standard Tcl commands to manipulate parameters in the script, such as the set command to
create variables, or the expr command for mathematical manipulation of the parameter values. Instance
scripts also use Tcl commands to query the parameters of a Qsys system, or to set the values of the
parameters of the sub-IP-components instantiated in the system.
get_instance_parameter_value
Description
Returns the value of a parameter in a child instance.
Usage
get_instance_parameter_value <instance> <parameter>
Returns
The value of the parameter.
Arguments
instance
The name of the child instance.
parameter
The name of the parameter in the instance.
Example
get_instance_parameter_value pixel_converter input_DPI
Creating a System With Qsys
Send Feedback
Altera Corporation
5-18
get_instance_parameters
QII5V1
2015.05.04
get_instance_parameters
Description
Returns the names of all parameters on a child instance that can be manipulated by the parent. It omits
parameters that are derived and those that have the SYSTEM_INFO parameter property set.
Usage
get_instance_parameters <instance>
Returns
A list of parameters in the instance.
Arguments
instance
The name of the child instance.
Example
get_instance_parameters instance
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_parameter_value
5-19
get_parameter_value
Description
Returns the current value of a parameter defined previously with the add_parameter command.
Usage
get_parameter_value <parameter>
Returns
The value of the parameter.
Arguments
parameter
The name of the parameter whose value is being retrieved.
Example
get_parameter_value fifo_width
Creating a System With Qsys
Send Feedback
Altera Corporation
5-20
get_parameters
QII5V1
2015.05.04
get_parameters
Description
Returns the names of all the parameters in the component.
Usage
get_parameters
Returns
A list of parameter names.
Arguments
No arguments.
Example
get_parameters
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
send_message
5-21
send_message
Description
Sends a message to the user of the component. The message text is normally interpreted as HTML. The
<b> element can be used to provide emphasis. If you do not want the message text to be interpreted as
HTML, then pass a list like { Info Text } as the message level
Usage
send_message <level> <message>
Returns
No return value.
Arguments
level
The following message levels are supported:
•
•
•
•
•
ERROR--Provides an error message.
WARNING--Provides a warning message.
INFO--Provides an informational message.
PROGRESS--Provides a progress message.
DEBUG--Provides a debug message when debug mode is enabled.
message
The text of the message.
Example
send_message ERROR "The system is down!"
send_message { Info Text } "The system is up!"
Creating a System With Qsys
Send Feedback
Altera Corporation
5-22
set_instance_parameter_value
QII5V1
2015.05.04
set_instance_parameter_value
Description
Sets the value of a parameter for a child instance. Derived parameters and SYSTEM_INFO parameters for
the child instance may not be set using this command.
Usage
set_instance_parameter_value <instance> <parameter> <value>
Returns
No return value.
Arguments
instance
The name of the child instance.
parameter
The name of the parameter.
value
The new parameter value.
Example
set_instance_parameter_value uart_0 baudRate 9600
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
set_module_property
5-23
set_module_property
Description
Used to specify the Tcl procedure invoked to evaluate changes in Qsys system instance parameters.
Usage
set_module_property <property> <value>
Returns
No return value.
Arguments
property
The name of the property. Refer to Module Properties.
value
The new value of the property.
Example
set_module_property COMPOSITION_CALLBACK "my_composition_callback"
Creating a System With Qsys
Send Feedback
Altera Corporation
5-24
QII5V1
2015.05.04
Create a Custom IP Component (_hw.tcl)
Create a Custom IP Component (_hw.tcl)
Figure 5-11: Qsys System Design Flow
The Qsys system design flow describes how to create a custom IP component using the Qsys Component
Editor. You can optionally manually create a _hw_tcl file. The flow shows the simulation your custom IP,
and at what point you can integrate it with other IP components to create a Qsys system and complete
Quartus II project.
1
2
Create Component
Using Component Editor, or
by Manually Creating the
_hw.tcl File
Simulation at Unit-Level,
Possibly Using BFMs
Does
Simulation Give
Expected Results?
Yes
No
3
4
5
6
Debug Design
Complete System, Add and
Connect All IP Components,
Define Memory Map If
Needed
Generate Qsys
System
Perform System-Level
Simulation
Yes
8
9
No
Debug Design
Download .sof to PCB
with Altera FPGA
Does
HW Testing Give
Expected Results?
Does
Simulation Give
Expected Results?
7
Constrain, Compile
in Quartus II Generating .sof
Yes
Qsys System Complete
No
10
Modify Design or
Constraints
Note: For information on how to define and generate single IP cores for use in your Quartus II software
projects, refer to Introduction to Altera IP Cores.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Add IP Components to the Qsys IP Catalog
5-25
Related Information
Creating Qsys Components on page 6-1
Introduction to Altera IP Cores
Managing Quartus II Projects on page 1-1
Add IP Components to the Qsys IP Catalog
The Qsys IP Catalog lists IP components that you can use in your Qsys systems. IP components can
include Altera-provided, third-party, and custom IP components that you create on your own.
Because Qsys supports hierarchical design, previously created Qsys systems also appear in the IP Catalog.
Additionally, instance parameters set on a Qsys system, can be parameterized within a parent Qsys
system.
Altera and third-party developers provide ready-to-use IP components, which are installed with the
Quartus II software and appear in the IP Catalog. The Qsys IP Catalog includes the following IP
component types:
•
•
•
•
•
•
•
Microprocessors, such as the Nios® II processor
DSP IP components, such as the Reed Solomon Decoder II
Interface protocols, such as the IP Compiler for PCI Express
Memory controllers, such as the RLDRAM II Controller with UniPHY
Avalon Streaming (Avalon-ST) IP components, such as the Avalon-ST Multiplexer
Qsys Interconnect IP components
Verification IP (VIP) Bus Functional Models (BFMs)
You can use the IP Search Path option (Tools > Options) to include custom and third-party IP
components in the IP Catalog. The IP Catalog displays all IP cores that are found in the IP search path.
Qsys searches the directories listed in the IP search path for the following file types:
• *_hw.tcl—Defines a single IP component.
• *.ipx—Each IP Index File (.ipx) indexes a collection of available IP components, or a reference to other
directories to search. In general, .ipx files facilitate faster startup for Qsys because Qsys does not
traverse directories below the .ipx file. Additionally, the .ipx file can contain information about the IP
component, which eliminates the need for Qsys to read the _hw.tcl file to understand the basic
attributes of the IP core.
Qsys recursively searches directories specified in the IP search path until it finds a _hw.tcl file. When Qsys
finds a _hw.tcl file in a directory, Qsys does not search subdirectories for additional _hw.tcl files.
When you specify an IP search location in Qsys, a recursive descent is annotated by **. A single * signifies
a match against any file within the specified directory. However, even if a recursive descent is specified, if
Qsys finds a _hw.tcl or .ipx file, it does not search any subdirectories beyond that level.
Note: When you add a component to the search path, you must refresh your system by clicking File >
Refresh to update the IP Catalog.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-26
QII5V1
2015.05.04
Save IP Components to the Default Search Directory
Table 5-2: IP Search Locations
Location
Description
PROJECT_DIR/*
Finds IP components and index files in the Quartus II project
directory.
PROJECT_DIR/ip/**/*
Finds IP components and index files in any subdirectory of the /ip
subdirectory of the Quartus project directory.
Save IP Components to the Default Search Directory
The simplest method to add an IP component to the Qsys IP Catalog is to copy the IP component files
into an IP search path location.
When you create a component in the Qsys Component Editor, you can save the IP component in your
Qsys project directory, or in the /ip subdirectory of your Qsys project directory. These methods are useful
if you want to associate your IP component with a specific Qsys project.
You can also use the global IP search path in the Quartus II software (Tools > Options > IP Catalog
Search Locations) to modify the IP search path across all Quartus II projects, Qsys systems, and Altera
command line tools.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Save IP Components to the Default Search Directory
5-27
Figure 5-12: User IP Component Search
In this example, user_ip_components is a user-created directory for custom components.
<qsys_system>
ip
1
.
altera
altera_components.ipx
<ip components>
.
user_ip_components
2
ip_component1
ip_component1_hw.tcl
ip_component1.v
3
ip_component2
ip_component2_hw.tcl
ip_component2.v
Qsys performs the IP component search algorithm to locate .ipx and _hw.tcl files, as follows:
1. Qsys recursively searches the <qsys_system>/ip directory by default. The recursive search stops when
Qsys discovers an .ipx file.
Because of this traversal, if changes to the ip_component1_hw.tcl file are made, but the .ipx file is not
rebuilt using ip-make-ipx, those changes are not reflected in Qsys because the .ipx file contains old
information about the ip_component1 directory.
2. If the .ipx file is removed, Qsys discovers both the ip_component1 and ip_component2 directories,
which contain _hw.tcl files.
Note: If you save your _hw.tcl file in the <qsys_system>/ip directory, Qsys finds your _hw.tcl file and will
not search subdirectories adjacent to the _hw.tcl file. For more information about the IP search
path, refer to Introduction to Altera IP Cores.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-28
QII5V1
2015.05.04
Set up the IP Index File (.ipx) to Search for IP Components
Related Information
Introduction to Altera IP Cores
Set up the IP Index File (.ipx) to Search for IP Components
An IP Index File (.ipx) contains a search path that Qsys uses to search for IP components. You can use the
ip-make-ipx command to create an .ipx file for a any directory tree, which can reduce the startup time
for Qsys.
You can specify a search path in the user_components.ipx file in either in Qsys (Tools > Options) or the
Quartus II software (Tools > Options > IP Catalog Search Locations). This method of discovering IP
components allows you to add a locations dependent of the default search path. The
user_components.ipx file directs Qsys to the location of an IP component or directory to search.
A <path> element in the .ipx file specifies a directory where multiple IP components may be found. A
<component> entry specifies the path to a single component. A <path> element can use wildcards in its
definition. An asterisk matches any file name. If you use an asterisk as a directory name, it matches any
number of subdirectories.
Example 5-2: Path Element in an .ipx File
<library>
<path path="…<user directory>" />
<path path="…<user directory>" />
…
<component … file="…<user directory>" />
…
</library>
A <component> element in an .ipx file contains several attributes to define a component. If you provide
the required details for each component in an .ipx file, the startup time for Qsys is less than if Qsys must
discover the files in a directory. The example below shows two <component> elements. Note that the
paths for file names are specified relative to the .ipx file.
Example 5-3: Component Element in an .ipx File
<library>
<component
name="A Qsys Component"
displayName="Qsys FIR Filter Component"
version="2.1"
file="./components/qsys_filters/fir_hw.tcl"
/>
<component
name="rgb2cmyk_component"
displayName="RGB2CMYK Converter(Color Conversion Category!)"
version="0.9"
file="./components/qsys_converters/color/rgb2cmyk_hw.tcl"
/>
</library>
Note: You can verify that IP components are available with the ip-catalog command.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Integrate Third-Party IP Components into the Qsys IP Catalog
5-29
Related Information
Create an .ipx File with ip-make-ipx on page 5-74
Integrate Third-Party IP Components into the Qsys IP Catalog
You can use IP components created by Altera partners in your Qsys systems. These IP components have
interfaces that are supported by Qsys, such as Avalon-MM or AXI. Additionally, some include timing and
placement constraints, software drivers, simulation models, and reference designs.
To locate supported third-party IP components on Altera's web page, navigate to the Intellectual Property
& Reference Designs page, type Qsys Certified in the Search box, select IP Core & Reference
Designs, and then press Enter.
Refer to Altera's Intellectual Property & Reference Designs page for more information.
Related Information
Intellectual Property & Reference Designs
Upgrade Outdated IP Components
When you open a Qsys system that contains outdated IP components, Qsys automatically attempts to
upgrade the IP components if it cannot locate the requested version. IP components that Qsys successfully
updates appear in the Upgrade IP Cores dialog box with a green check mark. Most Qsys IP components
support automatic upgrade.
You can include a path to older IP components in the IP Search Path, which Qsys uses even if updated
versions are available. However, older versions of IP components may not work in newer version of Qsys.
Note: If your Qsys system includes an IP component(s) outside of the project directory, the directory of
the .qsys file, or other any other directory location, you must add these dependency paths to the
Qsys IP Search Path (Tools > Options).
1. With your Qsys system open, click System > Upgrade IP Cores.
Only IP Components that are associated with the open Qsys system, and that do not support
automatic upgrade appear in Upgrade IP Cores dialog box.
2. In the Upgrade IP Cores dialog box, click one or multiple IP components, and then click Upgrade.
A green check mark appears for the IP components that Qsys successfully upgrades.
3. Generate your Qsys system.
Note: Qsys supports command-line upgrade for IP components with the following command:
qsys-generate -–upgrade-ip-cores <qsys_file>
The <qsys_file> variable accepts a path to the .qsys file so that you are not constrained to running
this command in the same directory as the .qsys file. Qsys reports the start and finish of the
command-line upgrade, but does not name the particular IP component(s) upgraded.
For device migration information, refer to Introduction to Altera IP Cores.
Related Information
Add IP Components to the Qsys IP Catalog on page 5-25
Introduction to Altera IP Cores
Creating a System With Qsys
Send Feedback
Altera Corporation
5-30
Create and Manage Hierarchical Qsys Systems
QII5V1
2015.05.04
Create and Manage Hierarchical Qsys Systems
Qsys supports hierarchical system design. You can add any Qsys system as a subsystem in another Qsys
system. Qsys hierarchical system design allows you to create, explore and edit hierarchies dynamically
within a single instance of the Qsys editor. Qsys generates the complete hierarchy during the top-level
system’s generation.
Note: You can explore parameterizable Qsys systems and _hw.tcl files, but you cannot edit their elements.
Your Qsys systems appear in the IP Catalog under the System category under Project. You can reuse
systems across multiple designs. In a team-based hierarchical design flow, you can divide large designs
into subsystems and have team members develop subsystems simultaneously.
Related Information
Navigate Your Qsys System on page 5-12
Add a Subsystem to Your Qsys Design
You can create a child subsystem or nest subsystems at any level in the hierarchy. Qsys adds a subsystem
to the system you are currently editing. This can be the top-level system, or a subsystem.
To create or nest subsystems in your Qsys design, use the following methods within the System Contents
tab:
• Right-click command: Add a new subsystem to the current system.
• Left panel icon.
• CTRL+SHIFT+N.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Drill into a Qsys Subsystem to Explore its Contents
5-31
Figure 5-13: Add a Subsystem to Your Qsys Design
Drill into a Qsys Subsystem to Explore its Contents
The ability to drill into a system provides visibility into its elements and connections. When you drill into
an instance, you open the system it instantiates for editing.
You can drill into a subsystem with the following commands:
• Double-click a system in the Hierarchy tab.
• Right-click a system in the Hierarchy, System Contents, or Schematic tabs, and then select Drill into
subsystem.
• CTRL+SHIFT+D in the System Contents tab.
Note: You can only drill into .qsys files, not parameterizable Qsys systems or _hw.tcl files.
The Hierarchy tab is rooted at the top-level and drives global selection. You can manage a hierarchical
Qsys system that you build across multiple Qsys files, and view and edit their interconnected paths and
address maps simultaneously. As an example, you can select a path to a subsystem in the Hierarchy tab,
and then drill deeper into the subsystem in the System Contents or Schematic tabs. You could also select
a subsystem in the System Contents tab, and then drill into the selected susbsystem in the Hierarchy tab.
Views that manage system-level editing, for example, the System Contents and Schematic tabs, contain
the hierarchy widget, which allows you to efficiently navigate your subsystems. The hierarchy widget also
displays the name of the current selection, and its path in the context of the system or subsystem.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-32
QII5V1
2015.05.04
Edit a Qsys Subsystem
The hierarchy widget contains the following controls and information:
•
•
•
•
•
Top—Navigates to the project-level .qsys file that contains the subsystem.
Up—Navigates up one level from the current selection.
Drill Into—Allows you to drill into an editable system.
System—Displays the hierarchical location of the system you are currently editing.
Path—Displays the relative path to the current selection.
Note: In the System Contents tab, you can use CTRL+SHIFT+U to navigate up one level, and CTRL
+SHIFT+D to drill into a system.
Figure 5-14: Drill into a Qsys System to Explore its Contents
Edit a Qsys Subsystem
You can double-click a Qsys subsystem in the Hierarchy tab to edit its contents in any tab. When you
make a change, open tabs refresh their content to reflect your edit. You can change the level of a
subsystem, or push it into another subsystem with commands in the System Contents tab.
Note: To edit a .qsys file, the file must be writeable and reside outside of the ACDS installation directory.
You cannot edit systems that you create from composed _hw.tcl files, or systems that define
instance parameters.
1. In the System Contents or Schematic tabs, use the hierarchy widget to navigate to the top-level
system, up one level, or down one level (drill into a system).
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Change the Hierarchy Level of a Qsys Component
5-33
All tabs refresh and display the requested hierarchy level.
2. To edit a system, double-click the system in the Hierarchy tab. You can also drill into the system with
the Hierarchy tool or right-click commands, which are available in the Hierarchy, Schematic, System
Contents tabs.
The system is open and available for edit in all Qsys views. A system currently open for edit appears as
bold in the Hierarchy tab.
3. In the System Contents tab, you can rename any element, add, remove, or duplicate connections, and
export interfaces, as appropriate.
Changes to a subsystem affect all instances. Qsys identifies unsaved changes to a subsystem with an
asterisk next to the subsystem in the Hierarchy tab.
Related Information
View a Schematic of Your Qsys System on page 5-11
Change the Hierarchy Level of a Qsys Component
You can push selected components down into their own subsytem, which can simplify your top-level
system view. Similarly, you can pull a component up out of a subsystem to perhaps share it between two
unique subsystems. Hierarchical-level management facilitates system optimization and can reduce
complex connectivity in your subsystems. When you make a change, open tabs refresh their content to
reflect your edit.
1. In the System Contents tab, to group multiple components that perhaps share a system-level
component, select the components, right-click, and then select Push down into new subsystem.
Qsys pushes the components into their own subsystem and re-establishes the exported signals and
connectivity in the new location.
2. In the System Contents tab, to pull a component up out of a subsystem, select the component, and
then click Pull up.
Qsys pulls the component up out of the subsystem and re-establishes the exported signals and
connectivity in the new location.
Save New Qsys Subsystem
When you save a subsystem to your Qsys design, Qsys confirms the new subsystem(s) in the Confirm
New System Filenames dialog box. The Confirm New System Filenames dialog box appears when you
save your Qsys design. Qsys uses the name that you give a subsystem as .qsys filename, and saves the
subsystems in the project’s ip directory.
1. Click File > Save to save your Qsys design.
2. In the Confirm New System Filenames dialog box, click OK to accept the subsystem file names.
Note: If you have not yet saved your top-level system, or multiple subsystems, you can type a name,
and then press Enter, to move to the next un-named system.
3. In the Confirm New System Filenames dialog box, to edit the name of a subsystem, click the
subsystem, and then type the new name.
4. To cancel the save process, click Cancel in the Confirm New System Filenames dialog box.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-34
Create an IP Component Based on a Qsys System
QII5V1
2015.05.04
Create an IP Component Based on a Qsys System
The Export System as hw.tcl Component command on the Qsys File menu allows you to save the system
currently open in Qsys as an _hw.tcl file in project directory. The saved system displays as a new
component under the System category in the IP Catalog.
Hierarchical System Using Instance Parameters Example
This example illustrates how you can use instance parameters to control the implementation of an onchip memory component, onchip_memory_0 when instantiated into a higher-level Qsys system.
Follow the steps below to create a system that contains an on-chip memory IP component with instance
parameters, and the instantiating higher-level Qsys system. With your completed system, you can vary the
values of the instance parameters to review their effect within the On-Chip Memory component.
Create the Memory System
This procedure creates a Qsys system to use as subsystem as part of a hierarchical instance parameter
example.
1. In Qsys, click File > New System.
2. Right-click clk_0, and then click Remove.
3. In the IP Catalog search box, type on-chip to locate the On-Chip Memory (RAM or ROM)
component.
4. Double-click to add the On-Chip Memory component to your system.
The parameter editor opens. When you click Finish, Qsys adds the component to your system with
default selections.
5. Rename the On-Chip Memory component to onchip_memory_0.
6. In the System Contents tab, for the clk1 element (onchip_memory_0), double-click the Export
column.
7. In the System Contents tab, for the s1 element (onchip_memory_0), double-click the Export column.
8. In the System Contents tab, for the reset1 element (onchip_memory_0), double-click the Export
column.
9. Click File > Save to save your Qsys system as memory_system.qsys.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Add Qsys Instance Parameters
5-35
Figure 5-15: On-Chip Memory Component System and Instance Parameters (memory_system.qsys)
Add Qsys Instance Parameters
The Instance Parameters tab allows you to define parameters to control the implementation of a
subsystem component. Each column in the Instance Parameters table defines a property of the
parameter. This procedure creates instance parameters in a Qsys system to be used as a subsystem in a
higher-level system.
1. In the memory_system.qsys system, click View > Instance Parameters.
2. Click Add Parameter.
3. In the Name and Display Name columns, rename the new_parameter_0 parameter to
component_data_width.
4. For component_data_width, select Integer for Type, and 8 as the Default Value.
5. Click Add Parameter.
6. In the Name and Display Name columns, rename the new_parameter_0 parameter to
component_memory_size.
7. For component_memory_size, select Integer for Type, and 1024 as the Default Value.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-36
QII5V1
2015.05.04
Add Qsys Instance Parameters
Figure 5-16: Qsys Instance Parameters Tab
8. In the Instance Script section, type the commands that control how Qsys passes parameters to an
instance from the higher-level system. For example, in the script below, the onchip_memory_0 instance
receives its dataWidth and memorySize parameter values from the instance parameters that you
define.
# request a specific version of the scripting API
package require -exact qsys 15.0
# Set the name of the procedure to manipulate parameters
set_module_property COMPOSITION_CALLBACK compose
proc compose {} {
# manipulate parameters in here
set_instance_parameter_value onchip_memory_0 dataWidth [get_parameter_value
component_data_width]
set_instance_parameter_value onchip_memory_0 memorySize
[get_parameter_value component_memory_size]
set value [get_instance_parameter_value onchip_memory_0 dataWidth]
send_message info "Value of onchip memory ram data width is $value "
}
9. Click Preview Instance to open the parameter editor GUI.
Preview Instance allows you to see how an instance of a system appears when you use it in another
system.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Create a Qsys Instantiating Memory System
5-37
Figure 5-17: Preview Your Instance in the Parameter Editor
10.Click File > Save.
Create a Qsys Instantiating Memory System
This procedure creates a Qsys system to use as a higher-level system as part of a hierarchical instance
parameter example.
1. In Qsys, click File > New System.
2. Right-click clk_0, and then click Remove.
3. In the IP Catalog, under System, double-click memory_system.
The parameter editor opens. When you click Finish, Qsys adds the component to your system.
4. In the Systems Contents tab, for each element under system_0, double-click the Export column.
5. Click File > Save to save your Qsys as instantiating_memory_system.qsys.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-38
QII5V1
2015.05.04
Apply Instance Parameters at a Higher-Level Qsys System and Pass the Parameters
to the Instantiated Lower-Level System
Figure 5-18: Instantiating Memory System (instantiating_memory_system.qsys)
Apply Instance Parameters at a Higher-Level Qsys System and Pass the Parameters to the
Instantiated Lower-Level System
This procedure shows you how to use Qsys instance parameters to control the implementation of an onchip memory component as part of a hierarchical instance parameter example.
1. In the instantiating_memory_system.qsys system, in the Hierarchy tab, click and expand system_0
(memory_system.qsys).
2. Click View > Parameters.
The instance paramters for the memory_system.qsys display in the parameter editor.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Apply Instance Parameters at a Higher-Level Qsys System and Pass the Parameters
to the Instantiated Lower-Level System
5-39
Figure 5-19: Displays memory_system.qsys Instance Parameters in the Parameter Editor
3. On the Parameters tab, change the value of memory_data_width to 16, and memory_memory_size
to 2048.
4. In the Hierarchy tab, under system_0 (memory_system.qsys), click onchip_memory_0.
When you select onchip_memory_0, the new parameter values for Data width and Total memory size
size are displayed.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-40
QII5V1
2015.05.04
View and Filter Clock and Reset Domains in Your Qsys System
Figure 5-20: Changing the Values of Your Instance Parameters
View and Filter Clock and Reset Domains in Your Qsys System
The Qsys clock and reset domains tabs allow you to see clock domains and reset domains in your Qsys
system. Qsys determines clock and reset domains by the associated clocks and resets, which are displayed
in tooltips for each interface in your system. You can filter your system to display particular components
or interfaces within a selected clock or reset domain. The clock and reset domain tabs also provide quick
access to performance bottlenecks by indicating connection points where Qsys automatically inserts clock
crossing adapters and reset synchronizers during system generation. With these tools, you can more easily
create optimal connections between interfaces.
Click View > Clock Domains, or View > Reset Domains to open the respective tabs in your workspace.
The domain tools display as a tree with the current system at the root. You can select each clock or reset
domain in the list to view associated interfaces.
When you select an element in the Clock Domains tab, the corresponding selection appears in the
System Contents tab. You can select single or multiple interface(s) and module(s). Mouse over tooltips in
the System Contents tab to provide detailed information for all elements and connections. Colors that
appear for the clocks and resets in the domain tools correspond to the colors in the System Contents and
Schematic tabs.
Clock and reset control tools at the bottom on the System Contents tab allow you to toggle between
highlighting clock or reset domains. You can further filter your view with options in the Filters dialog
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
View Clock Domains in Your Qsys System
5-41
box, which is accessible by clicking the filter icon at the bottom of the System Contents tab. In the Filters
dialog box, you can choose to view a single interface, or to hide clock, reset, or interrupt interfaces.
Clock and reset domain tools respond to global selection and edits, and help to provide answers to the
following system design questions:
•
•
•
•
•
How many clock and reset domains do you have in your Qsys system?
What interfaces and modules does each clock or reset domain contain?
Where do clock or reset crossings occur?
At what connection points does Qsys automatically insert clock or reset adapters?
Where do you have to manually insert a clock or reset adapter?
Figure 5-21: Qsys Clock and Reset Domains
View Clock Domains in Your Qsys System
With the Clock Domains tab, you can filter the System Contents tab to display a single clock domain, or
multiple clock domains. You can further filter your view with selections in the Filters dialog box. When
you select an element in the Clock Domains tab, the corresponding selection appears highlighted in the
System Contents tab.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-42
View Clock Domains in Your Qsys System
QII5V1
2015.05.04
1. To view clock domain interfaces and their connections in your Qsys system, click View > Clock
Domains to open the Clock Domains tab.
2. To enables and disable highlighting of the clock domains in the System Contents tab, click the clock
control tool at the bottom of the System Contents tab.
Figure 5-22: Clock Control Tool
3. To view a single clock domain, or multiple clock domains and their modules and connections, click the
clock name(s) in the Clock Domains tab.
The modules for the selected clock domain(s) and their connections appear highlighted in the System
Contents tab. Detailed information for the current selection appears in the clock domain details pane.
Red dots in the Connections column indicate auto insertions by Qsys during system generation, for
example, a reset synchronizer or clock crossing adapter.
Figure 5-23: Clock Domains
4. To view interfaces that cross clock domains, expand the Clock Domain Crossings icon in the Clock
Domains tab, and select each element to view its details in the System Contents tab.
Qsys lists the interfaces that cross clock domain under Clock Domain Crossings. As you click through
the elements, detailed information appears in the clock domain details pane. Qsys also highlights the
selection in the System Contents tab.
If a connection crosses a clock domain, the connection circle appears as a red dot in the System
Contents tab. Mouse over tooltips at the red dot connections provide details about the connection, as
well as what adapter type Qsys automatically inserts during system generation.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
View Reset Domains in Your Qsys System
5-43
Figure 5-24: Clock Domain Crossings
View Reset Domains in Your Qsys System
With the Reset Domains tab, you can filter the System Contents tab to display a single reset domain, or
multiple reset domains. When you select an element in the Reset Domains tab, the corresponding
selection appears in the System Contents tab.
1. To view reset domain interfaces and their connections in your Qsys system, click View > Reset
Domains to open the Reset Domains tab.
2. To show reset domains in the System Contents tab, click the reset control tool at the bottom of the
System Contents tab.
Figure 5-25: Reset Control Tool
3. To view a single reset domain, or multiple reset domains and their modules and connections, click the
reset name(s) in the Reset Domain tab.
Qsys displays your selection according to the following rules:
Creating a System With Qsys
Send Feedback
Altera Corporation
5-44
QII5V1
2015.05.04
Filter Qsys Clock and Reset Domains in the System Contents Tab
• When you select multiple reset domains, the System Contents tab shows interfaces and modules in
both reset domains.
• When you select a single reset domain, the other reset domain(s) are grayed out, unless the two
domains have interfaces in common.
• Reset interfaces appear black when connected to multiple reset domains.
• Reset interfaces appear gray when they are not connected to all of the selected reset domains.
• If an interface is contained in multiple reset domains, the interface is grayed out.
Detailed information for your selection appears in the reset domain details pane.
Note: Red dots in the Connections column between reset sinks and sources indicate auto insertions
by Qsys during system generation, for example, a reset synchronizer. Qsys decides when to
display a red dot with the following protocol, and ends the decision process at first match.
• Multiple resets fan into a common sink.
• Reset inputs are associated with different clock domains.
• Reset inputs have different synchronicity.
Figure 5-26: Reset Domains
Filter Qsys Clock and Reset Domains in the System Contents Tab
You can filter the display of your Qsys clock and reset domains in the System Contents tab.
1. To filter the display in the System Contents tab to view only a particular interface and its connections,
or to choose to hide clock, reset, or interrupt interfaces, click the Filters icon in the clock and reset
control tool to open the Filters dialog box.
The selected interfaces appear in the System Contents tab.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Specify Qsys Interconnect Requirements
5-45
Figure 5-27: Filters Dialog Box
2. To clear all clock and reset filters in the System Contents tab and show all interfaces, click the Filters
icon with the red "x" in the clock and reset control tool.
Figure 5-28: Show All Interfaces
Specify Qsys Interconnect Requirements
The Interconnect Requirements tab allows you to apply system-wide, $system, and interface
interconnect requirements for IP components in your system. Options in the Setting column vary
depending on what you select in the Identifier column
Table 5-3: Specifying System-Wide Interconnect Requirements
Option
Limit interconnect pipeline
stages to
Creating a System With Qsys
Send Feedback
Description
Specifies the maximum number of pipeline stages that Qsys may insert in
each command and response path to increase the fMAX at the expense of
additional latency. You can specify between 0–4 pipeline stages, where 0
means that the interconnect has a combinational data path. Choosing 3 or
4 pipeline stages may significantly increase the logic utilization of the
system. This setting is specific for each Qsys system or subsystem,
meaning that each subsystem can have a different setting. Additional
latency is added once on the command path, and once on the response
path. You can manually adjust this setting in the Memory-Mapped
Interconnect tab. Access this tab by clicking Show System With Qsys
Interconnect command on the System menu.
Altera Corporation
5-46
QII5V1
2015.05.04
Specify Qsys Interconnect Requirements
Option
Clock crossing adapter type
Description
Specifies the default implementation for automatically inserted clock
crossing adapters:
• Handshake—This adapter uses a simple hand-shaking protocol to
propagate transfer control signals and responses across the clock
boundary. This methodology uses fewer hardware resources because
each transfer is safely propagated to the target domain before the next
transfer can begin. The Handshake adapter is appropriate for systems
with low throughput requirements.
• FIFO—This adapter uses dual-clock FIFOs for synchronization. The
latency of the FIFO-based adapter is a couple of clock cycles more than
the handshaking clock crossing component. However, the FIFO-based
adapter can sustain higher throughput because it supports multiple
transactions at any given time. FIFO-based clock crossing adapters
require more resources. The FIFO adapter is appropriate for
memory-mapped transfers requiring high throughput across clock
domains.
• Auto—If you select Auto, Qsys specifies the FIFO adapter for bursting
links, and the Handshake adapter for all other links.
Automate default slave
insertion
Specifies whether you want Qsys to automatically insert a default slave for
undefined memory region accesses during system generation.
Enable instrumentation
Allows you to choose the converter type that Qsys applies to each burst.
•
• Generic converter (slower, lower area)—Default. Controls all burst
conversions with a single converter that is able to adapt incoming
burst types. This results in an adapter that has lower fmax, but smaller
area.
• Per-burst-type converter (faster, higher area)—Controls incoming
bursts with a particular converter, depending on the burst type. This
results in an adapter that has higher fmax, but higher area. This setting
is useful when you have AXI masters or slaves and you want a higher
fmax.
Burst Adapter Implementa‐
tion
Altera Corporation
Allows you to choose the converter type that Qsys applies to each burst.
• Generic converter (slower, lower area)—Default. Controls all burst
conversions with a single converter that is able to adapt incoming
burst types. This results in an adapter that has lower fmax, but smaller
area.
• Per-burst-type converter (faster, higher area)—Controls incoming
bursts with a particular converter, depending on the burst type. This
results in an adapter that has higher fmax, but higher area. This setting
is useful when you have AXI masters or slaves and you want a higher
fmax.
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Manage Qsys System Security
Option
Enable ECC protection
5-47
Description
Specifies the default implementation for ECC protection for memory
elements. Currently supports only Read Data FIFO (rdata_FIFO)
instances..
• FALSE—Default. ECC protection is disabled for memory elements in
the Qsys interconnect.
• TRUE—ECC protection is enabled for memory elements. Qsys
interconnect sends ECC errors that cannot be corrected as
DECODEERROR (DECERR) on the Avalon response bus. This setting may
increase logic utilization and cause lower fMax, but provides additional
protection against data corruption.
Note: For more information about Error Correction Coding (ECC),
refer to Error Correction Coding in Qsys Interconnect.
Table 5-4: Specifying Interface Interconnect Requirements
You can apply the following interconnect requirements when you select a component interface as the Identifier in
the Interconnect Requirements tab, in the All Requirements table.
Option
Security
Value
•
•
•
•
Non-secure
Secure
Secure ranges
TrustZone-aware
Description
After you establish connections between the
masters and slaves, allows you to set the
security options, as needed, for each master
and slave in your system.
Note: You can also set these values in the
Security column in the System
Contents tab.
Secure address ranges
Accepts valid address
range.
Allows you to type in any valid address range.
For more information about HPS, refer to the Cyclone V Device Handbook in volume 3 of the Hard
Processor System Technical Reference Manual.
Related Information
Error Correction Coding in Qsys Interconnect
Manage Qsys System Security
TrustZone is the security extension of the ARM®-based architecture. It includes secure and non-secure
transactions designations, and a protocol for processing between the designations. TrustZone security
support is a part of the Qsys interconnect.
The AXI AxPROT protection signal specifies a secure or non-secure transaction. When an AXI master
sends a command, the AxPROT signal specifies whether the command is secure or non-secure. When an
AXI slave receives a command, the AxPROT signal determines whether the command is secure or nonCreating a System With Qsys
Send Feedback
Altera Corporation
5-48
QII5V1
2015.05.04
Configure Qsys Security Settings Between Interfaces
secure. Determining the security of a transaction while sending or receiving a transaction is a run-time
protocol.
The Avalon specification does not include a protection signal as part of its specification. When an Avalon
master sends a command, it has no embedded security and Qsys recognizes the command as non-secure.
When an Avalon slave receives a command, it also has no embedded security, and the slave always accepts
the command and responds.
AXI masters and slaves can be TrustZone-aware. All other master and slave interfaces, such as AvalonMM interfaces, are non-TrustZone-aware. You can set compile-time security support for all components
(except AXI masters, including AXI3, AXI4,and AXI4-Lite) in the Security column in the System
Contents tab, or in the Interconnect Requirements tab under the Identifier column for the master or
slave interface. To begin creating a secure system, you must first add masters and slaves to your system,
and the connections between them. After you establish connections between the masters and slaves, you
can then set the security options, as needed
An example of when you may need to specify compile-time security support is when an Avalon master
needs to communicate with a secure AXI slave, and you can specify whether the connection point is
secure or non-secure. You can specify a compile-time secure address ranges for a memory slave if an
interface-level security setting is not sufficient.
Related Information
• Qsys Interconnect on page 7-1
• Qsys System Design Components on page 10-1
Configure Qsys Security Settings Between Interfaces
The AXI AxPROT signal specifies a transaction as secure or non-secure at runtime when a master sends a
transaction. Qsys identifies AXI master interfaces as TrustZone-aware. You can configure AXI slaves as
Trustzone-aware, secure, non-secure, or secure ranges.
Table 5-5: Compile-Time Security Options
For non-TrustZone-aware components, compile-time security support options are available in Qsys on the
System Contents tab, or on the Interconnect Requirements tab.
Compile-Time Security Options
Description
Non-secure
Master sends only non-secure transactions, and the slave receives
any transaction, secure or non-secure.
Secure
Master sends only secure transactions, and the slave receives only
secure transactions.
Secure ranges
Applies to only the slave interface. The specified address ranges
within the slave's address span are secure, all other address ranges
are not. The format is a comma-separated list of inclusive-low and
inclusive-high addresses, for example, 0x0:0xfff,
0x2000:0x20ff.
After setting compile-time security options for non-TrustZone-aware master and slave interfaces, you
must identify those masters that require a default slave before generation. To designate a slave interface as
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Specify a Default Slave in a Qsys System
5-49
the default slave, turn on Default Slave in the System Contents tab. A master can have only one default
slave.
Note: The Security and Default Slave columns in the System Contents tab are hidden by default. Rightclick the System Contents header to select which columns you want to display.
The following are descriptions of security support for master and slave interfaces. These description can
guide you in your design decisions when you want to create secure systems that have mixed secure and
non-TrustZone-aware components:
• All AXI, AXI4, and AXI4-Lite masters are TrustZone-aware.
• You can set AXI, AXI4, and AXI4-Lite slaves as Trust-Zone-aware, secure, non-secure, or secure range
ranges.
• You can set non-AXI master interfaces as secure or non-secure.
• You can set non-AXI slave interfaces as secure, non-secure, or secure address ranges.
Specify a Default Slave in a Qsys System
If a master issues "per-access" or "not allowed" transactions, your design must contain a default slave. Peraccess refers to the ability of a TrustZone-aware master to allow or disallow access or transactions. A
transaction that violates security is rerouted to the default slave and subsequently responds to the master
with an error. You can designate any slave as the default slave.
You can share a default slave between multiple masters. You should have one default slave for each
interconnect domain. An interconnect domain is a group of connected memory-mapped masters and
slaves that share the same interconnect. The altera_axi_default_slave component includes the
required TrustZone features.
You can achieve an optimized secure system by partitioning your design and carefully designating secure
or non-secure address maps to maintain reliable data. Avoid a design where, under the same hierarchy, a
non-secure master initiates transactions to a secure slave resulting in unsuccessful transfers.
Table 5-6: Secure and Non-Secure Access Between Master, Slave, and Memory Components
Transaction Type
TrustZone-aware
slave/memory
TrustZone-aware Master
Non-TrustZone-aware
Master
Secure
Non-Secure
OK
OK
Non-TrustZone-aware Per-access
slave (secure)
OK
Not allowed
Non-TrustZone-aware OK
slave (non-secure)
OK
OK
Non-TrustZone-aware Per-access
memory (secure
region)
OK
Not allowed
Creating a System With Qsys
Send Feedback
OK
Non-TrustZone-aware
Master
Altera Corporation
5-50
QII5V1
2015.05.04
Access Undefined Memory Regions
Transaction Type
TrustZone-aware Master
Non-TrustZone-aware OK
memory (non-secure
region)
Non-TrustZone-aware
Master
Non-TrustZone-aware
Master
Secure
Non-Secure
OK
OK
Access Undefined Memory Regions
When a transaction from a master targets a memory region that is not specified in the slave memory map,
it is known as an "access to an undefined memory region." To ensure predictable response behavior when
this occurs, you must add a default slave to your design. Qsys then routes undefined memory region
accesses to the default slave, which terminates the transaction with an error response.
You can designate any memory-mapped slave as a default slave. Altera recommends that you have only
one default slave for each interconnect domain in your system. Accessing undefined memory regions can
occur in the following cases:
• When there are gaps within the accessible memory map region that are within the addressable range of
slaves, but are not mapped.
• Accesses by a master to a region that does not belong to any slaves that is mapped to the master.
• When a non-secured transaction is accessing a secured slave. This applies to only slaves that are
secured at compilation time.
• When a read-only slave is accessed with a write command, or a write-only slave is accessed with a read
command.
To designate a slave as the default slave, for the selected component, turn on Default Slave in the Systems
Content tab.
Note: If you do not specify the default slave, Qsys automatically assigns the slave at the lowest address
within the memory map for the master that issues the request as the default slave.
Related Information
• Qsys System Design Components on page 10-1
Integrate a Qsys System with the Quartus II Software
To integrate a Qsys system with your Quartus II project, you must add either the Qsys System File (.qsys)
or the Quartus II IP File (.qip), but never both to your Quartus II project. Qsys creates the .qsys file when
you save your Qsys system, and produces the .qip file when you generate your Qsys system. Both the .qsys
and .qip files contain the information necessary for compiling your Qsys system within a Quartus II
project.
You can choose to include the .qsys file automatically in your Quartus II project when you generate your
Qsys system by turning on the Automatically add Quartus II IP files to all projects option in the
Quartus II software (Tools > Options > IP Settings). If this option is turned off, the Quartus II software
asks you if you want to include the .qsys file in your Quartus II project after you exit Qsys.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Integrate a Qsys System and the Quartus II Software With the .qsys File
5-51
If you want file generation to occur as part of the Quartus II software's compilation, you should include
the .qsys file in your Quartus II project. If you want to manually control file generation outside of the
Quartus II software, you should include the .qip file in your Quartus II project.
Note: The Quartus II software generates an error message during compilation if you add both the .qsys
and .qip files to your Quartus II project.
Does Quartus II Overwrite Qsys-Generated Files During Compilation?
Qsys supports standard and legacy device generation. Standard device generation refers to generating files
for the Arria 10 device, and later device families. Legacy device generation refers to generating files for
device families prior to the release of the Arria 10 device, including Max 10 devices.
When you integrate your Qsys system with the Quartus II software, if a .qsys file is included as a source
file, Qsys generates standard device files under <system>/ next to the location of the .qsys file. For legacy
devices, if a .qsys file is included as a source file, Qsys generates HDL files in the Quartus II project
directory under /db/ip.
For standard devices, Qsys-generated files are only overwritten during Quartus II compilation if the .qip
file is removed or missing. For legacy devices, each time you compile your Quartus II project with a .qsys
file, the Qsys-generated files are overwritten. Therefore, you should not edit Qsys-generated HDL in the /
db/ip directory; any edits made to these files are lost and never used as input to the Quartus HDL synthesis
engine.
Related Information
•
•
•
•
•
•
Add IP Components to the Qsys IP Catalog on page 5-25
Generate a Qsys System on page 5-54
Qsys Synthesis Standard and Legacy Device Output Directories on page 5-58
Qsys Simulation Standard and Legacy Device Output Directories on page 5-59
Introduction to Altera IP Cores
Implementing and Parameterizing Memory IP
Integrate a Qsys System and the Quartus II Software With the .qsys File
Use the following steps to integrate your Qsys system and your Quartus II project using the .qsys file:
1. In Qsys, create and save a Qsys system.
2. To automatically include the .qsys file in the your Quartus II project during compilation, in the
Quartus II software, select Tools > Options > IP Settings, and turn on Automatically add Quartus II
IP files to all projects.
3. When the Automatically add Quartus II IP files to all projects option is not checked, when you exit
Qsys, the Quartus II software displays a dialog box asking whether you want to add the .qsys file to
your Quartus II project. Click Yes to add the .qsys file to your Quartus II project.
4. In the Quartus II software, select Processing > Start Compilation.
Integrate a Qsys System and the Quartus II Software With the .qip File
Use the following steps to integrate your Qsys system and your Quartus II project using the .qip file:
Creating a System With Qsys
Send Feedback
Altera Corporation
5-52
QII5V1
2015.05.04
Manage IP Settings in the Quartus II Software
1.
2.
3.
4.
5.
In Qsys, create and save a Qsys system.
In Qsys, click Generate HDL.
In the Quartus II software, select Assignments > Settings > Files.
On the Files page, use the controls to locate your .qip file, and then add it to your Quartus II project.
In the Quartus II software, select Processing > Start Compilation.
Manage IP Settings in the Quartus II Software
To specify the following IP Settings in the Quartus II software, click Tools > Option > IP Settings:
Table 5-7: IP Settings
Setting
Description
Maximum Qsys memory usage
Allows you to increase memory usage for Qsys if
you experience slow processing for large systems, or
if Qsys reports an Out of Memory error.
IP generation HDL preference
The Quartus II software uses this setting when
the .qsys file appears in the Files list for the current
project in the Settings dialog box and you run
Analysis & Synthesis. Qsys uses this setting when
you generate HDL files.
Automatically add Quartus II IP files to all
projects
The Quartus II software uses this setting when you
create an IP core file variation with options in the
Quartus II IP Catalog and parameter editor. When
turned on, the Quartus II software adds the IP
variation files to the project currently open.
IP Catalog Search Locations
The Quartus II software uses the settings that you
specify for global and project search paths under IP
Search Locations, in addition to the IP Search Path
in Qsys (Tools > Options), to populate the Quartus
II software IP Catalog.
Qsys uses the uses the settings that you specify for
global search paths under IP Search Locations to
populate the Qsys IP Catalog, which appears in
Qsys (Tools > Options). Qsys uses the project
search path settings to populate the Qsys IP Catalog
when you open Qsys from within the Quartus II
software (Tools > Qsys), but not when you open
Qsys from the command-line.
Note: You can also access IP Settings by clicking Assignments > Settings > IP Settings. This access is
available only when you have a Quartus II project open. This allows you access to IP Settings when
you want to create IP cores independent of a Quartus II project. Settings that you apply or create in
either location are shared.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Opening Qsys with Additional Memory
5-53
Opening Qsys with Additional Memory
If your Qsys system requires more than the 512 megabytes of default memory, you can increase the
amount of memory either in the Quartus II software Options dialog box, or at the command-line.
• When you open Qsys from within the Quartus II software, you can increase memory for your Qsys
system, by clicking Tools > Options > IP Settings, and then selecting the appropriate amount of
memory with the Maximum Qsys memory usage option.
• When you open Qsys from the command-line, you can add an option to increase the memory. For
example, the following qsys-edit command allows you to open Qsys with 1 gigabytes of memory.
qsys-edit --jvm-max-heap-size=1g
Set Qsys Clock Constraints
Many IP components include Synopsys Design Constraint (.sdc) files that provide timing constraints.
Generated .sdc files are included in your Quartus II project with the generated .qip file. For your top-level
clocks and PLLs, you must provide clock and timing constraints in SDC format to direct synthesis and
fitting to optimize the design appropriately, and to evaluate performance against timing constraints.
You can specify a base clock assignment for each clock input in the TimeQuest GUI or with the
create_clock command, and then use the derive_pll_clocks command to define the PLL clock output
frequencies and phase shifts for all PLLs in the Quartus II project using the .sdc file.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-54
Generate a Qsys System
QII5V1
2015.05.04
Figure 5-29: Single Clock Input Signal
For the case of a single clock input signal called clk, and one PLL with a single output, you can use the
following commands in your Synopsys Design Constraint (.sdc) file:
create_clock -name master_clk -period 20 [get_ports {clk}]
derive_pll_clocks
Related Information
The Quartus II TimeQuest Timing Analyzer
Generate a Qsys System
In Qsys, you can choose options for generation of synthesis, simulation and testbench files for your Qsys
system.
Qsys system generation creates the interconnect between IP components and generates synthesis and
simulation HDL files. You can generate a testbench system that adds Bus Functional Models (BFMs) that
interact with your system in a simulator.
When you make changes to a system, Qsys gives you the option to exit without generating. If you choose
to generate your system before you exit, the Generation dialog box opens and allows you to select
generation options.
The Generate HDL button in the lower-right of the Qsys window allows you to quickly generate synthesis
and simulation files for your system.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Set the Generation ID
5-55
Note: If you cannot find the memory interface generated by Qsys when you use EMIF (External Memory
Interface Debug Toolkit), verify that the .sopcinfo file appears in your Qsys project folder.
Related Information
• Avalon Verification IP Suite User Guide
• Mentor Verification IP (VIP) Altera Edition (AE)
• External Memory Interface Debug Toolkit
Set the Generation ID
The Generation Id parameter is a unique integer value that is set to a timestamp during Qsys system
generation. System tools, such as NIOS II or HPS (Hard Processor System) use the Generation ID to
ensure software-build compatibility with your Qsys system.
To set the Generation Id parameter, select the top-level system in the Hierarchy tab, and then locating
the parameter in the open Parameters tab.
Generate Files for Synthesis and Simulation
The Quartus II software uses Qsys-generated synthesis HDL files during compilation.
In Qsys, you can generate simulation HDL files (Generate > Generate HDL), which can include
simulation-only features targeted towards your simulator. You can generate simulation files as Verilog,
VHDL, or as a mixed-language simulation for use in your simulation environment.
Note: For a list of Altera-supported simulators, refer to Simulating Altera Designs.
Qsys supports standard and legacy device generation. Standard device generation refers to generating files
for the Arria 10 device, and later device families. Legacy device generation refers to generating files for
device families prior to the release of the Arria 10 device, including Max 10 devices.
The Output Directory option applies to both synthesis and simulation generation. By default, the path of
the generation output directory is fixed relative to the .qsys file. You can change the default directory in
the Generation dialog box for legacy devices. For standard devices, the generation directory is fixed to the
Qsys project directory.
Note: If you need to change top-level I/O pin or instance names, create a top-level HDL file that instanti‐
ates the Qsys system. The Qsys-generated output is then instantiated in your design without
changes to the Qsys-generated output files.
The following options in the Generation dialog box (Generate > Generate HDL) allow you to generate
synthesis and simulation files:
Option
Create HDL design files for synthesis
Creating a System With Qsys
Send Feedback
Description
Generates Verilog HDL or VHDL design files for
the system's top-level definition and child instances
for the selected target language. Synthesis file
generation is optional.
Altera Corporation
5-56
QII5V1
2015.05.04
Files Generated for Qsys IP Components
Option
Description
Create timing and resource estimates for thirdparty EDA synthesis tools
Generates a non-functional Verilog Design File (.v)
for use by some third-party EDA synthesis tools.
Estimates timing and resource usage for your IP
component. The generated netlist file name is
<your_ip_component_name>_syn.v.
Create Block Symbol File (.bsf)
Allows you to optionally create a (.bsf) file to use in
a schematic Block Diagram File (.bdf).
Create simulation model
Allows you to optionally generate Verilog HDL or
VHDL simulation model files, and simulation
scripts.
Allow mixed-language simulation
Generates a simulation model that contains both
Verilog and VHDL as specified by the individual IP
cores. Using this option, each IP core produces their
HDL using it's native implementation, which results
in simulation HDL that is easier to understand and
faster to simulate. You must have a simulator that
supports mixed language simulation.
Note: Modelsim-Altera now supports native mixed-language (VHDL/Verilog/SystemVerilog)
simulation. Therefore, Altera simulation libraries may not be compatible with single language
simulators. If you have a VHDL-only license, some versions of Mentor simulators may not be able
to simulate IP written in Verilog. As a workaround, you can use Modelsim-Altera, or purchase a
mixed language simulation license from Mentor.
Related Information
Simulating Altera Designs
Files Generated for Qsys IP Components
Qsys generates the following files for your Qsys system that are used during synthesis and simulation.
Table 5-8: Qsys-Generated IP Component Files
File Name
Description
<system>.qsys
The Qsys system file. <system> is the name that you give your system.
<system>.sopcinfo
Describes the connections and IP component parameterizations in
your Qsys system. You can parse its contents to get requirements
when you develop software drivers for IP components.
Downstream tools such as the Nios II tool chain use this file.
The .sopcinfo file and the system.h file generated for the Nios II tool
chain include address map information for each slave relative to each
master that accesses the slave. Different masters may have a different
address map to access a particular slave component.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Files Generated for Qsys IP Components
File Name
5-57
Description
<system>.cmp
The VHDL Component Declaration (.cmp) file is a text file that
contains local generic and port definitions that you can use in VHDL
design files.
<system>.html
A system report that contains connection information, a memory
map showing the address of each slave with respect to each master to
which it is connected, and parameter assignments.
<system>_generation.rpt
Qsys generation log file. A summary of the messages that Qsys issues
during system generation.
<system>.debuginfo
Contains post-generation information. Used to pass System Console
and Bus Analyzer Toolkit information about the Qsys interconnect.
The Bus Analysis Toolkit uses this file to identify debug components
in the Qsys interconnect.
<system>.qip
Contains all the required information about the IP component or
system to integrate and compile the component in the Quartus II
software.
<system>.bsf
A Block Symbol File (.bsf) representation of the top-level Qsys
system for use in Quartus II Block Diagram Files (.bdf).
<system>.spd
Input file for ip-make-simscript to generate simulation scripts for
supported simulators. The .spd file contains a list of files generated
for simulation, including memory initialization files.
<system>.ppf
The Pin Planner File (.ppf) stores the port and node assignments for
IP components created for use with the Pin Planner.
<system>_bb.v
You can use the Verilog black-box (_bb.v) file as an empty module
declaration for use as a black box.
<system>.sip
Contains information required for NativeLink simulation of IP
components. You must add the .sip file to your Quartus II project.
<system>_inst.v or _inst.vhd
HDL example instantiation template. You can copy and paste the
contents of this file into your HDL file to instantiate a Qsys system.
<system>.regmap
If IP in the system contain register information, Qsys generates
a .regmap file. The .regmap file describes the register map informa‐
tion of master and slave interfaces. This file complements
the .sopcinfo file by providing more detailed register information
about the system. This enables register display views and user
customizable statistics in the System Console.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-58
QII5V1
2015.05.04
Qsys Synthesis Standard and Legacy Device Output Directories
File Name
<system>.svd
Description
Allows HPS System Debug tools to view the register maps of
peripherals connected to HPS within a Qsys system.
During synthesis, the .svd files for slave interfaces visible to System
Console masters are stored in the .sof file in the debug section.
System Console reads this section, which Qsys can query for register
map information. For system slaves, Qsys can access the registers by
name.
<system>.v
or
HDL files that instantiate each submodule or child IP core in the
system for synthesis or simulation.
<system>.vhd
mentor/
Contains a ModelSim script msim_setup.tcl to set up and run a
simulation.
aldec/
Contains a Riviera-PRO script rivierapro_setup.tcl to setup and run a
simulation.
/synopsys/vcs
Contains a shell script vcs_setup.sh to set up and run a VCS
simulation.
/synopsys/vcsmx
Contains a shell script vcsmx_setup.sh and synopsys_ sim.setup file to
set up and run a VCS MX simulation.
/cadence
Contains a shell script ncsim_setup.sh and other setup files to set up
and run an NCSIM simulation.
/submodules
Contains HDL files for the submodule of the Qsys system.
<child IP cores>/
For each generated child IP core directory, Qsys generates /synth and /
sim subdirectories.
Related Information
• Qsys Synthesis Standard and Legacy Device Output Directories on page 5-58
• Qsys Simulation Standard and Legacy Device Output Directories on page 5-59
Qsys Synthesis Standard and Legacy Device Output Directories
The /synth or /synthesis directories contain the Qsys-generated files that the Quartus II software uses to
synthesize your design.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Qsys Simulation Standard and Legacy Device Output Directories
5-59
Figure 5-30: Qsys Synthesis Output Directories
Standard Directory Structure
Legacy Directory Structure
<system>.qsys
<system>.qsys
<system>.sopcinfo
<system>.sopcinfo
<system>
<system>
<system>.cmp
<system>.cmp
<system>.debuginfo
<system>.html
<system>.html
<system>.rpt
<system>.qip
synthesis
<system>.regmap
<system>.qip
<system>_generation.rpt
<system>.debuginfo
synth
<HDL files>
<HDL files>
<Child IP core>
submodules
<HDL files>
synth
<HDL files>
Related Information
Files Generated for Qsys IP Components on page 5-56
Qsys Simulation Standard and Legacy Device Output Directories
The /sim and /simulation directories contain the Qsys-generated output files to simulate your Qsys system.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-60
QII5V1
2015.05.04
Generate Files for a Testbench Qsys System
Figure 5-31: Qsys Simulation Output Directories
Standard Directory Structure
Legacy Directory Structure
<system>.qsys
<system>.qsys
<system>.sopcinfo
<system>.sopcinfo
<system>
<system>
<system>.cmp
<system>.cmp
<system>.csv
<system>.csv
<system>.html
<system>.html
<system>.regmap
<system>.spd
<system>.sip
<system>_generation.rpt
<system>.spd
simulation
<system>_generation.rpt
<system>.sip
sim
<HDL files>
<HDL files>
aldec
submodules
<HDL files>
cadence
aldec
mentor
cadence
synopsys
mentor
<Child IP core>
synopsys
sim
<HDL files>
Related Information
Files Generated for Qsys IP Components on page 5-56
Generate Files for a Testbench Qsys System
Qsys testbench is a new system that instantiates the current Qsys system by adding BFMs to drive the toplevel interfaces. BFMs interact with the system in the simulator. You can use options in the Generation
dialog box (Generate > Generate Testbench System) to generate a testbench Qsys system.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Generate Files for a Testbench Qsys System
5-61
You can generate a standard or simple testbench system with BFM or Mentor Verification IP (for AXI3/
AXI4) IP components that drive the external interfaces of your system. Qsys generates a Verilog HDL or
VHDL simulation model for the testbench system to use in your simulation tool. You should first
generate a testbench system, and then modify the testbench system in Qsys before generating its
simulation model. In most cases, you should select only one of the simulation model options.
By default, the path of the generation output directory is fixed relative to the .qsys file. You can change the
default directory in the Generation dialog box for legacy devices. For standard devices, the generation
directory is fixed to the Qsys project directory.
The following options are available for generating a Qsys testbench system:
Option
Description
Create testbench Qsys system
• Standard, BFMs for standard Qsys Interconnect—Creates
a testbench Qsys system with BFM IP components attached
to exported Avalon and AXI3/AXI4 interfaces. Includes any
simulation partner modules specified by IP components in
the system. The testbench generator supports AXI interfaces
and can connect AXI3/AXI4 interfaces to Mentor Graphics
AXI3/AXI4 master/slave BFMs. However, BFMs support
address widths only up to 32-bits.
• Simple, BFMs for clocks and resets—Creates a testbench
Qsys system with BFM IP components driving only clock
and reset interfaces. Includes any simulation partner
modules specified by IP components in the system.
Create testbench simulation model
Creates Verilog HDL or VHDL simulation model files and
simulation scripts for the testbench Qsys system currently open
in your workspace. Use this option if you do not need to
modify the Qsys-generated testbench before running the
simulation.
Allow mixed-language simulation
Generates a simulation model that contains both Verilog and
VHDL as specified by the individual IP cores. Using this
option, each IP core produces their HDL using it's native
implementation, which results in simulation HDL that is easier
to understand and faster to simulate. You must have a
simulator that supports mixed language simulation.
Note: Modelsim-Altera now supports native mixed-language (VHDL/Verilog/SystemVerilog)
simulation. Therefore, Altera simulation libraries may not be compatible with single language
simulators. If you have a VHDL-only license, some versions of Mentor simulators may not be able
to simulate IP written in Verilog. As a workaround, you can use Modelsim-Altera, or purchase a
mixed language simulation license from Mentor.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-62
QII5V1
2015.05.04
Files Generated for Qsys Testbench
Files Generated for Qsys Testbench
Table 5-9: Qsys-Generated Testbench Files
File Name or Directory Name
Description
<system>_tb.qsys
The Qsys testbench system.
<system>_tb.v
The top-level testbench file that connects BFMs to the top-level
interfaces of <system>_tb.qsys.
or
<system>_tb.vhd
<system>_tb.spd
Required input file for ip-make-simscript to generate simulation
scripts for supported simulators. The .spd file contains a list of files
generated for simulation and information about memory that you can
initialize.
<system>.html
A system report that contains connection information, a memory map
showing the address of each slave with respect to each master to which
it is connected, and parameter assignments.
and
<system>_tb.html
<system>_generation.rpt
Qsys generation log file. A summary of the messages that Qsys issues
during testbench system generation.
<system>.ipx
The IP Index File (.ipx) lists the available IP components, or a reference
to other directories to search for IP components.
<system>.svd
Allows HPS System Debug tools to view the register maps of
peripherals connected to HPS within a Qsys system.
Similarly, during synthesis the .svd files for slave interfaces visible to
System Console masters are stored in the .sof file in the debug section.
System Console reads this section, which Qsys can query for register
map information. For system slaves, Qsys can access the registers by
name.
mentor/
Contains a ModelSim script msim_setup.tcl to set up and run a
simulation
aldec/
Contains a Riviera-PRO script rivierapro_setup.tcl to setup and run a
simulation.
/synopsys/vcs
Contains a shell script vcs_setup.sh to set up and run a VCS simulation.
/synopsys/vcsmx
Contains a shell script vcsmx_setup.sh and synopsys_ sim.setup file to set
up and run a VCS MX simulation.
/cadence
Contains a shell script ncsim_setup.sh and other setup files to set up and
run an NCSIM simulation.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Qsys Testbench Simulation Standard and Legacy Device Output Directories
File Name or Directory Name
5-63
Description
Contains HDL files for the submodule of the Qsys testbench system.
/submodules
For each generated child IP core directory, Qsys testbench generates /
<child IP cores>/
synth and /sim subdirectories.
Qsys Testbench Simulation Standard and Legacy Device Output Directories
The /sim and /simulation directories contain the Qsys-generated output files to simulate your Qsys
testbench system.
Figure 5-32: Qsys Simulation Testbench Directory Structure
Standard Directory Structure
Legacy Directory Structure
<system>.qsys
<system>.qsys
<system>.sopcinfo
<system>.sopcinfo
<system>_tb
<system>_tb.csv
<system>.html
<system>_tb.spd
<system>.ipx
<system>
<system>.regmap
<system>.html
<system>_generation.rpt
<system>_generation.rpt
<system>_tb.html
<system>_tb.html
<system>_tb.qsys
testbench/
<system>_tb
<system>.ipx
<system>_tb.csv
<system>_tb.qsys
<system>_tb.spd
<system>_tb
sim
simulation
<HDL files>
<HDL files>
aldec
submodules
cadence
<HDL files>
mentor
aldec
synopsys
cadence
<Child IP core>
sim
mentor
synopsys
<HDL files>
Creating a System With Qsys
Send Feedback
Altera Corporation
5-64
QII5V1
2015.05.04
Generate and Modify a Qsys Testbench System
Generate and Modify a Qsys Testbench System
You can use the following steps to create a Qsys testbench system of your Qsys system.
1. Create a Qsys system.
2. Generate a testbench system in the Qsys Generation dialog box (Generate > Generate Testbench
System).
3. Open the testbench system in Qsys. Make changes to the BFMs, as needed, such as changing the
instance names and VHDL ID value. For example, you can modify the VHDL ID value in the Altera
Avalon Interrupt Source IP component.
4. If you modify a BFM, regenerate the simulation model for the testbench system.
5. Create a custom test program for the BFMs.
6. Compile and load the Qsys system and testbench into your simulator, and then run the simulation.
Simulation Scripts
Qsys generates simulation scripts to set up the simulation environment for Mentor Graphics Modelsim®
and Questasim®, Synopsys VCS and VCS MX, Cadence Incisive Enterprise Simulator® (NCSIM), and the
Aldec Riviera-PRO® Simulator.
You can use scripts to compile the required device libraries and system design files in the correct order
and elaborate or load the top-level system for simulation.
Table 5-10: Simulation Script Variables
The simulation scripts provide variables that allow flexibility in your simulation environment.
Variable
TOP_LEVEL_NAME
QSYS_SIMDIR
QUARTUS_INSTALL_DIR
Description
If the testbench Qsys system is not the top-level instance in your
simulation environment because you instantiate the Qsys testbench
within your own top-level simulation file, set the TOP_LEVEL_NAME
variable to the top-level hierarchy name.
If the simulation files generated by Qsys are not in the simulation
working directory, use the QSYS_SIMDIR variable to specify the
directory location of the Qsys simulation files.
Points to the Quartus installation directory that contains the device
family library.
Example 5-4: Top-Level Simulation HDL File for a Testbench System
The example below shows the pattern_generator_tb generated for a Qsys system called
pattern_generator. The top.sv file defines the top-level module that instantiates the
pattern_generator_tb simulation model, as well as a custom SystemVerilog test program with
BFM transactions, called test_program.
module top();
pattern_generator_tb tb();
test_program pgm();
endmodule
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Simulating Software Running on a Nios II Processor
5-65
Note: The VHDL version of the Altera Tristate Conduit BFM is not supported in Synopsys VCS, NCSim,
and Riviera-PRO in the Quartus II software version 14.0. These simulators do not support the
VHDL protected type, which is used to implement the BFM. For a workaround, use a simulator
that supports the VHDL protected type.
Note: Modelsim-Altera now supports native mixed-language (VHDL/Verilog/SystemVerilog)
simulation. Therefore, Altera simulation libraries may not be compatible with single language
simulators. If you have a VHDL-only license, some versions of Mentor simulators may not be able
to simulate IP written in Verilog. As a workaround, you can use Modelsim-Altera, or purchase a
mixed language simulation license from Mentor.
Related Information
•
•
•
•
ModelSim-Altera software, Mentor Graphics ModelSim support
Synopsys VCS and VCS MX support
Cadence Incisive Enterprise Simulator (IES) support
Aldec Active-HDL and Rivera-PRO support
Simulating Software Running on a Nios II Processor
To simulate the software in a system driven by a Nios II processor, generate the simulation model for the
Qsys testbench system with the following steps:
1. In the Generation dialog box (Generate > Generate Testbench System), select Simple, BFMs for
clocks and resets.
2. For the Create testbench simulation model option select Verilog or VHDL.
3. Click Generate.
4. Open the Nios II Software Build Tools for Eclipse.
5. Set up an application project and board support package (BSP) for the <system> .sopcinfo file.
6. To simulate, right-click the application project in Eclipse, and then click Run as > Nios II ModelSim.
Sets up the ModelSim simulation environment, and compiles and loads the Nios II software
simulation.
7. To run the simulation in ModelSim, type run -all in the ModelSim transcript window.
8. Set the ModelSim settings and select the Qsys Testbench Simulation Package Descriptor (.spd) file, <
system > _tb.spd. The .spd file is generated with the testbench simulation model for Nios II designs
and specifies the files required for Nios II simulation.
Related Information
• Getting Started with the Graphical User Interface (Nios II)
• Getting Started from the Command-Line (Nios II)
Add Assertion Monitors for Simulation
You can add monitors to Avalon-MM, AXI, and Avalon-ST interfaces in your system to verify protocol
and test coverage with a simulator that supports SystemVerilog assertions.
Note: Modelsim Altera Edition does not support SystemVerilog assertions. If you want to use assertion
monitors, you must use a supported third-party simulators such as Mentor Questasim, Synopsys
VCS, or Cadence Incisive. For more information, refer to Introduction to Altera IP Cores.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-66
QII5V1
2015.05.04
CMSIS Support for the HPS IP Component
Figure 5-33: Inserting an Avalon-MM Monitor Between an Avalon-MM Master and Slave Interface
This example demonstrates the use of a monitor with an Avalon-MM monitor between the
pcie_compiler bar1_0_Prefetchable Avalon-MM master interface, and the
dma_0 control_port_slave Avalon-MM slave interface.
Similarly, you can insert an Avalon-ST monitor between Avalon-ST source and sink interfaces.
Related Information
Introduction to Altera IP Cores
CMSIS Support for the HPS IP Component
Qsys systems that contain an HPS IP component generate a System View Description (.svd) file that lists
peripherals connected to the ARM processor.
The .svd (or CMSIS-SVD) file format is an XML schema specified as part of the Cortex Microcontroller
Software Interface Standard (CMSIS) provided by ARM. The .svd file allows HPS system debug tools
(such as the DS-5 Debugger) to view the register maps of peripherals connected to HPS in a Qsys system.
Related Information
Component Interface Tcl Reference on page 9-1
CMSIS - Cortex Microcontroller Software
Explore and Manage Qsys Interconnect
The System with Qsys Interconnect window allows you to see the contents of the Qsys interconnect
before you generate your system. In this display of your system, you can review a graphical representation
of the generated interconnect. Qsys converts connections between interfaces to interconnect logic during
system generation.
You access the System with Qsys Interconnect window by clicking Show System With Qsys Interconnect
command on the System menu.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Manually Controlling Pipelining in the Qsys Interconnect
5-67
The System with Qsys Interconnect window has the following tabs:
• System Contents—Displays the original instances in your system, as well as the inserted interconnect
instances. Connections between interfaces are replaced by connections to interconnect where
applicable.
• Hierarchy—Displays a system hierarchical navigator, expanding the system contents to show modules,
interfaces, signals, contents of subsystems, and connections.
• Parameters—Displays the parameters for the selected element in the Hierarchy tab.
• Memory-Mapped Interconnect—Allows you to select a memory-mapped interconnect module and
view its internal command and response networks. You can also insert pipeline stages to achieve
timing closure.
The System Contents, Hierarchy, and Parameters tabs are read-only. Edits that you apply on the
Memory-Mapped Interconnect tab are automatically reflected on the Interconnect Requirements tab.
The Memory-Mapped Interconnect tab in the System with Qsys Interconnect window displays a
graphical representation of command and response data paths in your system. Data paths allow you
precise control over pipelining in the interconnect. Qsys displays separate figures for the command and
response data paths. You can access the data paths by clicking their respective tabs in the MemoryMapped Interconnect tab.
Each node element in a figure represents either a master or slave that communicates over the intercon‐
nect, or an interconnect sub-module. Each edge is an abstraction of connectivity between elements, and
its direction represents the flow of the commands or responses.
Click Highlight Mode (Path, Successors, Predecessors) to identify edges and data paths between
modules. Turn on Show Pipeline Locations to add greyed-out registers on edges where pipelining is
allowed in the interconnect.
Note: You must select more than one module to highlight a path.
Manually Controlling Pipelining in the Qsys Interconnect
The Memory-Mapped Interconnect tab allows you to manipulate pipleline connections in the Qsys
interconnect. You access the Memory-Mapped Interconnect tab by clicking the Show System With Qsys
Interconnect command on the System menu.
Note: To increase interconnect frequency, you should first try increasing the value of the Limit intercon‐
nect pipeline stages to option on the Interconnect Requirements tab. You should only consider
manually pipelining the interconnect if changes to this option do not improve frequency, and you
have tried all other options to achieve timing closure, including the use of a bridge. Manually
pipelining the interconnect should only be applied to complete systems.
1. In the Interconnect Requirements tab, first try increasing the value of the Limit interconnect
pipeline stages to option until it no longer gives significant improvements in frequency, or until it
causes unacceptable effects on other parts of the system.
2. In the Quartus II software, compile your design and run timing analysis.
3. Using the timing report, identify the critical path through the interconnect and determine the approxi‐
mate mid-point. The following is an example of a timing report:
2.800
3.004
3.246
3.346
3.685
0.000
0.204
0.242
0.100
0.339
Creating a System With Qsys
Send Feedback
cpu_instruction_master|out_shifter[63]|q
mm_domain_0|addr_router_001|Equal5~0|datac
mm_domain_0|addr_router_001|Equal5~0|combout
mm_domain_0|addr_router_001|Equal5~1|dataa
mm_domain_0|addr_router_001|Equal5~1|combout
Altera Corporation
5-68
QII5V1
2015.05.04
Implement Performance Monitoring
4.153 0.468 mm_domain_0|addr_router_001|src_channel[5]~0|datad
4.373 0.220 mm_domain_0|addr_router_001|src_channel[5]~0|combout
4. In Qsys, click System > Show System With Qsys Interconnect.
5. In the Memory-Mapped Interconnect tab, select the interconnect module that contains the critical
path. You can determine the name of the module from the hierarchical node names in the timing
report.
6. Click Show Pipelinable Locations. Qsys display all possible pipeline locations in the interconnect.
Right-click the possible pipeline location to insert or remove a pipeline stage.
7. Locate the possible pipeline location that is closest to the mid-point of the critical path. The names of
the blocks in the memory-mapped interconnect tab correspond to the module instance names in the
timing report.
8. Right-click the location where you want to insert a pipeline, and then click Insert Pipeline.
9. Regenerate the Qsys system, recompile the design, and then rerun timing analysis. If necessary, repeat
the manual pipelining process again until timing requirements are met.
Manual pipelining has the following limitations:
• If you make changes to your original system's connectivity after manually pipelining an interconnect,
your inserted pipelines may become invalid. Qsys displays warning messages when you generate your
system if invalid pipeline stages are detected. You can remove invalid pipeline stages with the Remove
Stale Pipelines option in the Memory-Mapped Interconnect tab. Altera recommends that you do not
make changes to the system's connectivity after manual pipeline insertion.
• Review manually-inserted pipelines when upgrading to newer versions of Qsys. Manually-inserted
pipelines in one version of Qsys may not be valid in a future version.
Related Information
Specify Qsys $system Interconnect Requirements
Qsys System Design Components on page 10-1
Implement Performance Monitoring
You use the Qsys Instrumentation tab in to set up real-time performance monitoring using throughput
metrics such as read and write transfers. The Add debug instrumentation to the Qsys Interconnect
option allows you to interact with the Bus Analyzer Toolkit, which you can access on the Tools menu in
the Quartus II software.
Qsys supports performance monitoring for only Avalon-MM interfaces. In your Qsys system, you can
monitor the performance of no less than three, and no greater than 15 components at one time. The
performance monitoring feature works with Quartus II software devices 13.1 and newer.
Note: For more information about the Bus Analyzer Toolkit and the Qsys Instrumentation tab,
refer to the Bus Analyzer Toolkit page.
Related Information
Bus Analyzer Toolkit
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Qsys 64-Bit Addressing Support
5-69
Qsys 64-Bit Addressing Support
Qsys interconnect supports up to 64-bit addressing for all Qsys interfaces and IP components, with a
range of: 0x0000 0000 0000 0000 to 0xFFFF FFFF FFFF FFFF, inclusive.
Address parameters appear in the Base and End columns in the System Contents tab, on the Address
Map tab, in the parameter editor, and in validation messages. Qsys displays as many digits as needed in
order to display the top-most set bit, for example, 12 hex digits for a 48-bit address.
A Qsys system can have multiple 64-bit masters, with each master having its own address space. You can
share slaves between masters and masters can map slaves to different addresses. For example, one master
can interact with slave 0 at base address 0000_0000_0000, and another master can see the same slave at
base address c000_000_000.
Quartus II debugging tools provide access to the state of an addressable system via the Avalon-MM
interconnect. These are also 64-bit compatible, and process within a 64-bit address space, including a
JTAG to Avalon master bridge.
For more information on design practices when using slaves with large address spans, refer to Address
Span Extender in volume 1 of the Quartus II Handbook.
Related Information
• Qsys System Design Components on page 10-1
Support for Avalon-MM Non-Power of Two Data Widths
Qsys requires that you connect all multi-point Avalon-MM connections to interfaces with data widths
that are equal to powers of two.
Qsys issues a validation error if an Avalon-MM master or slave interface on a multi-point connection is
parameterized with a non-power of two data width.
Note: Avalon-MM point-to-point connections between an Avalon-MM master and an Avalon-MM slave
are an exception and may set their data widths to a non-power of two.
View the Qsys HDL Example
Click Generate > HDL Example to generate a template for the top-level HDL definition of your Qsys
system in either Verilog HDL or VHDL. The HDL template displays the IP component declaration.
You can copy and paste the example into a top-level HDL file that instantiates the Qsys system, if the Qsys
system is not the top-level module in your Quartus II project.
Qsys System Example Designs
Click the Example Design button in the parameter editor to generate an example design.
If there are multiple example designs for an IP component, then there is a button for each example in the
parameter editor. When you click the Example Design button, the Select Example Design Directory
dialog box appears, where you can select the directory to save the example design.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-70
QII5V1
2015.05.04
Qsys Command-Line Utilities
The Example Design button does not appear in the parameter editor if there is no example. For some IP
components, you can click Generate > Example Designs to access an example design.
The following Qsys system example designs demonstrate various design features and flows that you can
replicate in your Qsys system.
Related Information
• NIOS II Qsys Example Design
• PCI Express Avalon-ST Qsys Example Design
• Triple Speed Ethernet Qsys Example Design
Qsys Command-Line Utilities
You can perform many of the functions available in the Qsys GUI from the command-line with the qsysedit, qsys-generate, and qsys-script utilities.
You run Qsys command-line executables from the Quartus II installation directory:
<Quartus II installation directory>\quartus\sopc_builder\bin
You can use qsys-generate to generate a Qsys system or IP variation outside of the Qsys GUI. You can
use qsys-script to create, manipulate or manage a Qsys system with command-line scripting.
For command-line help listing all options for these executables, type the following command:
<Quartus II installation directory>\quartus\sopc_builder\bin\<executable name> --help
Example 5-5: Qsys Command-Line Scripting Example
qsys-script --script=my_script.tcl \
--system-file=fancy.qsys my_script.tcl contains:
package require -exact qsys 13.1
# get all instance names in the system and print one by one
set instances [ get_instances ]
foreach instance $instances {
send_message Info "$instance"
}
Note: You must add $QUARTUS_ROOTDIR/sopc_builder/bin/ to the PATH variable to access command-line
utilities. Once you add this PATH variable, you can launch the unities from any directory location.
Related Information
• Working with Instance Parameters in Qsys
• Altera Wiki Qsys Scripts
Run the Qsys Editor with qsys-edit
You can use the qsys-edit utility to run the Qsys editor from the command-line.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Scripting IP Core Generation
5-71
You can use the following options with the qsys-edit utility:
Table 5-11: qsys-edit Command-Line Options
Option
Usage
Description
1st arg file
Optional
The name of the .qsys system or .qvar variation
file to edit.
--search-path[=<value>]
Optional
If omitted, Qsys uses a standard default path. If
provided, Qsys searches a comma-separated list
of paths. To include the standard path in your
replacement, use "$", for example: /extra/dir.$.
--project-directory=<directory>
Optional
Allows you to find IP components in certain
locations relative to the project, if any. By default,
the current directory is:'.' . To exclude any
project directory, use ''.
--new-component-type=<value>
Optional
Allows you to specify the kind of instance that is
parameterized in a variation.
--debug
Optional
Enables debugging features and output.
--host-controller
Optional
Launches the application with an XML host
controller interface on standard input/output.
--jvm-max-heap-size=<value>
Optional
The maximum memory size Qsys uses for
allocations when running qsys-edit. You
specify this value as <size><unit>, where unit is
m (or M) for multiples of megabytes, or g (or G) for
multiples of gigabytes. The default value is 512m.
--help
Optional
Display help for qsys-edit.
Scripting IP Core Generation
You can alternatively use command-line utilities to define and generate an IP core variation outside of the
Quartus II GUI.Use qsys-script to run a Tcl file that parameterizes an IP variation you define in a
script. Then, use qsys-generate to generate a .qsys file representing your parameterized IP variation.
The qsys-generate command is the same as when generating using the Qsys GUI. For command-line
help listing all options for these executables, type <executable name> --help
Creating a System With Qsys
Send Feedback
Altera Corporation
5-72
QII5V1
2015.05.04
Scripting IP Core Generation
To create a instance of a parameterizable Altera IP core at the command line, rather than using the GUI,
follow these steps:
1. Run qsys-script to execute a Tcl script, similar to the example, that instantiates the IP and sets the IP
parameters defined by the script:
qsys-script --script=<script_file>.tcl
2. Run qsys-generate to generate the RTL for the IP variation:
qsys-generate <IP variation file>.qsys
Note: Creating an IP generation script is an advanced feature that requires access to special IP core
parameters. For more information about creating an IP generation script, contact your Altera sales
representative.
Table 5-12: qsys-generate Command-Line Options
Option
Usage
Description
<1st arg file>
Required
The name of the .qsys system file to
generate.
--synthesis=<VERILOG|VHDL>
Optional
Creates synthesis HDL files that Qsys uses
to compile the system in a Quartus II
project. You must specify the preferred
generation language for the top-level RTL
file for the generated Qsys system.
--block-symbol-file
Optional
Creates a Block Symbol File (.bsf) for the
Qsys system.
--simulation=<VERILOG|VHDL>
Optional
Creates a simulation model for the Qsys
system. The simulation model contains
generated HDL files for the simulator, and
may include simulation-only features. You
must specify the preferred simulation
language.
--testbench=<SIMPLE|STANDARD>
Optional
Creates a testbench system that instantiates
the original system, adding bus functional
models (BFMs) to drive the top-level
interfaces. When you generate the system,
the BFMs interact with the system in the
simulator.
--testbench-simulation=<VERILOG|VHDL>
Optional
After you create the testbench system, you
can create a simulation model for the
testbench system.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Display Available IP Components with ip-catalog
Option
Usage
5-73
Description
--search-path=<value>
Optional
If you omit this command, Qsys uses a
standard default path. If you provide this
command, Qsys searches a commaseparated list of paths. To include the
standard path in your replacement, use "$",
for example, "/extra/dir,$".
--jvm-max-heap-size=<value>
Optional
The maximum memory size that Qsys uses
for allocations when running qsysgenerate. You specify the value as <size>
<unit>, where unit is m (or M) for
multiples of megabytes or g (or G) for
multiples of gigabytes. The default value is
512m.
--family=<value>
Optional
Specifies the device family.
--part=<value>
Optional
Specifies the device part number. If set, this
option overrides the --family option.
--allow-mixed-language-simulation
Optional
Enables a mixed language simulation
model generation. If true, if a preferred
simulation language is set, Qsys uses a
fileset of the component for the
simulation model generation. When false,
which is the default, Qsys uses the
language specified with --fileset=<value> for all components for
simulation model generation. The current
version of the ModelSim-Altera simulator
supports mixed language simulation.
Display Available IP Components with ip-catalog
The ip-catalog command displays a list of available IP components relative to the current Quartus II
project directory. Use the following format for the ip-catalog command:
ip-catalog
[--project-dir=<directory>]
[--name=<value>]
[--verbose]
[--xml]
[--help]
Creating a System With Qsys
Send Feedback
Altera Corporation
5-74
QII5V1
2015.05.04
Create an .ipx File with ip-make-ipx
Table 5-13: ip-catalog Command-Line Options
Option
Usage
Description
--project-dir= <directory>
Optional
Finds IP components relative to the Quartus II project
directory. By default, Qsys uses ‘.’ as the current
directory. To exclude a project directory, leave the
value empty.
--name=<value>
Optional
Provides a pattern to filter the names of the IP
components found. To show all IP components, use a
* or ‘ ‘. By default, Qsys shows all IP components. The
argument is not case sensitive.
--verbose
Optional
Reports the progress of the command.
--xml
Optional
Generates the output in XML format, in place of
colon-delimited format.
--help
Optional
Displays help for the ip-catalog command.
Create an .ipx File with ip-make-ipx
The ip-make-ipx command creates an .ipx file and is a convenient way to include a collection of IP
components from an arbitrary directory. You can edit the .ipx file to disable visibility of one or more IP
components in the IP Catalog. Use the following format for the ip-make-ipx command:
ip-make-ipx
[--source-directory=<directory>]
[--output=<file>]
[--relative-vars=<value>]
[--thorough-descent]
[--message-before=<value>]
[--message-after=<value>]
[--help]
Table 5-14: ip-make-ipx Command-Line Options
Option
Usage
Description
--source-directory=<directory>
Optional
Specifies the root directory for IP component files.
The default directory is *.*. You can provide a
comma-separated list of directories.
--output=<file>
Optional
Specifies the name of the file to generate. The
default name is /component.ipx.
--relative-vars=<value>
Optional
Causes the output file to include references relative
to the specified variable(s) where possible. You can
specify multiple variables as a comma-separated list.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Generate a Qsys System with qsys-script
Option
Usage
5-75
Description
--thorough-descent
Optional
If set, a component or .ipx file in a directory does
not stop Qsys from searching subdirectories.
--message-before=<value>
Optional
Prints a message: stdout when indexing begins.
--message-after=<value>
Optional
Sends a message: stdout when indexing is done.
--help
Optional
Displays help for the ip-make-ipx command.
Related Information
Set up the IP Index File (.ipx) to Search for IP Components on page 5-28
Generate a Qsys System with qsys-script
You can use the qsys-script utility to create and manipulate a Qsys system with Tcl scripting
commands.
Note: You must provide a package version for the qsys-script. If you do not specify the --packageversion=<value> command, you must then provide a Tcl script and request the system scripting
API directly with the package require -exact qsys < version > command.
Table 5-15: qsys-script Command-Line Options
Option
Usage
Description
--system-file=<file>
Optional
Specifies the path to a .qsys file. Qsys loads the system
before running scripting commands.
--script=<file>
Optional
A file that contains Tcl scripting commands that you
can use to create or manipulate Qsys systems. If you
specify both --cmd and --script, Qsys runs the --cmd
commands before the script specified by --script.
--cmd=<value>
Optional
A string that contains Tcl scripting commands that you
can use to create or manipulate a Qsys system. If you
specify both --cmd and --script, Qsys runs the --cmd
commands before the script specified by --script.
--package-version=<value>
Optional
Specifies which Tcl API scripting version to use and
determines the functionality and behavior of the Tcl
commands. The Quartus II software supports Tcl API
scripting commands. If you do not specify the version
on the command-line, your script must request the
scripting API directly with the package require exact qsys <version > command.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-76
QII5V1
2015.05.04
Generate a Qsys System with qsys-script
Option
Usage
Description
--search-path=<value>
Optional
If you omit this command, a Qsys uses a standard
default path. If you provide this command, Qsys
searches a comma-separated list of paths. To include
the standard path in your replacement, use "$", for
example, /< directory path >/dir,$. Separate
multiple directory references with a comma.
--jvm-max-heap-size=<value>
Optional
The maximum memory size that the qsys-script tool
uses. You specify this value as <size><unit>, where
unit is m (or M) for multiples of megabytes, or g (or G)
for multiples of gigabytes.
--help
Optional
Displays help for the qsys-script utility.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Qsys Scripting Command Reference
5-77
Qsys Scripting Command Reference
The following are Qsys scripting commands:
add_connection on page 5-80
add_instance on page 5-81
add_interface on page 5-82
apply_preset on page 5-83
auto_assign_base_addresses on page 5-84
auto_assign_system_base_addresses on page 5-85
auto_assign_irqs on page 5-86
auto_connect on page 5-87
create_system on page 5-88
export_hw_tcl on page 5-89
get_composed_connection_parameter_value on page 5-90
get_composed_connection_parameters on page 5-91
get_composed_connections on page 5-92
get_composed_instance_assignment on page 5-93
get_composed_instance_assignments on page 5-94
get_composed_instance_parameter_value on page 5-95
get_composed_instance_parameters on page 5-96
get_composed_instances on page 5-97
get_connection_parameter_property on page 5-98
get_connection_parameter_value on page 5-99
get_connection_parameters on page 5-100
get_connection_properties on page 5-101
get_connection_property on page 5-102
get_connections on page 5-103
get_instance_assignment on page 5-104
get_instance_assignments on page 5-105
get_instance_documentation_links on page 5-106
get_instance_interface_assignment on page 5-107
get_instance_interface_assignments on page 5-108
get_instance_interface_parameter_property on page 5-109
get_instance_interface_parameter_value on page 5-110
get_instance_interface_parameters on page 5-111
Creating a System With Qsys
Send Feedback
Altera Corporation
5-78
Qsys Scripting Command Reference
QII5V1
2015.05.04
get_instance_interface_port_property on page 5-112
get_instance_interface_ports on page 5-113
get_instance_interface_properties on page 5-114
get_instance_interface_property on page 5-115
get_instance_interfaces on page 5-116
get_instance_parameter_property on page 5-117
get_instance_parameter_value on page 5-118
get_instance_parameters on page 5-119
get_instance_port_property on page 5-120
get_instance_properties on page 5-121
get_instance_property on page 5-122
get_instances on page 5-123
get_interconnect_requirement on page 5-124
get_interconnect_requirements on page 5-125
get_interface_port_property on page 5-126
get_interface_ports on page 5-127
get_interface_properties on page 5-128
get_interface_property on page 5-129
get_interfaces on page 5-130
get_module_properties on page 5-131
get_module_property on page 5-132
get_parameter_properties on page 5-133
get_port_properties on page 5-134
get_project_properties on page 5-135
get_project_property on page 5-136
load_system on page 5-137
lock_avalon_base_address on page 5-138
remove_connection on page 5-139
remove_dangling_connections on page 5-140
remove_instance on page 5-141
remove_interface on page 5-142
save_system on page 5-143
send_message on page 5-144
set_connection_parameter_value on page 5-145
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Qsys Scripting Command Reference
5-79
set_instance_parameter_value on page 5-146
set_instance_property on page 5-147
set_interconnect_requirement on page 5-148
set_interface_property on page 5-149
set_module_property on page 5-150
set_project_property on page 5-151
set_use_testbench_naming_pattern on page 5-152
set_validation_property on page 5-153
unlock_avalon_base_address on page 5-154
validate_connection on page 5-155
validate_instance on page 5-156
validate_instance_interface on page 5-157
validate_system on page 5-158
Creating a System With Qsys
Send Feedback
Altera Corporation
5-80
QII5V1
2015.05.04
add_connection
add_connection
Description
Connects the named interfaces using an appropriate connection type. Both interface names consist of a
child instance name, followed by the name of an interface provided by that module. For example,
mux0.out is the interface named on the instance named mux0. Be careful to connect the start to the end,
and not the reverse.
Usage
add_connection <start> [<end>]
Returns
No return value.
Arguments
start
The start interface that is connected, in <instance_name>.<interface_name> format. If
the end argument is omitted, the connection must be of the form
<instance1>.<interface>/<instance2>.<interface>.
end (optional)
The end interface that is connected, <instance_name>.<interface_name>.
Example
add_connection dma.read_master sdram.s1
Related Information
•
•
•
•
•
Altera Corporation
get_connection_parameter_value on page 5-99
get_connection_property on page 5-102
get_connections on page 5-103
remove_connection on page 5-139
set_connection_parameter_value on page 5-145
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
add_instance
5-81
add_instance
Description
Adds an instance of a component, referred to as a child or child instance, to the system.
Usage
add_instance <name> <type> [<version>]
Returns
No return value.
Arguments
name
Specifies a unique local name that you can use to manipulate the instance. Qsys uses this
name in the generated HDL to identify the instance.
type
Refers to a kind of instance available in the IP Catalog, for example altera_avalon_uart.
version (optional)
The required version of the specified instance type. If no version is specified, Qsys uses the
latest version.
Example
add_instance uart_0 altera_avalon_uart
Related Information
•
•
•
•
•
get_instance_parameter_value on page 5-118
get_instance_property on page 5-122
get_instances on page 5-123
remove_instance on page 5-141
set_instance_parameter_value on page 5-146
Creating a System With Qsys
Send Feedback
Altera Corporation
5-82
QII5V1
2015.05.04
add_interface
add_interface
Description
Adds an interface to your system, which Qsys uses to export an interface from within the system. You
specify the exported internal interface with set_interface_property <interface> EXPORT_OF
instance.interface.
Usage
add_interface <name> <type> <direction>.
Returns
No return value.
Arguments
name
The name of the interface that Qsys exports from the system.
type
The type of interface.
direction
The interface direction.
Example
add_interface my_export conduit end
set_interface_property my_export EXPORT_OF uart_0.external_connection
Related Information
•
•
•
•
Altera Corporation
get_interface_ports on page 5-127
get_interface_properties on page 5-128
get_interface_property on page 5-129
set_interface_property on page 5-149
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
apply_preset
5-83
apply_preset
Description
Applies the settings in a preset to the specified instance.
Usage
apply_preset <instance> <preset_name>
Returns
No return value.
Arguments
instance
The name of the instance.
preset_name
The name of the preset.
Example
apply_preset cpu_0 "Custom Debug Settings"
Creating a System With Qsys
Send Feedback
Altera Corporation
5-84
auto_assign_base_addresses
QII5V1
2015.05.04
auto_assign_base_addresses
Description
Assigns base addresses to all memory mapped interfaces on an instance in the system. Instance interfaces
that are locked with lock_avalon_base_address keep their addresses during address auto-assignment.
Usage
auto_assign_base_addresses <instance>
Returns
No return value.
Arguments
instance
The name of the instance with memory mapped interfaces.
Example
auto_assign_base_addresses sdram
Related Information
• auto_assign_system_base_addresses on page 5-85
• lock_avalon_base_address on page 5-138
• unlock_avalon_base_address on page 5-154
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
auto_assign_system_base_addresses
5-85
auto_assign_system_base_addresses
Description
Assigns legal base addresses to all memory mapped interfaces on all instances in the system. Instance
interfaces that are locked with lock_avalon_base_address keep their addresses during address autoassignment.
Usage
auto_assign_system_base_addresses
Returns
No return value.
Arguments
No arguments.
Example
auto_assign_system_base_addresses
Related Information
• auto_assign_base_addresses on page 5-84
• lock_avalon_base_address on page 5-138
• unlock_avalon_base_address on page 5-154
Creating a System With Qsys
Send Feedback
Altera Corporation
5-86
QII5V1
2015.05.04
auto_assign_irqs
auto_assign_irqs
Description
Assigns interrupt numbers to all connected interrupt senders on an instance in the system.
Usage
auto_assign_irqs <instance>
Returns
No return value.
Arguments
instance
The name of the instance with an interrupt sender.
Example
auto_assign_irqs uart_0
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
auto_connect
5-87
auto_connect
Description
Creates connections from an instance or instance interface to matching interfaces in other instances in the
system. For example, Avalon-MM slaves connect to Avalon-MM masters.
Usage
auto_connect <element>
Returns
No return value.
Arguments
element
The name of the instance interface, or the name of an instance.
Example
auto_connect sdram
auto_connect uart_0.s1
Related Information
add_connection on page 5-80
Creating a System With Qsys
Send Feedback
Altera Corporation
5-88
create_system
QII5V1
2015.05.04
create_system
Description
Replaces the current system with a new system with the specified name.
Usage
create_system [<name>]
Returns
No return value.
Arguments
name (optional)
The name of the new system.
Example
create_system my_new_system_name
Related Information
• load_system on page 5-137
• save_system on page 5-143
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
export_hw_tcl
5-89
export_hw_tcl
Description
Allows you to save the currently open system as an _hw.tcl file in the project directory. The saved systems
appears under the System category in the IP Category.
Usage
export_hw_tcl
Returns
No return value.
Arguments
No arguments
Example
export_hw_tcl
Creating a System With Qsys
Send Feedback
Altera Corporation
5-90
QII5V1
2015.05.04
get_composed_connection_parameter_value
get_composed_connection_parameter_value
Description
Returns the value of a parameter in a connection in a child instance containing a subsystem.
Usage
get_composed_connection_parameter_value <instance> <child_connection> <parameter>
Returns
The parameter value.
Arguments
instance
The child instance that contains a subsystem
child_connection
The name of the connection in the subsystem
parameter
The name of the parameter to query on the connection.
Example
get_composed_connection_parameter_value subsystem_0 cpu.data_master/memory.s0
baseAddress
Related Information
• get_composed_connection_parameters on page 5-91
• get_composed_connections on page 5-92
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_composed_connection_parameters
5-91
get_composed_connection_parameters
Description
Returns a list of all connections in the subsystem, for an instance that contains a subsystem.
Usage
get_composed_connection_parameters <instance> <child_connection>
Returns
A list of parameter names.
Arguments
instance
The child instance containing a subsystem.
child_connection
The name of the connection in the subsystem.
Example
get_composed_connection_parameters subsystem_0 cpu.data_master/memory.s0
Related Information
• get_composed_connection_parameter_value on page 5-90
• get_composed_connections on page 5-92
Creating a System With Qsys
Send Feedback
Altera Corporation
5-92
get_composed_connections
QII5V1
2015.05.04
get_composed_connections
Description
For an instance that contains a subsystem of the Qsys system, returns a list of all connections found in a
subsystem.
Usage
get_composed_connections <instance>
Returns
A list of connection names in the subsystem. These connection names are not qualified with the instance
name.
Arguments
instance
The child instance containing a subsystem.
Example
get_composed_connections subsystem_0
Related Information
• get_composed_connection_parameter_value on page 5-90
• get_composed_connection_parameters on page 5-91
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_composed_instance_assignment
5-93
get_composed_instance_assignment
Description
For an instance that contains a subsystem of the Qsys system, returns the value of an assignment found on
the instance in the subsystem.
Usage
get_composed_instance_assignment <instance> <child_instance> <assignment>
Returns
The value of the assignment.
Arguments
instance
The child instance containing a subsystem.
child_instance
The name of a child instance found in the subsystem.
assignment
The assignment key.
Example
get_composed_instance_assignment subsystem_0 video_0 "embeddedsw.CMacro.colorSpace"
Related Information
• get_composed_instance_assignments on page 5-94
• get_composed_instances on page 5-97
Creating a System With Qsys
Send Feedback
Altera Corporation
5-94
get_composed_instance_assignments
QII5V1
2015.05.04
get_composed_instance_assignments
Description
For an instance that contains a subsystem of the Qsys system, returns a list of assignments found on the
instance in the subsystem.
Usage
get_composed_instance_assignments <instance> <child_instance>
Returns
A list of assignment names.
Arguments
instance
The child instance containing a subsystem.
child_instance
The name of a child instance found in the subsystem.
Example
get_composed_instance_assignments subsystem_0 cpu
Related Information
• get_composed_instance_assignment on page 5-93
• get_composed_instances on page 5-97
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_composed_instance_parameter_value
5-95
get_composed_instance_parameter_value
Description
For an instance that contains a subsystem of the Qsys system, returns the value of a parameters found on
the instance in the subsystem.
Usage
get_composed_instance_parameter_value <instance> <child_instance> <parameter>
Returns
The value of a parameter on the instance in the subsystem.
Arguments
instance
The child instance containing a subsystem.
child_instance
The name of a child instance found in the subsystem.
parameter
The name of the parameter to query on the instance in the subsystem.
Example
get_composed_instance_parameter_value subsystem_0 cpu DATA_WIDTH
Related Information
• get_composed_instance_parameters on page 5-96
• get_composed_instances on page 5-97
Creating a System With Qsys
Send Feedback
Altera Corporation
5-96
get_composed_instance_parameters
QII5V1
2015.05.04
get_composed_instance_parameters
Description
For an instance that contains a subsystem of the Qsys system, returns a list of parameters found on the
instance in the subsystem.
Usage
get_composed_instance_parameters <instance> <child_instance>
Returns
A list of parameter names.
Arguments
instance
The child instance containing a subsystem.
child_instance
The name of a child instance found in the subsystem.
Example
get_composed_instance_parameters subsystem_0 cpu
Related Information
• get_composed_instance_parameter_value on page 5-95
• get_composed_instances on page 5-97
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_composed_instances
5-97
get_composed_instances
Description
For an instance that contains a subsystem of the Qsys system, returns a list of child instances found in the
subsystem.
Usage
get_composed_instances <instance>
Returns
A list of instance names found in the subsystem.
Arguments
instance
The child instance containing a subsystem.
Example
get_composed_instances subsystem_0
Related Information
•
•
•
•
get_composed_instance_assignment on page 5-93
get_composed_instance_assignments on page 5-94
get_composed_instance_parameter_value on page 5-95
get_composed_instance_parameters on page 5-96
Creating a System With Qsys
Send Feedback
Altera Corporation
5-98
QII5V1
2015.05.04
get_connection_parameter_property
get_connection_parameter_property
Description
Returns the value of a property on a parameter in a connection. Parameter properties are metadata about
how Qsys uses the parameter.
Usage
get_connection_parameter_property <connection> <parameter> <property>
Returns
The value of the parameter property.
Arguments
connection
The connection to query.
parameter
The name of the parameter.
property
The property of the connection. Refer to Parameter Properties.
Example
get_connection_parameter_property cpu.data_master/dma0.csr baseAddress UNITS
Related Information
•
•
•
•
•
Altera Corporation
get_connection_parameter_value on page 5-99
get_connection_property on page 5-102
get_connections on page 5-103
get_parameter_properties on page 5-133
Parameter Properties on page 5-168
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_connection_parameter_value
5-99
get_connection_parameter_value
Description
Returns the value of a parameter on the connection. Parameters represent aspects of the connection that
you can modify, such as the base address for an Avalon-MM connection.
Usage
get_connection_parameter_value <connection> <parameter>
Returns
The value of the parameter.
Arguments
connection
The connection to query.
parameter
The name of the parameter.
Example
get_connection_parameter_value cpu.data_master/dma0.csr baseAddress
Related Information
• get_connection_parameters on page 5-100
• get_connections on page 5-103
• set_connection_parameter_value on page 5-145
Creating a System With Qsys
Send Feedback
Altera Corporation
5-100
get_connection_parameters
QII5V1
2015.05.04
get_connection_parameters
Description
Returns a list of parameters found on a connection.
Usage
get_connection_parameters <connection>
Returns
A list of parameter names.
Arguments
connection
The connection to query.
Example
get_connection_parameters cpu.data_master/dma0.csr
Related Information
• get_connection_parameter_property on page 5-98
• get_connection_parameter_value on page 5-99
• get_connection_property on page 5-102
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_connection_properties
5-101
get_connection_properties
Description
Returns a list of properties found on a connection.
Usage
get_connection_properties
Returns
A list of connection properties.
Arguments
No arguments.
Example
get_connection_properties
Related Information
• get_connection_property on page 5-102
• get_connections on page 5-103
Creating a System With Qsys
Send Feedback
Altera Corporation
5-102
get_connection_property
QII5V1
2015.05.04
get_connection_property
Description
Returns the value of a property found on a connection. Properties represent aspects of the connection that
you can modify, such as the type of connection.
Usage
get_connection_property <connection> <property>
Returns
The value of a connection property.
Arguments
connection
The connection to query.
property
The name of the connection. property. Refer to Connection Properties.
Example
get_connection_property cpu.data_master/dma0.csr TYPE
Related Information
• get_connection_properties on page 5-101
• Connection Properties on page 5-160
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_connections
5-103
get_connections
Description
Returns a list of all connections in the system if no element is specified. If you specify a child instance, for
example cpu, Qsys returns all connections to any interface on the instance. If specify an interface on a
child instance, for example cpu.instruction_master, Qsys returns all connections to that interface.
Usage
get_connections [<element>]
Returns
A list of connections.
Arguments
element (optional)
The name of a child instance, or the qualified name of an interface on a child instance.
Example
get_connections
get_connections cpu
get_connections cpu.instruction_master
Related Information
• add_connection on page 5-80
• remove_connection on page 5-139
Creating a System With Qsys
Send Feedback
Altera Corporation
5-104
get_instance_assignment
QII5V1
2015.05.04
get_instance_assignment
Description
Returns the value of an assignment on a child instance. Qsys uses assignments to transfer information
about hardware to embedded software tools and applications.
Usage
get_instance_assignment <instance> <assignment>
Returns
The value of the specified assignment.
Arguments
instance
The name of the child instance.
assignment
The assignment key to query.
Example
get_instance_assignment video_0 embeddedsw.CMacro.colorSpace
Related Information
get_instance_assignments on page 5-105
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_instance_assignments
5-105
get_instance_assignments
Description
Returns a list of assignment keys for any assignments defined for the instance.
Usage
get_instance_assignments <instance>
Returns
A list of assignment keys.
Arguments
instance
The name of the child instance.
Example
get_instance_assignments sdram
Related Information
get_instance_assignment on page 5-104
get_instance_assignment on page 5-104
Creating a System With Qsys
Send Feedback
Altera Corporation
5-106
get_instance_documentation_links
QII5V1
2015.05.04
get_instance_documentation_links
Description
Returns a list of all documentation links provided by an instance.
Usage
get_instance_documentation_links <instance>
Returns
A list of documentation links.
Arguments
instance
The name of the child instance.
Example
get_instance_documentation_links cpu_0
Notes
The list of documentation links includes titles and URLs for the links. For instance, a component with a
single data sheet link may return:
{Data Sheet} {http://url/to/data/sheet}
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_instance_interface_assignment
5-107
get_instance_interface_assignment
Description
Returns the value of an assignment on an interface of a child instance. Qsys uses assignments to transfer
information about hardware to embedded software tools and applications.
Usage
get_instance_interface_assignment <instance> <interface> <assignment>
Returns
The value of the specified assignment.
Arguments
instance
The name of the child instance.
interface
The name of an interface on the child instance.
assignment
The assignment key to query.
Example
get_instance_interface_assignment sdram s1 embeddedsw.configuration.isFlash
Related Information
get_instance_interface_assignments on page 5-108
Creating a System With Qsys
Send Feedback
Altera Corporation
5-108
QII5V1
2015.05.04
get_instance_interface_assignments
get_instance_interface_assignments
Description
Returns a list of assignment keys for any assignments defined for an interface of a child instance.
Usage
get_instance_interface_assignments <instance> <interface>
Returns
A list of assignment keys.
Arguments
instance
The name of the child instance.
interface
The name of an interface on the child instance.
Example
get_instance_interface_assignments sdram s1
Related Information
get_instance_interface_assignment on page 5-107
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_instance_interface_parameter_property
5-109
get_instance_interface_parameter_property
Description
Returns the value of a property on a parameter in an interface of a child instance. Parameter properties
are metadata about how Qsys uses the parameter.
Usage
get_instance_interface_parameter_property <instance> <interface> <parameter>
<property>
Returns
The value of the parameter property.
Arguments
instance
The name of the child instance.
interface
The name of an interface on the child instance.
parameter
The name of the parameter on the interface.
property
The name of the property on the parameter. Refer to Parameter Properties.
Example
get_instance_interface_parameter_property uart_0 s0 setupTime ENABLED
Related Information
•
•
•
•
get_instance_interface_parameters on page 5-111
get_instance_interfaces on page 5-116
get_parameter_properties on page 5-133
Parameter Properties on page 5-168
Creating a System With Qsys
Send Feedback
Altera Corporation
5-110
QII5V1
2015.05.04
get_instance_interface_parameter_value
get_instance_interface_parameter_value
Description
Returns the value of a parameter of an interface in a child instance.
Usage
get_instance_interface_parameter_value <instance> <interface> <parameter>
Returns
The value of the parameter.
Arguments
instance
The name of the child instance.
interface
The name of an interface on the child instance.
parameter
The name of the parameter on the interface.
Example
get_instance_interface_parameter_value uart_0 s0 setupTime
Related Information
• get_instance_interface_parameters on page 5-111
• get_instance_interfaces on page 5-116
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_instance_interface_parameters
5-111
get_instance_interface_parameters
Description
Returns a list of parameters for an interface in a child instance.
Usage
get_instance_interface_parameters <instance> <interface>
Returns
A list of parameter names for parameters in the interface.
Arguments
instance
The name of the child instance.
interface
The name of an interface on the uart_0 s0.
Example
get_instance_interface_parameters instance interface
Related Information
• get_instance_interface_parameter_value on page 5-110
• get_instance_interfaces on page 5-116
Creating a System With Qsys
Send Feedback
Altera Corporation
5-112
QII5V1
2015.05.04
get_instance_interface_port_property
get_instance_interface_port_property
Description
Returns the value of a property of a port found in the interface of a child instance.
Usage
get_instance_interface_port_property <instance> <interface> <port> <property>
Returns
The value of the port property.
Arguments
instance
The name of the child instance.
interface
The name of an interface on the child instance.
port
The name of the port in the interface.
property
The name of the property of the port. Refer to Port Properties.
Example
get_instance_interface_port_property uart_0 exports tx WIDTH
Related Information
• get_instance_interface_ports on page 5-113
• get_port_properties on page 5-134
• Port Properties on page 5-173
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_instance_interface_ports
5-113
get_instance_interface_ports
Description
Returns a list of ports found in an interface of a child instance.
Usage
get_instance_interface_ports <instance> <interface>
Returns
A list of port names found in the interface.
Arguments
instance
The name of the child instance.
interface
The name of an interface on the child instance.
Example
get_instance_interface_ports uart_0 s0
Related Information
• get_instance_interface_port_property on page 5-112
• get_instance_interfaces on page 5-116
Creating a System With Qsys
Send Feedback
Altera Corporation
5-114
QII5V1
2015.05.04
get_instance_interface_properties
get_instance_interface_properties
Description
Returns a list of properties that can be queried for an interface in a child instance.
Usage
get_instance_interface_properties
Returns
A list of property names.
Arguments
No arguments.
Example
get_instance_interface_properties
Related Information
• get_instance_interface_property on page 5-115
• get_instance_interfaces on page 5-116
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_instance_interface_property
5-115
get_instance_interface_property
Description
Returns the value of a property for an interface in a child instance.
Usage
get_instance_interface_property <instance> <interface> <property>
Returns
The value of the property.
Arguments
instance
The name of the child instance.
interface
The name of an interface on the child instance.
property
The name of the property of the interface. Refer to Element Properties.
Example
get_instance_interface_property uart_0 s0 DESCRIPTION
Related Information
• get_instance_interface_properties on page 5-114
• get_instance_interfaces on page 5-116
• Element Properties on page 5-163
Creating a System With Qsys
Send Feedback
Altera Corporation
5-116
get_instance_interfaces
QII5V1
2015.05.04
get_instance_interfaces
Description
Returns a list of interfaces found in a child instance
Usage
get_instance_interfaces <instance>
Returns
A list of interface names.
Arguments
instance
The name of the child instance.
Example
get_instance_interfaces uart_0
Related Information
• get_instance_interface_ports on page 5-113
• get_instance_interface_properties on page 5-114
• get_instance_interface_property on page 5-115
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_instance_parameter_property
5-117
get_instance_parameter_property
Description
Returns the value of a property on a parameter in a child instance. Parameter properties are metadata
about how Qsys uses the parameter.
Usage
get_instance_parameter_property <instance> <parameter> <property>
Returns
The value of the parameter property.
Arguments
instance
The name of the child instance.
parameter
The name of the parameter in the instance.
property
The name of the property of the parameter. Refer to Parameter Properties.
Example
get_instance_parameter_property uart_0 baudRate ENABLED
Related Information
• get_instance_parameters on page 5-119
• get_parameter_properties on page 5-133
• Parameter Properties on page 5-168
Creating a System With Qsys
Send Feedback
Altera Corporation
5-118
get_instance_parameter_value
QII5V1
2015.05.04
get_instance_parameter_value
Description
Returns the value of a parameter in a child instance.
Usage
get_instance_parameter_value <instance> <parameter>
Returns
The value of the parameter.
Arguments
instance
The name of the child instance.
parameter
The name of the parameter in the instance.
Example
get_instance_parameter_value uart_0 baudRate
Related Information
• get_instance_parameters on page 5-119
• set_instance_parameter_value on page 5-146
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_instance_parameters
5-119
get_instance_parameters
Description
Returns a list of parameters in a child instance.
Usage
get_instance_parameters <instance>
Returns
A list of parameters in the instance.
Arguments
instance
The name of the child instance.
Example
get_instance_parameters uart_0
Related Information
• get_instance_parameter_property on page 5-117
• get_instance_interface_parameter_value on page 5-110
• set_instance_parameter_value on page 5-146
Creating a System With Qsys
Send Feedback
Altera Corporation
5-120
QII5V1
2015.05.04
get_instance_port_property
get_instance_port_property
Description
Returns the value of a property of a port contained by an interface in a child instance.
Usage
get_instance_port_property <instance> <port> <property>
Returns
The value of the property for the port.
Arguments
instance
The name of the child instance.
port
The name of a port in one of the interfaces on the child instance.
property
The name of a property found on the port. Refer to Port Properties.
Example
get_instance_port_property uart_0 tx WIDTH
Related Information
• get_instance_interface_ports on page 5-113
• get_port_properties on page 5-134
• Port Properties on page 5-173
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_instance_properties
5-121
get_instance_properties
Description
Returns a list of properties for a child instance.
Usage
get_instance_properties
Returns
A list of property names for the child instance.
Arguments
No arguments.
Example
get_instance_properties
Related Information
get_instance_property on page 5-122
Creating a System With Qsys
Send Feedback
Altera Corporation
5-122
QII5V1
2015.05.04
get_instance_property
get_instance_property
Description
Returns the value of a property for a child instance.
Usage
get_instance_property <instance> <property>
Returns
The value of the property.
Arguments
instance
The name of the child instance.
property
The name of a property found on the instance. Refer to Element Properties.
Example
get_instance_property uart_0 ENABLED
Related Information
• get_instance_properties on page 5-121
• Element Properties on page 5-163
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_instances
5-123
get_instances
Description
Returns a list of the instance names for all child instances in the system.
Usage
get_instances
Returns
A list of child instance names.
Arguments
No arguments.
Example
get_instances
Related Information
• add_instance on page 5-81
• remove_instance on page 5-141
Creating a System With Qsys
Send Feedback
Altera Corporation
5-124
QII5V1
2015.05.04
get_interconnect_requirement
get_interconnect_requirement
Description
Returns the value of an interconnect requirement for a system or interface on a child instance.
Usage
get_interconnect_requirement <element_id> <requirement>
Returns
The value of the interconnect requirement.
Arguments
element_id
{$system} for the system, or the qualified name of the interface of an instance, in
<instance>.<interface> format. In Tcl, the system identifier is escaped, for example,
{$system}.
requirement
The name of the requirement.
Example
get_interconnect_requirement {$system} qsys_mm.maxAdditionalLatency
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_interconnect_requirements
5-125
get_interconnect_requirements
Description
Returns a list of all interconnect requirements in the system.
Usage
get_interconnect_requirements
Returns
A flattened list of interconnect requirements. Every sequence of three elements in the list corresponds to
one interconnect requirement. The first element in the sequence is the element identifier. The second
element is the requirement name. The third element is the value. You can loop over the returned list with
a foreach loop, for example:
foreach { element_id name value } $requirement_list { loop_body
}
Arguments
No arguments.
Example
get_interconnect_requirements
Creating a System With Qsys
Send Feedback
Altera Corporation
5-126
QII5V1
2015.05.04
get_interface_port_property
get_interface_port_property
Description
Returns the value of a property of a port contained by one of the top-level exported interfaces
Usage
get_interface_port_property <interface> <port> <property>
Returns
The value of the property.
Arguments
interface
The name of a top-level interface on the system.
port
The name of a port found in the interface.
property
The name of a property found on the port. Refer to Port Properties.
Example
get_interface_port_property uart_exports tx DIRECTION
Related Information
• get_interface_ports on page 5-127
• get_port_properties on page 5-134
• Port Properties on page 5-173
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_interface_ports
5-127
get_interface_ports
Description
Returns the names of all of the ports that have been added to a given interface.
Usage
get_interface_ports <interface>
Returns
A list of port names.
Arguments
interface
The name of a top-level interface on the system.
Example
get_interface_ports export_clk_out
Related Information
• get_interface_port_property on page 5-126
• get_interfaces on page 5-130
Creating a System With Qsys
Send Feedback
Altera Corporation
5-128
QII5V1
2015.05.04
get_interface_properties
get_interface_properties
Description
Returns the names of all the available interface properties common to all interface types.
Usage
get_interface_properties
Returns
A list of interface properties.
Arguments
No arguments.
Example
get_interface_properties
Related Information
• get_interface_property on page 5-129
• set_interface_property on page 5-149
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_interface_property
5-129
get_interface_property
Description
Returns the value of a single interface property from the specified interface.
Usage
get_interface_property <interface> <property>
Returns
The property value.
Arguments
interface
The name of a top-level interface on the system.
property
The name of the property. Refer to Interface Properties.
Example
get_interface_property export_clk_out EXPORT_OF
Related Information
• get_interface_properties on page 5-128
• set_interface_property on page 5-149
• Interface Properties on page 5-165
Creating a System With Qsys
Send Feedback
Altera Corporation
5-130
get_interfaces
QII5V1
2015.05.04
get_interfaces
Description
Returns a list of top-level interfaces in the system.
Usage
get_interfaces
Returns
A list of the top-level interfaces exported from the system.
Arguments
No arguments.
Example
get_interfaces
Related Information
•
•
•
•
•
Altera Corporation
add_interface on page 5-82
get_interface_ports on page 5-127
get_interface_property on page 5-129
remove_interface on page 5-142
set_interface_property on page 5-149
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_module_properties
5-131
get_module_properties
Description
Returns the properties that you can manage for top-level module of the Qsys system.
Usage
get_module_properties
Returns
A list of property names.
Arguments
No arguments.
Example
get_module_properties
Related Information
• get_module_property on page 5-132
• set_module_property on page 5-150
Creating a System With Qsys
Send Feedback
Altera Corporation
5-132
get_module_property
QII5V1
2015.05.04
get_module_property
Description
Returns the value of a top-level system property.
Usage
get_module_property <property>
Returns
The value of the property.
Arguments
property
The name of the property to query. Refer to Module Properties.
Example
get_module_property NAME
Related Information
• get_module_properties on page 5-131
• set_module_property on page 5-150
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_parameter_properties
5-133
get_parameter_properties
Description
Returns a list of properties that you can query for any parameters, for example parameters on instances,
interfaces, instance interfaces, and connections.
Usage
get_parameter_properties
Returns
A list of parameter properties.
Arguments
No arguments.
Example
get_parameter_properties
Related Information
• get_connection_parameter_property on page 5-98
• get_instance_interface_parameter_property on page 5-109
• get_instance_parameter_property on page 5-117
Creating a System With Qsys
Send Feedback
Altera Corporation
5-134
get_port_properties
QII5V1
2015.05.04
get_port_properties
Description
Returns a list of properties that you can query for ports.
Usage
get_port_properties
Returns
A list of port properties.
Arguments
No arguments.
Example
get_port_properties
Related Information
•
•
•
•
•
Altera Corporation
get_instance_interface_port_property on page 5-112
get_instance_interface_ports on page 5-113
get_instance_port_property on page 5-120
get_interface_port_property on page 5-126
get_interface_ports on page 5-127
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
get_project_properties
5-135
get_project_properties
Description
Returns a list of properties that you can query for properties pertaining to the Quartus II project.
Usage
get_project_properties
Returns
A list of project properties.
Arguments
No arguments
Example
get_project_properties
Related Information
• get_project_property on page 5-136
• set_project_property on page 5-151
Creating a System With Qsys
Send Feedback
Altera Corporation
5-136
get_project_property
QII5V1
2015.05.04
get_project_property
Description
Returns the value of a Quartus II project property. Not all Quartus II project properties are available.
Usage
get_project_property <property>
Returns
The value of the property.
Arguments
property
The name of the project property. Refer to Project properties.
Example
get_project_property DEVICE_FAMILY
Related Information
• get_module_properties on page 5-131
• get_module_property on page 5-132
• set_module_property on page 5-150
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
load_system
5-137
load_system
Description
Loads a Qsys system from a file, and uses the system as the current system for scripting commands.
Usage
load_system <file>
Returns
No return value.
Arguments
file
The path to a .qsys file.
Example
load_system example.qsys
Related Information
• create_system on page 5-88
• save_system on page 5-143
Creating a System With Qsys
Send Feedback
Altera Corporation
5-138
QII5V1
2015.05.04
lock_avalon_base_address
lock_avalon_base_address
Description
Prevents the memory-mapped base address from being changed for connections to the specified interface
on an instance when Qsys runs the auto_assign_base_addresses or
auto_assign_system_base_addresses commands.
Usage
lock_avalon_base_address <instance.interface>
Returns
No return value.
Arguments
instance.interface
The qualified name of the interface of an instance, in <instance>.<interface> format.
Example
lock_avalon_base_address sdram.s1
Related Information
• auto_assign_base_addresses on page 5-84
• auto_assign_system_base_addresses on page 5-85
• unlock_avalon_base_address on page 5-154
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
remove_connection
5-139
remove_connection
Description
This command removes a connection from the system.
Usage
remove_connection <connection>
Returns
no return value
Arguments
connection
The name of the connection to remove
Example
remove_connection cpu.data_master/sdram.s0
Related Information
• add_connection on page 5-80
• get_connections on page 5-103
Creating a System With Qsys
Send Feedback
Altera Corporation
5-140
QII5V1
2015.05.04
remove_dangling_connections
remove_dangling_connections
Description
Removes connections where both end points of the connection no longer exist in the system.
Usage
remove_dangling_connections
Returns
No return value.
Arguments
No arguments.
Example
remove_dangling_connections
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
remove_instance
5-141
remove_instance
Description
Removes a child instance from the system.
Usage
remove_instance <instance>
Returns
No return value.
Arguments
instance
The name of the child instance to remove.
Example
remove_instance cpu
Related Information
• add_instance on page 5-81
• get_instances on page 5-123
Creating a System With Qsys
Send Feedback
Altera Corporation
5-142
remove_interface
QII5V1
2015.05.04
remove_interface
Description
Removes an exported top-level interface from the system.
Usage
remove_interface <interface>
Returns
No return value.
Arguments
interface
The name of the exported top-level interface.
Example
remove_interface clk_out
Related Information
• add_interface on page 5-82
• get_interfaces on page 5-130
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
save_system
5-143
save_system
Description
Saves the current system to the named file. If you do not specify the file, Qsys saves the system to the same
file that was opened with the load_system command. You can specify the file as an absolute or relative
path. Relative paths are relative to directory of the most recently loaded system, or relative to the working
directory if no systems are loaded.
Usage
save_system <file>
Returns
No return value.
Arguments
file
If available, the path of the .qsys file to save.
Example
save_system
save_system file.qsys
Creating a System With Qsys
Send Feedback
Altera Corporation
5-144
QII5V1
2015.05.04
send_message
send_message
Description
Sends a message to the user of the script. The message text is normally interpreted as HTML. You can use
the <b> element to provide emphasis.
Usage
send_message <level> <message>
Returns
No return value.
Arguments
level
The following message levels are supported:
•
•
•
•
•
ERROR--Provides an error message.
WARNING--Provides a warning message.
INFO--Provides an informational message.
PROGRESS--Provides a progress message.
DEBUG--Provides a debug message when debug mode is enabled. Refer to Message Levels
Properties.
message
The text of the message.
Example
send_message ERROR "The system is down!"
Related Information
Message Levels Properties on page 5-166
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
set_connection_parameter_value
5-145
set_connection_parameter_value
Description
Sets the value of a parameter for a connection.
Usage
set_connection_parameter_value <connection> <parameter> <value>
Returns
No return value.
Arguments
connection
The name if the connection.
parameter
The name of the parameter.
value
The new parameter value.
Example
set_connection_parameter_value cpu.data_master/dma0.csr baseAddress "0x000a0000"
Related Information
• get_connection_parameter_value on page 5-99
• get_connection_parameters on page 5-100
Creating a System With Qsys
Send Feedback
Altera Corporation
5-146
set_instance_parameter_value
QII5V1
2015.05.04
set_instance_parameter_value
Description
Set the value of a parameter for a child instance. You cannot set derived parameters and SYSTEM_INFO
parameters for the child instance with this command.
Usage
set_instance_parameter_value <instance> <parameter> <value>
Returns
No return value.
Arguments
instance
The name of the child instance.
parameter
The name of the parameter.
value
The new parameter value.
Example
set_instance_parameter_value uart_0 baudRate 9600
Related Information
• get_instance_parameter_value on page 5-118
• get_instance_parameter_property on page 5-117
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
set_instance_property
5-147
set_instance_property
Description
Sets the value of a property of a child instance. Most instance properties are read-only and can only be set
by the instance itself. The primary use for this command is to update the ENABLED parameter, which
includes or excludes a child instance when generating Qsys interconnect.
Usage
set_instance_property <instance> <property> <value>
Returns
No return value.
Arguments
instance
The name of the child instance.
property
The name of the property. Refer to Instance Properties.
value
The new property value.
Example
set_instance_property cpu ENABLED false
Related Information
• get_instance_parameters on page 5-119
• get_instance_property on page 5-122
• Instance Properties on page 5-164
Creating a System With Qsys
Send Feedback
Altera Corporation
5-148
QII5V1
2015.05.04
set_interconnect_requirement
set_interconnect_requirement
Description
Sets the value of an interconnect requirement for a system or an interface on a child instance.
Usage
set_interconnect_requirement <element_id> <requirement> <value>
Returns
No return value.
Arguments
element_id
{$system} for the system, or qualified name of the interface of an instance, in
<instance>.<interface> format. In Tcl, the system identifier is escaped, for example,
{$system}.
requirement
The name of the requirement.
value
The new requirement value.
Example
set_interconnect_requirement {$system} qsys_mm.clockCrossingAdapter HANDSHAKE
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
set_interface_property
5-149
set_interface_property
Description
Sets the value of a property on an exported top-level interface. You use this command to set the
EXPORT_OF property to specify which interface of a child instance is exported via this top-level interface.
Usage
set_interface_property <interface> <property> <value>
Returns
No return value.
Arguments
interface
The name of an exported top-level interface.
property
The name of the property. Refer to Interface Properties.
value
The new property value.
Example
set_interface_property clk_out EXPORT_OF clk.clk_out
Related Information
•
•
•
•
add_interface on page 5-82
get_interface_properties on page 5-128
get_interface_property on page 5-129
Interface Properties on page 5-165
Creating a System With Qsys
Send Feedback
Altera Corporation
5-150
QII5V1
2015.05.04
set_module_property
set_module_property
Description
Sets the value of a system property, such as the name of the system using the NAME property.
Usage
set_module_property <property> <value>
Returns
No return value.
Arguments
property
The name of the property. Refer to Module Properties.
value
The new property value.
Example
set_module_property NAME "new_system_name"
Related Information
• get_module_properties on page 5-131
• get_module_property on page 5-132
• Module Properties on page 5-167
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
set_project_property
5-151
set_project_property
Description
Sets the value of a project property, such as the device family.
Usage
set_project_property <property> <value>
Returns
No return value.
Arguments
property
The name of the property. Refer to Project Properties.
value
The new property value.
Example
set_project_property DEVICE_FAMILY "Cyclone IV GX"
Related Information
•
•
•
•
•
•
get_project_properties on page 5-135
set_project_property on page 5-151
Project Properties on page 5-174
get_project_properties on page 5-135
get_project_property on page 5-136
Project Properties on page 5-174
Creating a System With Qsys
Send Feedback
Altera Corporation
5-152
set_use_testbench_naming_pattern
QII5V1
2015.05.04
set_use_testbench_naming_pattern
Description
Use this command to create testbench systems so that the generated file names for the test system match
the system's original generated file names. Without setting this, the generated file names for the test
system receive the top-level testbench system name.
Usage
set_use_testbench_naming_pattern <value>
Returns
No return value.
Arguments
value
True or false.
Example
set_use_testbench_naming_pattern true
Notes
Use this command only to create testbench systems.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
set_validation_property
5-153
set_validation_property
Description
Sets a property that affects how and when validation is run. To disable system validation after each
scripting command, set AUTOMATIC_VALIDATION to False.
Usage
set_validation_property <property> <value>
Returns
No return value.
Arguments
property
The name of the property. Refer to Validation Properties.
value
The new property value.
Example
set_validation_property AUTOMATIC_VALIDATION false
Related Information
• validate_system on page 5-158
• Validation Properties on page 5-178
Creating a System With Qsys
Send Feedback
Altera Corporation
5-154
QII5V1
2015.05.04
unlock_avalon_base_address
unlock_avalon_base_address
Description
Allows the memory-mapped base address to change for connections to the specified interface on an
instance when Qsys runs the auto_assign_base_addresses or auto_assign_system_base_addresses
commands.
Usage
unlock_avalon_base_address <instance.interface>
Returns
No return value.
Arguments
instance.interface
The qualified name of the interface of an instance, in <instance>.<interface> format.
Example
unlock_avalon_base_address sdram.s1
Related Information
• auto_assign_base_addresses on page 5-84
• auto_assign_system_base_addresses on page 5-85
• lock_avalon_base_address on page 5-138
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
validate_connection
5-155
validate_connection
Description
Validates the specified connection and returns validation messages.
Usage
validate_connection <connection>
Returns
A list of messages produced during validation.
Arguments
connection
The name of the connection to validate.
Example
validate_connection cpu.data_master/sdram.s1
Related Information
• validate_instance on page 5-156
• validate_instance_interface on page 5-157
• validate_system on page 5-158
Creating a System With Qsys
Send Feedback
Altera Corporation
5-156
validate_instance
QII5V1
2015.05.04
validate_instance
Description
Validates the specified child instance and returns validation messages.
Usage
validate_instance <instance>
Returns
A list of messages produced during validation.
Arguments
instance
The name of the child instance to validate.
Example
validate_instance cpu
Related Information
• validate_connection on page 5-155
• validate_instance_interface on page 5-157
• validate_system on page 5-158
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
validate_instance_interface
5-157
validate_instance_interface
Description
Validates an interface on a child instance and returns validation messages.
Usage
validate_instance_interface <instance> <interface>
Returns
A list of messages produced during validation.
Arguments
instance
The name of a child instance.
interface
The name of the interface on the child instance to validate.
Example
validate_instance_interface cpu data_master
Related Information
• validate_connection on page 5-155
• validate_instance on page 5-156
• validate_system on page 5-158
Creating a System With Qsys
Send Feedback
Altera Corporation
5-158
validate_system
QII5V1
2015.05.04
validate_system
Description
Validates the system and returns validation messages.
Usage
validate_system
Returns
A list of validation messages produced during validation.
Arguments
No arguments.
Example
validate_system
Related Information
• validate_connection on page 5-155
• validate_instance on page 5-156
• validate_instance_interface on page 5-157
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Qsys Scripting Property Reference
5-159
Qsys Scripting Property Reference
Interface properties work differently for _hw.tcl scripting than with qsys scripting. In _hw.tcl, interfaces
do not distinguish between properties and parameters. In qsys scripting, properties and parameters are
unique.
Connection Properties on page 5-160
Design Environment Type Properties on page 5-161
Direction Properties on page 5-162
Element Properties on page 5-163
Instance Properties on page 5-164
Interface Properties on page 5-165
Message Levels Properties on page 5-166
Module Properties on page 5-167
Parameter Properties on page 5-168
Parameter Status Properties on page 5-171
Parameter Type Properties on page 5-172
Port Properties on page 5-173
Project Properties on page 5-174
System Info Type Properties on page 5-175
Units Properties on page 5-177
Validation Properties on page 5-178
Creating a System With Qsys
Send Feedback
Altera Corporation
5-160
QII5V1
2015.05.04
Connection Properties
Connection Properties
Type
Name
Description
string
END
The end interface of the connection.
string
NAME
The name of the connection.
string
START
The start interface of the connection.
String
TYPE
The type of the connection.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Design Environment Type Properties
5-161
Design Environment Type Properties
Description
IP cores use the design environment to identify what sort of interfaces are most appropriate to connect in
the parent system.
Name
Description
NATIVE
The design environment supports native IP interfaces.
QSYS
The design environment supports standard Qsys interfaces.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-162
QII5V1
2015.05.04
Direction Properties
Direction Properties
Name
Description
BIDIR
The direction for a bidirectional signal.
INOUT
The direction for an input signal.
OUTPUT
The direction for an output signal.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Element Properties
5-163
Element Properties
Description
Element properties are, with the exception of ENABLED and NAME, read-only properties of the types of
instances, interfaces, and connections. These read-only properties represent metadata that does not vary
between copies of the same type. ENABLED and NAME properties are specific to particular instances,
interfaces, or connections.
Type
String
Name
AUTHOR
Description
The author of the component or interface.
Boolean AUTO_EXPORT
Indicates whether unconnected interfaces on the instance are automatically
exported.
String
CLASS_NAME
The type of the instance, interface or connection, for example, altera_nios2
or avalon_slave.
String
DESCRIPTION
The description of the instance, interface or connection type.
String
DISPLAY_NAME
The display name for referencing the type of instance, interface or connection.
Boolean EDITABLE
Indicates whether you can edit the component in the Qsys Component Editor.
Boolean ENABLED
Indicates whether the instance is turned on.
String
The IP Catalog category.
GROUP
Boolean INTERNAL
Hides internal IP components or sub-components from the IP Catalog..
String
NAME
The name of the instance, interface or connection.
String
VERSION
Creating a System With Qsys
Send Feedback
The version number of the instance, interface or connection, for example,
14.0.
Altera Corporation
5-164
QII5V1
2015.05.04
Instance Properties
Instance Properties
Type
String
Name
AUTO_EXPORT
Description
Indicates whether unconnected interfaces on the instance are automatically
exported.
Boolean ENABLED
If true, this instance is included in the generated system. if false, it is not
included.
String
The name of the system, which is used as the name of the top-level module in
the generated HDL.
Altera Corporation
NAME
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Interface Properties
5-165
Interface Properties
Type
Name
Description
String EXPORT_OF Indicates which interface of a child instance to export through the top-level
interface. Before using this command, you must create the top-level interface using
the add_interface command. You must use the format:
<instanceName.interfaceName>. For example:
set_interface_property CSC_input EXPORT_OF my_colorSpaceConverter.input_port
Creating a System With Qsys
Send Feedback
Altera Corporation
5-166
QII5V1
2015.05.04
Message Levels Properties
Message Levels Properties
Name
Description
COMPONENT_INFO
Reports an informational message only during component editing.
DEBUG
Provides messages when debug mode is turned on.
ERROR
Provides an error message.
INFO
Provides an informational message.
PROGRESS
Reports progress during generation.
TODOERROR
Provides an error message that indicates the system is incomplete.
WARNING
Provides a warning message.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Module Properties
5-167
Module Properties
Type
Name
Description
String
GENERATION_ID
The generation ID for the system.
String
NAME
The name of the instance.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-168
QII5V1
2015.05.04
Parameter Properties
Parameter Properties
Type
Name
Description
Boolean AFFECTS_ELABORATION Set AFFECTS_ELABORATION to false for parameters that do not affect
the external interface of the module. An example of a parameter that
does not affect the external interface is isNonVolatileStorage. An
example of a parameter that does affect the external interface is
width. When the value of a parameter changes and
AFFECTS_ELABORATION is false, the elaboration phase does not repeat
and improves performance. When AFFECTS_ELABORATION is set to
true, the default value, Qsys reanalyzes the HDL file to determine the
port widths and configuration each time a parameter changes.
Boolean AFFECTS_GENERATION
The default value of AFFECTS_GENERATION is false if you provide a
top-level HDL module. The default value is true if you provide a
fileset callback. Set AFFECTS_GENERATION to false if the value of a
parameter does not change the results of fileset generation.
Boolean AFFECTS_VALIDATION
The AFFECTS_VALIDATION property determines whether a
parameter's value sets derived parameters, and whether the value
affects validation messages. When set to false, this may improve
response time in the parameter editor when the value changes.
String[]
Indicates the range or ranges of the parameter. For integers, Each
range is a single value, or a range of values defined by a start and end
value, and delimited by a colon, for example, 11:15. This property
also specifies the legal values and description strings for integers, for
example, {0:None 1:Monophonic 2:Stereo 4:Quadrophonic},
where 0, 1, 2, and 4 are the legal values. You can assign description
strings in the parameter editor for string variables. For example,
ALLOWED_RANGES
ALLOWED_RANGES {"dev1:Cyclone IV GX""dev2:Stratix V
GT"}
String
DEFAULT_VALUE
The default value.
Boolean DERIVED
When True, indicates that the parameter value is set by the
component and cannot be set by the user. Derived parameters are not
saved as part of an instance's parameter values. The default value is
False.
String
DESCRIPTION
A short user-visible description of the parameter, suitable for a
tooltip description in the parameter editor.
String[]
DISPLAY_HINT
Altera Corporation
Provides a hint about how to display a property.
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Parameter Properties
Type
Name
5-169
Description
• boolean--For integer parameters whose value are 0 or 1. The
parameter displays as an option that you can turn on or off.
• radio--Displays a parameter with a list of values as radio buttons.
• hexadecimal--For integer parameters, displays and interprets
the value as a hexadecimal number, for example: 0x00000010
instead of 16.
• fixed_size--For string_list and integer_list parameters,
the fixed_size DISPLAY_HINT eliminates the Add and Remove
buttons from tables.
String
DISPLAY_NAME
The GUI label that appears to the left of this parameter.
String
DISPLAY_UNITS
The GUI label that appears to the right of the parameter.
Boolean ENABLED
When False, the parameter is turned off. It displays in the parameter
editor but is grayed out, indicating that you cannot edit this
parameter.
String
Controls the layout of parameters in the GUI.
GROUP
Boolean HDL_PARAMETER
When True, Qsys passes the parameter to the HDL component
description. The default value is False.
String
LONG_DESCRIPTION
A user-visible description of the parameter. Similar to DESCRIPTION,
but allows a more detailed explanation.
String
NEW_INSTANCE_VALUE
String[]
SYSTEM_INFO
Changes the default value of a parameter without affecting older
components that do not explicitly set a parameter value, and use the
DEFAULT_VALUE property. Oder instances continue to use
DEFAULT_VALUE for the parameter and new instances use the value
assigned by NEW_INSTANCE_VALUE.
Allows you to assign information about the instantiating system to a
parameter that you define. SYSTEM_INFO requires an argument
specifying the type of information for example,
SYSTEM_INFO <info-type>
String
SYSTEM_INFO_ARG
Defines an argument to pass to SYSTEM_INFO. For example, the name
of a reset interface.
(various) SYSTEM_INFO_TYPE
Specifies the types of system information that you can query. Refer to
System Info Type Properties.
(various) TYPE
Specifies the type of the parameter. Refer to Parameter Type
Properties.
(various) UNITS
Sets the units of the parameter. Refer to Units Properties.
Boolean VISIBLE
Indicates whether or not to display the parameter in the parameter
editor.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-170
QII5V1
2015.05.04
Parameter Properties
Type
String
Name
WIDTH
Description
Indicates the width of the logic vector for the STD_LOGIC_VECTOR
parameter.
Related Information
• System Info Type Properties on page 5-175
• Parameter Type Properties on page 5-172
• Units Properties on page 5-177
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Parameter Status Properties
5-171
Parameter Status Properties
Type
Name
Description
Boolean ACTIVE
Indicates that this parameter is an active parameter.
Boolean DEPRECATED
Indicates that this parameter exists only for backwards compatibility, and may
not have any effect.
Boolean EXPERIMENTAL Indicates that this parameter is experimental and not exposed in the design
flow.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-172
QII5V1
2015.05.04
Parameter Type Properties
Parameter Type Properties
Name
Description
BOOLEAN
A boolean parameter set to true or false.
FLOAT
A signed 32-bit floating point parameter. (Not supported for HDL parameters.)
INTEGER
A signed 32-bit integer parameter.
INTEGER_LIST
A parameter that contains a list of 32-bit integers. (Not supported for HDL
parameters.)
LONG
A signed 64-bit integer parameter. (Not supported for HDL parameters.)
NATURAL
A 32-bit number that contains values 0 to 2147483647 (0x7fffffff).
POSITIVE
A 32-bit number that contains values 1 to 2147483647 (0x7fffffff).
STD_LOGIC
A single bit parameter set to 0 or 1.
STD_LOGIC_VECTOR
An arbitrary-width number. The parameter property WIDTH determines the size of
the logic vector.
STRING
A string parameter.
STRING_LIST
A parameter that contains a list of strings. (Not supported for HDL parameters.)
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Port Properties
5-173
Port Properties
Type
Name
Description
(various) DIRECTION The direction of the signal. Refer to Direction Properties.
String
ROLE
Integer
WIDTH
Creating a System With Qsys
Send Feedback
The type of the signal. Each interface type defines a set of interface types for its
ports.
The width of the signal in bits.
Altera Corporation
5-174
QII5V1
2015.05.04
Project Properties
Project Properties
Type
Name
String DEVICE
Description
The device part number in the Quartus II project that contains the Qsys system.
String DEVICE_FAMILY The device family name in the Quartus II project that contains the Qsys system.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
System Info Type Properties
5-175
System Info Type Properties
Type
Name
String
ADDRESS_MAP
Integer
ADDRESS_WIDTH
String
AVALON_SPEC
Integer
CLOCK_DOMAIN
Description
An XML-formatted string that describes the address
map for the interface specified in the SYSTEM_INFO
parameter property.
The number of address bits that Qsys requires to address
memory-mapped slaves connected to the specified
memory-mapped master in this instance.
The version of the Qsys interconnect. Refer to Avalon
Interface Specifications.
An integer that represents the clock domain for the
interface specified in the SYSTEM_INFO parameter
property. If this instance has interfaces on multiple clock
domains, you can use this property to determine which
interfaces are on each clock domain. The absolute value
of the integer is arbitrary.
Long, Integer CLOCK_RATE
The rate of the clock connected to the clock input
specified in the SYSTEM_INFO parameter property. If
zero, the clock rate is currently unknown.
String
CLOCK_RESET_INFO
The name of this instance's primary clock or reset sink
interface. You use this property to determine the reset
sink for global reset when you use SOPC Builder
interconnect that conforms to Avalon Interface
Specifications.
String
CUSTOM_INSTRUCTION_SLAVES
String
DESIGN_ENVIRONMENT
String
DEVICE
The device part number of the selected device.
String
DEVICE_FAMILY
The family name of the selected device.
String
DEVICE_FEATURES
String
DEVICE_SPEEDGRADE
Integer
GENERATION_ID
Creating a System With Qsys
Send Feedback
Provides slave information, including the name, base
address, address span, and clock cycle type.
A string that identifies the current design environment.
Refer to Design Environment Type Properties.
A list of key/value pairs delimited by spaces that indicate
whether a device feature is available in the selected
device family. The format of the list is suitable for
passing to the array command. The keys are device
features. The values are 1 if the feature is present, and 0 if
the feature is absent.
The speed grade of the selected device.
A integer that stores a hash of the generation time that
Qsys uses as a unique ID for a generation run.
Altera Corporation
5-176
QII5V1
2015.05.04
System Info Type Properties
Type
BigInteger,
Long
Integer
String,
Boolean,
Integer
Name
INTERRUPTS_USED
MAX_SLAVE_DATA_WIDTH
QUARTUS_INI
Integer
RESET_DOMAIN
String
TRISTATECONDUIT_INFO
String
TRISTATECONDUIT_MASTERS
String
UNIQUE_ID
Description
A mask indicating which bits of an interrupt receiver are
connected to interrupt senders. The interrupt receiver is
specified in the system info argument.
The data width of the widest slave connected to the
specified memory-mapped master.
The value of the quartus.ini setting specified in the system
info argument.
An integer representing the reset domain for the
interface specified in the SYSTEM_INFO parameter
property If this instance has interfaces on multiple reset
domains, you can use this property to determine which
interfaces are on each reset domain. The absolute value
of the integer is arbitrary.
An XML description of the tri-state conduit masters
connected to a tri-state conduit slave. The slave is
specified as the SYSTEM_INFO parameter property. The
value contains information about the slave, connected
master instance and interface names, and signal names,
directions, and widths.
The names of the instance's interfaces that are tri-state
conduit slaves.
A string guaranteed to be unique to this instance.
Related Information
• Design Environment Type Properties on page 5-161
• Avalon Interface Specifications
• Qsys Interconnect on page 7-1
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Units Properties
5-177
Units Properties
Name
Description
ADDRESS
A memory-mapped address.
BITS
Memory size in bits.
BITSPERSECOND
Rate in bits per second.
BYTES
Memory size in bytes.
CYCLES
A latency or count in clock cycles.
GIGABITSPERSECOND
Rate in gigabits per second.
GIGABYTES
Memory size in gigabytes.
GIGAHERTZ
Frequency in GHz.
HERTZ
Frequency in Hz.
KILOBITSPERSECOND
Rate in kilobits per second.
KILOBYTES
Memory size in kilobytes.
KILOHERTZ
Frequency in kHz.
MEGABITSPERSECOND
Rate, in megabits per second.
MEGABYTES
Memory size in megabytes.
MEGAHERTZ
Frequency in MHz.
MICROSECONDS
Time in microseconds.
MILLISECONDS
Time in milliseconds.
NANOSECONDS
Time in nanoseconds.
NONE
Unspecified units.
PERCENT
A percentage.
PICOSECONDS
Time in picoseconds.
SECONDS
Time in seconds.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-178
QII5V1
2015.05.04
Validation Properties
Validation Properties
Type
Name
Description
Boolean AUTOMATIC_VALIDATION When true, Qsys runs system validation and elaboration after each
scripting command. When false, Qsys runs system validation with
validation scripting commands. Some queries affected by system
elaboration may be incorrect if automatic validation is turned off.
You can disable validation to make a system script run faster.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2015.05.04
Document Revision History
5-179
Document Revision History
The table below indicates edits made to the Creating a System With Qsys content since its creation.
Table 5-16: Document Revision History
Date
Version
Changes
2015.05.04
15.0.0
• New figure: Avalon-MM Write Master Timing Waveforms in
the Parameters Tab.
• Added Enable ECC protection option, Specify Qsys
Interconnect Requirements.
• Added External Memory Interface Debug Toolkit note,
Generate a Qsys System.
• Modelsim-Altera now supports native mixed-language
(VHDL/Verilog/SystemVerilog) simulation, Generating
Files for Synthesis and Simulation.
December 2014
14.1.0
•
•
•
•
•
August 2014
14.0a10.0
• Added distinction between legacy and standard device
generation.
• Updated: Upgrading Outdated IP Components.
• Updated: Generating a Qsys System.
• Updated: Integrating a Qsys System with the Quartus II
Software.
• Added screen shot: Displaying Your Qsys System.
June 2014
14.0.0
•
•
•
•
Added tab descriptions: Details, Connections.
Added Managing IP Settings in the Quartus II Software.
Added Upgrading Outdated IP Components.
Added Support for Avalon-MM Non-Power of Two Data
Widths.
November 2013
13.1.0
•
•
•
•
Added Integrating with the .qsys File.
Added Using the Hierarchy Tab.
Added Managing Interconnect Requirements.
Added Viewing Qsys Interconnect.
Creating a System With Qsys
Send Feedback
Create and Manage Hierarchical Qsys Systems.
Schematic tab.
View and Filter Clock and Reset Domains.
File > Recent Projects menu item.
Updated example: Hierarchical System Using Instance
Parameters
Altera Corporation
5-180
QII5V1
2015.05.04
Document Revision History
Date
Version
Changes
May 2013
13.0.0
•
•
•
•
•
Added AMBA APB support.
Added qsys-generate utility.
Added VHDL BFM ID support.
Added Creating Secure Systems (TrustZones) .
Added CMSIS Support for Qsys Systems With An HPS
Component.
• Added VHDL language support options.
November 2012
12.1.0
• Added AMBA AXI4 support.
June 2012
12.0.0
• Added AMBA AX3I support.
• Added Preset Editor updates.
• Added command-line utilities, and scripts.
November 2011
11.1.0
• Added Synopsys VCS and VCS MX Simulation Shell Script.
• Added Cadence Incisive Enterprise (NCSIM) Simulation
Shell Script.
• Added Using Instance Parameters and Example Hierarchical
System Using Parameters.
May 2011
11.0.0
• Added simulation support in Verilog HDL and VHDL.
• Added testbench generation support.
• Updated simulation and file generation sections.
December 2010
10.1.0
Initial release.
Related Information
Quartus II Handbook Archive
Altera Corporation
Creating a System With Qsys
Send Feedback
Creating Qsys Components
6
2015.05.04
QII5V1
Subscribe
Send Feedback
In order to describe and package IP components for use in a Qsys system, you must create a Hardware
Component Definition File (_hw.tcl) which will describes your component, its interfaces and HDL files.
Qsys provides the Component Editor to help you create a simple _hw.tcl file.
The Demo AXI Memory example on the Qsys Design Examples page of the Altera web site provides the
full code examples that appear in the following topics.
Qsys supports Avalon, AMBA AXI3 (version 1.0), AMBA AXI4 (version 2.0), AMBA AXI4-Lite (version
2.0), AMBA AXI4-Stream (version 1.0), and AMBA APB3 (version 1.0) interface specifications.
Related Information
• Avalon Interface Specifications
• AMBA Protocol Specifications
• Demo AXI Memory Example
Qsys Components
A Qsys component includes the following elements:
• Information about the component type, such as name, version, and author.
• HDL description of the component’s hardware, including SystemVerilog, Verilog HDL, or VHDL files
• Constraint files (Synopsys Design Constraints File (.sdc) and/or Quartus II IP File (.qip)) that define
the component for synthesis and simulation.
• A component’s interfaces, including I/O signals.
• The parameters that configure the operation of the component.
IP Component Interface Support in Qsys
IP components can have any number of interfaces in any combination. Each interface represents a set of
signals that you can connect within a Qsys system, or export outside of a Qsys system.
© 2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos are
trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as
trademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance
of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any
products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information,
product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device
specifications before relying on any published information and before placing orders for products or services.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
ISO
9001:2008
Registered
6-2
QII5V1
2015.05.04
Component Structure
Qsys IP components can include the following interface types:
Table 6-1: IP Component Interface Types
Interface Type
Description
Memory-Mapped
Connects memory-referencing master devices with slave memory devices. Master
devices may be processors and DMAs, while slave memory devices may be RAMs,
ROMs, and control registers. Data transfers between master and slave may be unidirectional (read only or write only), or bi-directional (read and write).
Streaming
Connects Avalon Streaming (Avalon-ST) sources and sinks that stream unidirec‐
tional data, as well as high-bandwidth, low-latency IP components. Streaming
creates datapaths for unidirectional traffic, including multichannel streams, packets,
and DSP data. The Avalon-ST interconnect is flexible and can implement on-chip
interfaces for industry standard telecommunications and data communications
cores, such as Ethernet, Interlaken, and video. You can define bus widths, packets,
and error conditions.
Interrupts
Connects interrupt senders to interrupt receivers. Qsys supports individual,
single-bit interrupt requests (IRQs). In the event that multiple senders assert their
IRQs simultaneously, the receiver logic (typically under software control)
determines which IRQ has highest priority, then responds appropriately
Clocks
Connects clock output interfaces with clock input interfaces. Clock outputs can fanout without the use of a bridge. A bridge is required only when a clock from an
external (exported) source connects internally to more than one source.
Resets
Connects reset sources with reset input interfaces. If your system requires a
particular positive-edge or negative-edge synchronized reset, Qsys inserts a reset
controller to create the appropriate reset signal. If you design a system with multiple
reset inputs, the reset controller ORs all reset inputs and generates a single reset
output.
Conduits
Connects point-to-point conduit interfaces, or represent signals that are exported
from the Qsys system. Qsys uses conduits for component I/O signals that are not
part of any supported standard interface. You can connect two conduits directly
within a Qsys system as a point-to-point connection, or conduit interfaces can be
exported and brought to the top-level of the system as top-level system I/O. You can
use conduits to connect to external devices, for example external DDR SDRAM
memory, and to FPGA logic defined outside of the Qsys system.
Component Structure
Altera provides components automatically installed with the Quartus II software. You can obtain a list of
Qsys-compliant components provided by third-party IP developers on Altera's Intellectual Property &
Reference Designs page by typing: qsys certified in the Search box, and then selecting IP Core &
Reference Designs. Components are also provided with Altera development kits, which are listed on the
All Development Kits page.
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
Component File Organization
6-3
Every component is defined with a < component_name >_hw.tcl file, a text file written in the Tcl scripting
language that describes the component to Qsys. When you design your own custom component, you can
create the _hw.tcl file manually, or by using the Qsys Component Editor.
The Component Editor simplifies the process of creating _hw.tcl files by creating a file that you can edit
outside of the Component Editor to add advanced procedures. When you edit a previously saved _hw.tcl
file, Qsys automatically backs up the earlier version as _hw.tcl~.
You can move component files into a new directory, such as a network location, so that other users can
use the component in their systems. The _hw.tcl file contains relative paths to the other files, so if you
move an _hw.tcl file, you should also move all the HDL and other files associated with it.
There are three component types:
• Static— Static components always generate the same output, regardless of their parameterization.
Components that instantiate static components must have only static children.
• Generated—A generated component's fileset callback allows an instance of the component to create
unique HDL design files based on the instance's parameter values.
• Composed—Composed components are subsystems constructed from instances of other components.
You can use a composition callback to manage the subsystem in a composed component.
Related Information
• Create a Composed Component or Subsystem on page 6-28
• Add Component Instances to a Static or Generated Component on page 6-31
• Intellectual Property & Reference Designs
Component File Organization
A typical component uses the following directory structure where the names of the directories are not
significant:
<component_directory>/
• <hdl>/—Contains the component HDL design files, for example .v, .sv, or .vhd files that contain the
top-level module, along with any required constraint files.
• <component_name> _hw.tcl—The component description file.
• <component_name> _sw.tcl—The software driver configuration file. This file specifies the paths for
the .c and .h files associated with the component, when required.
• <software>/—Contains software drivers or libraries related to the component.
Note: Refer to the Nios II Software Developer’s Handbook for information about writing a device driver or
software package suitable for use with the Nios II processor.
Related Information
• Hardware Abstraction LayerTool Reference (Nios II Software Developer’s Handbook)
• Nios II Software Build Tool Reference (Nios II Software Developer’s Handbook)
Component Versions
Qsys systems support multiple versions of the same component within the same system; you can create
and maintain multiple versions of the same component.
Creating Qsys Components
Send Feedback
Altera Corporation
6-4
QII5V1
2015.05.04
Upgrade IP Components to the Latest Version
If you have multiple _hw.tcl files for components with the same NAME module properties and different
VERSION module properties, both versions of the component are available.
If multiple versions of the component are available in the IP Catalog, you can add a specific version of a
component by right-clicking the component, and then selecting Add version <version_number>.
Upgrade IP Components to the Latest Version
When you open a Qsys design, if Qsys detects IP components that require regeneration, the Upgrade IP
Cores dialog box appears and allows you to upgrade outdated components.
Components that you must upgrade in order to successfully compile your design appear in red. Status
icons indicate whether a component is currently being regenerated, the component is encrypted, or that
there is not enough information to determine the status of component. To upgrade a component, in the
Upgrade IP Cores dialog box, select the component that you want to upgrade, and then click Upgrade.
The Quartus II software maintains a list of all IP components associated with your design on the
Components tab in the Project Navigator.
Related Information
Upgrade IP Components Dialog Box
Design Phases of an IP Component
When you define a component with the Qsys Component Editor, or a custom _hw.tcl file, you specify the
information that Qsys requires to instantiate the component in a Qsys system and to generate the
appropriate output files for synthesis and simulation.
The following phases describe the process when working with components in Qsys:
• Discovery—During the discovery phase, Qsys reads the _hw.tcl file to identify information that
appears in the IP Catalog, such as the component's name, version, and documentation URLs. Each
time you open Qsys, the tool searches for the following file types using the default search locations and
entries in the IP Search Path:
• _hw.tcl files—Each _hw.tcl file defines a single component.
• IP Index (.ipx) files—Each .ipx file indexes a collection of available components, or a reference to
other directories to search.
• Static Component Definition—During the static component definition phase, Qsys reads the _hw.tcl
file to identify static parameter declarations, interface properties, interface signals, and HDL files that
define the component. At this stage of the life cycle, the component interfaces may be only partially
defined.
• Parameterization—During the parameterization phase, after an instance of the component is added
to a Qsys system, the user of the component specifies parameters with the component’s parameter
editor.
• Validation—During the validation phase, Qsys validates the values of each instance's parameters
against the allowed ranges specified for each parameter. You can use callback procedures that run
during the validation phase to provide validation messages. For example, if there are dependencies
between parameters where only certain combinations of values are supported, you can report errors
for the unsupported values.
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
Create IP Components in the Qsys Component Editor
6-5
• Elaboration—During the elaboration phase, Qsys queries the component for its interface information.
Elaboration is triggered when an instance of a component is added to a system, when its parameters
are changed, or when a system property changes. You can use callback procedures that run during the
elaboration phase to dynamically control interfaces, signals, and HDL files based on the values of
parameters. For example, interfaces defined with static declarations can be enabled or disabled during
elaboration. When elaboration is complete, the component's interfaces and design logic must be
completely defined.
• Composition—During the composition phase, a component can manipulate the instances in the
component's subsystem. The _hw.tcl file uses a callback procedure to provide parameterization and
connectivity of sub-components.
• Generation—During the generation phase, Qsys generates synthesis or simulation files for each
component in the system into the appropriate output directories, as well as any additional files that
support associated tools.
Create IP Components in the Qsys Component Editor
The Qsys Component Editor, accessed by clicking New Component in the IP Catalog, allows you to
create and package a component for use in Qsys. When you use the Component Editor to define a
component, the Component Editor writes the information to an _hw.tcl file.
The Component Editor allows you to perform the following tasks:
• Specify component’s identifying information, such as name, version, author, etc.
• Specify the SystemVerilog, Verilog HDL, or VHDL files, and constraint files that define the
component for synthesis and simulation.
• Create an HDL template for a component by first defining its parameters, signals, and interfaces.
• Associate and define signals for a component’s interfaces.
• Set parameters on interfaces, which specify characteristics.
• Specify relationships between interfaces.
• Declare parameters that alter the component structure or functionality.
If the component is HDL-based, you must define the parameters and signals in the HDL file, and cannot
add or remove them in the Component Editor. If you have not yet created the top-level HDL file, you
declare the parameters and signals in the Component Editor, and they are then included in the HDL
template file that Qsys creates.
In a Qsys system, the interfaces of a component are connected within the system, or exported as top-level
signals from the system.
If you are creating the component using an existing HDL file, the order in which the tabs appear in the
Component Editor reflects the recommended design flow for component development. You can use the
Prev and Next buttons at the bottom of the Component Editor window to guide you through the tabs.
If the component is not based on an existing HDL file, enter the parameters, signals, and interfaces first,
and then return to the Files tab to create the top-level HDL file template. When you click Finish, Qsys
creates the component _hw.tcl file with the details provided on the Component Editor tabs.
After the component is saved, it is available in the IP Catalog.
If you require features in the component that are not supported by the Component Editor, such as
callback procedures, you can use the Component Editor to create the _hw.tcl file, and then manually edit
Creating Qsys Components
Send Feedback
Altera Corporation
6-6
Create IP Components in the Qsys Component Editor
QII5V1
2015.05.04
the file to complete the component definition. Subsequent topics document the _hw.tcl commands that
are generated by the Component Editor, as well as some of the advanced features that you can add with
your own _hw.tcl commands.
Note: By default, custom components do not have registered outputs, even if they are exported out of the
Qsys system. For a custom component, if you want to export the signals, you must add the
registered outputs.
Example 6-1: Qsys Creates an _hw.tcl File from Entries in the Component Editor
#
# connection point clock
#
add_interface clock clock end
set_interface_property clock clockRate 0
set_interface_property clock ENABLED true
add_interface_port clock clk clk Input 1
#
# connection point reset
#
add_interface reset reset end
set_interface_property reset associatedClock clock
set_interface_property reset synchronousEdges DEASSERT
set_interface_property reset ENABLED true
add_interface_port reset reset_n reset_n Input 1
#
# connection point streaming
#
add_interface streaming avalon_streaming start
set_interface_property streaming associatedClock clock
set_interface_property streaming associatedReset reset
set_interface_property streaming dataBitsPerSymbol 8
set_interface_property streaming errorDescriptor ""
set_interface_property streaming firstSymbolInHighOrderBits true
set_interface_property streaming maxChannel 0
set_interface_property streaming readyLatency 0
set_interface_property streaming ENABLED true
add_interface_port streaming aso_data data Output 8
add_interface_port streaming aso_valid valid Output 1
add_interface_port streaming aso_ready ready Input 1
#
# connection point slave
#
add_interface slave axi end
set_interface_property slave
set_interface_property slave
set_interface_property slave
set_interface_property slave
set_interface_property slave
set_interface_property slave
set_interface_property slave
associatedClock clock
associatedReset reset
readAcceptanceCapability 1
writeAcceptanceCapability 1
combinedAcceptanceCapability 1
readDataReorderingDepth 1
ENABLED true
add_interface_port slave axs_awid awid Input AXI_ID_W
...
add_interface_port slave axs_rresp rresp Output 2
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
Save an IP Component and Create the _hw.tcl File
6-7
Related Information
• Component Interface Tcl Reference on page 9-1
Save an IP Component and Create the _hw.tcl File
You save a component by clicking Finish in the Qsys Component Editor. The Component Editor saves
the component as <component_name> _hw.tcl file.
Altera recommends that you save _hw.tcl files and their associated files in an ip/ <class-name> directory
within your Quartus II project directory. You can also create components to use with other applications,
such as the C compiler and a board support package (BSP) generator.
Refer to Creating a System with Qsys for information on how to search for and add components to the IP
Catalog for use in your designs.
Related Information
Publishing Component Information to Embedded Software (Nios II Software Developer’s Handbook)
Creating a System with Qsys on page 5-1
Edit an IP Component with the Qsys Component Editor
In Qsys, you make changes to a component by right-clicking the component in the System Contents tab,
and then clicking Edit. After making changes, click Finish to save the changes to the _hw.tcl file.
You can open an _hw.tcl file in a text editor to view the hardware Tcl for the component. If you edit the
_hw.tcl file to customize the component with advanced features, you cannot use the Component Editor to
make further changes without over-writing your customized file.
You cannot use the Component Editor to edit components installed with the Quartus II software, such as
Altera-provided components. If you edit the HDL for a component and change the interface to the toplevel module, you must edit the component to reflect the changes you make to the HDL.
Related Information
Creating Qsys Components
Specify IP Component Type Information
The Component Type tab in the Qsys Component Editor allows you to specify the following information
about the component:
Creating Qsys Components
Send Feedback
Altera Corporation
6-8
Specify IP Component Type Information
QII5V1
2015.05.04
• Name—Specifies the name used in the _hw.tcl filename, as well as in the top-level module name when
you create a synthesis wrapper file for a non HDL-based component.
• Display name—Identifies the component in the parameter editor, which you use to configure and
instance of the component, and also appears in the IP Catalog under Project and on the System
Contents tab.
• Version—Specifies the version number of the component.
• Group—Represents the category of the component in the list of available components in the IP
Catalog. You can select an existing group from the list, or define a new group by typing a name in the
Group box. Separating entries in the Group box with a slash defines a subcategory. For example, if you
type Memories and Memory Controllers/On-Chip, the component appears in the IP Catalog under
the On-Chip group, which is a subcategory of the Memories and Memory Controllers group. If you
save the component in the project directory, the component appears in the IP Catalog in the group you
specified under Project. Alternatively, if you save the component in the Quartus II installation
directory, the component appears in the specified group under IP Catalog.
• Description—Allows you to describe the component. This description appears when the user views
the component details.
• Created By—Allows you to specify the author of the component.
• Icon—Allows you to enter the relative path to an icon file (.gif, .jpg, or .png format) that represents
the component and appears as the header in the parameter editor for the component. The default
image is the Altera MegaCore function icon.
• Documentation—Allows you to add links to documentation for the component, and appears when
you right-click the component in the IP Catalog, and then select Details.
• To specify an Internet file, begin your path with http://, for example: http://mydomain.com/
datasheets/my_memory_controller.html.
• To specify a file in the file system, begin your path with file:/// for Linux, and file://// for Windows;
for example (Windows): file:////company_server/datasheets my_memory_controller.pdf.
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
Specify IP Component Type Information
6-9
Figure 6-1: Component Type Tab in the Component Editor
The Display name, Group, Description, Created By, Icon, and Documentation entries are optional.
When you use the Component Editor to create a component, it writes this basic component information
in the _hw.tcl file. The example below shows the component hardware Tcl code related to the entries for
the Component Type tab in figure above. The package require command specifies the Quartus II
software version that Qsys uses to create the _hw.tcl file, and ensures compatibility with this version of
the Qsys API in future ACDS releases.
Example 6-2: _hw.tcl Created from Entries in the Component Type Tab
The component defines its basic information with various module properties using the
set_module_property command. For example, set_module_property NAME specifies the name
of the component, while set_module_property VERSION allows you to specify the version of the
component. When you apply a version to the _hw.tcl file, it allows the file to behave exactly the
same way in future releases of the Quartus II software.
# request TCL package from ACDS 14.0
package require -exact qsys 14.0
# demo_axi_memory
Creating Qsys Components
Send Feedback
Altera Corporation
6-10
QII5V1
2015.05.04
Create an HDL File in the Qsys Component Editor
set_module_property DESCRIPTION \
"Demo AXI-3 memory with optional Avalon-ST port"
set_module_property
set_module_property
set_module_property
set_module_property
set_module_property
NAME demo_axi_memory
VERSION 1.0
GROUP "My Components"
AUTHOR Altera
DISPLAY_NAME "Demo AXI Memory"
Related Information
• Component Interface Tcl Reference on page 9-1
Create an HDL File in the Qsys Component Editor
If you do not have an HDL file for your component, you can use the Qsys Component Editor to define the
component signals, interfaces, and parameters of your component, and then create a simple top-level
HDL file.
You can then edit the HDL file to add the logic that describes the component's behavior.
1. In the Qsys Component Editor, specify the information about the component in the Signals &
Interfaces, and Interfaces, and Parameters tabs.
2. Click the Files tab.
3. Click Create Synthesis File from Signals.
The Component Editor creates an HDL file from the specified signals, interfaces, and parameters, and
the .v file appears in the Synthesis File table.
Related Information
Specify Synthesis and Simulation Files in the Qsys Component Editor on page 6-12
Create an HDL File Using a Template in the Qsys Component Editor
You can use a template to create interfaces and signals for your Qsys component
1. In Qsys, click new_component in the IP Catalog.
2. On the Component Type tab, define your component information in the Name, Display Name,
Version, Group, Description, Created by, Icon, and Documentation boxes.
3. Click Finish.
Your new component appears in the IP Catalog under the category that you define for "Group".
4. In Qsys, right-click your new component in the IP Catalog, and then click Edit.
5. In the Qsys Component Editor, click any interface from the Templates drop-down menu.
The Component Editor fills the Signals and Interfaces tabs with the component interface template
details.
6. On the Files tab, click Create Synthesis File from Signals.
7. Do the following in the Create HDL Template dialog box as shown below:
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
Create an HDL File Using a Template in the Qsys Component Editor
6-11
a. Verify that the correct files appears in File path, or browse to the location where you want to save
your file.
b. Select the HDL language.
c. Click Save to save your new interface, or Cancel to discard the new interface definition.
Create HDL Template Dialog Box
8. Verify the <component_name>.v file appears in the Synthesis Files table on the Files tab.
Related Information
Specify Synthesis and Simulation Files in the Qsys Component Editor on page 6-12
Creating Qsys Components
Send Feedback
Altera Corporation
6-12
QII5V1
2015.05.04
Specify Synthesis and Simulation Files in the Qsys Component Editor
Specify Synthesis and Simulation Files in the Qsys Component Editor
The Files tab in the Qsys Component Editor allows you to specify synthesis and simulation files for your
custom component.
If you already an HDL files that describe the behavior and structure of your component, you can specify
those files on the Files tab.
If you do not yet have an HDL file, you can specify the signals, interfaces, and parameters of the
component in the Component Editor, and then use the Create Synthesis File from Signals option on the
Files tab to create the top-level HDL file. The Component Editor generates the _hw.tcl commands to
specify the files.
Note: After you analyze the component's top-level HDL file (on the Files tab), you cannot add or remove
signals or change the signal names on the Signals & Interfaces tab. If you need to edit signals, edit
your HDL source, and then click Create Synthesis File from Signals on the Files tab to integrate
your changes.
A component uses filesets to specify the different sets of files that you can generate for an instance of the
component. The supported fileset types are: QUARTUS_SYNTH, for synthesis and compilation in the Quartus
II software, SIM_VERILOG, for Verilog HDL simulation, and SIM_VHDL, for VHDL simulation.
In an _hw.tcl file, you can add a fileset with the add_fileset command. You can then list specific files
with the add_fileset_file command. The add_fileset_property command allows you to add
properties such as TOP_LEVEL.
You can populate a fileset with a a fixed list of files, add different files based on a parameter value, or even
generate an HDL file with a custom HDL generator function outside of the _hw.tcl file.
Related Information
• Create an HDL File in the Qsys Component Editor on page 6-10
• Create an HDL File Using a Template in the Qsys Component Editor on page 6-10
Specify HDL Files for Synthesis in the Qsys Component Editor
In the Qsys Component Editor, you can add HDL files and other support files with options on the Files
tab.
A component must specify an HDL file as the top-level file. The top-level HDL file contains the top-level
module. The Synthesis Files list may also include supporting HDL files, such as timing constraints, or
other files required to successfully synthesize and compile in the Quartus II software. The synthesis files
for a component are copied to the generation output directory during Qsys system generation.
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
Analyze Synthesis Files in the Qsys Component Editor
6-13
Figure 6-2: Using HDL Files to Define a Component
In the Synthesis Files section on the Files tab in the Qsys Component Editor, the demo_axi_memory.sv
file should be selected as the top-level file for the component.
Analyze Synthesis Files in the Qsys Component Editor
After you specify the top-level HDL file in the Qsys Component Editor, click Analyze Synthesis Files to
analyze the parameters and signals in the top-level, and then select the top-level module from the Top
Level Module list. If there is a single module or entity in the HDL file, Qsys automatically populates the
Top-level Module list.
Once analysis is complete and the top-level module is selected, you can view the parameters and signals
on the Parameters and Signals & Interfaces tabs. The Component Editor may report errors or warnings
at this stage, because the signals and interfaces are not yet fully defined.
Note: At this stage in the Component Editor flow, you cannot add or remove parameters or signals
created from a specified HDL file without editing the HDL file itself.
The synthesis files are added to a fileset with the name QUARTUS_SYNTH and type QUARTUS_SYNTH in the
_hw.tcl file created by the Component Editor. The top-level module is used to specify the TOP_LEVEL
fileset property. Each synthesis file is individually added to the fileset. If the source files are saved in a
different directory from the working directory where the _hw.tcl is located, you can use standard fixed or
relative path notation to identify the file location for the PATH variable.
Example 6-3: _hw.tcl Created from Entries in the Files tab in the Synthesis Files Section
# file sets
add_fileset QUARTUS_SYNTH QUARTUS_SYNTH "" ""
set_fileset_property QUARTUS_SYNTH TOP_LEVEL demo_axi_memory
add_fileset_file demo_axi_memory.sv
SYSTEM_VERILOG PATH demo_axi_memory.sv
Creating Qsys Components
Send Feedback
Altera Corporation
6-14
QII5V1
2015.05.04
Name HDL Signals for Automatic Interface and Type Recognition in the Qsys
Component Editor
add_fileset_file single_clk_ram.v VERILOG PATH single_clk_ram.v
Related Information
Specify HDL Files for Synthesis in the Qsys Component Editor on page 6-12
Component Interface Tcl Reference on page 9-1
Name HDL Signals for Automatic Interface and Type Recognition in the Qsys
Component Editor
If you create the component's top-level HDL file before using the Component Editor, the Component
Editor recognizes the interface and signal types based on the signal names in the source HDL file. This
auto-recognition feature eliminates the task of manually assigning each interface and signal type in the
Component Editor.
To enable auto-recognition, you must create signal names using the following naming convention:
<interface type prefix>_<interface name>_<signal type>
Specifying an interface name with <interface name> is optional if you have only one interface of each type
in the component definition. For interfaces with only one signal, such as clock and reset inputs, the
<interface type prefix> is also optional.
Table 6-2: Interface Type Prefixes for Automatic Signal Recognition
When the Component Editor recognizes a valid prefix and signal type for a signal, it automatically assigns an
interface and signal type to the signal based on the naming convention. If no interface name is specified for a
signal, you can choose an interface name on the Signals & Interfaces tab in the Component Editor.
Interface Prefix
Interface Type
asi
Avalon-ST sink (input)
aso
Avalon-ST source (output)
avm
Avalon-MM master
avs
Avalon-MM slave
axm
AXI master
axs
AXI slave
apm
APB master
aps
APB slave
coe
Conduit
csi
Clock Sink (input)
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
Specify Files for Simulation in the Component Editor
Interface Prefix
6-15
Interface Type
cso
Clock Source (output)
inr
Interrupt receiver
ins
Interrupt sender
ncm
Nios II custom instruction master
ncs
Nios II custom instruction slave
rsi
Reset sink (input)
rso
Reset source (output)
tcm
Avalon-TC master
tcs
Avalon-TC slave
Refer to the Avalon Interface Specifications or the AMBA Protocol Specification for the signal types
available for each interface type.
Related Information
• Avalon Interface Specifications
• AMBA Protocol Specification
Specify Files for Simulation in the Component Editor
To support Qsys system generation for your custom component, you must specify VHDL or Verilog
simulation files.
You can choose to generate Verilog or VHDL simulation files. In most cases, these files are the same as
the synthesis files. If there are simulation-specific HDL files or simulation models, you can use them in
addition to, or in place of the synthesis files. To use your synthesis files as your simulation files, click Copy
From Synthesis Files on the Files tab in the Qsys Component Editor.
Note: The order that you add files to the fileset determines the order of compilation. For VHDL filesets
with VHDL files, you must add the files bottom-up, adding the top-level file last.
Creating Qsys Components
Send Feedback
Altera Corporation
6-16
QII5V1
2015.05.04
Specify Files for Simulation in the Component Editor
Figure 6-3: Specifying the Simulation Output Files on the Files Tab
You specify the simulation files in a similar way as the synthesis files with the fileset commands in a
_hw.tcl file. The code example below shows SIM_VERILOG and SIM_VHDL filesets for Verilog and VHDL
simulation output files. In this example, the same Verilog files are used for both Verilog and VHDL
outputs, and there is one additional System Verilog file added. This method works for designers of
Verilog IP to support users who want to generate a VHDL top-level simulation file when they have a
mixed-language simulation tool and license that can read the Verilog output for the component.
Example 6-4: _hw.tcl Created from Entries in the Files tab in the Simulation Files Section
add_fileset SIM_VERILOG SIM_VERILOG "" ""
set_fileset_property SIM_VERILOG TOP_LEVEL demo_axi_memory
add_fileset_file single_clk_ram.v VERILOG PATH single_clk_ram.v
add_fileset_file verbosity_pkg.sv SYSTEM_VERILOG PATH \
verification_lib/verbosity_pkg.sv
add_fileset_file demo_axi_memory.sv SYSTEM_VERILOG PATH \
demo_axi_memory.sv
add_fileset SIM_VHDL SIM_VHDL "" ""
set_fileset_property SIM_VHDL TOP_LEVEL demo_axi_memory
set_fileset_property SIM_VHDL ENABLE_RELATIVE_INCLUDE_PATHS false
add_fileset_file demo_axi_memory.sv SYSTEM_VERILOG PATH \
demo_axi_memory.sv
add_fileset_file single_clk_ram.v VERILOG PATH single_clk_ram.v
add_fileset_file verbosity_pkg.sv SYSTEM_VERILOG PATH \
verification_lib/verbosity_pkg.sv
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
Related Information
Include an Internal Register Map Description in the .svd for Slave Interfaces
Connected to an HPS Component
6-17
• Component Interface Tcl Reference on page 9-1
Include an Internal Register Map Description in the .svd for Slave Interfaces
Connected to an HPS Component
Qsys supports the ability for IP component designers to specify register map information on their slave
interfaces. This allows components with slave interfaces that are connected to an HPS component to
include their internal register description in the generated .svd file.
To specify their internal register map, the IP component designer must write and generate their own .svd
file and attach it to the slave interface using the following command:
set_interface_property <slave interface> CMSIS_SVD_FILE <file path>
The CMSIS_SVD_VARIABLES interface property allows for variable substitution inside the .svd file. You can
dynamically modify the character data of the .svd file by using the CMSIS_SVD_VARIABLES property.
Example 6-5: Setting the CMSIS_SVD_VARIBLES Interface Property
For example, if you set the CMSIS_SVD_VARIABLES in the _hw tcl file, then in the .svd file if there
is a variable {width} that describes the element <size>${width}</size>, it is replaced by
<size>23</size> during generation of the .svd file. Note that substitution works only within
character data (the data enclosed by <element>...</element>) and not on element attributes.
set_interface_property <interface name> \
CMSIS_SVD_VARIABLES "{width} {23}"
Related Information
Component Interface Tcl Reference on page 9-1
CMSIS - Cortex Microcontroller Software
Specify Interfaces and Signals in the Qsys Component Editor
The Signals & Interfaces tab allows you to add signals and interfaces to your component.
You can configure the type and properties of signals and interfaces. Some interfaces display waveforms
that illustrate the timing of the interface. If you update the timing parameters, the waveforms automati‐
cally update.
1. In Qsys, click new_component in the IP Catalog.
2. In the Qsys Component Editor, click the Signals & Interfaces tab.
3. To create an interface using a template, click any template in the Templates drop-down menu, and
then perform the following steps:
a. Click each bold interface to edit its properties in the right pane.
b. For each interface, click the its associated signals to edit their properties in the right pane.
The signals for an interface appear as indented elements below the interface.
Creating Qsys Components
Send Feedback
Altera Corporation
6-18
Specify Parameters in the Qsys Component Editor
QII5V1
2015.05.04
Signals & Interfaces tab - Templates
4. To create a custom interface and its associated signals, in the Signals & Interfaces tab, perform the
following steps:
a. Click <add interface>, and then click inside the left pane.
b. To create an associated signal for the new interface, click <add signal> under the new interface, and
then click inside the left pane.
c. Click each bold interface to edit its properties in the right pane.
d. For each interface, click its associated signals to edit their properties in the right pane.
5. To move signals between interfaces, select the signal, and then drag it to another interface.
6. To rename an interface or signal, select the element, and then press F2.
7. To remove an interface or signal, right-click the element, and then click Remove.
Alternatively, to remove an interface or signal, you can select the element, and then press Delete.
When you remove an interface, Qsys also removes all of it associated signals.
Specify Parameters in the Qsys Component Editor
Components can include parameterized HDL, which allow users of the component flexibility in meeting
their system requirements. For example, a component may have a configurable memory size or data
width, where one HDL implementation can be used in different systems, each with unique parameters
values.
The Parameters tab allows you specify the parameters that are used to configure instances of the
component in a Qsys system. You can specify various properties for each parameter that describe how to
display and use the parameter. You can also specify a range of allowed values that are checked during the
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
Specify Parameters in the Qsys Component Editor
6-19
validation phase. The Parameters table displays the HDL parameters that are declared in the top-level
HDL module. If you have not yet created the top-level HDL file, the parameters that you create on the
Parameters tab are included in the top-level synthesis file template created from the Files tab.
When the component includes HDL files, the parameters match those defined in the top-level module,
and you cannot be add or remove them on the Parameters tab. To add or remove the parameters, edit
your HDL source, and then re-analyze the file.
If you used the Component Editor to create a top-level template HDL file for synthesis, you can remove
the newly-created file from the Synthesis Files list on the Files tab, make your parameter changes, and
then re-analyze the top-level synthesis file.
You can use the Parameters table to specify the following information about each parameter:
Name—Specifies the name of the parameter.
Default Value—Sets the default value used in new instances of the component.
Editable—Specifies whether or not the user can edit the parameter value.
Type—Defines the parameter type as string, integer, boolean, std_logic, logic vector, natural, or
positive.
• Group—Allows you to group parameters in parameter editor.
• Tooltip—Allows you to add a description of the parameter that appears when the user of the
component points to the parameter in the parameter editor.
•
•
•
•
Creating Qsys Components
Send Feedback
Altera Corporation
6-20
QII5V1
2015.05.04
Specify Parameters in the Qsys Component Editor
Figure 6-4: Parameters Tab in the Qsys Components Editor
On the Parameters tab, you can click Preview the GUI at any time to see how the declared parameters
appear in the parameter editor. Parameters with their default values appear with checks in the Editable
column, indicating that users of this component are allowed to modify the parameter value. Editable
parameters cannot contain computed expressions. You can group parameters under a common heading
or section in the parameter editor with the Group column, and a tooltip helps users of the component
understand the function of the parameter. Various parameter properties allow you to customize the
component’s parameter editor, such as using radio buttons for parameter selections, or displaying an
image.
Example 6-6: _hw.tcl Created from Entries in the Parameters Tab
In this example, the first add_parameter command includes commonly-specified properties. The
set_parameter_property command specifies each property individually. The Tooltip column
on the Parameters tab maps to the DESCRIPTION property, and there is an additional unused
UNITS property created in the code. The HDL_PARAMETER property specifies that the value of the
parameter is specified in the HDL instance wrapper when creating instances of the component.
The Group column in the Parameters tab maps to the display items section with the
add_display_item commands.
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
Valid Ranges for Parameters in the _hw.tcl File
6-21
Note: If a parameter <n> defines the width of a signal, the signal width must follow the
format: <n-1>:0.
#
# parameters
#
add_parameter AXI_ID_W INTEGER 4 "Width of ID fields"
set_parameter_property AXI_ID_W DEFAULT_VALUE 4
set_parameter_property AXI_ID_W DISPLAY_NAME AXI_ID_W
set_parameter_property AXI_ID_W TYPE INTEGER
set_parameter_property AXI_ID_W UNITS None
set_parameter_property AXI_ID_W DESCRIPTION "Width of ID fields"
set_parameter_property AXI_ID_W HDL_PARAMETER true
add_parameter AXI_ADDRESS_W INTEGER 12
set_parameter_property AXI_ADDRESS_W DEFAULT_VALUE 12
add_parameter AXI_DATA_W INTEGER 32
...
#
# display items
#
add_display_item "AXI Port Widths" AXI_ID_W PARAMETER ""
Note: If an AXI slave's ID bit width is smaller than required for your system, the AXI slave response may
not reach all AXI masters. The formula of an AXI slave ID bit width is calculated as follows:
maximum_master_id_width_in_the_interconnect + log2
(number_of_masters_in_the_same_interconnect)
For example, if an AXI slave connects to three AXI masters and the maximum AXI master ID
length of the three masters is 5 bits, then the AXI slave ID is 7 bits, and is calculated as follows:
5 bits + 2 bits (log2(3 masters)) = 7
Table 6-3: AXI Master and Slave Parameters
Qsys refers to AXI interface parameters to build AXI interconnect. If these parameter settings are incompatible
with the component's HDL behavior, Qsys interconnect and transactions may not work correctly. To prevent
unexpected interconnect behavior, you must set the AXI component parameters.
AXI Master Parameters
AXI Slave Parameters
readIssuingCapability
readAcceptanceCapability
writeIssuingCapability
writeAcceptanceCapability
combinedIssuingCapability
combinedAcceptanceCapability
readDataReorderingDepth
Related Information
• Component Interface Tcl Reference on page 9-1
Valid Ranges for Parameters in the _hw.tcl File
In the _hw.tcl file, you can specify valid ranges for parameters.
Creating Qsys Components
Send Feedback
Altera Corporation
6-22
QII5V1
2015.05.04
Types of Qsys Parameters
Qsys validation checks each parameter value against the ALLOWED_RANGES property. If the values specified
are outside of the allowed ranges, Qsys displays an error message. Specifying choices for the allowed
values enables users of the component to choose the parameter value from a drop-down list or radio
button in the parameter editor GUI instead of entering a value.
The ALLOWED_RANGES property is a list of valid ranges, where each range is a single value, or a range of
values defined by a start and end value.
Table 6-4: ALLOWED_RANGES Property
ALLOWED_RANGES Property
Values
{a b c}
a, b, or c
{"No Control" "Single Control"
"Dual Controls"}
Unique string values. Quotation marks are required if the
strings include spaces .
{1 2 4 8 16}
1, 2, 4, 8, or 16
{1:3}
1 through 3, inclusive.
{1 2 3 7:10}
1, 2, 3, or 7 through 10 inclusive.
Related Information
Declare Parameters with Custom _hw.tcl Commands on page 6-23
Types of Qsys Parameters
Qsys uses the following parameter types: user parameters, system information parameters, and derived
parameters.
Qsys User Parameters on page 6-22
Qsys System Information Parameters on page 6-22
Qsys Derived Parameters on page 6-23
Related Information
Declare Parameters with Custom _hw.tcl Commands on page 6-23
Qsys User Parameters
User parameters are parameters that users of a component can control, and appear in the parameter
editor for instances of the component. User parameters map directly to parameters in the component
HDL. For user parameter code examples, such as AXI_DATA_W and ENABLE_STREAM_OUTPUT, refer to
Declaring Parameters with Custom hw.tcl Commands.
Qsys System Information Parameters
A SYSTEM_INFO parameter is a parameter whose value is set automatically by the Qsys system. When you
define a SYSTEM_INFO parameter, you provide an information type, and additional arguments.
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
Qsys Derived Parameters
6-23
For example, you can configure a parameter to store the clock frequency driving a clock input for your
component. To do this, define the parameter as SYSTEM_INFO of type CLOCK_RATE:
set_parameter_property <param> SYSTEM_INFO CLOCK_RATE
You then set the name of the clock interface as the SYSTEM_INFO argument:
set_parameter_property <param> SYSTEM_INFO_ARG <clkname>
Qsys Derived Parameters
Derived parameter values are calculated from other parameters during the Elaboration phase, and are
specified in the hw.tcl file with the DERIVED property. Derived parameter values are calculated from other
parameters during the Elaboration phase, and are specified in the hw.tcl file with the DERIVED property.
For example, you can derive a clock period parameter from a data rate parameter. Derived parameters are
sometimes used to perform operations that are difficult to perform in HDL, such as using logarithmic
functions to determine the number of address bits that a component requires.
Related Information
Declare Parameters with Custom _hw.tcl Commands on page 6-23
Parameterized Parameter Widths
Qsys allows a std_logic_vector parameter to have a width that is defined by another parameter, similar
to derived parameters. The width can be a constant or the name of another parameter.
Declare Parameters with Custom _hw.tcl Commands
The example below illustrates a custom _hw.tcl file, with more advanced parameter commands than those
generated when you specify parameters in the Component Editor. Commands include the
ALLOWED_RANGES property to provide a range of values for the AXI_ADDRESS_W (Address Width)
parameter, and a list of parameter values for the AXI_DATA_W (Data Width) parameter. This example also
shows the parameter AXI_NUMBYTES (Data width in bytes) parameter; that uses the DERIVED property. In
addition, these commands illustrate the use of the GROUP property, which groups some parameters under a
heading in the parameter editor GUI. You use the ENABLE_STREAM_OUTPUT_GROUP (Include Avalon
streaming source port) parameter to enable or disable the optional Avalon-ST interface in this design,
and is displayed as a check box in the parameter editor GUI because the parameter is of type BOOLEAN.
Refer to figure below to see the parameter editor GUI resulting from these hw.tcl commands.
Example 6-7: Parameter Declaration
In this example, the AXI_NUMBYTES parameter is derived during the Elaboration phase based on
another parameter, instead of being assigned to a specific value. AXI_NUMBYTES describes the
number of bytes in a word of data. Qsys calculates the AXI_NUMBYTES parameter from the
DATA_WIDTH parameter by dividing by 8. The _hw.tcl code defines the AXI_NUMBYTES parameter
as a derived parameter, since its value is calculated in an elaboration callback procedure. The
AXI_NUMBYTES parameter value is not editable, because its value is based on another parameter
value.
add_parameter AXI_ADDRESS_W INTEGER 12
set_parameter_property AXI_ADDRESS_W DISPLAY_NAME \
"AXI Slave Address Width"
set_parameter_property AXI_ADDRESS_W DESCRIPTION \
Creating Qsys Components
Send Feedback
Altera Corporation
6-24
Declare Parameters with Custom _hw.tcl Commands
QII5V1
2015.05.04
"Address width."
set_parameter_property AXI_ADDRESS_W UNITS bits
set_parameter_property AXI_ADDRESS_W ALLOWED_RANGES 4:16
set_parameter_property AXI_ADDRESS_W HDL_PARAMETER true
set_parameter_property AXI_ADDRESS_W GROUP \
"AXI Port Widths"
add_parameter AXI_DATA_W INTEGER 32
set_parameter_property AXI_DATA_W DISPLAY_NAME "Data Width"
set_parameter_property AXI_DATA_W DESCRIPTION \
"Width of data buses."
set_parameter_property AXI_DATA_W UNITS bits
set_parameter_property AXI_DATA_W ALLOWED_RANGES \
{8 16 32 64 128 256 512 1024}
set_parameter_property AXI_DATA_W HDL_PARAMETER true
set_parameter_property AXI_DATA_W GROUP "AXI Port Widths"
add_parameter AXI_NUMBYTES INTEGER 4
set_parameter_property AXI_NUMBYTES DERIVED true
set_parameter_property AXI_NUMBYTES DISPLAY_NAME \
"Data Width in bytes; Data Width/8"
set_parameter_property AXI_NUMBYTES DESCRIPTION \
"Number of bytes in one word"
set_parameter_property AXI_NUMBYTES UNITS bytes
set_parameter_property AXI_NUMBYTES HDL_PARAMETER true
set_parameter_property AXI_NUMBYTES GROUP "AXI Port Widths"
add_parameter ENABLE_STREAM_OUTPUT BOOLEAN true
set_parameter_property ENABLE_STREAM_OUTPUT DISPLAY_NAME \
"Include Avalon Streaming Source Port"
set_parameter_property ENABLE_STREAM_OUTPUT DESCRIPTION \
"Include optional Avalon-ST source (default),\
or hide the interface"
set_parameter_property ENABLE_STREAM_OUTPUT GROUP \
"Streaming Port Control"
...
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
Validate Parameter Values with a Validation Callback
6-25
Figure 6-5: Resulting Parameter Editor GUI from Parameter Declarations
Related Information
Control Interfaces Dynamically with an Elaboration Callback on page 6-26
Component Interface Tcl Reference on page 9-1
Validate Parameter Values with a Validation Callback
You can use a validation callback procedure to validate parameter values with more complex validation
operations than the ALLOWED_RANGES property allows. You define a validation callback by setting the
VALIDATION_CALLBACK module property to the name of the Tcl callback procedure that runs during the
validation phase. In the validation callback procedure, the current parameter values is queried, and
warnings or errors are reported about the component's configuration.
Example 6-8: Demo AXI Memory Example
If the optional Avalon streaming interface is enabled, then the control registers must be wide
enough to hold an AXI RAM address, so the designer can add an error message to ensure that the
user enters allowable parameter values.
set_module_property VALIDATION_CALLBACK validate
proc validate {} {
if {
[get_parameter_value ENABLE_STREAM_OUTPUT ] &&
([get_parameter_value AXI_ADDRESS_W] >
[get_parameter_value AV_DATA_W])
}
send_message error "If the optional Avalon streaming port\
is enabled, the AXI Data Width must be equal to or greater\
than the Avalon control port Address Width"
}
}
Related Information
Component Interface Tcl Reference on page 9-1
Demo AXI Memory Example
Creating Qsys Components
Send Feedback
Altera Corporation
6-26
QII5V1
2015.05.04
Control Interfaces Dynamically with an Elaboration Callback
Control Interfaces Dynamically with an Elaboration Callback
You can allow user parameters to dynamically control your component's behavior with a an elaboration
callback procedure during the elaboration phase. Using an elaboration callback allows you to change
interface properties, remove interfaces, or add new interfaces as a function of a parameter value. You
define an elaboration callback by setting the module property ELABORATION_CALLBACK to the name of the
Tcl callback procedure that runs during the elaboration phase. In the callback procedure, you can query
the parameter values of the component instance, and then change the interfaces accordingly.
Example 6-9: Avalon-ST Source Interface Optionally Included in a Component Specified with an
Elaboration Callback
set_module_property ELABORATION_CALLBACK elaborate
proc elaborate {} {
# Optionally disable the Avalon- ST data output
if{[ get_parameter_value ENABLE_STREAM_OUTPUT] == "false" }{
set_port_property aso_data
termination true
set_port_property aso_valid
termination true
set_port_property aso_ready
termination true
set_port_property aso_ready
termination_value 0
}
# Calculate the Data Bus Width in bytes
set bytewidth_var [expr [get_parameter_value AXI_DATA_W]/8]
set_parameter_value AXI_NUMBYTES $bytewidth_var
}
Related Information
• Creating Custom _hw.tcl Interface Settings and Properties
• Validate Parameter Values with a Validation Callback on page 6-25
• Component Interface Tcl Reference on page 9-1
Control File Generation Dynamically with Parameters and a Fileset
Callback
You can use a fileset callback to control which files are created in the output directories during the
generation phase based on parameter values, instead of providing a fixed list of files. In a callback
procedure, you can query the values of the parameters and use them to generate the appropriate files. To
define a fileset callback, you specify a callback procedure name as an argument in the add_fileset
command. You can use the same fileset callback procedure for all of the filesets, or create separate
procedures for synthesis and simulation, or Verilog and VHDL.
Example 6-10: Fileset Callback Using Parameters to Control Filesets in Two Different Ways
The RAM_VERSION parameter chooses between two different source files to control the implemen‐
tation of a RAM block. For the top-level source file, a custom Tcl routine generates HDL that
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
Control File Generation Dynamically with Parameters and a Fileset Callback
6-27
optionally includes control and status registers, depending on the value of the CSR_ENABLED
parameter.
During the generation phase, Qsys creates a a top-level Qsys system HDL wrapper module to
instantiate the component top-level module, and applies the component's parameters, for any
parameter whose parameter property HDL_PARAMETER is set to true.
#Create synthesis fileset with fileset_callback and set top level
add_fileset my_synthesis_fileset QUARTUS_SYNTH fileset_callback
set_fileset_property my_synthesis_fileset TOP_LEVEL \
demo_axi_memory
# Create Verilog simulation fileset with same fileset_callback
# and set top level
add_fileset my_verilog_sim_fileset SIM_VERILOG fileset_callback
set_fileset_property my_verilog_sim_fileset TOP_LEVEL \
demo_axi_memory
# Add extra file needed for simulation only
add_fileset_file verbosity_pkg.sv SYSTEM_VERILOG PATH \
verification_lib/verbosity_pkg.sv
# Create VHDL simulation fileset (with Verilog files
# for mixed-language VHDL simulation)
add_fileset my_vhdl_sim_fileset SIM_VHDL fileset_callback
set_fileset_property my_vhdl_sim_fileset TOP_LEVEL demo_axi_memory
add_fileset_file verbosity_pkg.sv SYSTEM_VERILOG PATH
verification_lib/verbosity_pkg.sv
# Define parameters required for fileset_callback
add_parameter RAM_VERSION INTEGER 1
set_parameter_property RAM_VERSION ALLOWED_RANGES {1 2}
set_parameter_property RAM_VERSION HDL_PARAMETER false
add_parameter CSR_ENABLED BOOLEAN enable
set_parameter_property CSR_ENABLED HDL_PARAMETER false
# Create Tcl callback procedure to add appropriate files to
# filesets based on parameters
proc fileset_callback { entityName } {
send_message INFO "Generating top-level entity $entityName"
set ram [get_parameter_value RAM_VERSION]
set csr_enabled [get_parameter_value CSR_ENABLED]
send_message INFO "Generating memory
implementation based on RAM_VERSION $ram
"
if {$ram == 1} {
add_fileset_file single_clk_ram1.v VERILOG PATH \
single_clk_ram1.v
} else
{
add_fileset_file single_clk_ram2.v VERILOG PATH \
single_clk_ram2.v
}
send_message INFO "Generating top-level file for \
CSR_ENABLED $csr_enabled"
Creating Qsys Components
Send Feedback
Altera Corporation
6-28
QII5V1
2015.05.04
Create a Composed Component or Subsystem
generate_my_custom_hdl $csr_enabled demo_axi_memory_gen.sv
add_fileset_file demo_axi_memory_gen.sv VERILOG PATH \
demo_axi_memory_gen.sv
}
Related Information
Specify Synthesis and Simulation Files in the Qsys Component Editor on page 6-12
Component Interface Tcl Reference on page 9-1
Create a Composed Component or Subsystem
A composed component is a subsystem containing instances of other components. Unlike an HDL-based
component, a composed component's HDL is created by generating HDL for the components in the
subsystem, in addition to the Qsys interconnect to connect the subsystem instances.
You can add child instances in a composition callback of the _hw.tcl file.
With a composition callback, you can also instantiate and parameterize sub-components as a function of
the composed component’s parameter values. You define a composition callback by setting the COMPOSITION_CALLBACK module property to the name of the composition callback procedures.
A composition callback replaces the validation and elaboration phases. HDL for the subsystem is
generated by generating all of the sub-components and the top-level that combines them.
To connect instances of your component, you must define the component's interfaces. Unlike an HDLbased component, a composed component does not directly specify the signals that are exported. Instead,
interfaces of submodules are chosen as the external interface, and each internal interface's ports are
connected through the exported interface.
Exporting an interface means that you are making the interface visible from the outside of your
component, instead of connecting it internally. You can set the EXPORT_OF property of the externally
visible interface from the main program or the composition callback, to indicate that it is an exported
view of the submodule's interface.
Exporting an interface is different than defining an interface. An exported interface is an exact copy of the
subcomponent’s interface, and you are not allowed to change properties on the exported interface. For
example, if the internal interface is a 32-bit or 64-bit master without bursting, then the exported interface
is the same. An interface on a subcomponent cannot be exported and also connected within the
subsystem.
When you create an exported interface, the properties of the exported interface are copied from the
subcomponent’s interface without modification. Ports are copied from the subcomponent’s interface with
only one modification; the names of the exported ports on the composed component are chosen to ensure
that they are unique.
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
6-29
Create a Composed Component or Subsystem
Figure 6-6: Top-Level of a Composed Component
my_component
reset
altera
reset
bridge
altera
clock
bridge
clk
slave
my_regs_microcore
my_phy_microcore
pins
Example 6-11: Composed _hw.tcl File that Instantiates Two Sub-Components
Qsys connects the components, and also connects the clocks and resets. Note that clock and reset
bridge components are required to allow both sub-components to see common clock and reset
inputs.
package require -exact qsys 14.0
set_module_property name my_component
set_module_property COMPOSITION_CALLBACK composed_component
proc composed_component {} {
add_instance clk altera_clock_bridge
add_instance reset altera_reset_bridge
add_instance regs my_regs_microcore
add_instance phy my_phy_microcore
add_interface
add_interface
add_interface
add_interface
clk clock end
reset reset end
slave avalon slave
pins conduit end
set_interface_property clk EXPORT_OF clk.in_clk
set_instance_property_value reset synchronous_edges deassert
set_interface_property reset EXPORT_OF reset.in_reset
set_interface_property slave EXPORT_OF regs.slave
set_interface_property pins EXPORT_OF phy.pins
Creating Qsys Components
Send Feedback
Altera Corporation
6-30
QII5V1
2015.05.04
Create an IP Component with Qsys a System View Different from the Generated
Synthesis Output Files
add_connection clk.out_clk reset.clk
add_connection clk.out_clk regs.clk
add_connection clk.out_clk phy.clk
add_connection reset.out_reset regs.reset
add_connection reset.out_reset phy.clk_reset
add_connection regs.output phy.input
add_connection phy.output regs.input
}
Related Information
• Component Interface Tcl Reference on page 9-1
Create an IP Component with Qsys a System View Different from the
Generated Synthesis Output Files
There are cases where it may be beneficial to have the structural Qsys system view of a component differ
from the generated synthesis output files. The structural composition callback allows you to define a
structural hierarchy for a component separately from the generated output files.
One application of this feature is for IP designers who want to send out a placed-and-routed component
that represents a Qsys system in order to ensure timing closure for the end-user. In this case, the designer
creates a design partition for the Qsys system, and then exports a post-fit Quartus II Exported Partition
File (.qxp) when satisfied with the placement and routing results.
The designer specifies a .qxp file as the generated synthesis output file for the new component. The
designer can specify whether to use a simulation output fileset for the custom simulation model file, or to
use simulation output files generated from the original Qsys system.
When the end-user adds this component to their Qsys system, the designer wants the end-user to see a
structural representation of the component, including lower-level components and the address map of the
original Qsys system. This structural view is a logical representation of the component that is used during
the elaboration and validation phases in Qsys.
Example 6-12: Structural Composition Callback and .qxp File as the Generated Output
To specify a structural representation of the component for Qsys, connect components or
generate a hardware Tcl description of the Qsys system, and then insert the Tcl commands into a
structural composition callback. To invoke the structural composition callback use the command:
set_module_property STRUCTURAL_COMPOSITION_CALLBACK structural_hierarchy
package require -exact qsys 14.0
set_module_property name example_structural_composition
set_module_property STRUCTURAL_COMPOSITION_CALLBACK \
structural_hierarchy
add_fileset synthesis_fileset QUARTUS_SYNTH \
synth_callback_procedure
add_fileset simulation_fileset SIM_VERILOG \
sim_callback_procedure
set_fileset_property synthesis_fileset TOP_LEVEL \
my_custom_component
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
Add Component Instances to a Static or Generated Component
6-31
set_fileset_property simulation_fileset TOP_LEVEL \
my_custom_component
proc structural_hierarchy {} {
# called during elaboration and validation phase
# exported ports should be same in structural_hierarchy
# and generated QXP
# These commands could come from the exported hardware Tcl
add_interface clk clock sink
add_interface reset reset sink
add_instance clk_0 clock_source
set_interface_property clk EXPORT_OF clk_0.clk_in
set_interface_property reset EXPORT_OF clk_0.clk_in_reset
add_instance pll_0 altera_pll
# connections and connection parameters
add_connection clk_0.clk pll_0.refclk clock
add_connection clk_0.clk_reset pll_0.reset reset
}
proc synth_callback_procedure { entity_name } {
# the QXP should have the same name for ports
# as exportedin structural_hierarchy
add_fileset_file my_custom_component.qxp QXP PATH \
"my_custom_component.qxp"
}
proc sim_callback_procedure { entity_name } {
# the simulation files should have the same name for ports as
# exported in structural_hierarchy
add_fileset_file my_custom_component.v VERILOG PATH \
"my_custom_component.v"
….
….
}
Related Information
Create a Composed Component or Subsystem on page 6-28
Add Component Instances to a Static or Generated Component
You can create nested components by adding component instances to an existing component. Both static
and generated components can create instances of other components. You can add child instances of a
component in a _hw.tcl using elaboration callback.
With an elaboration callback, you can also instantiate and parameterize sub-components with the
add_hdl_instance command as a function of the parent component's parameter values.
When you instantiate multiple nested components, you must create a unique variation name for each
component with the add_hdl_instance command. Prefixing a variation name with the parent
Creating Qsys Components
Send Feedback
Altera Corporation
6-32
QII5V1
2015.05.04
Static Components
component name prevents conflicts in a system. The variation name can be the same across multiple
parent components if the generated parameterization of the nested component is exactly the same.
Note: If you do not adhere to the above naming variation guidelines, Qsys validation-time errors occur,
which are often difficult to debug.
Related Information
• Static Components on page 6-32
• Generated Components on page 6-33
Static Components
Static components always generate the same output, regardless of their parameterization. Components
that instantiate static components must have only static children.
A design file that is static between all parameterizations of a component can only instantiate other static
design files. Since static IPs always render the same HDL regardless of parameterization, Qsys generates
static IPs only once across multiple instantiations, meaning they have the same top-level name set.
Example 6-13: Typical Usage of the add_hdl_instance Command for Static Components
package require -exact qsys 14.0
set_module_property name add_hdl_instance_example
add_fileset synth_fileset QUARTUS_SYNTH synth_callback
set_fileset_property synth_fileset TOP_LEVEL basic_static
set_module_property elaboration_callback elab
proc elab {} {
# Actual API to instantiate an IP Core
add_hdl_instance emif_instance_name altera_mem_if_ddr3_emif
# Make sure the parameters are set appropriately
set_instance_parameter_value emif_instance_name SPEED_GRADE {7}
...
}
proc synth_callback { output_name } {
add_fileset_file "basic_static.v" VERILOG PATH basic_static.v
}
Example 6-14: Top-Level HDL Instance and Wrapper File Created by Qsys
In this example, Qsys generates a wrapper file for the instance name specified in the _hw.tcl file.
//Top Level Component HDL
module basic_static (input_wire, output_wire, inout_wire);
input [31:0] input_wire;
output [31:0] output_wire;
inout [31:0] inout_wire;
//
//
//
//
Instantiation of the instance added via add_hdl_instance
command. This is an example of how the instance added via
the add_hdl_instance command can be used
in the top-level file of the component.
emif_instance_name fixed_name_instantiation_in_top_level(
.pll_ref_clk (input_wire), // pll_ref_clk.clk
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
Generated Components
6-33
.global_reset_n (input_wire), // global_reset.reset_n
.soft_reset_n (input_wire), // soft_reset.reset_n
...
... );
endmodule
//Wrapper for added HDL instance
// emif_instance_name.v
// Generated using ACDS version 14.0
`timescale 1 ps / 1 ps
module emif_instance_name (
input wire pll_ref_clk, // pll_ref_clk.clk
input wire global_reset_n, // global_reset.reset_n
input wire soft_reset_n, // soft_reset.reset_n
output wire afi_clk, // afi_clk.clk
...
...);
example_addhdlinstance_system
_add_hdl_instance_example_0_emif_instance
_name_emif_instance_name emif_instance_name (
.pll_ref_clk (pll_ref_clk), // pll_ref_clk.clk
.global_reset_n (global_reset_n), // global_reset.reset_n
.soft_reset_n (soft_reset_n), // soft_reset.reset_n
...
...);
endmodule
Generated Components
A generated component's fileset callback allows an instance of the component to create unique HDL
design files based on the instance's parameter values. For example, you can write a fileset callback to
include a control and status interface based on the value of a parameter. The callback overcomes a
limitation of HDL languages, which do not allow run-time parameters.
Generated components change their generation output (HDL) based on their parameterization. If a
component is generated, then any component that may instantiate it with multiple parameter sets must
also be considered generated, since its HDL changes with its parameterization. This case has an effect that
propagates up to the top-level of a design.
Since generated components are generated for each unique parameterized instantiation, when
implementing the add_hdl_instance command, you cannot use the same fixed name (specified using
instance_name) for the different variants of the child HDL instances. To facilitate unique naming for the
wrapper of each unique parameterized instantiation of child HDL instances, you must use the following
command so that Qsys generates a unique name for each wrapper. You can then access this unique
wrapper name with a fileset callback so that the instances are instantiated inside the component's top-level
HDL.
Creating Qsys Components
Send Feedback
Altera Corporation
6-34
QII5V1
2015.05.04
Generated Components
• To declare auto-generated fixed names for wrappers, use the command:
set_instance_property instance_name HDLINSTANCE_USE_GENERATED_NAME \
true
Note: You can only use this command with a generated component in the global context, or in an
elaboration callback.
• To obtain auto-generated fixed name with a fileset callback, use the command:
get_instance_property instance_name HDLINSTANCE_GET_GENERATED_NAME
Note: You can only use this command with a fileset callback. This command returns the value of the
auto-generated fixed name, which you can then use to instantiate inside the top-level HDL.
Example 6-15: Typical Usage of the add_hdl_instance Command for Generated Components
Qsys generates a wrapper file for the instance name specified in the _hw.tcl file.
package require -exact qsys 14.0
set_module_property name generated_toplevel_component
set_module_property ELABORATION_CALLBACK elaborate
add_fileset QUARTUS_SYNTH QUARTUS_SYNTH generate
add_fileset SIM_VERILOG SIM_VERILOG generate
add_fileset SIM_VHDL SIM_VHDL generate
proc elaborate {} {
# Actual API to instantiate an IP Core
add_hdl_instance emif_instance_name altera_mem_if_ddr3_emif
# Make sure the parameters are set appropriately
set_instance_parameter_value emif_instance_name SPEED_GRADE {7}
...
# instruct Qsys to use auto generated fixed name
set_instance_property emif_instance_name \
HDLINSTANCE_USE_GENERATED_NAME 1
}
proc generate { entity_name } {
# get the autogenerated name for emif_instance_name added
# via add_hdl_instance
set autogeneratedfixedname [get_instance_property \
emif_instance_name HDLINSTANCE_GET_GENERATED_NAME]
set fileID [open "generated_toplevel_component.v" r]
set temp ""
# read the contents of the file
while {[eof $fileID] != 1} {
gets $fileID lineInfo
# replace the top level entity name with the name provided
# during generation
regsub -all "substitute_entity_name_here" $lineInfo \
"${entity_name}" lineInfo
# replace the autogenerated name for emif_instance_name added
# via add_hdl_instance
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2015.05.04
Generated Components
6-35
regsub -all "substitute_autogenerated_emifinstancename_here" \
$lineInfo"${autogeneratedfixedname}" lineInfo \
append temp "${lineInfo}\n"
}
# adding a top level component file
add_fileset_file ${entity_name}.v VERILOG TEXT $temp
}
Example 6-16: Top-Level HDL Instance and Wrapper File Created By Qsys
// Top Level Component HDL
module substitute_entity_name_here (input_wire, output_wire,
inout_wire);
input [31:0] input_wire;
output [31:0] output_wire;
inout [31:0] inout_wire;
//
//
//
//
Instantiation of the instance added via add_hdl_instance
command. This is an example of how the instance added
via add_hdl_instance command can be used
in the top-level file of the component.
substitute_autogenerated_emifinstancename_here
fixed_name_instantiation_in_top_level (
.pll_ref_clk (input_wire), // pll_ref_clk.clk
.global_reset_n (input_wire), // global_reset.reset_n
.soft_reset_n (input_wire), // soft_reset.reset_n
...
... );
endmodule
//
//
//
//
Wrapper for added HDL instance
generated_toplevel_component_0_emif_instance_name.v is the
auto generated //emif_instance_name
Generated using ACDS version 13.
`timescale 1 ps / 1 ps
module generated_toplevel_component_0_emif_instance_name (
input wire pll_ref_clk, // pll_ref_clk.clk
input wire global_reset_n, // global_reset.reset_n
input wire soft_reset_n, // soft_reset.reset_n
output wire afi_clk, // afi_clk.clk
...
...);
example_addhdlinstance_system_add_hdl_instance_example_0_emif
_instance_name_emif_instance_name emif_instance_name (
.pll_ref_clk (pll_ref_clk), // pll_ref_clk.clk
.global_reset_n (global_reset_n), // global_reset.reset_n
.soft_reset_n (soft_reset_n), // soft_reset.reset_n
...
...);
endmodule
Related Information
Control File Generation Dynamically with Parameters and a Fileset Callback on page 6-26
Creating Qsys Components
Send Feedback
Altera Corporation
6-36
QII5V1
2015.05.04
Design Guidelines for Adding Component Instances
Design Guidelines for Adding Component Instances
In order to promote standard and predictable results when generating static and generated components,
Altera recommends the following best-practices:
• For two different parameterizations of a component, a component must never generate a file of the
same name with different instantiations. The contents of a file of the same name must be identical for
every parameterization of the component.
• If a component generates a nested component, it must never instantiate two different parameteriza‐
tions of the nested component using the same instance name. If the parent component's parameteriza‐
tion affects the parameters of the nested component, the parent component must use a unique instance
name for each unique parameterization of the nested component.
• Static components that generate differently based on parameterization have the potential to cause
problems in the following cases:
• Different file names with the same entity names, results in same entity conflicts at compilation-time
• Different contents with the same file name results in overwriting other instances of the component,
and in either file, compile-time conflicts or unexpected behavior.
• Generated components that generate files not based on the output name and that have different
content results in either compile-time conflicts, or unexpected behavior.
Document Revision History
Th