Quartus II Handbook Version 14.1.0

Quartus II Handbook Version 14.1.0
Quartus II Handbook Volume 1: Design and Synthesis
Subscribe
Send Feedback
QII5V1
2014.12.15
101 Innovation Drive
San Jose, CA 95134
www.altera.com
Managing Quartus II Projects
1
2014.12.15
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.
Figure 1-1: New Project Wizard
© 2014 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
2014.12.15
Understanding Quartus II Projects
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
Qsys System File (.qsys)
EDA tool
files
Tools > Options > EDA
Tool Options
Verilog Output File (.vo)
Generated for third-party
EDA tools
quartus2.ini (global)
Quartus II IP File (.qip)
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
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Viewing Basic Project Information
1-3
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-2: 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
Analyze the detailed project information in these reports to determine correct implementation. Rightclick report data to locate and edit the source in project files.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-4
QII5V1
2014.12.15
Viewing Project Messages
Figure 1-3: 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-4: Messages Window
You can suppress display of unimportant messages so they do not obscure valid messages.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Suppressing Messages
1-5
Figure 1-5: 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.
Click Assignments > Settings to access global project settings, including:
•
•
•
•
Project files list
Synthesis directives and constraints
Logic options and compiler effort levels
Placement constraints
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-6
Managing Project Settings
•
•
•
•
QII5V1
2014.12.15
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-6: 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.
Figure 1-7: Assignment Editor Spreadsheet
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Optimizing Project Settings
1-7
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
Use Design Space Explorer II (Tools > Launch Design Space Explorer) to find optimal project settings
for resource, performance, or power optimization goals. Design Space Explorer II (DSE) 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.
Figure 1-8: Design Space Explorer II
Optimizing with Project Revisions
You can save multiple, named project revisions within your Quartus II project (Project > Revisions).
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-8
Copying Your Project
QII5V1
2014.12.15
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.
Figure 1-9: 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.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Including Design Libraries
1-9
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.
Figure 1-10: 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-38
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
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-10
Managing Timing Constraints
QII5V1
2014.12.15
• 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.
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-11: 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 Altera Complete Design Suite (ACDS) installation includes the Altera IP library.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Installing and Licensing IP Cores
1-11
The OpenCore and OpenCore Plus IP evaluation features enable fast acquisition, evaluation, and
hardware testing of Altera IP cores.
You can integrate optimized and verified IP cores into your design to shorten design cycles and maximize
performance. The Quartus II® software also supports IP cores from other sources. Use the IP Catalog to
efficiently parameterize and generate a custom IP variation for instantiation in your design.
The Altera IP library includes the following IP core types:
•
•
•
•
•
Basic functions
DSP functions
Interface protocols
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 production use without purchasing an
additional license. You can evaluate any Altera IP core in simulation and compilation in the Quartus® II
software using the OpenCore® evaluation feature. Some Altera IP cores, such as MegaCore® functions,
require that you purchase a separate license for production use. You can use the OpenCore Plus feature to
evaluate IP that requires purchase of an additional license until you are satisfied with the functionality and
performance. After you purchase a license, visit the Self Service Licensing Center to obtain a license
number for any Altera product.
Figure 1-12: 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
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-12
QII5V1
2014.12.15
OpenCore Plus IP Evaluation
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:
•
•
•
•
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 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.
• Search to locate any full or partial IP core name in IP Catalog. Click Search for Partner IP, to access
partner IP information on the Altera website.
• Right-click an IP core name in IP Catalog to display details about supported devices, open the IP core's
installation folder, andor view links to documentation.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Using the Parameter Editor
1-13
Figure 1-13: Quartus II IP Catalog
Search and filter IP for your target device
Double-click to customize, right-click for 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).
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-14
QII5V1
2014.12.15
Adding IP Cores to IP Catalog
Figure 1-14: 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
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 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 project directory.
PROJECT_DIR/ip/**/*
Finds IP components and index files in any subdirectory of the /ip
subdirectory of the Quartus project directory.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
General IP Core Settings
1-15
Figure 1-15: 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 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 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 IP Core Settings
You can use the following settings to control how the Quartus software manages IP cores in your project.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-16
QII5V1
2014.12.15
Specifying IP Core Parameters and Options
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 Generation 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
The parameter editor GUI allows you to quickly configure your custom IP variation. Use the following
steps to specify IP core options and parameters in the Quartus II software. 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.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Files Generated for Altera IP Cores
1-17
5. Specify output file generation options, and then click Generate. The IP variation files generate
according to your specifications.
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-16: 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 software generates the following IP core output file structure.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-18
QII5V1
2014.12.15
Files Generated for Altera IP Cores
Figure 1-17: 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 - Lists files for simulation
<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 individual simulation scripts
<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.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Files Generated for Altera IP Cores
File Name
1-19
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 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 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 IP contains register information, .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 the
System Console.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-20
QII5V1
2014.12.15
Specifying IP Core Parameters and Options (Legacy Parameter Editors)
File Name
<my_ip>.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.
<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.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Files Generated for Altera IP Cores (Legacy Parameter Editors)
1-21
Figure 1-18: 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 software generates one of the following output file structures for Altera IP cores that use a
legacy parameter editor.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-22
QII5V1
2014.12.15
Generate a Qsys System or IP Variation with qsys-generate
Figure 1-19: 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 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.
Generate a Qsys System or IP Variation with qsys-generate
You can use the qsys-generate utility to generate RTL for your Qsys system, an IP core variation, or
simulation models and scripts. You can create testbench systems for testing your Qsys system in a
simulator using bus functional models (BFMs). Output from the qsys-generate command is the same as
when generating using the Qsys GUI.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Generate a Qsys System or IP Variation with qsys-generate
1-23
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.
--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.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-24
QII5V1
2014.12.15
Modifying an IP Variation
Option
Usage
Description
--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.
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.
Project > Upgrade IP Components
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 IP core variants.
The Upgrade IP Components dialog box provides instructions when IP upgrade is required, optional, or
unsupported for specific IP cores in your design. You must upgrade IP cores that require it before you can
compile the IP variation in the current version of the Quartus II software. Many Altera IP cores support
automatic upgrade.
The upgrade process renames and preserves the existing variation file (.v, .sv, or .vhd) as <my_variant>_
BAK.v, .sv, .vhd in the project directory.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Upgrading IP Cores
1-25
Table 1-7: IP Core Upgrade Status
IP Core Status
Corrective Action
Required Upgrade IP
Components
You must upgrade the IP variation before compiling in the current version of
the Quartus II software.
Optional Upgrade IP
Components
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.
Upgrade Unsupported
Upgrade of the IP variation is not supported in the current version of the
Quartus II software due to IP core end of life or incompatibility with the
current version of the Quartus II software. You are prompted to replace the
obsolete IP core with a current equivalent IP core from the IP Catalog.
Before you begin
• Archive the Quartus II project containing outdated IP cores in the original version of the Quartus II
software: Click Project > Archive Project to save the project in your previous version of the Quartus II
software. This archive preserves your original design source and project files.
• Restore the archived project in the latest version of the Quartus II software: Click Project > Restore
Archived Project. Click OK if prompted to change to a supported device or overwrite the project
database. File paths in the archive must be relative to the project directory. File paths in the archive
must reference the IP variation .v or .vhd file or .qsys file (not the .qip file).
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 simultaneously upgrade all IP cores that support automatic upgrade, 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 the IP core.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-26
QII5V1
2014.12.15
Upgrading IP Cores
Figure 1-20: Upgrading IP Cores
Displays upgrade
status for all IP cores
in the Project
Double-click to
individually migrate
Checked IP cores
support “Auto Upgrade”
Successful
“Auto Upgrade”
Upgrade
unavailable
Upgrades all IP core that support “Auto Upgrade”
Upgrades individual IP cores unsupported by “Auto Upgrade”
Example 1-1: Upgrading IP Cores at the Command Line
You can upgrade IP cores that support auto upgrade at the command line. IP cores that do not
support automatic upgrade do not support command line upgrade.
• To upgrade a single IP core that supports auto-upgrade, type the following command:
quartus_sh –ip_upgrade –variation_files <my_ip_filepath/my_ip>.<hdl>
<qii_project>
Example:
quartus_sh -ip_upgrade -variation_files mega/pll25.v hps_testx
• To simultaneously upgrade multiple IP cores that support auto-upgrade, type the following
command:
quartus_sh –ip_upgrade –variation_files “<my_ip_filepath/my_ip1>.<hdl>;
<my_ip_filepath/my_ip2>.<hdl>” <qii_project>
Example:
quartus_sh -ip_upgrade -variation_files "mega/pll_tx2.v;mega/pll3.v"
hps_testx
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 verifica‐
tion exceptions for Altera IP cores. Altera does not verify compilation for IP cores
older than the previous two releases.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Migrating IP Cores to a Different Device
1-27
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 require individual migration to upgrade. The Upgrade IP Components
dialog box prompts you to double-click IP cores that require individual migration.
1. To display IP cores requiring migration, click Project > Upgrade IP Components. The Description
field prompts you to double-click IP cores that require individual migration.
2. Double-click the IP core name, and then click OK after reading the information panel.
The parameter editor appears showing the original IP core parameters.
3. For the Currently selected device family, turn off Match project/default, and then select the new
target device family.
4. Click Finish, and then click Finish again to migrate the IP variation using best-effort mapping to new
parameters and settings. Click OK if you are prompted that the IP core is unsupported for the current
device. A new parameter editor opens displaying best-effort mapped parameters.
5. Click Generate HDL, and then confirm the Synthesis and Simulation file options. Verilog is the
parameter editor default HDL for synthesis files. If your original IP core was generated for VHDL,
select VHDL to retain the original output HDL format.
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 migrated device support. 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.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-28
QII5V1
2014.12.15
Generating Simulation Scripts
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.
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 not supported for 28nm and later device archetectures. 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 industrystandard 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,
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Generating Simulation Scripts
1-29
independent of IP simulation files that are replaced during regeneration. You can modify the scripts to set
up supported simulators.
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.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-30
QII5V1
2014.12.15
Generating Custom Simulation Scripts with ip-make-simscript
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.
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.
• To run ip-make-simscript, type the following at the command prompt:
<Quartus installation path>\quartus\sopc_builder\bin\ip-make-simscript
Table 1-9: ip-make-simscript Examples
Option
--spd=<file>
Description
Status
Describes the list of compiled files and
Requi
memory model hierarchy. If your design
red
includes multiple IP cores or Qsys systems
that include .spd files, use this option for
each file. For example:
ip-make-simscript --spd=ip1.spd -spd=ip2.spd
--output-directory=<directory>
--compile-to-work
--use-relative-paths
Specifies the location of output files. If
Optio
unspecified, the default setting is the
nal
directory from which ip-make-simscript
is run.
Compiles all design files to the default
work library. Use this option only if you
encounter problems managing your
simulation with multiple libraries.
Optio
nal
Uses relative paths whenever possible.
Optio
nal
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
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Instantiating IP Cores in HDL
1-31
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.
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 on page 16-1
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
Managing Quartus II Projects
Send Feedback
(
pipeline => 11,
Altera Corporation
1-32
QII5V1
2014.12.15
Integrating Other EDA Tools
width_exp => 8,
width_man => 23,
exception_handling => "no")
port map (
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
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Managing Team-based Projects
1-33
Simulating Altera Designs
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-33
Archiving Projects on page 1-35
Using External Revision Control on page 1-36
Migrating Projects Across Operating Systems on page 1-37
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.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-34
QII5V1
2014.12.15
Migrating Results Across Quartus II Software Versions
Migrating Results Across Quartus II Software Versions
View basic information about your project in the Project Navigator, Report panel, and Messages window.
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:
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Archiving Projects
1-35
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-34
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:
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-36
QII5V1
2014.12.15
Using External Revision Control
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:
•
•
•
•
•
•
Altera Corporation
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
QII5V1
2014.12.15
Migrating Projects Across Operating Systems
1-37
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.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-38
Design Library Migration Guidelines
QII5V1
2014.12.15
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.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Project Revision Commands
1-39
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-39
Set Current Revision Command on page 1-39
Get Project Revisions Command on page 1-39
Delete Revision Command on page 1-39
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.
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-40
QII5V1
2014.12.15
Creating a Project Archive
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-40
Import and Export Version-Compatible Databases from a Flow Package on page 1-40
Generate Version-Compatible Database After Compilation on page 1-41
quartus_cdb and quartus_sh Executables to Manage Version-Compatible Databases on page 1-41
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.
Altera Corporation
Managing Quartus II Projects
Send Feedback
QII5V1
2014.12.15
Generate Version-Compatible Database After Compilation
1-41
• 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-41
Report Specified Project Libraries Commands on page 1-41
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
Managing Quartus II Projects
Send Feedback
Altera Corporation
1-42
QII5V1
2014.12.15
Document Revision History
Document Revision History
Table 1-10: Document Revision History
Date
Version
Changes
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.
December 2010
10.1.0
•
•
•
•
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
2014.06.30
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.
© 2014 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
2014.06.30
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
2014.06.30
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
2014.06.30
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
2014.06.30
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
2014.06.30
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
2014.06.30
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
2014.06.30
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
2014.06.30
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
2014.06.30
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
2014.06.30
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
2014.06.30
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
2014.06.30
Fast Synthesis and Early Timing Estimation
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 .
Fast Synthesis and Early Timing Estimation
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.
Regardless of your compilation flow, you can run an early timing estimate to perform a quick placement
and routing, and a timing analysis of your design. The software chooses a device automatically if required,
places any LogicLock regions to create a floorplan, finds a quick initial placement for all the design logic,
and provides a useful estimate of the final design performance. If you have entered timing constraints,
timing analysis reports on these constraints.
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 and early timing estimation 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 get an early timing estimate and detect any problems with design integration.
Related Information
• Synthesis Effort logic option
For more information about Fast synthesis, refer to Quartus II Help.
• Running a Timing Analysis
For more information about how to run an early timing estimate, refer to Quartus II Help.
Design Planning with the Quartus II Software
Send Feedback
Altera Corporation
2-14
QII5V1
2014.06.30
Document Revision History
Document Revision History
Table 2-2: Document Revision History
Date
Version
Changes
2014.06.30 14.0.0
Updated format.
November
2013
Removed HardCopy device information.
13.1.0
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
Altera Corporation
Design Planning with the Quartus II Software
Send Feedback
QII5V1
2014.06.30
Document Revision History
Date
Version
Changes
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
November
2009
9.1.0
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
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.
Design Planning with the Quartus II Software
Send Feedback
2-15
Altera Corporation
2-16
QII5V1
2014.06.30
Document Revision History
Date
May 2008
Version
8.0.0
Changes
• 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
Altera Corporation
Design Planning with the Quartus II Software
Send Feedback
3
Quartus II Incremental Compilation for
Hierarchical and Team-Based Design
2014.12.15
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.
© 2014 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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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-55
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
Design Creation Flow
3-15
Figure 3-4: Design Creation Flow
Create Design Hierarchy
Define Safety Partitions
Create Safety IP
LogicLock Region
Compile the Design
Export Safety IP Partition
Generate Safety POF Part
Create Safety POF Part 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.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-16
QII5V1
2014.12.15
Design Modification Flow
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.
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
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2014.12.15
How to Turn On the Functional Safety Separation Flow
3-17
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.
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.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-18
QII5V1
2014.12.15
Preservation of Device Resources
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
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.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2014.12.15
General Guidelines for Implementation
3-19
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.
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
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-20
QII5V1
2014.12.15
POF Comparison Tool for Verification
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.
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
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2014.12.15
Deciding Which Design Blocks Should Be Design Partitions
3-21
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.
Figure 3-6: Partitions in a Hierarchical Design
Representation i
Partition Top
A
B
C
E
D
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.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-22
Impact of Design Partitions on Design Optimization
QII5V1
2014.12.15
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.
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.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2014.12.15
Design Partition Assignments Compared to Physical Placement Assignments
3-23
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
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.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-24
QII5V1
2014.12.15
Other Synthesis Tools
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
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.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2014.12.15
Incremental Compilation Advisor
3-25
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
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,
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-26
QII5V1
2014.12.15
Netlist Type for Design Partitions
explains the behavior of the Quartus II software for each setting, and provides guidance on when to use
each setting.
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
2014.12.15
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
2014.12.15
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
2014.12.15
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-50
• 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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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-25
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
2014.12.15
Taking Advantage of the Early Timing Estimator
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
Taking Advantage of the Early Timing Estimator
When creating a floorplan you can take advantage of the Early Timing Estimator to enable quick
compilations of the design while creating assignments. The Early Timing Estimator feature provides a
timing estimate for a design without having to run a full compilation. You can use the Chip Planner to
view the “placement estimate” created by this feature, identify critical paths by locating from the timing
analyzer reports, and, if necessary, add or modify floorplan constraints. You can then rerun the Early
Timing Estimator to quickly assess the impact of any floorplan location assignments or logic changes,
enabling rapid iterations on design variants to help you find the best solution. This faster placement has
an impact on the quality of results. If getting the best quality of results is important in a given design
iteration, perform a full compilation with the Fitter instead of using the Early Timing Estimate feature.
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
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-50
Using Incremental Compilation With Quartus II Archive Files
QII5V1
2014.12.15
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
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.
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2014.12.15
SignalTap II Logic Analyzer in Exported Partitions
3-51
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
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.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-52
QII5V1
2014.12.15
Design Partition Script Limitations
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.
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
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2014.12.15
Pin Assignments for GXB and LVDS Blocks in Design Partition Scripts
3-53
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.
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.
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-54
QII5V1
2014.12.15
Register Packing and Partition Boundaries
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.
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
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2014.12.15
Scripting Support
3-55
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
• 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
-h | -help
Description
Short 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>
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-56
QII5V1
2014.12.15
Setting the Netlist Type
Table 3-5: Tcl Script Command: set_global_assignment
Value
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.
OFF
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
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2014.12.15
Specifying the Software Should Use the Specified Netlist and Ignore Source File
Changes
3-57
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:
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 flow
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
Altera Corporation
3-58
QII5V1
2014.12.15
Generating Design Partition Scripts
load_package incremental_compilation
load_package project
project_open $project
# Turn on Physical Synthesis Optimization
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
Altera Corporation
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Send Feedback
QII5V1
2014.12.15
Importing a Partition into the Top-Level Design
3-59
export_partition -partition <partition name>
-qxp <.qxp file name> -<options>
#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
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
2014.12.15
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
2014.12.15
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
2014.12.15
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-7
Implementation Details for Partial Reconfiguration on page 4-18
Partial Reconfiguration with an External Host on page 4-25
Partial Reconfiguration with an Internal Host on page 4-27
Partial Reconfiguration Project Management on page 4-28
Programming Files for a Partial Reconfiguration Project on page 4-30
Partial Reconfiguration Known Limitations on page 4-37
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.
© 2014 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
2014.12.15
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
2014.12.15
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
2014.12.15
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
2014.12.15
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. They are neither erased nor reset.
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 PR regions above or below the region being reconfigured. As a
result, it is not currently possible to correctly determine the bits associated with a PR region above or
below the region being reconfigured, because those bits could have already been reconfigured and
changed to an unknown value. This restriction does not apply to static bits above or below the PR region,
since those bits never change and you can rewrite them with the same value as the current state of the
configuration bit. You cannot use the SCRUB mode when two PR regions have a vertically overlapping
column in the device.
The advantage of using the SCRUB mode is that the programming file size is much smaller than the
AND/OR mode.
Figure 4-3: 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
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-6
QII5V1
2014.12.15
AND/OR Mode
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.
Figure 4-4: 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)
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Partial Reconfiguration Design Flow
4-7
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 SCRUB 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>
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.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-8
QII5V1
2014.12.15
Partial Reconfiguration Design Flow
Figure 4-5: 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.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Design Partitions for Partial Reconfiguration
4-9
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
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-10
QII5V1
2014.12.15
Partial Reconfiguration Controller Instantiation in the Design
Partial Reconfiguration Controller Instantiation in the Design
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.
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 ;
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Instantiating the PR Control Block and CRC Block in VHDL
4-11
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
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-12
QII5V1
2014.12.15
Instantiating the PR Control Block and CRC Block in Verilog HDL
clk=>
crcerror
);
dummy_clk,
=>
//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
// Following shows the connectivity within the Chip_Top module
Core_Top : Core_Top
port_map (
..
..
);
m_pr : stratixv_prblock
//set corectl to '1' when using PR from inside
//set corectl to '0' for PR from pins. You must also enable
// the appropriate option in Quartus II settings.
port map(
clk => dclk,
corectl=> '0',
prrequest=> pr_request,
data=> pr_data,
error=> pr_error,
ready=> pr_ready,
done=> pr_done
);
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Wrapper Logic for PR Regions
4-13
m_crc : stratixv_crcblock
//If you want to read the EMR register when an 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.
port map(
shiftnld=> '1',
clk=> dummy_clk,
crcerror=> 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
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-6: 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,
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-14
QII5V1
2014.12.15
Wrapper Logic for PR Regions
output [7:0] q
);
reg [3:0] p, q;
[email protected](a or b) begin
p = a + b ;
end
[email protected](a or b or c or p)begin
q = (p*a - b*c )
end
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;
[email protected](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
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Freeze Logic for PR Regions
4-15
p <= a *b; --note q is not assigned a value in this persona
end process;
end synth;
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-7: 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;
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-16
QII5V1
2014.12.15
Freeze Logic for PR Regions
wire clk2_to_wr;
//instantiate pr_module
pr_module pr_module
(
.reset (reset), //input
.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;
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Clocks and Other Global Signals for a PR Design
4-17
framer_ctl_wr <= logic_high when (freeze ='1') else framer_ctl;
clk2_to_wr <= logic_high(0) when (freeze ='1') else clk2;
end architecture;
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.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-18
QII5V1
2014.12.15
Floorplan Assignments for PR Designs
• 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.
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.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Partial Reconfiguration Pins
4-19
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.
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.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-20
QII5V1
2014.12.15
Interface with the PR Control Block through a PR Host
Pin Name
PR_ERROR
Pin Type
Output
Pin Description
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.
DATA[15:0]
Input
Dedicated input when Enable
PR pins is turned on; otherwise
available as user I/O.
These pins provide connectivity
for PR_DATA when Enable PR
pins is turned on.
DCLK
Bidirectional
Dedicated input when Enable
PR pins is turned on; PR_DATA is
sent synchronous to this clock.
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.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
PR Control Signals Interface
4-21
Figure 4-8: 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
External
Host
PR Control
Block (CB)
PR
Region
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.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-22
QII5V1
2014.12.15
Reconfiguring a PR Region
Figure 4-9: 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.
• 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.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Reconfiguring a PR Region
4-23
Figure 4-10: 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.
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.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-24
QII5V1
2014.12.15
Partial Reconfiguration Cycle Waveform
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.
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.
Figure 4-11: 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]
PR_READY
D0LSW D0MSW D1LSW D1MSW
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
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Partial Reconfiguration with an External Host
4-25
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)
Encrypted and Compressed PR_READY to first data
(when using double PR)
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.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-26
QII5V1
2014.12.15
Using an External Host with Multiple Devices
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].
Figure 4-12: 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
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.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Partial Reconfiguration with an Internal Host
4-27
Figure 4-13: 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
The PR internal host is a piece of soft logic implemented in the FPGA that you must design to
accommodate the 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), and can be stored in on-chip memory such as MLABs or M20K blocks, for
processing by the internal logic. This data must be formatted into the 16 bit wide data so that it can be
transmitted to the PR control block by the internal IP, because the PR control block can only accept PR
data via its FPPx16 interface.
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,
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-28
QII5V1
2014.12.15
Partial Reconfiguration Project Management
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.
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-14: 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]
PR
Controller
EPCS
DATA
DCLK
nCS
ASDI
AS_DATA1
DCLK
nCSO
ASDO
User Logic
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.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Compiling Reconfigurable Revisions
4-29
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.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-30
QII5V1
2014.12.15
Programming Files for a Partial Reconfiguration Project
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-35
• Enable Bitstream Decryption Option on page 4-36
• Generate PR Programming Files with the Convert Programming Files Dialog Box on page 4-33
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.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Programming Files for a Partial Reconfiguration Project
4-31
Figure 4-15: 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.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-32
QII5V1
2014.12.15
Programming Files for a Partial Reconfiguration Project
Figure 4-16: 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-17: 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
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Generating Required Programming Files
4-33
Related Information
Generate PR Programming Files with the Convert Programming Files Dialog Box on page 4-33
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
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-34
QII5V1
2014.12.15
Generating a .pmsf File from a .msf and .sof Input File
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-42
• Initializing M20K Blocks with a Double PR Cycle on page 4-42
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Create a Merged .msf File from Multiple .msf Files
4-35
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.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-36
QII5V1
2014.12.15
Enable Bitstream Decryption Option
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-18: 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.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Partial Reconfiguration Known Limitations
4-37
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-40
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-19: 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.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-38
QII5V1
2014.12.15
Limitations When Using Stratix V Production Devices
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-20: 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
•
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
MLAB Blocks in PR designs
4-39
Figure 4-21: 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
Design Planning for Partial Reconfiguration
Send Feedback
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
Altera Corporation
4-40
QII5V1
2014.12.15
Implementing Memories with Initialized Content
PR Mode
Type of memory in PR region
LUT RAM (no initial content)
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.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Implementing Memories with Initialized Content
4-41
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
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-42
QII5V1
2014.12.15
Initializing M20K Blocks with a Double PR Cycle
Figure 4-22: 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-42
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.
Altera Corporation
Design Planning for Partial Reconfiguration
Send Feedback
QII5V1
2014.12.15
Double PR with Compressed Programming Bitstream
4-43
Figure 4-23: Next PR Request Assertion During Double PR Cycle
This figure displays the second phase of a double PR cycle, where the host logic must issue another
PR_REQUEST signal after exactly seven clock cycles after the PR_DONE signal is asserted.
PR_REQUEST
PR_CLK
READY_to_NEXT_DATA
PR_DATA[15:0]
PR_READY
DONE_to_NEXT_REQ
PR_DONE
PR_ERROR
CRC_ERROR
If the PR encryption feature (without compression) is enabled , the host logic must issue another
PR_REQUEST signal exactly six clock cycles after PR_DONE is asserted.
If the PR compression feature is enabled (with or without encryption), the host logic must issue another
PR_REQUEST signal exactly two clock cycles after PR_DONE is asserted. The FPGA responds with PR_READY
signal to the second PR_REQUEST signal assertion.
The PR host must continue sending PR_DATA signal exactly four clock cycles after the PR_READY signal,
just as in the first PR cycle. The data on PR_DATA pins can be don't care between the first PR_DONE signal
and until four clock cycles after the PR_READY signal is asserted for the second PR cycle.
The host must continue sending a PR_DATA signal for the second PR cycle, until it receives the PR_DONE
signal for the second request, similar to the first PR cycle. After the PR_DONE signal is asserted for the
second time, the host should de-assert the PR_REQUEST signal and continue with other operations needed
for region bring up, such as issuing a reset to bring the region to a known state.
Double PR with Compressed Programming Bitstream
You can use bitstream compression along with PR designs that also require memory initialization for
M20K blocks.
For a compressed bitstream requiring a double PR cycle, the PR host must stop sending the PR_DATA
signal in the bitstream as soon as the first PR_DONE is asserted. The PR host must resume sending the
PR_DATA signal immediately after the second PR_READY signal is asserted.
Design Planning for Partial Reconfiguration
Send Feedback
Altera Corporation
4-44
QII5V1
2014.12.15
Document Revision History
Document Revision History
Table 4-8: Document Revision History
Date
2015.12.15
Version
14.1.0
Changes
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
2014.12.15
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. These components 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
© 2014 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
2014.12.15
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 or 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
2014.12.15
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
2014.12.15
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 configurecomponents.
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
2014.12.15
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
2014.12.15
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
2014.12.15
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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-8
Manage Qsys Window Views with Layouts
QII5V1
2014.12.15
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.
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
2014.12.15
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
2014.12.15
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.
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.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
View Assignments and Connections in Your Qsys System
5-11
Figure 5-7: Qsys Schematic Tab
Related Information
Edit a Qsys Subsystem on page 5-23
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
2014.12.15
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
2014.12.15
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-21
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
2014.12.15
Configure Your IP Component with a Pre-Defined Set of 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. 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.
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.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Create a Custom IP Component (_hw.tcl)
5-15
Create a Custom IP Component (_hw.tcl)
Figure 5-10: 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
Create Component
Using Component Editor, or
by Manually Creating the
_hw.tcl File
2
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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-16
QII5V1
2014.12.15
Add IP Components to the Qsys IP Catalog
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.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Save IP Components to the Default Search Directory
5-17
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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-18
QII5V1
2014.12.15
Save IP Components to the Default Search Directory
Figure 5-11: 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.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Set up the IP Index File (.ipx) to Search for IP Components
5-19
Related Information
Introduction to Altera IP Cores
Set up the IP Index File (.ipx) to Search for IP Components
An IP Index File (.ipx) is an XML file that contains a search path that Qsys uses to search for IP
components that are available for a Qsys system. You can use the ip-make-ipx command to create
an .ipx file for a directory tree, which can reduce the startup time for Qsys.
You can specify a search path in a user_components.ipx file located anywhere in a customizable search
path 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 location that is independent
of the default search path. The user_components.ipx file directs Qsys to the location of each 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-1: 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-2: 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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-20
QII5V1
2014.12.15
Integrate Third-Party IP Components into the Qsys IP Catalog
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 checkmark. 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 checkmark 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-16
Introduction to Altera IP Cores
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Create and Manage Hierarchical Qsys Systems
5-21
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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-22
QII5V1
2014.12.15
Drill into a Qsys Subsystem to Explore its Contents
Figure 5-12: 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.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Edit a Qsys Subsystem
5-23
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-13: 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).
Creating a System With Qsys
Send Feedback
Altera Corporation
5-24
QII5V1
2014.12.15
Change the Hierarchy Level of a Qsys Component
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-10
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.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Create an IP Component Based on a Qsys System
5-25
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 Component System
This procedure creates a Qsys system to use as subsystem in 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 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.
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 components_system.qsys.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-26
QII5V1
2014.12.15
Add Qsys Instance Parameters
Figure 5-14: On-Chip Memory Component System and Instance Parameters
(components_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 use as subsystem in a higherlevel system as part of a hierarchical instance parameter example.
1. In the components_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_size, select Integer for Type, and 1024 as the Default Value.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Add Qsys Instance Parameters
5-27
Figure 5-15: Qsys Instance Parameters Tab
8. In the Instance Script section, type the commands that control how the parameters are passed 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.
Figure 5-16: Instance Script
9. Click Preview Instance to view the parameter editor GUI.
Preview Instance allows you to see how an instance of a system appears when you use it in another
system.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-28
Create a Qsys Instantiating Component System
QII5V1
2014.12.15
Figure 5-17: Preview Your Instance in the Parameter Editor
10.Click File > Save.
Create a Qsys Instantiating Component System
This procedure creates a Qsys system to use as a higher-level system as part of a hierarchical instance
parameter example.
1.
2.
3.
4.
5.
Altera Corporation
In Qsys, click File > New System.
Right-click clk_0, and then click Remove.
In the IP Catalog, under System, double-click components_system.
In the Systems Contents tab, for each element under system_0, double-click the Export column.
Click File > Save to save your Qsys as instantiating_component_system.qsys.
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Apply Instance Parameters at a Higher-Level Qsys System and Pass the Parameters
to the Instantiated Lower-Level System
5-29
Figure 5-18: Instantiating Component System (instantiating_component_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 instance parameters to control the implementation of an On-Chip
Memory component as part of a hierarchical instance parameter example.
1. In the instantiating_component_system.qsys system, in the Hierarchy tab, click and expand system_0
(components_system.qsys).
2. Click View > Parameters.
The instance paramters that you defined in components_system.qsys display in the Parameter Editor.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-30
Apply Instance Parameters at a Higher-Level Qsys System and Pass the Parameters
to the Instantiated Lower-Level System
QII5V1
2014.12.15
Figure 5-19: Display Your Instance Parameters in the Parameter Editor
3. In the Parameters tab, change the value of component_data_width to 16, and
component_memory_size to 2048.
4. In the Hierarchy tab, under system_0 (components_system.qsys), click onchip_memory_0.
When you select onchip_memory_0, the new parameter values for Data width and Total memory size
are displayed.
The entries for the On-Chip Memory component appear grayed out at this lower-level of hierarchy.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
View and Filter Clock and Reset Domains in Your Qsys System
5-31
Figure 5-20: Vary the Values for 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
box, which is accesible by clicking the filter icon at the bottom of the System Contents tab. In the Filters
dialog box, you can choose to view a a single interface, or to hide clock, reset, or interrupt interfaces.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-32
QII5V1
2014.12.15
View Clock Domains in Your Qsys System
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.
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.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
View Clock Domains in Your Qsys System
5-33
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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-34
View Reset Domains in Your Qsys System
QII5V1
2014.12.15
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:
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Filter Qsys Clock and Reset Domains in the System Contents Tab
5-35
• 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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-36
QII5V1
2014.12.15
Define Qsys Instance Parameters
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
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
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Create an Instance Parameter Script in Qsys
5-37
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-3: Instance 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
Creating a System With Qsys
Send Feedback
Altera Corporation
5-38
Supported Tcl Commands for Qsys Instance Parameter Scripts
QII5V1
2014.12.15
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
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_instance_parameters
5-39
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
Creating a System With Qsys
Send Feedback
Altera Corporation
5-40
QII5V1
2014.12.15
get_parameter_value
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
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_parameters
5-41
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
Creating a System With Qsys
Send Feedback
Altera Corporation
5-42
send_message
QII5V1
2014.12.15
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!"
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
set_instance_parameter_value
5-43
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 vaule.
Example
set_instance_parameter_value uart_0 baudRate 9600
Creating a System With Qsys
Send Feedback
Altera Corporation
5-44
QII5V1
2014.12.15
set_module_property
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"
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
Altera Corporation
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.
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Specify Qsys Interconnect Requirements
Option
Clock crossing adapter type
5-45
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.
Table 5-4: Specifying $system Interconnect Requirements
You can apply the following interconnect requirements when you select $system as the Identifier in the
Interconnect Requirements tab, in the All Requirements table. $system is the current system that is open in
Qsys.
Option
Description
Limit interconnect pipeline
stages to
Refer to Specifying System-Wide Interconnect Requirements.
Clock crossing adapter type
Refer to Specifying System-Wide Interconnect Requirements.
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
When you set this option to TRUE, Qsys enables debug instrumentation
in the Qsys interconnect, which then monitors interconnect performance
in the system console.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-46
QII5V1
2014.12.15
Manage Qsys System Security
Option
Burst Adapter Implementa‐
tion
Description
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.
Table 5-5: 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.
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 nonsecure. 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.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Configure Qsys Security Settings Between Interfaces
5-47
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-6: 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
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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-48
QII5V1
2014.12.15
Specify a Default Slave in a Qsys System
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-7: 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
Non-TrustZone-aware OK
memory (non-secure
region)
OK
OK
Altera Corporation
OK
Non-TrustZone-aware
Master
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Access Undefined Memory Regions
5-49
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.
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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-50
QII5V1
2014.12.15
Integrate a Qsys System and the Quartus II Software With the .qsys File
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-16
Generate a Qsys System on page 5-53
Qsys Synthesis Standard and Legacy Device Output Directories on page 5-56
Qsys Simulation Standard and Legacy Device Output Directories on page 5-57
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:
1.
2.
3.
4.
5.
Altera Corporation
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.
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Manage IP Settings in the Quartus II Software
5-51
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-8: 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.
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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-52
QII5V1
2014.12.15
Set Qsys Clock Constraints
• 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.
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
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Generate a Qsys System
5-53
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.
Related Information
• Avalon Verification IP Suite User Guide
• Mentor Verification IP (VIP) Altera Edition (AE)
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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-54
QII5V1
2014.12.15
Files Generated for Qsys IP Components
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
Description
Create HDL design files for synthesis
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.
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.
When turned off, Qsys generates all simulation files
in the selected simulation model language.
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-9: Qsys-Generated IP Component Files
File Name
<system>.qsys
Altera Corporation
Description
The Qsys system file. <system> is the name that you give your system.
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Files Generated for Qsys IP Components
File Name
<system>.sopcinfo
5-55
Description
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.
<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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-56
QII5V1
2014.12.15
Qsys Synthesis Standard and Legacy Device Output Directories
File Name
Description
<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.
<system>.svd
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-56
• Qsys Simulation Standard and Legacy Device Output Directories on page 5-57
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
2014.12.15
Qsys Simulation Standard and Legacy Device Output Directories
5-57
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-54
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-58
QII5V1
2014.12.15
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-54
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
2014.12.15
Files Generated for Qsys Testbench
5-59
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 mixed-language simulation model. If you have a
mixed-language simulator license, generating for mixedlanguage simulation can shorten the generation time, and
produce files that can simulate faster. When turned off, all
simulation files are generated in the selected simulation model
language.
Files Generated for Qsys Testbench
Table 5-10: Qsys-Generated Testbench Files
File Name or Directory Name
<system>_tb.qsys
Creating a System With Qsys
Send Feedback
Description
The Qsys testbench system.
Altera Corporation
5-60
QII5V1
2014.12.15
Files Generated for Qsys Testbench
File Name or Directory Name
<system>_tb.v
or
Description
The top-level testbench file that connects BFMs to the top-level
interfaces of <system>_tb.qsys.
<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.
/submodules
Contains HDL files for the submodule of the Qsys testbench system.
<child IP cores>/
For each generated child IP core directory, Qsys testbench generates /
synth and /sim subdirectories.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Qsys Testbench Simulation Standard and Legacy Device Output Directories
5-61
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>
Generate and Modify a Qsys Testbench System
You can use the following steps to create a Qsys testbench system of your Qsys system.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-62
QII5V1
2014.12.15
Simulation Scripts
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, re-generate 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 the 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-11: 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
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.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Simulating Software Running on a Nios II Processor
5-63
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-64
QII5V1
2014.12.15
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
2014.12.15
Manually Controlling Pipelining in the Qsys Interconnect
5-65
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-66
QII5V1
2014.12.15
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
2014.12.15
Qsys 64-Bit Addressing Support
5-67
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-68
QII5V1
2014.12.15
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
2014.12.15
Generate a Qsys System or IP Variation with qsys-generate
5-69
You can use the following options with the qsys-edit utility:
Table 5-12: 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.
Generate a Qsys System or IP Variation with qsys-generate
You can use the qsys-generate utility to generate RTL for your Qsys system, an IP core variation, or
simulation models and scripts. You can create testbench systems for testing your Qsys system in a
simulator using bus functional models (BFMs). Output from the qsys-generate command is the same as
when generating using the Qsys GUI.
Table 5-13: qsys-generate Command-Line Options
Option
<1st arg file>
Creating a System With Qsys
Send Feedback
Usage
Required
Description
The name of the .qsys system file to
generate.
Altera Corporation
5-70
QII5V1
2014.12.15
Generate a Qsys System or IP Variation with qsys-generate
Option
Usage
Description
--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.
--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.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Display Available IP Components with ip-catalog
Option
Usage
--allow-mixed-language-simulation
Optional
5-71
Description
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.
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]
Table 5-14: 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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-72
QII5V1
2014.12.15
Create an .ipx File with ip-make-ipx
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-15: 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.
--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.
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.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Generate a Qsys System with qsys-script
5-73
Table 5-16: 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.
--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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-74
Qsys Scripting Command Reference
QII5V1
2014.12.15
Qsys Scripting Command Reference
The following are Qsys scripting commands:
add_connection on page 5-77
add_instance on page 5-78
add_interface on page 5-79
apply_preset on page 5-80
auto_assign_base_addresses on page 5-81
auto_assign_system_base_addresses on page 5-82
auto_assign_irqs on page 5-83
auto_connect on page 5-84
create_system on page 5-85
export_hw_tcl on page 5-86
get_composed_connection_parameter_value on page 5-87
get_composed_connection_parameters on page 5-88
get_composed_connections on page 5-89
get_composed_instance_assignment on page 5-90
get_composed_instance_assignments on page 5-91
get_composed_instance_parameter_value on page 5-92
get_composed_instance_parameters on page 5-93
get_composed_instances on page 5-94
get_connection_parameter_property on page 5-95
get_connection_parameter_value on page 5-96
get_connection_parameters on page 5-97
get_connection_properties on page 5-98
get_connection_property on page 5-99
get_connections on page 5-100
get_instance_assignment on page 5-101
get_instance_assignments on page 5-102
get_instance_documentation_links on page 5-103
get_instance_interface_assignment on page 5-104
get_instance_interface_assignments on page 5-105
get_instance_interface_parameter_property on page 5-106
get_instance_interface_parameter_value on page 5-107
get_instance_interface_parameters on page 5-108
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Qsys Scripting Command Reference
5-75
get_instance_interface_port_property on page 5-109
get_instance_interface_ports on page 5-110
get_instance_interface_properties on page 5-111
get_instance_interface_property on page 5-112
get_instance_interfaces on page 5-113
get_instance_parameter_property on page 5-114
get_instance_parameter_value on page 5-115
get_instance_parameters on page 5-116
get_instance_port_property on page 5-117
get_instance_properties on page 5-118
get_instance_property on page 5-119
get_instances on page 5-120
get_interconnect_requirement on page 5-121
get_interconnect_requirements on page 5-122
get_interface_port_property on page 5-123
get_interface_ports on page 5-124
get_interface_properties on page 5-125
get_interface_property on page 5-126
get_interfaces on page 5-127
get_module_properties on page 5-128
get_module_property on page 5-129
get_parameter_properties on page 5-130
get_port_properties on page 5-131
get_project_properties on page 5-132
get_project_property on page 5-133
load_system on page 5-134
lock_avalon_base_address on page 5-135
remove_connection on page 5-136
remove_dangling_connections on page 5-137
remove_instance on page 5-138
remove_interface on page 5-139
save_system on page 5-140
send_message on page 5-141
set_connection_parameter_value on page 5-142
Creating a System With Qsys
Send Feedback
Altera Corporation
5-76
Qsys Scripting Command Reference
QII5V1
2014.12.15
set_instance_parameter_value on page 5-143
set_instance_property on page 5-144
set_interconnect_requirement on page 5-145
set_interface_property on page 5-146
set_module_property on page 5-147
set_project_property on page 5-148
set_use_testbench_naming_pattern on page 5-149
set_validation_property on page 5-150
unlock_avalon_base_address on page 5-151
validate_connection on page 5-152
validate_instance on page 5-153
validate_instance_interface on page 5-154
validate_system on page 5-155
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
add_connection
5-77
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
•
•
•
•
•
get_connection_parameter_value on page 5-96
get_connection_property on page 5-99
get_connections on page 5-100
remove_connection on page 5-136
set_connection_parameter_value on page 5-142
Creating a System With Qsys
Send Feedback
Altera Corporation
5-78
QII5V1
2014.12.15
add_instance
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
•
•
•
•
•
Altera Corporation
get_instance_parameter_value on page 5-115
get_instance_property on page 5-119
get_instances on page 5-120
remove_instance on page 5-138
set_instance_parameter_value on page 5-143
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
add_interface
5-79
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
•
•
•
•
get_interface_ports on page 5-124
get_interface_properties on page 5-125
get_interface_property on page 5-126
set_interface_property on page 5-146
Creating a System With Qsys
Send Feedback
Altera Corporation
5-80
apply_preset
QII5V1
2014.12.15
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"
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
auto_assign_base_addresses
5-81
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-82
• lock_avalon_base_address on page 5-135
• unlock_avalon_base_address on page 5-151
Creating a System With Qsys
Send Feedback
Altera Corporation
5-82
auto_assign_system_base_addresses
QII5V1
2014.12.15
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-81
• lock_avalon_base_address on page 5-135
• unlock_avalon_base_address on page 5-151
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
auto_assign_irqs
5-83
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
Creating a System With Qsys
Send Feedback
Altera Corporation
5-84
auto_connect
QII5V1
2014.12.15
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-77
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
create_system
5-85
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-134
• save_system on page 5-140
Creating a System With Qsys
Send Feedback
Altera Corporation
5-86
export_hw_tcl
QII5V1
2014.12.15
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
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_composed_connection_parameter_value
5-87
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-88
• get_composed_connections on page 5-89
Creating a System With Qsys
Send Feedback
Altera Corporation
5-88
QII5V1
2014.12.15
get_composed_connection_parameters
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-87
• get_composed_connections on page 5-89
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_composed_connections
5-89
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-87
• get_composed_connection_parameters on page 5-88
Creating a System With Qsys
Send Feedback
Altera Corporation
5-90
QII5V1
2014.12.15
get_composed_instance_assignment
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-91
• get_composed_instances on page 5-94
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_composed_instance_assignments
5-91
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-90
• get_composed_instances on page 5-94
Creating a System With Qsys
Send Feedback
Altera Corporation
5-92
QII5V1
2014.12.15
get_composed_instance_parameter_value
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-93
• get_composed_instances on page 5-94
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_composed_instance_parameters
5-93
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-92
• get_composed_instances on page 5-94
Creating a System With Qsys
Send Feedback
Altera Corporation
5-94
get_composed_instances
QII5V1
2014.12.15
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
•
•
•
•
Altera Corporation
get_composed_instance_assignment on page 5-90
get_composed_instance_assignments on page 5-91
get_composed_instance_parameter_value on page 5-92
get_composed_instance_parameters on page 5-93
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_connection_parameter_property
5-95
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
•
•
•
•
•
get_connection_parameter_value on page 5-96
get_connection_property on page 5-99
get_connections on page 5-100
get_parameter_properties on page 5-130
Parameter Properties on page 5-165
Creating a System With Qsys
Send Feedback
Altera Corporation
5-96
QII5V1
2014.12.15
get_connection_parameter_value
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-97
• get_connections on page 5-100
• set_connection_parameter_value on page 5-142
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_connection_parameters
5-97
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-95
• get_connection_parameter_value on page 5-96
• get_connection_property on page 5-99
Creating a System With Qsys
Send Feedback
Altera Corporation
5-98
get_connection_properties
QII5V1
2014.12.15
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-99
• get_connections on page 5-100
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_connection_property
5-99
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-98
• Connection Properties on page 5-157
Creating a System With Qsys
Send Feedback
Altera Corporation
5-100
QII5V1
2014.12.15
get_connections
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-77
• remove_connection on page 5-136
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_instance_assignment
5-101
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-102
Creating a System With Qsys
Send Feedback
Altera Corporation
5-102
get_instance_assignments
QII5V1
2014.12.15
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-101
get_instance_assignment on page 5-101
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_instance_documentation_links
5-103
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}
Creating a System With Qsys
Send Feedback
Altera Corporation
5-104
QII5V1
2014.12.15
get_instance_interface_assignment
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-105
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_instance_interface_assignments
5-105
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-104
Creating a System With Qsys
Send Feedback
Altera Corporation
5-106
QII5V1
2014.12.15
get_instance_interface_parameter_property
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
•
•
•
•
Altera Corporation
get_instance_interface_parameters on page 5-108
get_instance_interfaces on page 5-113
get_parameter_properties on page 5-130
Parameter Properties on page 5-165
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_instance_interface_parameter_value
5-107
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-108
• get_instance_interfaces on page 5-113
Creating a System With Qsys
Send Feedback
Altera Corporation
5-108
get_instance_interface_parameters
QII5V1
2014.12.15
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-107
• get_instance_interfaces on page 5-113
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_instance_interface_port_property
5-109
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-110
• get_port_properties on page 5-131
• Port Properties on page 5-170
Creating a System With Qsys
Send Feedback
Altera Corporation
5-110
get_instance_interface_ports
QII5V1
2014.12.15
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-109
• get_instance_interfaces on page 5-113
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_instance_interface_properties
5-111
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-112
• get_instance_interfaces on page 5-113
Creating a System With Qsys
Send Feedback
Altera Corporation
5-112
QII5V1
2014.12.15
get_instance_interface_property
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-111
• get_instance_interfaces on page 5-113
• Element Properties on page 5-160
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_instance_interfaces
5-113
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-110
• get_instance_interface_properties on page 5-111
• get_instance_interface_property on page 5-112
Creating a System With Qsys
Send Feedback
Altera Corporation
5-114
QII5V1
2014.12.15
get_instance_parameter_property
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-116
• get_parameter_properties on page 5-130
• Parameter Properties on page 5-165
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_instance_parameter_value
5-115
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-116
• set_instance_parameter_value on page 5-143
Creating a System With Qsys
Send Feedback
Altera Corporation
5-116
get_instance_parameters
QII5V1
2014.12.15
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-114
• get_instance_interface_parameter_value on page 5-107
• set_instance_parameter_value on page 5-143
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_instance_port_property
5-117
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-110
• get_port_properties on page 5-131
• Port Properties on page 5-170
Creating a System With Qsys
Send Feedback
Altera Corporation
5-118
get_instance_properties
QII5V1
2014.12.15
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-119
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_instance_property
5-119
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-118
• Element Properties on page 5-160
Creating a System With Qsys
Send Feedback
Altera Corporation
5-120
get_instances
QII5V1
2014.12.15
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-78
• remove_instance on page 5-138
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_interconnect_requirement
5-121
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
Creating a System With Qsys
Send Feedback
Altera Corporation
5-122
get_interconnect_requirements
QII5V1
2014.12.15
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
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_interface_port_property
5-123
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-124
• get_port_properties on page 5-131
• Port Properties on page 5-170
Creating a System With Qsys
Send Feedback
Altera Corporation
5-124
get_interface_ports
QII5V1
2014.12.15
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-123
• get_interfaces on page 5-127
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_interface_properties
5-125
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-126
• set_interface_property on page 5-146
Creating a System With Qsys
Send Feedback
Altera Corporation
5-126
get_interface_property
QII5V1
2014.12.15
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-125
• set_interface_property on page 5-146
• Interface Properties on page 5-162
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_interfaces
5-127
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
•
•
•
•
•
add_interface on page 5-79
get_interface_ports on page 5-124
get_interface_property on page 5-126
remove_interface on page 5-139
set_interface_property on page 5-146
Creating a System With Qsys
Send Feedback
Altera Corporation
5-128
QII5V1
2014.12.15
get_module_properties
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-129
• set_module_property on page 5-147
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_module_property
5-129
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-128
• set_module_property on page 5-147
Creating a System With Qsys
Send Feedback
Altera Corporation
5-130
get_parameter_properties
QII5V1
2014.12.15
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-95
• get_instance_interface_parameter_property on page 5-106
• get_instance_parameter_property on page 5-114
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_port_properties
5-131
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
•
•
•
•
•
get_instance_interface_port_property on page 5-109
get_instance_interface_ports on page 5-110
get_instance_port_property on page 5-117
get_interface_port_property on page 5-123
get_interface_ports on page 5-124
Creating a System With Qsys
Send Feedback
Altera Corporation
5-132
QII5V1
2014.12.15
get_project_properties
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-133
• set_project_property on page 5-148
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
get_project_property
5-133
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-128
• get_module_property on page 5-129
• set_module_property on page 5-147
Creating a System With Qsys
Send Feedback
Altera Corporation
5-134
QII5V1
2014.12.15
load_system
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-85
• save_system on page 5-140
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
lock_avalon_base_address
5-135
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-81
• auto_assign_system_base_addresses on page 5-82
• unlock_avalon_base_address on page 5-151
Creating a System With Qsys
Send Feedback
Altera Corporation
5-136
remove_connection
QII5V1
2014.12.15
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-77
• get_connections on page 5-100
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
remove_dangling_connections
5-137
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
Creating a System With Qsys
Send Feedback
Altera Corporation
5-138
remove_instance
QII5V1
2014.12.15
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-78
• get_instances on page 5-120
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
remove_interface
5-139
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-79
• get_interfaces on page 5-127
Creating a System With Qsys
Send Feedback
Altera Corporation
5-140
save_system
QII5V1
2014.12.15
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
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
send_message
5-141
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-163
Creating a System With Qsys
Send Feedback
Altera Corporation
5-142
QII5V1
2014.12.15
set_connection_parameter_value
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-96
• get_connection_parameters on page 5-97
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
set_instance_parameter_value
5-143
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-115
• get_instance_parameter_property on page 5-114
Creating a System With Qsys
Send Feedback
Altera Corporation
5-144
set_instance_property
QII5V1
2014.12.15
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-116
• get_instance_property on page 5-119
• Instance Properties on page 5-161
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
set_interconnect_requirement
5-145
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
Creating a System With Qsys
Send Feedback
Altera Corporation
5-146
QII5V1
2014.12.15
set_interface_property
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
•
•
•
•
Altera Corporation
add_interface on page 5-79
get_interface_properties on page 5-125
get_interface_property on page 5-126
Interface Properties on page 5-162
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
set_module_property
5-147
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-128
• get_module_property on page 5-129
• Module Properties on page 5-164
Creating a System With Qsys
Send Feedback
Altera Corporation
5-148
set_project_property
QII5V1
2014.12.15
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
•
•
•
•
•
•
Altera Corporation
get_project_properties on page 5-132
set_project_property on page 5-148
Project Properties on page 5-171
get_project_properties on page 5-132
get_project_property on page 5-133
Project Properties on page 5-171
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
set_use_testbench_naming_pattern
5-149
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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-150
QII5V1
2014.12.15
set_validation_property
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-155
• Validation Properties on page 5-175
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
unlock_avalon_base_address
5-151
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-81
• auto_assign_system_base_addresses on page 5-82
• lock_avalon_base_address on page 5-135
Creating a System With Qsys
Send Feedback
Altera Corporation
5-152
validate_connection
QII5V1
2014.12.15
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-153
• validate_instance_interface on page 5-154
• validate_system on page 5-155
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
validate_instance
5-153
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-152
• validate_instance_interface on page 5-154
• validate_system on page 5-155
Creating a System With Qsys
Send Feedback
Altera Corporation
5-154
validate_instance_interface
QII5V1
2014.12.15
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-152
• validate_instance on page 5-153
• validate_system on page 5-155
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
validate_system
5-155
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-152
• validate_instance on page 5-153
• validate_instance_interface on page 5-154
Creating a System With Qsys
Send Feedback
Altera Corporation
5-156
Qsys Scripting Property Reference
QII5V1
2014.12.15
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-157
Design Environment Type Properties on page 5-158
Direction Properties on page 5-159
Element Properties on page 5-160
Instance Properties on page 5-161
Interface Properties on page 5-162
Message Levels Properties on page 5-163
Module Properties on page 5-164
Parameter Properties on page 5-165
Parameter Status Properties on page 5-168
Parameter Type Properties on page 5-169
Port Properties on page 5-170
Project Properties on page 5-171
System Info Type Properties on page 5-172
Units Properties on page 5-174
Validation Properties on page 5-175
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Connection Properties
5-157
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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-158
QII5V1
2014.12.15
Design Environment Type Properties
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.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Direction Properties
5-159
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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-160
QII5V1
2014.12.15
Element Properties
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
Altera Corporation
The version number of the instance, interface or connection, for example,
14.0.
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Instance Properties
5-161
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.
NAME
Creating a System With Qsys
Send Feedback
Altera Corporation
5-162
QII5V1
2014.12.15
Interface Properties
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
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Message Levels Properties
5-163
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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-164
QII5V1
2014.12.15
Module Properties
Module Properties
Type
Name
Description
String
GENERATION_ID
The generation ID for the system.
String
NAME
The name of the instance.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Parameter Properties
5-165
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 re-analyzes 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
Creating a System With Qsys
Send Feedback
Provides a hint about how to display a property.
Altera Corporation
5-166
QII5V1
2014.12.15
Parameter Properties
Type
Name
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 greyed 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.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Parameter Properties
Type
String
Name
WIDTH
5-167
Description
Indicates the width of the logic vector for the STD_LOGIC_VECTOR
parameter.
Related Information
• System Info Type Properties on page 5-172
• Parameter Type Properties on page 5-169
• Units Properties on page 5-174
Creating a System With Qsys
Send Feedback
Altera Corporation
5-168
QII5V1
2014.12.15
Parameter Status Properties
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.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Parameter Type Properties
5-169
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.)
Creating a System With Qsys
Send Feedback
Altera Corporation
5-170
QII5V1
2014.12.15
Port Properties
Port Properties
Type
Name
Description
(various) DIRECTION The direction of the signal. Refer to Direction Properties.
String
ROLE
Integer
WIDTH
Altera Corporation
The type of the signal. Each interface type defines a set of interface types for its
ports.
The width of the signal in bits.
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Project Properties
5-171
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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-172
QII5V1
2014.12.15
System Info Type Properties
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
Altera Corporation
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.
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
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
5-173
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-158
• Avalon Interface Specifications
• Qsys Interconnect on page 7-1
Creating a System With Qsys
Send Feedback
Altera Corporation
5-174
QII5V1
2014.12.15
Units Properties
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.
Altera Corporation
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Validation Properties
5-175
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.
Creating a System With Qsys
Send Feedback
Altera Corporation
5-176
QII5V1
2014.12.15
Document Revision History
Document Revision History
The table below indicates edits made to the Creating a System With Qsys content since its creation.
Table 5-17: Document Revision History
Date
Version
Changes
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.
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.
Altera Corporation
Create and Manage Hierarchical Qsys Systems.
Schematic tab.
View and Filter Clock and Reset Domains.
File > Recent Projects menu item.
Updated example: Hieratical System Using Instance
Parameters
Creating a System With Qsys
Send Feedback
QII5V1
2014.12.15
Document Revision History
Date
Version
5-177
Changes
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
Creating a System With Qsys
Send Feedback
Altera Corporation
Creating Qsys Components
6
2014.06.30
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.
© 2014 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
2014.06.30
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 or 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
2014.06.30
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
• Creating a Composed Component or Subsystem on page 6-28
• Adding 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
2014.06.30
Upgrading 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>.
Upgrading 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
Life Cycle of an IPComponent
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
2014.06.30
Creating Qsys Components in the 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.
Creating Qsys Components in the 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 the _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
Saving a Component and Creating an _hw.tcl File
QII5V1
2014.06.30
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 component 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.
Related Information
• Component Interface Tcl Reference on page 9-1
Saving a Component and Creating an _hw.tcl File
You save a component by clicking Finish in the Component Editor. The Component Editor saves the
component to a file with the file name <component_name> _hw.tcl.
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 publish component information for use by
software, such as a 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
Editing a Component with the Component Editor
In Qsys, you make changes to a component by right-clicking the component in the System Contents view,
and then clicking Edit. After making changes, click Finish to save the changes to the _hw.tcl file. You can
open the _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
top-level module, you must edit the component to reflect the changes you made to the HDL.
Related Information
Creating Qsys Components
Specifying Basic Component Information
The Component Type tab in the Component Editor allows you to specify the following information
about the component:
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2014.06.30
Specifying Basic Component Information
6-7
• 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.
Creating Qsys Components
Send Feedback
Altera Corporation
6-8
QII5V1
2014.06.30
Specifying Basic Component Information
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-1: _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
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
Altera Corporation
NAME demo_axi_memory
VERSION 1.0
GROUP "My Components"
AUTHOR Altera
DISPLAY_NAME "Demo AXI Memory"
Creating Qsys Components
Send Feedback
QII5V1
2014.06.30
Specifying Files for Synthesis and Simulation
6-9
Related Information
• Component Interface Tcl Reference on page 9-1
Specifying Files for Synthesis and Simulation
The Files tab in the Component Editor allows you to specify files for synthesis and simulation. If you
already have HDL code that describes the Qsys component that you want to create, you can specify the
files on the Files tab. If you have not yet created the HDL code that describes the component, but you
have identified the signals and parameters that you want in the component, you can use the Files tab to
create a top-level HDL template file. The Component Editor generates the appropriate _hw.tcl commands
to specify the files. You can also write your own hw.tcl file with the same commands, if you are not using
the Component Editor.
A component uses filesets to specify the different sets of files that can be generated 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 a _hw.tcl file, you add a fileset to a component with the add_fileset command. You then list specific
files with the add_fileset_file command, which adds the specified files to the most recently declared
fileset. The add_fileset_property command allows you to add properties such as TOP_LEVEL, which
specifies the top-level HDL module for the component.
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.
Specifying HDL Files for Synthesis
In the Component Editor, you can add HDL files and other support files that should be included when
this component is created to the list of Synthesis Files by clicking +, and then selecting the files in the
Open dialog box.
A component must specify an HDL file as the top-level file, which 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.
Creating Qsys Components
Send Feedback
Altera Corporation
6-10
QII5V1
2014.06.30
Creating a New HDL File for Synthesis
Figure 6-2: Using HDL Files to Define a Component
In the Synthesis Files section on the Files tab, the demo_axi_memory.sv file is selected as the top-level
file for the component.
Creating a New HDL File for Synthesis
If you do not already have an HDL implementation of the component, you can use the Component Editor
to define the component, and then create a simple top-level synthesis file containing the signals and
parameters for the component. You can then edit this HDL file to add the logic that directs the
component's behavior.
To begin, you first specify the information about the component on the Parameters, Signals, and
Interfaces tabs. Then, you return to the Files tab to create an HDL file by clicking Create Synthesis File
from Signals. The Component Editor creates an HDL file from the specified parameters and signals.
Analyzing Synthesis Files
After the top-level HDL file is specified in the 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 Toplevel Module list.
Once analysis is complete and the top-level module is selected, the parameters and signals found in the
top-level module are used as the parameters and signals for the component, and you can view them on the
Parameters and Signals 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
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2014.06.30
Naming HDL Signals for Automatic Interface and Type Recognition
6-11
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 Component Editor is launched and 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-2: _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
add_fileset_file single_clk_ram.v VERILOG PATH single_clk_ram.v
Related Information
Specifying HDL Files for Synthesis on page 6-9
Component Interface Tcl Reference on page 9-1
Naming HDL Signals for Automatic Interface and Type Recognition
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 this auto-recognition feature, 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 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
Creating Qsys Components
Send Feedback
Altera Corporation
6-12
QII5V1
2014.06.30
Specifying Files for Simulation
Interface Prefix
Interface Type
axm
AXI master
axs
AXI slave
apm
APB master
aps
APB slave
coe
Conduit
csi
Clock Sink (input)
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
Specifying Files for Simulation
To support Qsys system generation for simulation, a component must specify the VHDL or Verilog
simulation files. Simulation files are generated when a user adds the component to a Qsys system and
chooses 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 in the
Component Editor, on the Files tab, click Copy From Synthesis Files to copy the list of synthesis files to
the Verilog Simulation Files or VHDL Simulation Files lists.
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2014.06.30
Specifying Files for Simulation
6-13
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.
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.
Figure 6-3: Specifying the Simulation Output Files on the Files Tab
Example 6-3: _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
Creating Qsys Components
Send Feedback
Altera Corporation
6-14
QII5V1
2014.06.30
Including Internal Register Map Description in the .svd for Slave Interfaces
Connected to an HPS Component
add_fileset_file verbosity_pkg.sv SYSTEM_VERILOG PATH \
verification_lib/verbosity_pkg.sv
Related Information
• Component Interface Tcl Reference on page 9-1
Including 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-4: 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
Specifying Component Parameters
Components can include parameterized HDL, which allows 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 many different systems, each with unique
parameters values.
The Parameters tab in the Component Editor 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 the parameter is displayed and used. You can also specify a range of allowed
values that are checked during the 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.
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2014.06.30
Specifying Component Parameters
6-15
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-16
QII5V1
2014.06.30
Specifying Component Parameters
Figure 6-4: Parameters Tab in the 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-5: _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
2014.06.30
Allowed Ranges Parameter Property
6-17
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
Related Information
• Component Interface Tcl Reference on page 9-1
Allowed Ranges Parameter Property
In a component's hw.tcl file, you can specify valid ranges for parameters. In 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.
Creating Qsys Components
Send Feedback
Altera Corporation
6-18
QII5V1
2014.06.30
Types of Parameters
Table 6-3: ALLOWED_RANGES Property Examples
ALLOWED_RANGES
Meaning
{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
Declaring Parameters with Custom _hw.tcl Commands on page 6-19
Types of Parameters
Qsys uses the following parameter types: user parameters, system information parameters, and derived
parameters.
User Parameters on page 6-18
System Information Parameters on page 6-18
Derived Parameters on page 6-19
Related Information
Declaring Parameters with Custom _hw.tcl Commands on page 6-19
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.
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.
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>
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2014.06.30
Derived Parameters
6-19
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
Declaring Parameters with Custom _hw.tcl Commands on page 6-19
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.
Declaring 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-6: 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 \
"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
Creating Qsys Components
Send Feedback
Altera Corporation
6-20
Declaring Parameters with Custom _hw.tcl Commands
QII5V1
2014.06.30
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"
...
Figure 6-5: Resulting Parameter Editor GUI from Parameter Declarations
Related Information
Controlling Interfaces Dynamically with an Elaboration Callback on page 6-26
Component Interface Tcl Reference on page 9-1
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2014.06.30
Validating Parameter Values with a Validation Callback
6-21
Validating 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-7: 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
Specifying Interface and Signal Types
The Signals tab in the Components Editor allows you to specify the interface and signal type of each
signal in the component. When you add HDL files to the Synthesis Files table on the Files tab, and then
click Analyze Synthesis Files, the signals on the top-level module appear on the Signals tab.
If you have not yet created your top-level HDL file, you can click Add Signal to specify each top-level
signal in the component. For each signal that you add, you must provide the appropriate values in the
Name, Interface, Signal Type, Width, and Direction columns. You can use the error and warning
messages at the bottom of the window to guide your selections. You can edit the signal name by doubleclicking the Name column, and then typing the new name.
After you have analyzed 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 tab. To change the signals, edit your HDL source, and
then click Generate Synthesis File from Signals.
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 signal changes, and then
re-analyze the top-level synthesis file.
Creating Qsys Components
Send Feedback
Altera Corporation
6-22
Adding Interfaces and Managing Interface Settings
QII5V1
2014.06.30
The Interface column allows you assign a signal to an interface. Each signal must belong to an interface
and be assigned a legal signal type for that interface. To create a new interface of a specific type, select new
<interface type> from the list; this new interface then become available in the list for subsequent signal
assignments. You can highlight all of the signals in an interface and then select an Interface from the list
to apply the Interface name to each signal in the interface.
You edit the interface name on the Interface tab; you cannot edit the interface name on the Signals tab.
Figure 6-6: Signals Tab in the Qsys Components Editor
Related Information
Adding Interfaces and Managing Interface Settings on page 6-22
Component Interface Tcl Reference on page 9-1
Adding Interfaces and Managing Interface Settings
The Interfaces tab in the Component Editor allows you to manage settings for each interface of the
component. The interface name appears on the Signals tab, and in the Qsys System Contents tab when
the component is added to a system.
You can configure the type and properties of each interface. Some interfaces display waveforms that
illustrate the timing for the interface. If you update timing parameters, the waveforms automatically
update.
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2014.06.30
Adding Interfaces and Managing Interface Settings
6-23
You add additional interfaces by clicking Add Interface, and then you must specify the signals for the
added interface on the Signals tab. You can remove interfaces that have no assigned signals by clicking
Remove Interfaces With No Signals.
Figure 6-7: Avalon Streaming Source Interface on the Interfaces Tab
Example 6-8: _hw.tcl Created from Entries in the Interface Tab
Each interface is created with the add_interface command. You specify the properties of each
interface with the set_interface_property command. The interface's signals are specified with
the add_interface_port command.
#
# connection point clock
#
Creating Qsys Components
Send Feedback
Altera Corporation
6-24
QII5V1
2014.06.30
Adding Interfaces and Managing Interface Settings
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
Table 6-4: 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
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2014.06.30
Creating Custom _hw.tcl Interface Settings and Properties
AXI Master Parameters
6-25
AXI Slave Parameters
readDataReorderingDepth
Related Information
• Component Interface Tcl Reference on page 9-1
Creating Custom _hw.tcl Interface Settings and Properties
Example 6-9: Clock, Reset, AXI Slave, and Avalon Streaming Interfaces Using Variables
The clock, reset, AXI slave, and Avalon streaming interfaces use variables for the interface names
to make the file easier to read and update. The interface declaration statement includes the name,
type, and direction of the interface, as well as the associated clock and reset interfaces. Also in the
example below, some of the AXI memory signals use parameters to specify their width.
set CLOCK_INTERFACE "clk"
add_interface $CLOCK_INTERFACE clock end
add_interface_port $CLOCK_INTERFACE clk clk Input 1
set RESET_INTERFACE "reset"
add_interface $RESET_INTERFACE reset end
set_interface_property $RESET_INTERFACE associatedClock clk
set_interface_property $RESET_INTERFACE synchronousEdges DEASSERT
add_interface_port reset reset_n reset_n Input 1
set SLAVE_INTERFACE "slave"
add_interface $SLAVE_INTERFACE axi end
set_interface_property $SLAVE_INTERFACE associatedClock "clk"
set_interface_property $SLAVE_INTERFACE associatedReset "reset"
set_interface_property $SLAVE_INTERFACE \
readAcceptanceCapability 1
...
add_interface_port $SLAVE_INTERFACE axs_wdata wdata \
Input AXI_DATA_W
add_interface_port $SLAVE_INTERFACE axs_wstrb wstrb \
Input AXI_NUMBYTES
add_interface_port $SLAVE_INTERFACE axs_wlast wlast Input 1
...
set STREAMING_INTERFACE "streaming"
add_interface $STREAMING_INTERFACE avalon_streaming start
set_interface_property $STREAMING_INTERFACE associatedClock "clk"
...
add_interface_port $STREAMING_INTERFACE aso_data data Output 8
add_interface_port $STREAMING_INTERFACE aso_valid valid Output 1
add_interface_port $STREAMING_INTERFACE aso_ready ready Input 1
Related Information
• Component Interface Tcl Reference on page 9-1
Creating Qsys Components
Send Feedback
Altera Corporation
6-26
QII5V1
2014.06.30
Controlling Interfaces Dynamically with an Elaboration Callback
Controlling 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-10: 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 on page 6-25
• Validating Parameter Values with a Validation Callback on page 6-21
• Component Interface Tcl Reference on page 9-1
Controlling 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-11: 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
2014.06.30
Controlling 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
2014.06.30
Creating 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
Specifying Files for Synthesis and Simulation on page 6-9
Component Interface Tcl Reference on page 9-1
Creating 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
2014.06.30
6-29
Creating a Composed Component or Subsystem
Figure 6-8: 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-12: 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
2014.06.30
Creating a Component With Differing Structural Qsys View and Generated 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
Creating a Component With Differing Structural Qsys View and
Generated 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-13: 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
2014.06.30
Adding 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
Creating a Composed Component or Subsystem on page 6-28
Adding 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
2014.06.30
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-14: 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-15: 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
2014.06.30
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 runtime 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
2014.06.30
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-16: 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
2014.06.30
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-17: 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
Controlling File Generation Dynamically with Parameters and a Fileset Callback on page 6-26
Creating Qsys Components
Send Feedback
Altera Corporation
6-36
QII5V1
2014.06.30
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
The table below indicates edits made to the Creating Qsys Components content since its creation.
Table 6-5: Document Revision History
Date
Version
Changes
December 2014
14.1.0
• Note added about the order
in which to add simulation
files: Specifying Files for
Simulation.
November 2013
13.1.0
• add_hdl_instance
• Added Creating a Component
With Differing Structural
Qsys View and Generated
Output Files.
May 2013
13.0.0
• Consolidated content from
other Qsys chapters.
• Added Upgrading IP
Components to the Latest
Version.
• Updated for AMBA APB
support.
Altera Corporation
Creating Qsys Components
Send Feedback
QII5V1
2014.06.30
Document Revision History
Date
Version
6-37
Changes
November 2012
12.1.0
• Added AMBA AXI4 support.
• Added the demo_axi_
memory example with screen
shots and example _hw.tcl
code.
June 2012
12.0.0
• Added new tab structure for
the Component Editor.
• Added AMBA AXI3 support.
November 2011
11.1.0
Template update.
May 2011
11.0.0
• Removed beta status.
• Added Avalon Tri-state
Conduit (Avalon-TC)
interface type.
• Added many interface
templates for Nios custom
instructions and Avalon-TC
interfaces.
December 2010
10.1.0
Initial release.
For previous versions of the Quartus II Handbook, refer to the Quartus II Handbook Archive.
Related Information
Quartus II Handbook Archive
Creating Qsys Components
Send Feedback
Altera Corporation
Qsys Interconnect
7
2014.12.15
QII5V1
Subscribe
Send Feedback
Qsys interconnect is a high-bandwidth structure that allows you to connect IP components to other IP
components with various interfaces.
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.
Note: The video, AMBA AXI and Altera Avalon Interoperation Using Qsys, describes seamless integration
of IP components using the AMBA AXI interface, and the Altera Avalon interface.
Related Information
•
•
•
•
•
•
Avalon Interface Specifications
AMBA Specifications
Creating a System with Qsys on page 5-1
Creating Qsys Components on page 6-1
Qsys System Design Components on page 10-1
AMBA AXI and Altera Avalon Interoperation Using Qsys
Memory-Mapped Interfaces
Qsys supports the implementation of memory-mapped interfaces for Avalon, AXI, and APB protocols.
Qsys interconnect transmits memory-mapped transactions between masters and slaves in packets. The
command network transports read and write packets from master interfaces to slave interfaces. The
response network transports response packets from slave interfaces to master interfaces.
For each component interface, Qsys interconnect manages memory-mapped transfers and interacts with
signals on the connected interface. Master and slave interfaces can implement different signals based on
interface parameterizations, and Qsys interconnect provides any necessary adaptation between them. In
the path between master and slaves, Qsys interconnect may introduce registers for timing synchroniza‐
tion, finite state machines for event sequencing, or nothing at all, depending on the services required by
the interfaces.
© 2014 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
7-2
Memory-Mapped Interfaces
QII5V1
2014.12.15
Qsys interconnect supports the following implementation scenarios:
• Any number of components with master and slave interfaces. The master-to-slave relationship can be
one-to-one, one-to-many, many-to-one, or many-to-many.
• Masters and slaves of different data widths.
• Masters and slaves operating in different clock domains.
• IP Components with different interface properties and signals. Qsys adapts the component interfaces
so that interfaces with the following differences can be connected:
• Avalon and AXI interfaces that use active-high and active-low signaling. AXI signals are active
high, except for the reset signal.
• Interfaces with different burst characteristics.
• Interfaces with different latencies.
• Interfaces with different data widths.
• Interfaces with different optional interface signals.
Note: AXI3/4 to AXI3/4 interface connections declare a fixed set of signals with variable latency.
As a result, there is no need for adapting between active-low and active-high signaling, burst
characteristics, different latencies, or port signatures. Some adaptation may be necessary
between Avalon interfaces.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Memory-Mapped Interfaces
7-3
Figure 7-1: Qsys interconnect for an Avalon-MM System with Multiple Masters
In this example, there are two components mastering the system, a processor and a DMA controller, each
with two master interfaces. The masters connect through the Qsys interconnect to several slaves in the
Qsys system. The dark blue blocks represent interconnect components. The dark grey boxes indicate
items outside of the Qsys system and the Quartus II software design, and show how component interfaces
can be exported and connected to external devices.
PCB
Instruction
M
Master
Network
Interface
S
Control
Qsys Design
in Altera FPGA
Processor
DMA Controller
Data
M
Master
Network
Interface
Interconnect
Read
M
Write
M
Master
Network
Interface
Master
Network
Interface
Response Switch
(Avalon-ST)
Command Switch
(Avalon-ST)
Slave
Network
Interface
Slave
Network
Interface
Slave
Network
Interface
Slave
Network
Interface
S
S
S
S
S
Data
Memory
DDR3
Controller
Tri-State
Controller
Tri-State
Conduit
TCM
TCM
TCS
TCS
Instruction
Memory
Master Command Connectivity
Slave Response Connectivity
Interface to Off-Chip Device
M
Avalon-MM Master Interface
S
Avalon-MM Slave Interface
TCM Avalon Tri-State Conduit Master
TCS Avalon Tri-State Conduit Slave
Qsys Interconnect
Send Feedback
Tri-State Conduit
Pin Sharer & Bridge
DDR3 Chip
S
S
Ethernet
MAC/PHY
Chip
Flash
Memory
Chip
Altera Corporation
7-4
QII5V1
2014.12.15
Qsys Packet Format
Qsys Packet Format
The Qsys packet format supports Avalon, AXI, and APB transactions. Memory-mapped transactions
between masters and slaves are encapsulated in Qsys packets. For Avalon systems without AXI or APB
interfaces, some fields are ignored or removed.
Qsys Packet Format
Table 7-1: Qsys Packet Format for Memory-Mapped Master and Slave Interfaces
The fields of the Qsys packet format are of variable length to minimize resource usage. However, if the majority of
components in a design have a single data width, for example 32-bits, and a single component has a data width of
64-bits, Qsys inserts a width adapter to accommodate 64-bit transfers.
Command
Description
Address
Specifies the byte address for the lowest byte in the current cycle. There are no
restrictions on address alignment.
Size
Encodes the run-time size of the transaction.
In conjunction with address, this field describes the segment of the payload that
contains valid data for a beat within the packet.
Address Sideband
Carries “address” sideband signals. The interconnect passes this field from
master to slave. This field is valid for each beat in a packet, even though it is only
produced and consumed by an address cycle.
Up to 8-bit sideband signals are supported for both read and write address
channels.
Cache
Carries the AXI cache signals.
Transaction
(Exclusive)
Indicates whether the transaction has exclusive access.
Transaction
(Posted)
Used to indicate non-posted writes (writes that require responses).
Data
For command packets, carries the data to be written. For read response packets,
carries the data that has been read.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Qsys Packet Format
Command
Byteenable
Description
Specifies which symbols are valid. AXI can issue or accept any byteenable
pattern. For compatibility with Avalon, Altera recommends that you use the
following legal values for 32-bit data transactions between Avalon masters and
slaves:
•
•
•
•
•
•
•
1111—Writes full 32 bits
0011—Writes lower 2 bytes
1100—Writes upper 2 bytes
0001—Writes byte 0 only
0010—Writes byte 1 only
0100—Writes byte 2 only
1000—Writes byte 3 only
Source_ID
The ID of the master or slave that initiated the command or response.
Destination_ID
The ID of the master or slave to which the command or response is directed.
Response
Carries the AXI response signals.
Thread ID
Carries the AXI transaction ID values.
Byte count
The number of bytes remaining in the transaction, including this beat. Number
of bytes requested by the packet.
Qsys Interconnect
Send Feedback
7-5
Altera Corporation
7-6
QII5V1
2014.12.15
Qsys Packet Format
Command
Burstwrap
Description
The burstwrap value specifies the wrapping behavior of the current burst. The
burstwrap value is of the form 2<n> -1. The following types are defined:
• Variable wrap–Variable wrap bursts can wrap at any integer power of 2 value.
When the burst reaches the wrap boundary, it wraps back to the previous
burst boundary so that only the low order bits are used for addressing. For
example, a burst starting at address 0x1C, with a burst wrap boundary of 32
bytes and a burst size of 20 bytes, would write to addresses 0x1C, 0x0, 0x4,
0x8, and 0xC.
• For a burst wrap boundary of size <m>, Burstwrap = <m> - 1, or for this
case Burstwrap = (32 - 1) = 31 which is 25 -1.
• For AXI masters, the burstwrap boundary value (m) is based on the different
AXBURST:
• Burstwrap set to all 1’s. For example, for a 6-bit burstwrap, burstwrap is
6'b111111.
• For WRAP bursts, burstwrap = AXLEN * size – 1.
• For FIXED bursts, burstwrap = size – 1.
• Sequential bursts increment the address for each transfer in the burst. For
sequential bursts, the Burstwrap field is set to all 1s. For example, with a
6-bit Burstwrap field, the value for a sequential burst is 6'b111111 or 63,
which is 26 - 1.
For Avalon masters, Qsys adaptation logic sets a hardwired value for the
burstwrap field, according the declared master burst properties. For example, for
a master that declares sequential bursting, the burstwrap field is set to ones.
Similarly, masters that declare burst have their burstwrap field set to the
appropriate constant value.
AXI masters choose their burst type at run-time, depending on the value of the
AW or ARBURST signal. The interconnect calculates the burstwrap value at run-
time for AXI masters.
Protection
Access level protection. When the lowest bit is 0, the packet has normal access.
When the lowest bit is 1, the packet has privileged access. For Avalon-MM
interfaces, this field maps directly to the privileged access signal, which allows an
memory-mapped master to write to an on-chip memory ROM instance. The
other bits in this field support AXI secure accesses and uses the same encoding,
as described in the AXI specification.
QoS
QoS (Quality of Service Signaling) is a 4-bit field that is part of the AXI4
interface that carries QoS information for the packet from the AXI master to the
AXI slave.
Transactions from AXI3 and Avalon masters have the default value 4'b0000,
that indicates that they are not participating in the QoS scheme. QoS values are
dropped for slaves that do not support QoS.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Transaction Types for Memory-Mapped Interfaces
Command
Data sideband
7-7
Description
Carries data sideband signals for the packet. On a write command, the data
sideband directly maps to WUSER. On a read response, the data sideband directly
maps to RUSER. On a write response, the data sideband directly maps to BUSER.
Transaction Types for Memory-Mapped Interfaces
Table 7-2: Transaction Types for Memory-Mapped Interfaces
The table below describes the information that each bit transports in the packet format's transaction field.
Bit
Name
Definition
0
PKT_TRANS_READ
When asserted, indicates a read transaction.
1
PKT_TRANS_COMPRESSED_READ
For read transactions, specifies whether or not the read
command can be expressed in a single cycle, that is
whether or not it has all byteenables asserted on every
cycle.
2
PKT_TRANS_WRITE
When asserted, indicates a write transaction.
3
PKT_TRANS_POSTED
When asserted, no response is required.
4
PKT_TRANS_LOCK
When asserted, indicates arbitration is locked. Applies to
write packets.
Qsys Transformations
The memory-mapped master and slave components connect to network interface modules that
encapsulate the transaction in Avalon-ST packets. The memory-mapped interfaces have no information
about the encapsulation or the function of the layer transporting the packets. The interfaces operate in
accordance with memory-mapped protocol and use the read and write signals and transfers.
Qsys Interconnect
Send Feedback
Altera Corporation
7-8
QII5V1
2014.12.15
Interconnect Domains
Figure 7-2: Transformation when Generating a System with Memory-Mapped and Slave Components
Qsys components that implement the blocks appear shaded.
Avalon-MM or AXI
Avalon-ST
Master
Interface
Master
Network
Interface
Master
Interface
Master
Network
Interface
Avalon-ST
Network
(Command)
Avalon-ST
Network
(Response)
Avalon-MM or AXI
Slave
Network
Interface
Slave
Interface
Slave
Network
Interface
Slave
Interface
Master Command Connectivity
Slave Response Connectivity
Related Information
• Master Network Interfaces on page 7-11
• Slave Network Interfaces on page 7-13
Interconnect Domains
An interconnect domain is a group of connected memory-mapped masters and slaves that share the same
interconnect. The components in a single interconnect domain share the same packet format.
Using One Domain with Width Adaptation
When one of the masters in a system connects to all of the slaves, Qsys creates a single domain with two
packet formats: one with 64-bit data, and one with 16-bit data. A width adapter manages accesses between
the 16-bit master and 64-bit slaves.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Using One Domain with Width Adaptation
7-9
Figure 7-3: One Domain with 1:4 and 4:1 Width Adapters
In this system example, there are two 64-bit masters that access two 64-bit slaves. It also includes one 16bit master, that accesses two 16-bit slaves and two 64-bit slaves. The 16-bit Avalon master connects
through a 1:4 adapter, then a 4:1 adapter to reach its 16-bit slaves.
Single Domain with 1:4 & 4:1 Width Adapters
64-Bit
Avalon-MM
Master
M
1:4
S
64-Bit
Avalon-MM
Slave
Qsys Interconnect
Send Feedback
64-Bit
Avalon-MM
Master
M
4:1
16-Bit
Avalon-MM
Master
M
S
S
16-Bit
Avalon-MM
Slave
16-Bit
Avalon-MM
Slave
S
64-Bit
Avalon-MM
Slave
Altera Corporation
7-10
QII5V1
2014.12.15
Using Two Separate Domains
Using Two Separate Domains
Figure 7-4: Two Separate Domains
In this system example, Qsys uses two separate domains. The first domain includes two 64-bit masters
connected to two 64-bit slaves. A second domain includes one 16-bit master connected to two 16-bit
slaves. Because the interfaces in Domain 1 and Domain 2 do not share any connections, Qsys can
optimize the packet format for the two separate domains. In this example, the first domain uses a 64-bit
data width and the second domain uses 16-bit data.
Component 1
Component 2
64-bit
Avalon-MM
Master
64-bit
Avalon-MM
Master
16-bit
Avalon-MM
Master
M
M
M
Domain 1
Domain 2
S
S
S
S
64-bit
Avalon-MM
Slave
64-bit
Avalon-MM
Slave
16-bit
Avalon-MM
Slave
16-bit
Avalon-MM
Slave
Command Network
Altera Corporation
Response Network
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Master Network Interfaces
7-11
Master Network Interfaces
Figure 7-5: Avalon-MM Master Network Interface
Avalon network interfaces drive default values for the QoS and BUSER, WUSER, and RUSER packet fields in
the master agent, and drop the packet fields in the slave agent.
Note: The response signal from the Limiter to the Agent is optional.
Master Network Interface
Avalon-ST
Network
(Command)
Router
Master
Interface
Translator
Agent
response [1:0 ]
Limiter
Avalon-ST
Network
(Response)
Figure 7-6: AXI Master Network Interface
An AXI4 master supports INCR bursts up to 256 beats, QoS signals, and data sideband signals.
Master Network Interface
Read Command
Master
Interface
AXI
Translator
AXI
Master
Agent
Write Command
Router
Router
Limiter
Avalon-ST
Network
(Command)
Write Response
Read Response
Limiter
Avalon-ST
Network
(Response)
Note: For a complete definition of the optional read response signal, refer to Avalon Memory-Mapped
Interface Signal Types in the Avalon Interface Specifications.
Related Information
• Responses on page 7-24
• Avalon Interface Specifications
• Creating a System with Qsys on page 5-1
Qsys Interconnect
Send Feedback
Altera Corporation
7-12
QII5V1
2014.12.15
Avalon-MM Master Agent
Avalon-MM Master Agent
The Avalon-MM Master Agent translates Avalon-MM master transactions into Qsys command packets
and translates the Qsys Avalon-MM slave response packets into Avalon-MM responses.
Avalon-MM Master Translator
The Avalon-MM Master Translator interfaces with an Avalon-MM master component and converts the
Avalon-MM master interface to a simpler representation for use in Qsys.
The Avalon-MM Master translator performs the following functions:
•
•
•
•
•
•
Translates active-low signaling to active-high signaling
Inserts wait states to prevent an Avalon-MM master from reading invalid data
Translates word and symbol addresses
Translates word and symbol burst counts
Manages re-timing and re-sequencing bursts
Removes unnecessary address bits
AXI Master Agent
An AXI Master Agent accepts AXI commands and produces Qsys command packets. It also accepts Qsys
response packets and converts those into AXI responses. This component has separate packet channels
for read commands, write commands, read responses, and write responses. Avalon master agent drives
the QoS and BUSER, WUSER, and RUSER packet fields with default values AXQO and b0000, respectively.
Note: For signal descriptions, refer to Qsys Packet Format.
Related Information
Qsys Packet Format on page 7-4
AXI Translator
AXI4 allows some signals to be omitted from interfaces. The translator bridges between these
“incomplete” AXI4 interfaces and the “complete” AXI4 interface on the network interfaces.
The AXI translator is inserted for both AXI4 masters and slaves and performs the following functions:
• Matches ID widths between the master and slave in 1x1 systems.
• Drives default values as defined in the AMBA Protocol Specifications for missing signals.
• Performs lock transaction bit conversion when an AXI3 master connects to an AXI4 slave in 1x1
systems.
Related Information
AMBA Protocol Specifications
APB Master Agent
An APB master agent accepts APB commands and produces or generates Qsys command packets. It also
converts Qsys response packets to APB responses.
APB Slave Agent
An APB slave agent issues resulting transaction to the APB interface. It also accepts creates Qsys response
packets.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
APB Translator
7-13
APB Translator
An APB peripheral does not require pslverr signals to support additional signals for the APB debug
interface.
The APB translator is inserted for both the master and slave and performs the following functions:
• Sets the response value default to OKAY if the APB slave does not have a pslverr signal.
• Turns on or off additional signals between the APB debug interface, which is used with HPS (Altera
SoC’s Hard Processor System).
Memory-Mapped Router
The Memory-Mapped Router routes command packets from the master to the slave, and response packets
from the slave to the master. For master command packets, the router uses the address to set the
Destination_ID and Avalon-ST channel. For the slave response packet, the router uses the
Destination_ID to set the Avalon-ST channel. The demultiplexers use the Avalon-ST channel to route
the packet to the correct destination.
Memory-Mapped Traffic Limiter
The Memory-Mapped Traffic Limiter ensures the responses arrive in order. It prevents any command
from being sent if the response could conflict with the response for a command that has already been
issued. By guaranteeing in-order responses, the Traffic Limiter simplifies the response network.
Slave Network Interfaces
Figure 7-7: Avalon-MM Slave Network Interface
Slave Network Interface
Avalon-ST
Network
(Command)
Overflow Error
Command
Waitrequest
Agent
Avalon-ST
Network
(Response)
Qsys Interconnect
Send Feedback
Translator
Slave
Interface
Response
Altera Corporation
7-14
QII5V1
2014.12.15
Avalon-MM Slave Translator
Figure 7-8: AXI Slave Network Interface
An AXI4 slave supports up to 256 beat INCR bursts, QoS signals, and data sideband signals.
Network Interface
Avalon-ST
Network
(Command)
Write Command
Read Command
AXI
Agent
Avalon-ST
Network
(Response)
AXI
Translator
Slave
Interface
Write Response
Read Response
Avalon-MM Slave Translator
The Avalon-MM Slave Translator interfaces to an Avalon-MM slave component as the Avalon-MM Slave
Network Interface figure illustrates. It converts the Avalon-MM slave interface to a simplified
representation that the Qsys network can use.
An Avalon-MM Merlin Slave Translator performs the following functions:
• Drives the beginbursttransfer and byteenable signals.
• Supports Avalon-MM slaves that operate using fixed timing and or slaves that use the readdatavalid
signal to identify valid data.
• Translates the read, write, and chipselect signals into the representation that the Avalon-ST slave
response network uses.
• Converts active low signals to active high signals.
• Translates word and symbol addresses and burstcounts.
• Handles burstcount timing and sequencing.
• Removes unnecessary address bits.
Related Information
Slave Network Interfaces on page 7-13
AXI Translator
AXI4 allows some signals to be omitted from interfaces. The translator bridges between these
“incomplete” AXI4 interfaces and the “complete” AXI4 interface on the network interfaces.
The AXI translator is inserted for both AXI4 master and slave, and performs the following functions:
• Matches ID widths between master and slave in 1x1 systems.
• Drives default values as defined in the AMBA Protocol Specifications for missing signals.
• Performs lock transaction bit conversion when an AXI3 master connects to an AXI4 slave in 1x1
systems.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Wait State Insertion
7-15
Wait State Insertion
Wait states extend the duration of a transfer by one or more cycles. Wait state insertion logic
accommodates the timing needs of each slave, and causes the master to wait until the slave can proceed.
Qsys interconnect inserts wait states into a transfer when the target slave cannot respond in a single clock
cycle, as well as in cases when slave read and write signals have setup or hold time requirements.
Figure 7-9: Wait State Insertion Logic for One Master and One Slave
Wait state insertion logic is a small finate-state machine that translates control signal sequencing between
the slave side and the master side. Qsys interconnect can force a master to wait for the wait state needs of
a slave. For example, arbitration logic in a multi-master system. Qsys generates wait state insertion logic
based on the properties of all slaves in the system.
read/write
Master
Port
wait request
address
Wait-State
Insertion
Logic
read/write
Slave
Port
data
Avalon-MM Slave Agent
The Avalon-MM Slave Agent accepts command packets and issues the resulting transactions to the
Avalon interface. For pipelined slaves, an Avalon-ST FIFO stores information about pending transactions.
The size of this FIFO is the maximum number of pending responses that you specify when creating the
slave component. The Avalon-MM Slave Agent also backpressures the Avalon-MM master command
interface when the FIFO is full if the slave component includes the waitrequest signal.
AXI Slave Agent
An AXI Slave Agent works similar to a master agent in reverse. The AXI slave Agent accepts Qsys
command packets to create AXI commands, and accepts AXI responses to create Qsys response packets.
This component has separate packet channels for read commands, write commands, read responses, and
write responses.
Arbitration
When multiple masters contend for access to a slave, Qsys automatically inserts arbitration logic, which
grants access in fairness-based, round-robin order. You can alternatively choose to designate a slave as a
fixed priority arbitration slave, and then manually assign priorities in the Qsys GUI.
Round-Robin Arbitration
When multiple masters contend for access to a slave, Qsys automatically inserts arbitration logic which
grants access in fairness-based, round-robin order.
In a fairness-based arbitration protocol, each master has an integer value of transfer shares with respect to
a slave. One share represents permission to perform one transfer. The default arbitration scheme is equal
Qsys Interconnect
Send Feedback
Altera Corporation
7-16
Fairness-Based Shares
QII5V1
2014.12.15
share round-robin that grants equal, sequential access to all requesting masters. You can change the
arbitration scheme to weighted round-robin by specifying a relative number of arbitration shares to the
masters that access a particular slave. AXI slaves have separate arbitration for their independent read and
write channels, and the Arbitration Shares setting affects both the read and write arbitration. To display
arbitration settings, right-click an instance on the System Contents tab, and then click Show Arbitration
Shares.
Figure 7-10: Arbitration Shares in the Connections Column
Fairness-Based Shares
In a fairness-based arbitration scheme, each master-to-slave connection provides a transfer share count.
This count is a request for the arbiter to grant a specific number of transfers to this master before giving
control to a different master. One share represents permission to perform one transfer.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Round-Robin Scheduling
7-17
Figure 7-11: Arbitration of Continuous Transfer Requests from Two Masters
Consider a system with two masters connected to a single slave. Master 1 has its arbitration shares set to
three, and Master 2 has its arbitration shares set to four. Master 1 and Master 2 continuously attempt to
perform back-to-back transfers to the slave. The arbiter grants Master 1 access to the slave for three
transfers, and then grants Master 2 access to the slave for four transfers. This cycle repeats indefinitely.
The figure below describes the waveform for this scenario.
clk
M1_transfer_request
M1_waitrequest
M2_transfer_request
M2_waitrequest
Current_Master
Master 1
Master 2
Master 1
Master 2
Master 1
Figure 7-12: Arbitration of Two Masters with a Gap in Transfer Requests
If a master stops requesting transfers before it exhausts its shares, it forfeits all of its remaining shares, and
the arbiter grants access to another requesting master. After completing one transfer, Master 2 stops
requesting for one clock cycle. As a result, the arbiter grants access back to Master 1, which gets a
replenished supply of shares.
clk
M1_transfer_request
M1_waitrequest
M2_transfer_request
M2_waitrequest
Current_Master
Master 1
Master 2
Master 1
Master 2
Master 1
Master 2
Round-Robin Scheduling
When multiple masters contend for access to a slave, the arbiter grants shares in round-robin order. Qsys
includes only requesting masters in the arbitration for each slave transaction.
Memory-Mapped Arbiter
The input to the Memory-Mapped Arbiter is the command packet for all masters requesting access to a
particular slave. The arbiter outputs the channel number for the selected master. This channel number
controls the output of a multiplexer that selects the slave device. The figure below illustrates this logic.
Qsys Interconnect
Send Feedback
Altera Corporation
7-18
QII5V1
2014.12.15
Memory-Mapped Arbiter
Figure 7-13: Arbitration Logic
In this example, four Avalon-MM masters connect to four Avalon-MM slaves. In each cycle, an arbiter
positioned in front of each Avalon-MM slave selects among the requesting Avalon-MM masters.
Logic included in the Avalon-ST Command Network
Command
packet for
master 0
Command
packet for
master 1
Master 0
Arbiter
for
slave 0
Master 1
Selected request
Arbiter
Arbiter
for
for
slave
slave 11
Selected request
Master 2
Arbiter
for
slave 2
Command
packet for
master 2
Master 3
Command
packet for
master 3
Selected request
Arbiter
for
slave 3
Selected request
= Pipeline stage, masters 0-3
= Pipeline stage, selected request
Note: If you specify a Limit interconnect pipeline stages to parameter greater than zero, the output of
the Arbiter is registered. Registering this output reduces the amount of combinational logic
between the master and the interconnect, increasing the fMAX of the system.
Note: You can use the Memory-Mapped Arbiter for both round-robin and fixed priority arbitration.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Datapath Multiplexing Logic
7-19
Datapath Multiplexing Logic
Datapath multiplexing logic drives the writedata signal from the granted master to the selected slave,
and the readdata signal from the selected slave back to the requesting master. Qsys generates separate
datapath multiplexing logic for every master in the system (readdata), and for every slave in the system
(writedata). Qsys does not generate multiplexing logic if it is not needed.
Figure 7-14: Datapath Multiplexing Logic for One Master and Two Slaves
readdata1
address
Data
Path
Multiplexer
readdata
Slave
Port 1
writedata
Master
Port
control
Slave
Port 2
readdata2
Width Adaptation
Qsys width adaptation converts between Avalon memory-mapped master and slaves with different data
and byte enable widths, and manages the run-time size requirements of AXI. Width adaptation for AXI to
Avalon interfaces is also supported.
Memory-Mapped Width Adapter
The Memory-Mapped Width Adapter is used in the Avalon-ST domain and operates with information
contained in the packet format.
The memory-mapped width adapter accepts packets on its sink interface with one data width and
produces output packets on its source interface with a different data width. The ratio of the narrow data
width must be a power of two, such as 1:4, 1:8, and 1:16. The ratio of the wider data width to the narrower
width must also be a power of two, such as 4:1, 8:1, and 16:1 These output packets may have a different
size if the input size exceeds the output data bus width, or if data packing is enabled.
When the width adapter converts from narrow data to wide data, each input beat's data and byte enables
are copied to the appropriate segment of the wider output data and byte enables signals.
Qsys Interconnect
Send Feedback
Altera Corporation
7-20
QII5V1
2014.12.15
AXI Wide-to-Narrow Adaptation
Figure 7-15: Width Adapter Timing for a 4:1 Adapter
This adapter assumes that the field ordering of the input and output packets is the same, with the only
difference being the width of the data and accompanying byte enable fields. When the width adapter
converts from wide data to narrow data, the narrower data is transmitted over several beats. The first
output beat contains the lowest addressed segment of the input data and byte enables.
clock
addr_in[7:0]
Adapter
Input
byteenable_in[3:0]
wide_data[31:0]
addr_out[7:0]
Adapter
Output
08
C
AABBCCDD
08
09
0A
0B
byteenable_out[3:0]
0
0
1
1
narrow_data[7:0]
DD
CC
BB
AA
write
AXI Wide-to-Narrow Adaptation
For all cases of AXI wide-to-narrow adaptation, read data is re-packed to match the original size.
Responses are merged, with the following error precedence: DECERR, SLVERR, OKAY, and EXOKAY.
Table 7-3: AXI Wide-to-Narrow Adaptation (Downsizing)
Burst Type
Behavior
IncrementingInc If the transaction size is less than or equal to the output width, the burst is unmodified.
rementing
Otherwise, it is converted to an incrementing burst with a larger length and size equal
to the output width.
If the resulting burst is unsuitable for the slave, the burst is converted to multiple
sequential bursts of the largest allowable lengths. For example, for a 2:1 downsizing
ratio, an INCR9 burst is converted into INCR16 + INCR2 bursts. This is true if the
maximum burstcount a slave can accept is 16, which is the case for AXI3 slaves.
Avalon slaves have a maximum burstcount of 64.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
AXI Narrow-to-Wide Adaptation
Burst Type
Wrapping
7-21
Behavior
If the transaction size is less than or equal to the output width, the burst is unmodified.
Otherwise, it is converted to a wrapping burst with a larger length, with a size equal to
the output width.
If the resulting burst is unsuitable for the slave, the burst is converted to multiple
sequential bursts of the largest allowable lengths; respecting wrap boundaries. For
example, for a 2:1 downsizing ratio, a WRAP16 burst is converted into two or three INCR
bursts, depending on the address.
Fixed
If the transaction size is less than or equal to the output width, the burst is unmodified.
Otherwise, it is converted into repeated sequential bursts over the same addresses. For
example, for a 2:1 downsizing ratio, a FIXED single burst is converted into an INCR2
burst.
AXI Narrow-to-Wide Adaptation
Table 7-4: AXI Narrow-to-Wide Adaptation (Upsizing)
Burst Type
Behavior
Incrementing
The burst (and its response) passes through unmodified. Data and write strobes are
placed in the correct output segment.
Wrapping
The burst (and its response) passes through unmodified.
Fixed
The burst (and its response) passes through unmodified.
Burst Adapter
Qsys interconnect uses the memory-mapped burst adapter to accommodate the burst capabilities of each
interface in the system, including interfaces that do not support burst transfers.
The maximum burst length for each interface is a property of the interface and is independent of other
interfaces in the system. Therefore, a particular master may be capable of initiating a burst longer than a
slave’s maximum supported burst length. In this case, the burst adapter translates the large master burst
into smaller bursts, or into individual slave transfers if the slave does not support bursting. Until the
master completes the burst, arbiter logic prevents other masters from accessing the target slave. For
example, if a master initiates a burst of 16 transfers to a slave with maximum burst length of 8, the burst
adapter initiates 2 bursts of length 8 to the slave.
Avalon-MM and AXI burst transactions allow a master uninterrupted access to a slave for a specified
number of transfers. The master specifies the number of transfers when it initiates the burst. Once a burst
begins between a master and slave, arbiter logic is locked until the burst completes. For burst masters, the
length of the burst is the number of cycles that the master has access to the slave, and the selected arbitra‐
tion shares have no effect.
Note: AXI masters can issue burst types that Avalon cannot accept, for example, fixed bursts. In this case,
the burst adapter converts the fixed burst into a sequence of transactions to the same address.
Qsys Interconnect
Send Feedback
Altera Corporation
7-22
Burst Adapter Implementation Options
QII5V1
2014.12.15
Note: For AXI4 slaves, Qsys allows 256-beat INCR bursts. You must ensure that 256-beat narrow-sized
INCR bursts are shortened to 16-beat narrow-sized INCR bursts for AXI3 slaves.
Avalon-MM masters always issue addresses that are aligned to the size of the transfer. However, when
Qsys uses a narrow-to-wide width adaptation, the resulting address may be unaligned. For unaligned
addresses, the burst adapter issues the maximum sized bursts with appropriate byte enables. This brings
the burst-in-progress up to an aligned slave address. Then, it completes the burst on aligned addresses.
The burst adapter supports variable wrap or sequential burst types to accommodate different properties of
memory-mapped masters. Some bursting masters can issue more than one burst type.
Burst adaptation is available for Avalon to Avalon, Avalon to AXI, and AXI to Avalon, and AXI to AXI
connections. For information about AXI-to-AXI adaptation, refer to AXI Wide-to-Narrow Adaptation
Note: For AXI4 to AXI3 connections, Qsys follows an AXI4 256 burst length to AXI3 16 burst length.
Burst Adapter Implementation Options
Qsys automatically inserts burst adapters into your system depending on your master and slave
connections, and properties. You can select burst adapter implementation options on the Interconnect
Requirements tab.
To access the implementation options, you must select the Burst adapter implementation setting for the
$system identifier.
• 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.
Note: For more information about the Interconnect Requirements tab, refer to Creating a System with
Qsys.
Related Information
• Creating a System with Qsys on page 5-1
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Burst Adaptation: AXI to Avalon
7-23
Burst Adaptation: AXI to Avalon
Table 7-5: Burst Adaptation: AXI to Avalon
Entries specify the behavior when converting between AXI and Avalon burst types.
Burst Type
Incrementing
Behavior
Sequential Slave
Bursts that exceed slave_max_burst_length are converted to multiple
sequential bursts of a length less than or equal to the slave_max_burst_length.
Otherwise, the burst is unconverted. For example, for an Avalon slave with a
maximum burst length of 4, an INCR7 burst is converted to INCR4 + INCR3.
Wrapping Slave
Bursts that exceed the slave_max_burst_length are converted to multiple
sequential bursts of length less than or equal to the slave_max_burst_length.
Bursts that exceed the wrapping boundary are converted to multiple sequential
bursts that respect the slave's wrapping boundary.
Wrapping
Sequential Slave
A WRAP burst is converted to multiple sequential bursts. The sequential bursts
are less than or equal to the max_burst_length and respect the transaction's
wrapping boundary
Wrapping Slave
If the WRAP transaction's boundary matches the slave's boundary, then the
burst passes through. Otherwise, the burst is converted to sequential bursts that
respect both the transaction and slave wrap boundaries.
Fixed
Fixed bursts are converted to sequential bursts of length 1 that repeatedly access
the same address.
Narrow
All narrow-sized bursts are broken into multiple bursts of length 1.
Burst Adaptation: Avalon to AXI
Table 7-6: Burst Adaptation: Avalon to AXI
Entries specify the behavior when converting between Avalon and AXI burst types.
Burst Type
Sequential
Qsys Interconnect
Send Feedback
Definition
Bursts of length greater than16 are converted to multiple INCR bursts of a length
less than or equal to16. Bursts of length less than or equal to16 are not converted.
Altera Corporation
7-24
QII5V1
2014.12.15
Responses
Burst Type
Definition
Wrapping
Only Avalon masters with alwaysBurstMaxBurst = true are supported. The
WRAP burst is passed through if the length is less than or equal to16. Otherwise,
it is converted to two or more INCR bursts that respect the transaction's wrap
boundary.
GENERIC_CONVERTER
Controls all burst conversions with a single converter that is able to adapt all
incoming burst types. This results in an adapter that has smaller area, but lower
fMax.
Responses
Qsys merges write responses if a write is converted (burst adapted) into multiple bursts. Qsys requires
read response merging for a downsized (wide-to-narrow width adapted) read.
Qsys merges responses based on the following precedence rule:
DECERR > SLVERR > OKAY > EXOKAY
Figure 7-16: Mismatched Master and Slave Response Support
The Interconnect sends the slave response transaction back to the master that issues the transaction.
When there is a mismatch in response support between master and slave, the interconnect resolves the
transaction flow according to the following scenarios.
Slave with Response
Master with
Response
Interconnect delivers response
from the slave to the master.
Slave without Response
Interconnect delivers an OKAY
response to the master for
all reads.
Response merging or duplication
may be necessary for bus sizing.
Master without
Response
Master ignores responses from
the slave.
No need for responses. Master,
slave, and interconnect operate
without response support.
For the response case where the transaction violates security settings or uses an illegal address, the
interconnect routes the transactions to the default slave. For information about Qsys system security and
how to specify a default slave, refer to Creating a System with Qsys.
Note: For Avalon-MM slaves without the response signal, there is no way to notify a connected master
that a transaction has not completed successfully. As a result, the Qsys interconnect generates an
OKAY response on behalf of an Avalon-MM slave that does not have the response signal.
Related Information
Master Network Interfaces on page 7-11
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Qsys Address Decoding
7-25
Qsys Address Decoding
Address decoding logic forwards appropriate addresses to each slave.
Address decoding logic simplifies component design in the following ways:
• The interconnect selects a slave whenever it is being addressed by a master. Slave components do not
need to decode the address to determine when they are selected.
• Slave addresses are properly aligned to the slave interface.
• Changing the system memory map does not involve manually editing HDL.
Figure 7-17: Address Decoding for One Master and Two Slaves
In this example, Qsys generates separate address decoding logic for each master in a system. The address
decoding logic processes the difference between the master address width (<M> ) and the individual slave
address widths (<S >) and (<T >). The address decoding logic also maps only the necessary master address
bits to access words in each slave’s address space.
address [M..0]
Master
Port
Address
Decoding
Logic
read/write
address [S..0]
read/write
address [T..2]
Qsys Interconnect
Send Feedback
Slave
Port 1
(8-bit)
Slave
Port 2
(32-bit)
Altera Corporation
7-26
Avalon Streaming Interfaces
QII5V1
2014.12.15
Figure 7-18: Address Decoding Base Settings
Qsys controls the base addresses with the Base setting of active components on the System Contents tab.
The base address of a slave component must be a multiple of the address span of the component. This
restriction is part of the Qsys interconnect to allow the address decoding logic to be efficient, and to
achieve the best possible fMAX.
Avalon Streaming Interfaces
High bandwidth components with streaming data typically use Avalon-ST interfaces for the high
throughput datapath. Streaming interfaces can also use memory-mapped connection interfaces to provide
an access point for control. In contrast to the memory-mapped interconnect, the Avalon-ST interconnect
always creates a point-to-point connection between a single data source and data sink.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Avalon Streaming Interfaces
7-27
Figure 7-19: Memory-Mapped and Avalon-ST Interfaces
In this example, there are the following connection pairs:
• Data source in the Rx Interface transfers data to the data sink in the FIFO.
• Data source in the FIFO transfers data to the Tx Interface data sink.
The memory-mapped interface allows a processor to access the data source, FIFO, or data sink to provide
system control. If your source and sink interfaces have different formats, for example, a 32-bit source and
an 8-bit sink, Qsys automatically inserts the necessary adapters. You can view the adapters on the System
Contents tab by clicking System > Show System with Qsys Interconnect.
Control Plane
Memory Mapped Intefaces
RAM
Processor
Control
Slave
Data Source
Data Plane
Qsys Interconnect
Send Feedback
Timer
Control
Slave
Control
Slave
Data Sink
FIFO
( Rx Interface)
Data
Data
Source
Source
UART
ready
valid
channel
data
Data
Sink
( Tx Interface)
Data
Source
ready
valid
channel
data
Data
Sink
Avalon-Streaming Interface
Altera Corporation
7-28
QII5V1
2014.12.15
Avalon-ST Adapters
Figure 7-20: Avalon‑ST Connection Between the Source and Sink
This source-sink pair includes only the data signal. The sink must be able to receive data as soon as the
source interface comes out of reset.
Data Source
data
Data Sink
Figure 7-21: Signals Indicating the Start and End of Packets, Channel Numbers, Error Conditions, and
Backpressure
All data transfers using Avalon-ST interconnect occur synchronously on the rising edge of the associated
clock interface. Throughput and frequency of a system depends on the components and how they are
connected.
Data Source
ready
valid
channel
startof packet
endofpacket
empty
error
data
Data Sink
The IP Catalog includes a number of Avalon-ST components that you can use to create datapaths,
including datapaths whose input and output streams have different properties. Generated systems that
include memory-mapped master and slave components may also use these Avalon-ST components
because Qsys generation creates interconnect with a structure similar to a network topology, as described
in Qsys Transformations. The following sections introduce the Avalon-ST components.
Related Information
• Avalon-ST Adapters on page 7-28
• Qsys Transformations on page 7-7
• Avalon Interface Specification
Avalon-ST Adapters
Qsys automatically adds Avalon-ST adapters between two components during system generation when it
detects mismatched interfaces. If you connect mismatched Avalon-ST sources and sinks, for example, a
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Avalon-ST Adapter
7-29
32-bit source and an 8-bit sink, Qsys inserts the appropriate adapter type to connect the mismatched
interfaces.
After generation, you can view the inserted adapters with the Show System With Qsys Interconnect
command in the System menu. For each mismatched source-sink pair, Qsys inserts an Avalon-ST
Adapter. The adapter instantiates the necessary adaptation logic as sub-components. You can review the
logic for each adapter instantiation in the Hierarchy view by expanding each adapter's source and sink
interface and comparing the relevant ports. For example, to determine why a channel adapter is inserted,
expand the channel adapter's sink and source interfaces and review the channel port properties for each
interface.
You can turn off the auto-inserted adapters feature by adding the
qsys_enable_avalon_streaming_transform=off command to the quartus.ini file. When you turn off
the auto-inserted adapters feature, if mismatched interfaces are detected during system generation, Qsys
does not insert adapters and reports the mismatched interface with validation error message.
Note: The auto-inserted adapters feature does not work for video IP core connections.
Avalon-ST Adapter
The Avalon-ST adapter combines the logic of the channel, error, data format, and timing adapters. The
Avalon-ST adapter provides adaptations between interfaces that have mismatched Avalon-ST endpoints.
Based on the source and sink interface parameterizations for the Avalon-ST adapter, Qsys instantiates the
necessary adapter logic (channel, error, data format, or timing) as hierarchal sub-components.
Avalon-ST Adapter Parameters Common to Source and Sink Interfaces
Table 7-7: Avalon-ST Adapter Parameters Common to Source and Sink Interfaces
Parameter Name
Description
Symbol Width
Width of a single symbol in bits.
Use Packet
Indicates whether the source and sink interfaces connected to the
adapter's source and sink interfaces include the startofpacket and
endofpacket signals, and the optional empty signal.
Avalon-ST Adapter Upstream Source Interface Parameters
Table 7-8: Avalon-ST Adapter Upstream Source Interface Parameters
Parameter Name
Description
Source Data Width
Controls the data width of the source interface data port.
Source Top Channel
Maximum number of output channels allowed.
Source Channel Port Width
Sets the bit width of the source interface channel port. If set to 0, there
is no channel port on the sink interface.
Source Error Port Width
Sets the bit width of the source interface error port. If set to 0, there is
no error port on the sink interface.
Source Error Descriptors
A list of strings that describe the error conditions for each bit of the
source interface error signal.
Qsys Interconnect
Send Feedback
Altera Corporation
7-30
QII5V1
2014.12.15
Avalon-ST Adapter Downstream Sink Interface Parameters
Parameter Name
Description
Source Uses Empty Port
Indicates whether the source interface includes the empty port, and
whether the sink interface should also include the empty port.
Source Empty Port Width
Indicates the bit width of the source interface empty port, and sets the
bit width of the sink interface empty port.
Source Uses Valid Port
Indicates whether the source interface connected to the sink interface
uses the valid port, and if set, configures the sink interface to use the
valid port.
Source Uses Ready Port
Indicates whether the sink interface uses the ready port, and if set,
configures the source interface to use the ready port.
Source Ready Latency
Specifies what ready latency to expect from the source interface
connected to the adapter's sink interface.
Avalon-ST Adapter Downstream Sink Interface Parameters
Table 7-9: Avalon-ST Adapter Downstream Sink Interface Parameters
Parameter Name
Description
Sink Data Width
Indicates the bit width of the data port on the sink interface connected
to the source interface.
Sink Top Channel
Maximum number of output channels allowed.
Sink Channel Port Width
Indicates the bit width of the channel port on the sink interface
connected the source interface.
Sink Error Port Width
Indicates the bit width of the error port on the sink interface
connected to the adapter's source interface. If set to zero, there is no
error port on the source interface.
Sink Error Descriptors
A list of strings that describe the error conditions for each bit of the
error port on the sink interface connected to the source interface.
Sink Uses Empty Port
Indicates whether the sink interface connected to the source interface
uses the empty port, and whether the source interface should also use
the empty port.
Sink Empty Port Width
Indicates the bit width of the empty port on the sink interface
connected to the source interface, and configures a corresponding
empty port on the source interface.
Sink Uses Valid Port
Indicates whether the sink interface connected to the source interface
uses the valid port, and if set, configures the source interface to use
the valid port.
Sink Uses Ready Port
Indicates whether the ready port on the sink interface is connected to
the source interface , and if set, configures the sink interface to use the
ready port.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Channel Adapter
Parameter Name
Sink Ready Latency
7-31
Description
Specifies what ready latency to expect from the source interface
connected to the sink interface.
Channel Adapter
The channel adapter provides adaptations between interfaces that have different channel signal widths.
Table 7-10: Channel Adapter Adaptations
Condition
Description of Adapter Logic
The source uses channels, but the sink does not.
Qsys gives a warning at generation time. The
adapter provides a simulation error and signals an
error for data for any channel from the source other
than 0.
The sink has channel, but the source does not.
Qsys gives a warning at generation time, and the
channel inputs to the sink are all tied to a logical 0.
The source and sink both support channels, and the The source's channel is connected to the sink's
source's maximum channel number is less than the channel unchanged. If the sink's channel signal has
sink's maximum channel number.
more bits, the higher bits are tied to a logical 0.
The source and sink both support channels, but the The source’s channel is connected to the sink’s
source's maximum channel number is greater than channel unchanged. If the source’s channel signal
the sink's maximum channel number.
has more bits, the higher bits are left unconnected.
Qsys gives a warning that channel information may
be lost.
An adapter provides a simulation error message and
an error indication if the value of channel from the
source is greater than the sink's maximum number
of channels. In addition, the valid signal to the sink
is deasserted so that the sink never sees data for
channels that are out of range.
Avalon-ST Channel Adapter Input Interface Parameters
Table 7-11: Avalon-ST Channel Adapter Input Interface Parameters
Parameter Name
Description
Channel Signal Width (bits)
Width of the input channel signal in bits
Max Channel
Maximum number of input channels allowed.
Qsys Interconnect
Send Feedback
Altera Corporation
7-32
QII5V1
2014.12.15
Avalon-ST Channel Adapter Output Interface Parameters
Avalon-ST Channel Adapter Output Interface Parameters
Table 7-12: Avalon-ST Channel Adapter Output Interface Parameters
Parameter Name
Description
Channel Signal Width (bits)
Width of the output channel signal in bits.
Max Channel
Maximum number of output channels allowed.
Avalon-ST Channel Adapter Common to Input and Output Interface Parameters
Table 7-13: Avalon-ST Channel Adapter Common to Input and Output Interface Parameters
Parameter Name
Description
Data Bits Per Symbol
Number of bits for each symbol in a transfer.
Include Packet Support
When the Avalon-ST Channel adapter supports
packets, the startofpacket, endofpacket, and
optional empty signals are included on its sink and
source interfaces.
Include Empty Signal
Indicates whether an empty signal is required.
Data Symbols Per Beat
Number of symbols per transfer.
Support Backpreasure with the ready signal
Indicates whether a ready signal is required.
Ready Latency
Specifies the ready latency to expect from the sink
connected to the module's source interface.
Error Signal Width (bits)
Bit width of the error signal.
Error Signal Description
A list of strings that describes what each bit of the
error signal represents.
Data Format Adapter
The data format adapter allows you to connect interfaces that have different values for the parameters
defining the data signal, or interfaces where the source does not use the empty signal, but the sink does
use the empty signal. One of the most common uses of this adapter is to convert data streams of different
widths.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Data Format Adapter
7-33
Table 7-14: Data Format Adapter Adaptations
Condition
Description of Adapter Logic
The source and sink’s bits per
The connection cannot be made.
symbol parameters are different.
The source and sink have a
The adapter converts the source's width to the sink’s width.
different number of symbols per
If the adaptation is from a wider to a narrower interface, a beat of data
beat.
at the input corresponds to multiple beats of data at the output. If the
input error signal is asserted for a single beat, it is asserted on output
for multiple beats.
If the adaptation is from a narrow to a wider interface, multiple input
beats are required to fill a single output beat, and the output error is
the logical OR of the input error signal.
The source uses the empty signal, Qsys cannot make the connection.
but the sink does not use the
empty signal.
Qsys Interconnect
Send Feedback
Altera Corporation
7-34
QII5V1
2014.12.15
Avalon-ST Data Format Adapter Input Interface Parameters
Figure 7-22: Avalon Streaming Interconnect with Data Format Adapter
In this example, the data format adapter allows a connection between a 128-bit output data stream and
three 32-bit input data streams.
Data
Format
Adapter
128 Bits
128-Bit RX
Interface
128 Bits
32 Bits
32-Bit TX
Interface
32-Bit TX
Interface
128 Bits
Data
Format
Adapter
32 Bits
128 Bits
Data
Format
Adapter
32 Bits
32-Bit TX
Interface
Avalon-ST Data Format Adapter Input Interface Parameters
Table 7-15: Avalon-ST Data Format Adapter Input Interface Parameters
Parameter Name
Description
Data Symbols Per Beat
Number of symbols per transfer.
Include Empty Signal
Indicates whether an empty signal is required.
Avalon-ST Data Format Adapter Output Interface Parameters
Table 7-16: Avalon-ST Data Format Adapter Output Interface Parameters
Parameter Name
Description
Data Symbols Per Beat
Number of symbols per transfer.
Include Empty Signals
Indicates whether an empty signal is required.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Avalon-ST Data Format Adapter Common to Input and Output Interface Parameters
7-35
Avalon-ST Data Format Adapter Common to Input and Output Interface Parameters
Table 7-17: Avalon-ST Data Format Adapter Common to Input and Output Interface Parameters
Parameter Name
Description
Data Bits Per Symbol
Number of bits for each symbol in a transfer.
Include Packet Support
When the Avalon-ST Data Format adapter supports
packets, Qsys uses startofpacket, endofpacket, and
empty signals.
Channel Signal Width (bits)
Width of the output channel signal in bits.
Max Channel
Maximum number of channels allowed.
Read Latency
Specifies the ready latency to expect from the sink
connected to the module's source interface.
Error Signal Width (bits)
Width of the error signal output in bits.
Error Signal Description
A list of strings that describes what each bit of the error
signal represents.
Error Adapter
The error adapter ensures that per-bit-error information provided by the source interface is correctly
connected to the sink interface’s input error signal. Error conditions that both the source and sink are able
to process are connected. If the source has an error signal representing an error condition that is not
supported by the sink, the signal is left unconnected; the adapter provides a simulation error message and
an error indication if the error is asserted. If the sink has an error condition that is not supported by the
source, the sink's input error bit corresponding to that condition is set to 0.
Note: The output interface error signal descriptor accepts an error set with an other descriptor. Qsys
assigns the bit-wise ORing of all input error bits that are unmatched, to the output interface error
bits set with the other descriptor.
Avalon-ST Error Adapter Input Interface Parameters
Table 7-18: Avalon-ST Error Adapter Input Interface Parameters
Parameter Name
Description
Error Signal Width (bits)
The width of the error signal. Valid values are 0–256 bits. Type 0 if the
error signal is not used.
Error Signal Description
The description for each of the error bits. If scripting, separate the
description fields by commas. For a successful connection, the descrip‐
tion strings of the error bits in the source and sink must match and are
case sensitive.
Qsys Interconnect
Send Feedback
Altera Corporation
7-36
QII5V1
2014.12.15
Avalon-ST Error Adapter Output Interface Parameters
Avalon-ST Error Adapter Output Interface Parameters
Table 7-19: Avalon-ST Error Adapter Output Interface Parameters
Parameter Name
Description
Error Signal Width (bits)
The width of the error signal. Valid values are 0–256 bits.
Type 0 if you do not need to send error values.
Error Signal Description
The description for each of the error bits. Separate the
description fields by commas. For successful connection, the
description of the error bits in the source and sink must
match, and are case sensitive.
Avalon-ST Error Adapter Common to Input and Output Interface Parameters
Table 7-20: Avalon-ST Error Adapter Common to Input and Output Interface Parameters
Parameter Name
Description
Support Backpressure with the ready signal
Turn on this option to add the backpressure function‐
ality to the interface.
Ready Latency
When the ready signal is used, the value for ready_
latency indicates the number of cycles between
when the ready signal is asserted and when valid data
is driven.
Channel Signal Width (bits)
The width of the channel signal. A channel width of 4
allows up to 16 channels. The maximum width of the
channel signal is eight bits. Set to 0 if channels are
not used.
Max Channel
The maximum number of channels that the interface
supports. Valid values are 0–255.
Data Bits Per Symbol
Number of bits per symbol.
Data Symbols Per Beat
Number of symbols per active transfer.
Include Packet Support
Turn on this option if the connected interfaces
support a packet protocol, including the startofpacket, endofpacket and empty signals.
Include Empty Signal
Turn this option on if the cycle that includes the
endofpacket signal can include empty symbols. This
signal is not necessary if the number of symbols per
beat is 1.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Timing Adapter
7-37
Timing Adapter
The timing adapter allows you to connect component interfaces that require a different number of cycles
before driving or receiving data. This adapter inserts a FIFO buffer between the source and sink to buffer
data or pipeline stages to delay the back pressure signals. You can also use the timing adapter to connect
interfaces that support the ready signal, and those that do not. The timing adapter treats all signals other
than the ready and valid signals as payload, and simply drives them from the source to the sink.
Table 7-21: Timing Adapter Adaptations
Condition
Adaptation
The source has ready, but the sink does not.
In this case, the source can respond to backpressure, but the sink never needs to apply it. The
ready input to the source interface is connected
directly to logical 1.
The source does not have ready, but the sink does.
The sink may apply backpressure, but the source is
unable to respond to it. There is no logic that the
adapter can insert that prevents data loss when the
source asserts valid but the sink is not ready. The
adapter provides simulation time error messages if
data is lost. The user is presented with a warning,
and the connection is allowed.
The source and sink both support backpressure, but The source responds to ready assertion or deasser‐
the sink’s ready latency is greater than the source's. tion faster than the sink requires it. A number of
pipeline stages equal to the difference in ready
latency are inserted in the ready path from the sink
back to the source, causing the source and the sink
to see the same cycles as ready cycles.
The source and sink both support backpressure, but The source cannot respond to ready assertion or
the sink’s ready latency is less than the source's.
deassertion in time to satisfy the sink. A FIFO
whose depth is equal to the difference in ready
latency is inserted to compensate for the source’s
inability to respond in time.
Avalon-ST Timing Adapter Input Interface Parameters
Table 7-22: Avalon-ST Timing Adapter Input Interface Parameters
Parameter Name
Description
Support Backpreasure with the ready signal
Indicates whether a ready signal is required.
Read Latency
Specifies the ready latency to expect from the sink
connected to the module's source interface.
Qsys Interconnect
Send Feedback
Altera Corporation
7-38
QII5V1
2014.12.15
Avalon-ST Timing Adapter Output Interface Parameters
Parameter Name
Include Valid Signal
Description
Indicates whether the sink interface requires a valid
signal.
Avalon-ST Timing Adapter Output Interface Parameters
Table 7-23: Avalon-ST Timing Adapter Output Interface Parameters
Parameter Name
Description
Support Backpreasure with the ready signal
Indicates whether a ready signal is required.
Read Latency
Specifies the ready latency to expect from the sink
connected to the module's source interface.
Include Valid Signal
Indicates whether the sink interface requires a valid
signal.
Avalon-ST Timing Adapter Common to Input and Output Interface Parameters
Table 7-24: Avalon-ST Timing Adapter Common to Input and Output Interface Parameters
Parameter Name
Description
Data Bits Per Symbol
Number of bits for each symbol in a transfer.
Include Packet Support
Turn this option on if the connected interfaces
support a packet protocol, including the startofpacket, endofpacket and empty signals.
Include Empty Signal
Turn this option on if the cycle that includes the
endofpacket signal can include empty symbols. This
signal is not necessary if the number of symbols per
beat is 1.
Data Symbols Per Beat
Number of symbols per active transfer.
Channel Signal Width (bits)
Width of the output channel signal in bits.
Max Channel
Maximum number of output channels allowed.
Error Signal Width (bits)
Width of the output error signal in bits.
Error Signal Description
A list of strings that describes errors.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Interrupt Interfaces
7-39
Interrupt Interfaces
Using individual requests, the interrupt logic can process up to 32 IRQ inputs connected to each interrupt
receiver. With this logic, the interrupt sender connected to interrupt receiver_0 is the highest priority
with sequential receivers being successively lower priority. You can redefine the priority of interrupt
senders by instantiating the IRQ mapper component. For more information refer to IRQ Mapper.
You can define the interrupt sender interface as asynchronous with no associated clock or reset interfaces.
You can also define the interrupt receiver interface as asynchronous with no associated clock or reset
interfaces. As a result, the receiver does its own synchronization internally. Qsys does not insert interrupt
synchronizers for such receivers.
For clock crossing adaption on interrupts, Qsys inserts a synchronizer, which is clocked with the interrupt
end point interface clock when the corresponding starting point interrupt interface has no clock or a
different clock (than the end point). Qsys inserts the adapter if there is any kind of mismatch between the
start and end points. Qsys does not insert the adapter if the interrupt receiver does not have an associated
clock.
Related Information
IRQ Mapper on page 7-41
Individual Requests IRQ Scheme
In the individual requests IRQ scheme, Qsys interconnect passes IRQs directly from the sender to the
receiver, without making assumptions about IRQ priority. In the event that multiple senders assert their
Qsys Interconnect
Send Feedback
Altera Corporation
7-40
QII5V1
2014.12.15
Assigning IRQs in Qsys
IRQs simultaneously, the receiver logic determines which IRQ has highest priority, and then responds
appropriately.
Figure 7-23: Interrupt Controller Mapping IRQs
Using individual requests, the interrupt controller can process up to 32 IRQ inputs. The interrupt
controller generates a 32-bit signal irq[31:0] to the receiver, and maps slave IRQ signals to the bits of
irq[31:0]. Any unassigned bits of irq[31:0] are disabled.
Sender
1
irq
Interrupt
Controller
Sender
2
Sender
3
irq
irq
irq0
irq1
irq2
irq3
irq4
irq5
irq6
Receiver
irq31
Sender
4
irq
Assigning IRQs in Qsys
You assign IRQ connections on the System Contents tab of Qsys. After adding all components to the
system, you connect interrupt senders and receivers. You can use the IRQ column to specify an IRQ
number with respect to each receiver, or to specify a receiver's IRQ as unconnected. Qsys uses the
following three components to implement interrupt handling: IRQ Bridge, IRQ Mapper, and IRQ Clock
Crosser.
IRQ Bridge
The IRQ Bridge allows you to route interrupt wires between Qsys subsystems.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
IRQ Mapper
7-41
Figure 7-24: Qsys IRQ Bridge Application
The peripheral subsystem example below has three interrupt senders that are exported to the to- level of
the subsystem. The interrupts are then routed to the CPU subsystem using the IRQ bridge.
Top-Level Qsys System
3-bit bus
export
IR
export
export
IRQ
export
IS
IS
IS
Interrupt
Sender 1
Interrupt
Sender 2
Interrupt
Sender 3
Bridge
IS
Interrupt
Sender 4
IS
Peripheral Subsystem
4-bit bus
IR
CPU Subsystem
IS
Interrupt Sender
IR
Nios II
Processor
Interrupt Receiver
Note: Nios II BSP tools support the IRQ Bridge. Interrupts connected via an IRQ Bridge appear in the
generated system.h file. You can use the following properties with the IRQ Bridge, which do not
effect Qsys interconnect generation. Qsys uses these properties to generate the correct IRQ
information for downstream tools:
• set_interface_property <sender port> bridgesToReceiver <receiver port>—The <sender
port> of the IP generates a signal that is received on the IP's <receiver port>. Sender ports are
single bits. Receivers ports can be multiple bits. Qsys requires the bridgedReceiverOffset
property to identify the <receiver port> bit that the <sender port> sends.
• set_interface_property <sender port> bridgedReceiverOffset <port number>—
Indicates the <port number> of the receiver port that the <sender port> sends.
IRQ Mapper
Qsys inserts the IRQ Mapper automatically during generation. The IRQ Mapper converts individual
interrupt wires to a bus, and then maps the appropriate IRQ priority number onto the bus.
Qsys Interconnect
Send Feedback
Altera Corporation
7-42
QII5V1
2014.12.15
IRQ Clock Crosser
By default, the interrupt sender connected to the receiver0 interface of the IRQ mapper is the highest
priority, and sequential receivers are successively lower priority. You can modify the interrupt priority of
each IRQ wire by modifying the IRQ priority number in Qsys under the IRQ column. The modified
priority is reflected in the IRQ_MAP parameter for the auto-inserted IRQ Mapper.
Figure 7-25: IRQ Column in Qsys
Circled in the IRQ column are the default interrupt priorities allocated for the CPU subsystem.
Related Information
IRQ Bridge on page 7-40
IRQ Clock Crosser
The IRQ Clock Crosser synchronizes interrupt senders and receivers that are in different clock domains.
To use this component, connect the clocks for both the interrupt sender and receiver, and for both the
interrupt sender and receiver interfaces. Qsys automatically inserts this component when it is required.
Clock Interfaces
Clock interfaces define the clocks used by a component. Components can have clock inputs, clock
outputs, or both. You can use the Clock Settings tab to define external clock sources, for example an
oscillator on your board.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
(High Speed Serial Interface) HSSI Clock Interfaces
7-43
The Clock Source parameters allows you to set the following options:
• Clock frequency—The frequency of the output clock from this clock source.
• Clock frequency is known— When turned on, the clock frequency is known. When turned off, the
frequency is set from outside the system.
Note: If turned off, system generation may fail because the components do not receive the necessary
clock information. For best results, turn this option on before system generation.
• Reset synchronous edges
• None—The reset is asserted and deasserted asynchronously. You can use this setting if you have
internal synchronization circuitry that matches the reset required for the IP in the system.
• Both—The reset is asserted and deasserted synchronously.
• Deassert—The reset is deasserted synchronously and asserted asynchronously.
For more information about synchronous design practices, refer to Recommended Design Practices
Related Information
• Recommended Design Practices on page 11-1
(High Speed Serial Interface) HSSI Clock Interfaces
You can use HSSI Serial Clock and HSSI Bonded Clock interfaces in Qsys to enable high speed serial
connectivity between clocks that are used by certain IP protocols.
HSSI Serial Clock Interface
You can connect the HSSI Serial Clock interface with only similar type of interfaces, for example, you can
connect a HSSI Serial Clock Source interface to a HSSI Serial Clock Sink interface.
HSSI Serial Clock Source
The HSSI Serial Clock interface includes a source in the Start direction.
You can instantiate the HSSI Serial Clock Source interface in the _hw.tcl file as:
add_interface <name> hssi_serial_clock start
You can connect the HSSI Serial Clock Source to multiple HSSI Serial Clock Sinks because the HSSI Serial
Clock Source supports multiple fan-outs. This Interface has a single clk port role limited to a 1 bit width,
and a clockRate parameter, which is the frequency of the clock driven by the HSSI Serial Clock Source
interface.
An unconnected and unexported HSSI Serial Source is valid and does not generate error messages.
Table 7-25: HSSI Serial Clock Source Port Roles
Name
clk
Qsys Interconnect
Send Feedback
Direction
Output
Width
1 bit
Description
A single bit wide port role, which provides synchronization
for internal logic.
Altera Corporation
7-44
QII5V1
2014.12.15
HSSI Serial Clock Sink
Table 7-26: HSSI Serial Clock Source Parameters
Name
clockRate
Type
long
Default
0
Derived
No
Description
The frequency of the clock driven byte HSSI Serial
Clock Source interface.
HSSI Serial Clock Sink
The HSSI Serial Clock interface includes a sink in the End direction.
You can instantiate the HSSI Serial Clock Sink interface in the _hw.tcl file as:
add_interface <name> hssi_serial_clock end
You can connect the HSSI Serial Clock Sink interface to a single HSSI Serial Clock Source interface; you
cannot connect it to multiple sources. This Interface has a single clk port role limited to a 1 bit width, and
a clockRate parameter, which is the frequency of the clock driven by the HSSI Serial Clock Source
interface.
An unconnected and unexported HSSI Serial Sink is invalid and generates error messages.
Table 7-27: HSSI Serial Clock Sink Port Roles
Name
clk
Direction
Output
Width
Description
1
A single bit wide port role, which provides synchronization
for internal logic
Table 7-28: HSSI Serial Clock Sink Parameters
Name
clockRate
Type
long
Default
0
Derived
No
Description
The frequency of the clock driven by the HSSI Serial
Clock Source interface. When you specify a clockRate
greater than 0, then this interface can be driven only at
that rate.
HSSI Serial Clock Connection
The HSSI Serial Clock Connection defines a connection between a HSSI Serial Clock Source connection
point, and a HSSI Serial Clock Sink connection point.
A valid HSSI Serial Clock Connection exists when all of the following criteria are satisfied. If the following
criteria are not satisfied, Qsys generates error messages and the connection is prohibited.
• The starting connection point is an HSSI Serial Clock Source with a single port role clk and maximum
1 bit in width. The direction of the starting port is Output.
• The ending connection point is an HSSI Serial Clock Sink with a single port role clk, and maximum 1
bit in width. The direction of the ending port is Input.
• If the parameter, clockRate of the HSSI Serial Clock Sink is greater than 0, the connection is only valid
if the clockRate of the HSSI Serial Clock Source is the same as the clockRate of the HSSI Serial Clock
Sink.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
HSSI Serial Clock Example
7-45
HSSI Serial Clock Example
Example 7-1: HSSI Serial Clock Interface Example
You can make connections to declare the HSSI Serial Clock interfaces in the _hw.tcl.
package require -exact qsys 14.0
set_module_property name hssi_serial_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
set_fileset_property QUARTUS_SYNTH TOP_LEVEL \
"hssi_serial_component"
set_fileset_property SIM_VERILOG TOP_LEVEL "hssi_serial_component"
set_fileset_property SIM_VHDL TOP_LEVEL "hssi_serial_component"
proc elaborate {} {
# declaring HSSI Serial Clock Source
add_interface my_clock_start hssi_serial_clock start
set_interface_property my_clock_start ENABLED true
add_interface_port my_clock_start
clk Output 1
hssi_serial_clock_port_out \
# declaring HSSI Serial Clock Sink
add_interface my_clock_end hssi_serial_clock end
set_interface_property my_clock_end ENABLED true
add_interface_port my_clock_end
Input 1
hssi_serial_clock_port_in clk \
}
proc generate { output_name } {
add_fileset_file hssi_serial_component.v VERILOG PATH \
"hssi_serial_component.v"
}
Example 7-2: HSSI Serial Clock Instantiated in a Composed Component
If you use the components in a hierarchy, for example, instantiated in a composed component,
you can declare the connections as illustrated in this example.
add_instance myinst1 hssi_serial_component
add_instance myinst2 hssi_serial_component
# add connection from source of myinst1 to sink of myinst2
add_connection myinst1.my_clock_start myinst2.my_clock_end \
hssi_serial_clock
# adding connection from source of myinst2 to sink of myinst1
add_connection myinst2.my_clock_start myinst2.my_clock_end \
hssi_serial_clock
Qsys Interconnect
Send Feedback
Altera Corporation
7-46
QII5V1
2014.12.15
HSSI Bonded Clock Interface
HSSI Bonded Clock Interface
You can connect the HSSI Bonded Clock interface with only similar type of Interfaces, for example, you
can connect a HSSI Bonded Clock Source interface to a HSSI Bonded Clock Sink interface.
HSSI Bonded Clock Source
The HSSI Bonded Clock interface includes a source in the Start direction.
You can instantiate the HSSI Bonded Clock Source interface in the _hw.tcl file as:
add_interface <name> hssi_bonded_clock start
You can connect the HSSI Bonded Clock Source to multiple HSSI Bonded Clock Sinks because the HSSI
Serial Clock Source supports multiple fanouts. This Interface has a single clk port role limited to a width
range of 1 to 1024 bits. The HSSI Bonded Clock Source interface has two parameters: clockRate and
serialzationFactor. clockRate is the frequency of the clock driven by the HSSI Bonded Clock Source
interface, and the serializationFactor is the parallel data width that operates the HSSI TX serializer. The
serialization factor determines the required frequency and phases of the individual clocks within the HSSI
Bonded Clock interface
An unconnected and unexported HSSI Bonded Source is valid and does not generate error messages.
Table 7-29: HSSI Bonded Clock Source Port Roles
Name
clk
Direction
Output
Width
Description
1 to 24 bits
A multiple bit wide port role which provides synchronization
for internal logic.
Table 7-30: HSSI Bonded Clock Source Parameters
Name
Type
Default
Derived
Description
clockRate
long
0
No
The frequency of the clock driven byte HSSI Serial
Clock Source interface.
serialization
long
0
No
The serialization factor is the parallel data width that
operates the HSSI TX serializer. The serialization factor
determines the necessary frequency and phases of the
individual clocks within the HSSI Bonded Clock
interface.
HSSI Bonded Clock Sink
The HSSI Bonded Clock interface includes a sink in the End direction.
You can instantiate the HSSI Bonded Clock Sink interface in the _hw.tcl file as:
add_interface <name> hssi_bonded_clock end
You can connect the HSSI Bonded Clock Sink interface to a single HSSI Bonded Clock Source interface;
you cannot connect it to multiple sources. This Interface has a single clk port role limited to a width range
of 1 to 1024 bits. The HSSI Bonded Clock Source interface has two parameters: clockRate and serialza‐
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
HSSI Bonded Clock Connection
7-47
tionFactor. clockRate is the frequency of the clock driven by the HSSI Bonded Clock Source interface,
and the serialization factor is the parallel data width that operates the HSSI TX serializer. The serialization
factor determines the required frequency and phases of the individual clocks within the HSSI Bonded
Clock interface
An unconnected and unexported HSSI Bonded Sink is invalid and generates error messages.
Table 7-31: HSSI Bonded Clock Source Port Roles
Name
clk
Direction
Output
Width
Description
1 to 24 bits
A multiple bit wide port role which provides synchronization
for internal logic.
Table 7-32: HSSI Bonded Clock Source Parameters
Name
Type
Default
Derived
Description
clockRate
long
0
No
The frequency of the clock driven byte HSSI Serial
Clock Source interface.
serialization
long
0
No
The serialization factor is the parallel data width that
operates the HSSI TX serializer. The serialization factor
determines the necessary frequency and phases of the
individual clocks within the HSSI Bonded Clock
interface.
HSSI Bonded Clock Connection
The HSSI Bonded Clock Connection defines a connection between a HSSI Bonded Clock Source
connection point, and a HSSI Bonded Clock Sink connection point.
A valid HSSI Bonded Clock Connection exists when all of the following criteria are satisfied. If the
following criteria are not satisfied, Qsys generates error messages and the connection is prohibited.
• The starting connection point is an HSSI Bonded Clock Source with a single port role clk with a width
range of 1 to 24 bits. The direction of the starting port is Output.
• The ending connection point is an HSSI Bonded Clock Sink with a single port role clk with a width
range of 1 to 24 bits. The direction of the ending port is Input.
• The width of the starting connection point clk must be the same as the width of the ending connection
point.
• If the parameter, clockRate of the HSSI Bonded Clock Sink greater than 0, then the connection is only
valid if the clockRate of the HSSI Bonded Clock Source is same as the clockRate of the HSSI Bonded
Clock Sink.
• If the parameter, serializationFactor of the HSSI Bonded Clock Sink is greater than 0, Qsys generates
a warning if the serializationFactor of HSSI Bonded Clock Source is not same as the serialization‐
Factor of the HSSI Bonded Clock Sink.
Qsys Interconnect
Send Feedback
Altera Corporation
7-48
QII5V1
2014.12.15
HSSI Bonded Clock Example
HSSI Bonded Clock Example
Example 7-3: HSSI Bonded Clock Interface Example
You can make connections to declare the HSSI Bonded Clock interfaces in the _hw.tcl file.
package require -exact qsys 14.0
set_module_property name hssi_bonded_component
set_module_property ELABORATION_CALLBACK elaborate
add_fileset synthesis QUARTUS_SYNTH generate
add_fileset verilog_simulation SIM_VERILOG generate
set_fileset_property synthesis TOP_LEVEL "hssi_bonded_component"
set_fileset_property verilog_simulation TOP_LEVEL \
"hssi_bonded_component"
proc elaborate {} {
add_interface my_clock_start hssi_bonded_clock start
set_interface_property my_clock_start ENABLED true
add_interface_port my_clock_start
clk Output 1024
hssi_bonded_clock_port_out \
add_interface my_clock_end hssi_bonded_clock end
set_interface_property my_clock_end ENABLED true
add_interface_port my_clock_end
clk Input 1024
hssi_bonded_clock_port_in \
}
proc generate { output_name } {
add_fileset_file hssi_bonded_component.v VERILOG PATH \
"hssi_bonded_component.v"}
If you use the components in a hierarchy, for example, instantiated in a composed component, you can
declare the connections as illustrated in this example.
Example 7-4: HSII Bonded Clock Instantiated in a Composed Component
add_instance myinst1 hssi_bonded_component
add_instance myinst2 hssi_bonded_component
# add connection from source of myinst1 to sink of myinst2
add_connection myinst1.my_clock_start myinst2.my_clock_end \
hssi_bonded_clock
# adding connection from source of myinst2 to sink of myinst1
add_connection myinst2.my_clock_start myinst2.my_clock_end \
hssi_bonded_clock
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Reset Interfaces
7-49
Reset Interfaces
Reset interfaces provide both soft and hard reset functionality. Soft reset logic typically re-initializes
registers and memories without powering down the device. Hard reset logic initializes the device after
power-on. You can define separate reset sources for each clock domain, a single reset source for all clocks,
or any combination in between.
You can choose to create a single global reset domain by selecting Create Global Reset Network on the
System menu. If your design requires more than one reset domain, you can implement your own reset
logic and connectivity. The IP Catalog includes a reset controller, reset sequencer, and a reset bridge to
implement the reset functionality. You can also design your own reset logic.
Note: If you design your own reset circuitry, you must carefully consider situations which may result in
system lockup. For example, if an Avalon-MM slave is reset in the middle of a transaction, the
Avalon-MM master may lockup.
Single Global Reset Signal Implemented by Qsys
If you select Create Global Reset Network on the System menu, the Qsys interconnect creates a global
reset bus. All of the reset requests are ORed together, synchronized to each clock domain, and fed to the
reset inputs. The duration of the reset signal is at least one clock period.
The Qsys interconnect inserts the system-wide reset under the following conditions:
• The global reset input to the Qsys system is asserted.
• Any component asserts its resetrequest signal.
Reset Controller
Qsys automatically inserts a reset controller block if the input reset source does not have a reset request,
but the connected reset sink requires a reset request.
The Reset Controller has the following parameters that you can specify to customize its behavior:
• Number of inputs— Indicates the number of individual reset interfaces the controller ORs to create a
signal reset output.
• Output reset synchronous edges—Specifies the level of synchronization. You can select one the
following options:
• None—The reset is asserted and deasserted asynchronously. You can use this setting if you have
designed internal synchronization circuitry that matches the reset style required for the IP in the
system.
• Both—The reset is asserted and deasserted synchronously.
• Deassert—The reset is deasserted synchronously and asserted asynchronously.
• Synchronization depth—Specifies the number of register stages the synchronizer uses to eliminate the
propagation of metastable events.
• Reset request—Enables reset request generation, which is an early signal that is asserted before reset
assertion. The reset request is used by blocks that require protection from asynchronous inputs, for
example, M20K blocks.
Qsys Interconnect
Send Feedback
Altera Corporation
7-50
QII5V1
2014.12.15
Reset Bridge
Qsys automatically inserts reset synchronizers under the following conditions:
• More than one reset source is connected to a reset sink
• There is a mismatch between the reset source’s synchronous edges and the reset sinks’ synchronous
edges
Reset Bridge
The Reset Bridge allows you to use a reset signal in two or more subsystems of your Qsys system. You can
connect one reset source to local components, and export one or more to other subsystems, as required.
The Reset Bridge parameters are used to describe the incoming reset and include the following options:
• Active low reset—When turned on, reset is asserted low.
• Synchronous edges—Specifies the level of synchronization and includes the following options:
• None—The reset is asserted and deasserted asynchronously. Use this setting if you have internal
synchronization circuitry.
• Both—The reset is asserted and deasserted synchronously.
• Deassert—The reset is deasserted synchronously, and asserted asynchronously.
• Number of reset outputs—The number of reset interfaces that are exported.
Note: Qsys supports multiple reset sink connections to a single reset source interface. However, there are
situations in composed systems where an internally generated reset must be exported from the
composed system in addition to being used to connect internal components. In this situation, you
must declare one reset output interface as an export, and use another reset output to connect
internal components.
Reset Sequencer
The Reset Sequencer allows you to control the assertion and de-assertion sequence for Qsys system resets.
The Parameter Editor displays the expected assertion and de-assertion sequences based on the current
settings. You can connect multiple reset sources to the reset sequencer, and then connect the output of the
reset sequencer to components in the system.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Reset Sequencer Parameters
7-51
Figure 7-26: Elements and Flow of a Reset Sequencer
Reset Sequencer
Avalon
Interface
CSR
CSR_MASK/PVR
CSR_CONTROL(csr_*)
reset_logging
Parameter:
ASRT_DELAY(0:N)
Sync
Sync
Sync
Sync
reset_in0
reset_in1
reset_in2
reset_in M
Reset
Controller
reset_dsrt_qual0
reset_dsrt_qual1
reset_dsrt_qual2
reset_dsrt_qual N
assrt_en
reset_in_sync
Main
FSM
enable
done
enable
done
ASRT SEQ
set_reset[ N :0]
RESET_OUT
DSRT SEQ
reset_out0
reset_out1
reset_out2
reset_out N
dr_reset[ N :0]
Deglitch
Deglitch
Deglitch
Deglitch
Parameter:
DSRT_QUALCNT_(0:N)
Parameter:
MIN_ASRT_TIME
Parameter:
DSRT_DELAY(0:N)
ENABLE_DEASSERTION_INPUT_QUAL(0:N)
Reset Controller —Reused reset controller block. It synchronizes the reset inputs into one and feed into the main FSM of the sequencer
block.
Sync —Synchronization block (double flip-flop).
Deglitch —Deglitch block. This block waits for a signal to be at a level for
X clocks before propagating the input to the output.
CSR —This block contains the CSR Avalon interface and related CSR register and control block in the sequencer.
Main FSM —Main sequencer. This block determines when assertion/deassertion and assertion hold timing occurs.
[A/D]SRT SEQ —Generic sequencer block that sequences out assertion/deassertion of reset from 0:N. The block has multiple
counters that saturate upon reaching count.
RESET_OUT —Controls the end output via:
– Set/clear from the ASRT_SEQ/DSRT_SEQ.
– Masking/forcing from CSR controls.
– Remap of numbering (parameterization).
Reset Sequencer Parameters
Table 7-33: Reset Sequencer Parameters
Parameter
Description
Number of reset outputs
Sets the number of output resets to be sequenced, which is the
number of output reset signals defined in the component with a
range of 2 to 10.
Number of reset inputs
Sets the number of input reset signals to be sequenced, which is
the number of input reset signals defined in the component with a
range of 1 to 10.
Minimum reset assertion time
Specifies the minimum assertion cycles between the assertion of
the last sequenced reset, and the de-assertion of the first
sequenced reset. The range is 0 to 1023.
Qsys Interconnect
Send Feedback
Altera Corporation
7-52
QII5V1
2014.12.15
Reset Sequencer Parameters
Parameter
Description
Enable Reset Sequencer CSR
Enables CSR functionality of the Reset Sequencer through an
Avalon interface.
reset_out#
Lists the reset output signals. Set the parameters in the other
columns for each reset signal in the table.
ASRT Seq#
Determines the order of reset assertion. Enter the values 1, 2, 3,
etc. to specify the required non-overlapping assertion order. This
value determines the ASRT_REMAP value in the component HDL.
ASRT Cycle#
Number of cycles to wait before assertion of the reset. The value
set here corresponds to the ASRT_DELAY value in the component
HDL.The range is 0 to1023.
DSRT Seq#
Determines the reset order of reset de-assertion. Enter the values
1, 2, 3, etc .to specify the required non-overlapping de-assertion
order. This value determines the DSRT_REMAP value in the
component HDL.
DSRT Cycle#/Deglitch#
Number of cycles to wait before de-asserting or de-glitching the
reset. If the USE_DRST_QUAL parameter is set to 0, specifies the
number of cycles to wait before de-asserting the reset. If USE_
DSRT_QUAL is set to1, specifies the number of cycles to deglitch
the input reset_dsrt_qual signal. This value determines either
the DSRT_DELAY, or the DSRT_QUALCNT value in the component
HDL, depending on the USE_DSRT_QUAL parameter setting.
The range is 0 to 1023.
USE_DSRT_QUAL
If you set USE_DSRT_QUAL to 1, the de-assertion sequence
waits for an external input signal for sequence qualification
instead of waiting for a fixed delay count. To use a fixed delay
count for de-assertion, set this parameter to 0.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Reset Sequencer Timing Diagrams
7-53
Reset Sequencer Timing Diagrams
Figure 7-27: Basic Sequencing
Figure 7-28: Sequencing with USE_DSRT_QUAL Set
Reset Sequencer CSR Registers
Qsys Interconnect
Send Feedback
Altera Corporation
7-54
QII5V1
2014.12.15
Reset Sequencer Status Register Offset 0x00
The CSR registers on the reset sequencer provide the following functionality:
• Supports reset logging
• Ability to identify which reset is asserted.
• Ability to determine whether any reset is currently active.
• Supports software triggered resets
• Ability to generate reset by writing to the register.
• Ability to disable assertion or de-assertion sequence.
• Supports software sequenced reset
• Ability for the software to fully control the assertion/de-assertion sequence by writing to registers
and stepping through the sequence.
• Support reset override
• Ability to assert a particular component reset through software.
Reset Sequencer Status Register Offset 0x00
The Status register contains bits that indicate the sources of resets that cause a reset.
You can clear bits by writing 1 to the bit location. The Reset Sequencer ignores writes to bits with a value
of 0. If the sequencer is reset (power-on-reset), all bits are cleared, except the power on reset bit.
Table 7-34: Values for the Status Register at Offset 0x00
Bit
Attrib
ute
Defaul
t
31
RO
0
30
RW1C 0
Description
Reset Active—Indicates that the sequencer is currently active in reset sequence
(assertion or de-assertion).
Reset Asserted and waiting for SW to proceed:—Set when there is an active
reset assertion, and the next sequence is waiting for the software to proceed.
Only valid when the Enable SW sequenced reset entry option is turned on.
29
RW1C 0
Reset De-asserted and waiting for SW to proceed:—Set when there is an
active reset de-assertion, and the next sequence is waiting for the software to
proceed.
Only valid when the Enable SW sequenced reset bring up option is turned on.
28:26
RO
25:16
RW1C 0
Reset de-assertion input qualification signal reset_dsrt_qual [9:0] status—
Indicates that the reset de-assertion's input signal qualification signal is set. This
bit is set on the detection of assertion of the signal.
15:12
RO
Reserved.
11
RW1C 0
Altera Corporation
0
0
Reserved.
reset_in9 was triggered—Indicates that resetin9 triggered the reset. Cleared
by software by writing 1 to this bit location.
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Reset Sequencer Interrupt Enable Register Offset 0x04
Bit
Attrib
ute
Defaul
t
7-55
Description
10
RW1C 0
reset_in8 was triggered—Indicates that reset_in8 triggered the reset. Cleared
by software by writing a1 to this bit location.
9
RW1C 0
reset_in7 was triggered—Indicates that reset_in7 triggered the reset. Cleared
by software by writing 1 to this bit location.
8
RW1C 0
reset_in6 was triggered—Indicates that reset_in6 triggered the reset. Cleared
by software by writing 1 to this bit location.
7
RW1C 0
reset_in5 was triggered—Indicates that reset_in5 triggered the reset. Cleared
by software by writing 1 to this bit location.
6
RW1C 0
reset_in4 was triggered—Indicates that reset_in4 triggered the reset. Cleared
by software by writing 1 to this bit location.
5
RW1C 0
reset_in3 was triggered—Indicates that reset_in3 triggered the reset. Cleared
by software by writing 1 to this bit location.
4
RW1C 0
reset_in2 was triggered—Indicates that reset_in2 triggered the reset. Cleared
by software by writing 1 to this bit location.
3
RW1C 0
reset_in1 was triggered—Indicates that reset_in1 triggered the reset. Cleared
by software by writing 1 to this bit location.
2
RW1C 0
reset_in0 was triggered—Indicates that reset_in0 triggered. Cleared by
software by writing 1 to this bit location.
1
RW1C 0
Software triggered reset—Indicates that the software triggered reset is set by
the software, and triggering a reset.
0
RW1C 0
Power-On-Reset was triggered—Asserted whenever the reset to the sequencer
is triggered. This bit is NOT reset when sequencer is reset. Cleared by software
by writing 1 to this bit location.
Reset Sequencer Interrupt Enable Register Offset 0x04
The Interrupt Enable register contains the interrupt enable bit that you can use to enable any event
triggering the IRQ of the reset sequencer.
Table 7-35: Values for the Interrupt Enable Register at Offset 0x04
Bit
31
Attrib
ute
Defaul
t
RO
0
Qsys Interconnect
Send Feedback
Description
Reserved.
Altera Corporation
7-56
QII5V1
2014.12.15
Reset Sequencer Interrupt Enable Register Offset 0x04
Bit
Attrib
ute
Defaul
t
30
RW
0
Interrupt on Reset Asserted and waiting for SW to proceed enable. When set,
the IRQ is set when the sequencer is waiting for the software to proceed in an
assertion sequence.
29
RW
0
Interrupt on Reset De-asserted and waiting for SW to proceed enable. When
set, the IRQ is set when the sequencer is waiting for the software to proceed in a
de-assertion sequence.
28:26
RO
0
Reserved.
25:16
RW
0
Interrupt on Reset de-assertion input qualification signal reset_dsrt_qual_
[9:0] status— When set, the IRQ is set when the reset_dsrt_qual[9:0] status
bit (per bit enable) is set.
15:12
RO
0
Reserved.
11
RW
0
Interrupt on reset_in9 Enable—When set, the IRQ is set when the reset_in9
trigger status bit is set.
10
RW
0
Interrupt on reset_in8 Enable—When set, the IRQ is set when the reset_in8
trigger status bit is set.
9
RW
0
Interrupt on reset_in7 Enable—When set, the IRQ is set when the reset_in7
trigger status bit is set.
8
RW
0
Interrupt on reset_in6 Enable—When set, the IRQ is set when the reset_in6
trigger status bit is set.
7
RW
0
Interrupt on reset_in5 Enable—When set, the IRQ is set when the reset_in5
trigger status bit is set.
6
RW
0
Interrupt on reset_in4 Enable—When set, the IRQ is set when the reset_in4
trigger status bit is set.
5
RW
0
Interrupt on reset_in3 Enable—When set, the IRQ is set when the reset_in3
trigger status bit is set.
4
RW
0
Interrupt on reset_in2 Enable—When set, the IRQ is set when the reset_in2
trigger status bit is set.
3
RW
0
Interrupt on reset_in1 Enable—When set, the IRQ is set when the reset_in1
trigger status bit is set.
2
RW
0
Interrupt on reset_in0 Enable—When set, the IRQ is set when the reset_in0
trigger status bit is set.
Altera Corporation
Description
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Reset Sequencer Control Register Offset 0x08
Bit
7-57
Attrib
ute
Defaul
t
Description
1
RW
0
Interrupt on Software triggered reset Enable—When set, the IRQ is set when
the software triggered reset status bit is set.
0
RW
0
Interrupt on Power-On-Reset Enable—When set, the IRQ is set when the
power-on-reset status bit is set.
Reset Sequencer Control Register Offset 0x08
The Control register contains registers that you can use to control the reset sequencer.
Table 7-36: Values for the Control Register at Offset 0x08
Bit
Attrib
ute
Defaul
t
Description
31:3
RO
0
Reserved.
2
RW
0
Enable SW sequenced reset entry—Enable a software sequenced reset entry
sequence. Timer delays and input qualification are ignored, and only the
software can sequence the entry.
1
RW
0
Enable SW sequenced reset bring up—Enable a software sequenced reset
bring up sequence. Timer delays and input qualification are ignored, and only
the software can sequence the bring up.
0
WO
0
Initiate Reset Sequence—Reset Sequencer writes this bit to 1 a single time in
order to trigger the hardware sequenced warm reset. Reset Sequencer verifies
that Reset Active is 0 before setting this bit, and always reads the value 0. To
monitor this sequence, verify that Reset Active is asserted, and then
subsequently de-asserted.
Reset Sequencer Software Sequenced Reset Entry Control Register Offset 0x0C
You can program the Reset Sequencer Software Sequenced Reset Entry Control register to control the
reset entry sequence of the sequencer.
When the corresponding enable bit is set, the sequencer stops when the desired reset asserts, and then sets
the Reset Asserted and waiting for SW to proceed bit. The Reset Sequencer proceeds only after the Reset
Asserted and waiting for SW to proceed bit is cleared.
Table 7-37: Values for the Reset Sequencer Software Sequenced Reset Entry Controls Register at Offset
0x0C
Bit
31:10
Attrib
ute
Defaul
t
RO
0
Qsys Interconnect
Send Feedback
Description
Reserved.
Altera Corporation
7-58
QII5V1
2014.12.15
Reset Sequencer Software Sequenced Reset Bring Up Control Register Offset 0x10
Bit
9:0
Attrib
ute
Defaul
t
RW
3FF
Description
Per-reset SW sequenced reset entry enable—This is a per-bit enable for SW
sequenced reset entry. If bitN of this register is set, the sequencer sets the bit30
of the status register when a resetN is asserted. It then waits for the bit30 of
the status register to clear before proceeding with the sequence. By default, all
bits are enabled (fully SW sequenced).
Reset Sequencer Software Sequenced Reset Bring Up Control Register Offset 0x10
You can program the Software Sequenced Reset Bring Up Control register to control the reset bring up
sequence of the sequencer.
When the corresponding enable bit is set, the sequencer stops when the desired reset asserts, and then sets
the Reset De-asserted and waiting for SW to proceed bit. The Reset Sequencer proceeds only after the
Reset De-asserted and waiting for SW to proceed bit is cleared..
Table 7-38: Values for the Reset Sequencer Software Sequenced Bring Up Control Register at Offset 0x10
Bit
Attrib
ute
Defaul
t
Description
31:10
RO
0
Reserved.
9:0
RW
3FF
Per-reset SW sequenced reset entry enable—This is a per-bit enable for SW
sequenced reset bring up. If bitN of this register is set, the sequencer sets bit29
of the status register when a resetN is asserted. It then waits for the bit29 of
the status register to clear before proceeding with the sequence. By default, all
bits are enabled (fully SW sequenced).
Reset Sequencer Software Direct Controlled Resets Offset 0x14
You can write a bit to 1 to assert the reset_outN signal, and to 0 to de-assert the reset_outN signal.
Table 7-39: Values for the Software Direct Controlled Resets at Offset 0x14
Bit
Attrib
ute
Defaul
t
Description
31:26
RO
0
Reserved.
25:16
WO
0
Reset Overwrite Trigger Enable
—This is a per-bit control trigger bit for the overwrite value to take effect.
15:10
RO
0
Reserved.
9:0
WO
0
reset_outN Reset Overwrite Value—This is a per-bit control of the reset_out
bit. The Reset Sequencer can use this to forcefully drive the reset to a specific
value. A value of 1 sets the reset_out. A value of 0 clears the reset_out. A
write to this register only takes effect if the corresponding trigger bit in this
register is set.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Reset Sequencer Software Reset Masking Offset 0x18
7-59
Reset Sequencer Software Reset Masking Offset 0x18
You can write a bit to 1 to assert the reset_outN signal, and to 0 to de-assert the reset_outN signal.
Table 7-40: Values for the Reset Sequencer Software Reset Masking at Offset 0x18
Bit
Attrib
ute
Defaul
t
31:10
RO
0
Reserved.
9:0
RW
0
reset_outN "Reset Mask Enable"—This is a per-bit control to mask the reset_
outN bit. The Software Reset Masking masks the reset bit from being asserted
during a reset assertion sequence. If the reset_out is already asserted, it does
not de-assert the reset.
Qsys Interconnect
Send Feedback
Description
Altera Corporation
7-60
QII5V1
2014.12.15
Reset Sequencer Software Flows
Reset Sequencer Software Flows
Reset Sequencer (Software-Triggered) Flow
Figure 7-29: Reset Sequencer (Software-Triggered) Flow
Software verifies there is no active reset
by ensuring bit31 (reset active bit) in the
Status Resgister is not set.
Software clears all pending statuses by
writing all 1s to the Status Register.
Software initiates reset by writing a 1 to
bit 0 of the Control Register at offset 0x08.
IRQ
Asserted?
yes
Software waits for the IRQ.
no
Software checks bit 1 of the Status
egister. When set, it indicates that Reset
Sequencer has completed initiating a
rest throught he sequencer.
Software clears bit1 of the Status Register
by writing a 1 to the Status Register.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Reset Entry Flow
7-61
Reset Entry Flow
The following flow sequence occurs for a Reset Entry Flow:
• A reset is triggered either by the software, or when input resets to the Reset Sequencer are asserted.
• The IRQ is asserted, if the IRQ is enabled.
• Software reads the Status register to determine what reset was triggered.
Reset Bring-Up Flow
The following flow sequence occurs for a Reset Bring-Up Flow:
• When a reset source is de-asserted, or when the reset entry sequence has completed without any more
pending resets asserted, the bring-up flow is initiated.
• The IRQ is asserted, if the IRQ is enabled.
• Software reads the Status register to determine what reset was triggered.
Qsys Interconnect
Send Feedback
Altera Corporation
7-62
QII5V1
2014.12.15
Reset Entry (Software-Sequenced) Flow
Reset Entry (Software-Sequenced) Flow
Figure 7-30: Reset Entry (Software-Sequenced) Flow
Software sets the Enable softwaresequenced reset entry bit (bit 2 of the
Control Register).
Software sets up which reset sequence it
wants to control (or all reset outputs) with
the Per-reset-software-sequenced
reset entry enable bit.
Software enables Interrupt on reset
asserted so that the Resrt Sequencer
waits for software upon setting the IRQ
in the sequence.
Setup is complete.
Software asserts reset.
Hardware sequences a reset where the
software has previously set up the Reset
Sequencer to wait for a software signal.
Reset Sequencer asserts an IRQ.
Software acknowledges that the reset is
asserted and bit 30 of the Status Register
is set.
Software clears Reset asserted and
waiting for software to proceed bit
30 of the Status Register and the Reset
Sequencer proceeds with the sequence.
The IRQ is set on the next Reset
Sequencer trigger point (if any).
Reset Bring-Up (Software-Sequenced) Flow
The sequence and flow is similar to the Reset Entry (SW Sequenced) flow, though, this flow uses the reset
bring-up registers/bits in place of the reset entry registers/bits.
Related Information
Reset Entry (Software-Sequenced) Flow on page 7-62
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Conduits
7-63
Conduits
You can use the conduit interface type for interfaces that do not fit any of the other interface types, and to
group any arbitrary collection of signals. Like other interface types, you can export or connect conduit
interfaces. The PCI Express-to-Ethernet example in Creating a System with Qsys is an example of using a
conduit interface for export. You can declare an associated clock interface for conduit interfaces in the
same way as memory-mapped interfaces with the associatedClock.
To connect two conduit interfaces inside Qsys, the following conditions must be met:
• The interfaces must match exactly with the same signal roles and widths.
• The interfaces must be the opposite directions.
• Clocked conduit connections must have matching associatedClocks on each of their endpoint
interfaces.
Note: To connect a conduit output to more than one input conduit interface, you can create a custom
component. The custom component could have one input that connects to two outputs, and you
can use this component between other conduits that you want to connect. For information about
the Avalon Conduit interface, refer to the Avalon Interface Specifications
Related Information
Avalon Interface Specifications
Creating a System with Qsys on page 5-1
Interconnect Pipelining
If you set the Limit interconnect pipeline stages to parameter to a value greater than 0 on the Project
Settings tab, Qsys automatically inserts Avalon-ST pipeline stages when you generate your design. The
pipeline stages increase the fMAX of your design by reducing the combinational logic depth. The cost is
additional latency and logic.
The insertion of pipeline stages depends upon the existence of certain interconnect components. For
example, in a single-slave system, no multiplexer exists; therefore multiplexer pipelining does not occur.
In an extreme case, of a single-master to single-slave system, no pipelining occurs, regardless of the value
of theLimit interconnect pipeline stages to option.
Qsys Interconnect
Send Feedback
Altera Corporation
7-64
QII5V1
2014.12.15
Interconnect Pipelining
Figure 7-31: Pipeline Placement in Arbitration Logic
The example below shows the possible placement of up to four potential pipeline stages, which could be,
before the input to the demultiplexer, at the output of the multiplexer, between the arbiter and the
multiplexer, and at the outputs of the demultiplexer.
Logic included in the Avalon-ST Command Network
Command
packet for
master 0
Command
packet for
master 1
Master 0
Arbiter
for
slave 0
Master 1
Selected request
Arbiter
Arbiter
for
for
slave
slave 11
Selected request
Master 2
Arbiter
for
slave 2
Command
packet for
master 2
Master 3
Command
packet for
master 3
Selected request
Arbiter
for
slave 3
Selected request
= Pipeline stage, masters 0-3
= Pipeline stage, selected request
Note: For more information about manually inserting and removing pipelines from your system, refer to
Creating a System With Qsys. Refer to Optimizing Qsys System Performance for more information
about pipelined Avalon-MM Interfaces.
Related Information
• Creating a System With Qsys on page 5-1
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Manually Controlling Pipelining in the Qsys Interconnect
7-65
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
4.153
4.373
0.000
0.204
0.242
0.100
0.339
0.468
0.220
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
mm_domain_0|addr_router_001|src_channel[5]~0|datad
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
Qsys Interconnect
Send Feedback
Altera Corporation
7-66
AMBA 3 AXI Protocol Specification Support (version 1.0)
QII5V1
2014.12.15
AMBA 3 AXI Protocol Specification Support (version 1.0)
Qsys allows memory-mapped connections between AXI3 components, AXI3 and AXI4 components, and
AXI3 and Avalon interfaces with some unique or exceptional support.
Refer to the AMBA 3 Protocol Specifications on the ARM website for more information.
Related Information
AMBA 3 Protocol Specifications
Channels
Qsys 14.0 has the following support and restrictions for AXI3 channels.
Read and Write Address Channels
All signals are allowed with some limitations.
The following limitations are present in Qsys 14.0:
• Supports 64-bit addressing.
• ID width limited to 18-bits.
• HPS-FPGA master interface has a 12-bit ID.
Write Data, Write Response, and Read Data Channels
All signals are allowed with some limitations.
The following limitations are present in Qsys 14.0:
• Data widths limited to a maximum of 1024-bits
• Limited to a fixed byte width of 8-bits
Low Power Channel
Low power extensions are not supported in Qsys, version 14.0.
Cache Support
AWCACHE and ARCACHE are passed to an AXI slave unmodified.
Bufferable
Qsys interconnect treats AXI transactions as non-bufferable. All responses must come from the terminal
slave.
When connecting to Avalon-MM slaves, since they do not have write responses, the following exceptions
apply:
• For Avalon-MM slaves, the write response are generated by the slave agent once the write transaction
is accepted by the slave. The following limitation exists for an Avalon bridge:
• For an Avalon bridge, the response is generated before the write reaches the endpoint; users must be
aware of this limitation and avoid multiple paths past the bridge to any endpoint slave, or only
perform bufferable transactions to an Avalon bridge.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Cacheable (Modifiable)
7-67
Cacheable (Modifiable)
Qsys interconnect acknowledges the cacheable (modifiable) attribute of AXI transactions.
It does not change the address, burst length, or burst size of non-modifiable transactions, with the
following exceptions:
• Qsys considers a wide transaction to a narrow slave as modifiable because the size requires reduction.
• Qsys may consider AXI read and write transactions as modifiable when the destination is an Avalon
slave. The AXI transaction may be split into multiple Avalon transactions if the slave is unable to
accept the transaction. This may occur because of burst lengths, narrow sizes, or burst types.
Qsys ignores all other bits, for example, read allocate or write allocate because the interconnect does not
perform caching. By default, Qsys considers Avalon master transactions as non-bufferable and noncacheable, with the allocate bits tied low. Qsys provides compile-time options to control the cache
behavior of Avalon transactions on a per-master basis.
Security Support
TrustZone refers to the security extension of the ARM architecture, which includes the concept of "secure"
and "non-secure" transactions, and a protocol for processing between the designations.
The interconnect passes the AWPROT and ARPROT signals to the endpoint slave without modification. It
does not use or modify the PROT bits.
Refer to Creating a System with Qsys for more information about secure systems and the TrustZone
feature.
Related Information
• Creating a System with Qsys on page 5-1
Atomic Accesses
Exclusive accesses are supported for AXI slaves by passing the lock, transaction ID, and response signals
from master to slave, with the limitation that slaves that do not reorder responses. Avalon slaves do not
support exclusive accesses, and always return OKAY as a response. Locked accesses are also not supported.
Response Signaling
Full response signaling is supported. Avalon slaves always return OKAY as a response.
Ordering Model
Qsys interconnect provides responses in the same order as the commands are issued.
To prevent reordering, for slaves that accept reordering depths greater than 0, Qsys does not transfer the
transaction ID from the master, but provides a constant transaction ID of 0. For slaves that do not
reorder, Qsys allows the transaction ID to be transferred to the slave. To avoid cyclic dependencies, Qsys
supports a single outstanding slave scheme for both reads and writes. Changing the targeted slave before
all responses have returned stalls the master, regardless of transaction ID.
AXI and Avalon Ordering
According to the AMBA Protocol Specifications, there is no ordering requirement between reads and
writes. However, Avalon has an implicit ordering model that requires transactions from a master to the
same slave to be in order. As a result, there is a potential read-after-write risk when Avalon masters
Qsys Interconnect
Send Feedback
Altera Corporation
7-68
QII5V1
2014.12.15
Data Buses
transact to AXI slaves. In response to this potential risk, Avalon interfaces provide a compile-time option
to enforce strict order. When turned on, the Avalon interface waits for outstanding write responses before
issuing reads.
Data Buses
Narrow bus transfers are supported. AXI write strobes can have any pattern that is compatible with the
address and size information. Altera recommends that transactions to Avalon slaves follow Avalon
byteenable limitations for maximum compatibility.
Note: Byte 0 is always bits [7:0] in the interconnect, following AXI's and Avalon's byte (address)
invariance scheme.
Unaligned Address Commands
Unaligned address commands are commands with addresses that do not conform to the data width of a
slave. Since Avalon-MM slaves accept only aligned addresses, Qsys modifies unaligned commands from
AXI masters to the correct data width. Qsys must preserve commands issued by AXI masters when
passing the commands to AXI slaves.
Note: Unaligned transfers are aligned if downsizing occurs. For example, when downsizing to a bus
width narrower than that required by the transaction size, AWSIZE or ARSIZE, the transaction must
be modified.
Avalon and AXI Transaction Support
Qsys 14.0 supports transactions between Avalon and interfaces with some limitations.
Transaction Cannot Cross 4KB Boundaries
When an Avalon master issues a transaction to an AXI slave, the transaction cannot cross 4KB
boundaries. Non-bursting Avalon masters already follow this boundary restriction.
Handling Read Side Effects
Read side effects can occur when more bytes than necessary are read from the slave, and the unwanted
data that are read are later inaccessible on subsequent reads. For write commands, the correct byteenable
paths are asserted based on the size of the transactions. For read commands, narrow-sized bursts are
broken up into multiple non-bursting commands, and each command with the correct byteenable paths
asserted.
Note: Qsys always assumes that the byteenable is asserted based on the size of the command, not the
address of the command. The following scenarios are examples:
• For a 32-bit AXI master that issues a read command with an unaligned address starting at
address 0x01, and a burstcount of 2 to a 32-bit Avalon slave, the starting address is: 0x00.
• For a 32-bit AXI master that issues a read command with an unaligned address starting at
address 0x01, with 4-bytes to an 8-bit AXI slave, the starting address is: 0x00.
AMBA 3 APB Protocol Specification Support (version 1.0)
AMBA APB provides a low-cost interface that is optimized for minimal power consumption and reduced
interface complexity. You can use AMBA APB to interface to peripherals which are low-bandwidth and
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Bridges
7-69
do not require the high performance of a pipelined bus interface. Signal transitions are sampled at the
rising edge of the clock to enable the integration of APB peripherals easily into any design flow.
Qsys allows connections between APB components, and AXI3, AXI4, and Avalon memory-mapped
interfaces. The following sections describe unique or exceptional APB support in the Qsys software.
Refer to the AMBA APB Protocol Specifications for AXI4 on the ARM website for more information.
Related Information
AMBA APB Protocol Specifications
Bridges
With APB, you cannot use bridge components that use multiple PSELx in Qsys. As a workaround, you can
group PSELx, and then send the packet to the slave directly.
Altera recommends as an alternative that you instantiate the APB bridge and all the APB slaves in Qsys.
You should then connect the slave side of the bridge to any high speed interface and connect the master
side of the bridge to the APB slaves. Qsys creates the interconnect on either side of the APB bridge and
creates only one PSEL signal.
Alternatively, you can connect a bridge to the APB bus outside of Qsys. Use an Avalon/AXI bridge to
export the Avalon/AXI master to the top-level, and then connect this Avalon/AXI interface to the slave
side of the APB bridge. Alternatively, instantiate the APB bridge in Qsys and export APB master to the
top- level, and from there connect to APB bus outside of Qsys.
Burst Adaptation
APB is a non-bursting interface. Therefore, for any AXI or Avalon master with bursting support, a burst
adapter is inserted before the slave interface and the burst transaction is translated into a series of nonbursting transactions before reaching the APB slave.
Width Adaptation
Qsys allows different data width connections with APB. When connecting a wider master to a narrower
APB slave, the width adapter converts the wider transactions to a narrower transaction to fit the APB
slave data width. APB does not support Write Strobe. Therefore, when you connect a narrower
transaction to a wider APB slave, the slave cannot determine which byte lane to write. In this case, the
slave data may be overwritten or corrupted.
Error Response
Error responses are returned to the master. Qsys performs error mapping if the master is an AXI3 or
AXI4 master, for example, RRESP/BRESP= SLVERR. For the case when the slave does not use SLVERR
signal, an OKAY response is sent back to master by default.
AMBA AXI4 Memory-Mapped Interface Support (version 2.0)
Qsys allows memory-mapped connections between AXI4 components, AXI4 and AXI3 components, and
AXI4 and Avalon interfaces with some unique or exceptional support.
Qsys Interconnect
Send Feedback
Altera Corporation
7-70
QII5V1
2014.12.15
Burst Support
Burst Support
Qsys supports INCR bursts up to 256 beats. Qsys converts long bursts to multiple bursts in a packet with
each burst having a length less than or equal to MAX_BURST when going to AXI3 or Avalon slaves.
For narrow-sized transfers, bursts with Avalon slaves as destinations are shortened to multiple nonbursting transactions in order to transmit the correct address to the slaves, since Avalon slaves always
perform full-sized datawidth transactions.
Bursts with AXI3 slaves as destinations are shortened to multiple bursts, with each burst length less than
or equal to 16. Bursts with AXI4 slaves as destinations are not shortened.
QoS
Qsys routes 4-bit QoS signals (Quality of Service Signaling) on the read and write address channels
directly from the master to the slave.
Transactions from AXI3 and Avalon masters have a default value of 4'b0000, which indicates that the
transactions are not part of the QoS flow. QoS values are not used for slaves that do not support QoS.
For Qsys 14.0, there are no programmable QoS registers or compile-time QoS options for a master that
overrides its real or default value.
Regions
For Qsys 14.0, there is no support for the optional regions feature. AXI4 slaves with AXREGION signals are
allowed. AXREGION signals are driven with the default value of 0x0, and are limited to one entry in a
master's address map.
Write Response Dependency
Write response dependency as specified in the AMBA Protocol Specifications for AXI4 is not supported.
Related Information
AMBA Protocol Specifications
AWCACHE and ARCACHE
For AXI4, Qsys meets the requirement for modifiable and non-modifiable transactions. The modifiable
bit refers to ARCACHE[1]and AWCACHE[1].
Width Adaptation and Data Packing in Qsys
Data packing applies only to systems where the data width of masters is less than the data width of slaves.
The following rules apply:
• Data packing is supported when masters and slaves are Avalon-MM.
• Data packing is not supported when any master or slave is an AXI3, AXI4, or APB component.
For example, for a read/write command with a 32-bit master connected to a 64-bit slave, and a transaction
of 2 burstcounts, Qsys sends 2 separate read/write commands to access the 64-bit data width of the slave.
Data packing is only supported if the system does not contain AXI3, AXI4, or APB masters or slaves.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Ordering Model
7-71
Ordering Model
Out of order support is not implemented in Qsys, version 14.0. Qsys processes AXI slaves as device nonbufferable memory types.
The following describes the required behavior for the device non-bufferable memory type:
•
•
•
•
•
Write response must be obtained from the final destination.
Read data must be obtained from the final destination.
Transaction characteristics must not be modified.
Reads must not be pre-fetched. Writes must not be merged.
Non-modifiable read and write transactions.
(AWCACHE[1] = 0 or ARCACHE[1] = 0) from the same ID to the same slave must remain ordered. The
interconnect always provides responses in the same order as the commands issued. Slaves that support
reordering provide a constant transaction ID to prevent reordering. AXI slaves that do not reorder are
provided with transaction IDs, which allows exclusive accesses to be used for such slaves.
Read and Write Allocate
Read and write allocate does not apply to Qsys interconnect, which does not have caching features, and
always receives responses from an endpoint.
Locked Transactions
Locked transactions are not supported for Qsys, version 14.0.
Memory Types
For AXI4, Qsys processes transactions as though the endpoint is a device memory type. For device
memory types, using non-bufferable transactions to force previous bufferable transactions to finish is
irrelevant, because Qsys interconnect always identifies transactions as being non-bufferable.
Mismatched Attributes
There are rules for how multiple masters issue cache values to a shared memory region. The interconnect
meets requirements as long as cache signals are not modified.
Signals
Qsys supports up to 64-bits for the BUSER, WUSER and RUSER sideband signals. AXI4 allows some signals to
be omitted from interfaces by aligning them with the default values as defined in the AMBA Protocol
Specifications on the ARM website.
Related Information
AMBA Protocol Specifications
AMBA AXI4 Streaming Interface Support (version 1.0)
Connection Points
Qsys allows you to connect an AXI4 stream interface to another AXI4 stream interface.
Qsys Interconnect
Send Feedback
Altera Corporation
7-72
QII5V1
2014.12.15
AXI4 Streaming Connection Point Parameters
The connection is point-to-point without adaptation and must be between an axi4stream_master and
axi4stream_slave. Connected interfaces must have the same port roles and widths.
Non matching master to slave connections, and multiple masters to multiple slaves connections are not
supported.
AXI4 Streaming Connection Point Parameters
Table 7-41: AXI4 Streaming Connection Point Parameters
Name
Type
Description
associatedClock
string
Name of associated clock interface.
associatedReset
string
Name of associated reset interface
AXI4 Streaming Connection Point Signals
Table 7-42: AXI4 Stream Connection Point Signals
Port Role
Width
Master
Direction
Slave Direction
Required
tvalid
1
Output
Input
Yes
tready
1
Input
Output
No
tdata(6)
8:4096
Output
Input
No
tstrb
1:512
Output
Input
No
tkeep
1:512
Output
Input
No
tid(7)
1:8
Output
Input
No
tdest(8)
1:4
Output
Input
No
tuser(9)
1:4096
Output
Input
No
tlast
1
Output
Input
No
Adaptation
AXI4 stream adaptation support is not available. AXI4 stream master and slave interface signals and
widths must match.
AMBA AXI4-Lite Protocol Specification Support (version 2.0)
AXI4-Lite is a sub-set of AMBA AXI4. It is suitable for simpler control register-style interfaces that do not
require the full functionality of AXI4.
(6)
(7)
(8)
(9)
integer in mutiple of bytes
maximum 8-bits
maximum 4-bits
number of bits in multiple of the number of bytes of tdata
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
AXI4-Lite Signals
7-73
Qsys 14.0 supports the following AXI4-Lite features:
• Transactions with a burst length of 1.
• Data accesses use the full width of a data bus (32- bit or 64-bit) for data accesses, and no narrow-size
transactions.
• Non-modifiable and non-bufferable accesses.
• No exclusive accesses.
AXI4-Lite Signals
Qsys supports all AXI4-Lite interface signals. All signals are required.
Table 7-43: AXI4-Lite Signals
Global
Write Address
Channel
Write Data
Channel
Write
Response
Channel
Read Address
Channel
Read Data Channel
ACLK
AWVALID
WVALID
BVALID
ARVALID
RVALID
ARESETn
AWREADY
WREADY
BREADY
ARREADY
RREADY
-
AWADDR
WDATA
BRESP
ARADDR
RDATA
-
AWPROT
WSTRB
ARPROT
RRESP
-
AXI4-Lite Bus Width
AXI4-Lite masters or slaves must have either 32-bit or 64-bit bus widths. Qsys interconnect inserts a
width adapter if a master and slave pair have different widths.
AXI4-Lite Outstanding Transactions
AXI-Lite supports outstanding transactions. The options to control outstanding transactions is set in the
parameter editor for the selected component.
AXI4-Lite IDs
AXI4-Lite does not support IDs. Qsys performs ID reflection inside the slave agent.
Connections Between AXI3/4 and AXI4-Lite
AXI4-Lite Slave Requirements
For an AXI4-Lite slave side, the master can be any master interface type, such as an Avalon (with
bursting), AXI3, or AXI4. Qsys allows the following connections and inserts adapters, if needed.
Qsys Interconnect
Send Feedback
Altera Corporation
7-74
QII5V1
2014.12.15
AXI4-Lite Data Packing
• Burst adapter—Avalon and AXI3 and AXI4 bursting masters require a burst adapter to shorten the
burst length to 1 before sending a transaction to an AXI4-Lite slave.
• Qsys interconnect uses a width adapter for mismatched data widths.
• Qsys interconnect performs ID reflection inside the slave agent.
• An AXI4-Lite slave must have an address width of at least 12-bits.
• AXI4-Lite does not have the AXSIZE parameter. Narrow master to a wide AXI4-Lite slave is not
supported. For masters that support narrow-sized bursts, for example, AXI3 and AXI4, a burst to an
AXI4-Lite slave must have a burst size equal to or greater than the slave's burst size.
AXI4-Lite Data Packing
Qsys interconnect does not support AXI4-Lite data packing.
AXI4-Lite Response Merging
When Qsys interconnect merges SLVERR and DECERR, the error responses are not sticky. The response is
based on priority and the master always sees a DECERR. When SLVERR and DECERR are merged, it is based
on their priorities, not stickiness. DECERR receives priority in this case, even if SLVERR returns first.
Port Roles (Interface Signal Types)
Each interfaces defines a number of signal roles and their behavior. Many signal roles are optional,
allowing IP component designers the flexibility to select only the signal roles necessary to implement the
required functionality.
AXI Master Interface Signal Types
Table 7-44: AXI Master Interface Signal Types
Name
Direction
Width
araddr
output
1 - 64
arburst
output
2
arcache
output
4
arid
output
1 - 18
arlen
output
4
arlock
output
2
arprot
output
3
arready
input
1
arsize
output
3
aruser
output
1 - 64
arvalid
output
1
awaddr
output
1 - 64
awburst
output
2
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
AXI Slave Interface Signal Types
Name
Direction
7-75
Width
awcache
output
4
awid
output
1 - 18
awlen
output
4
awlock
output
2
awprot
output
3
awready
input
1
awsize
output
3
awuser
output
1 - 64
awvalid
output
1
bid
input
1 - 18
bready
output
1
bresp
input
2
bvalid
input
1
rdata
input
8, 16, 32, 64, 128, 256, 512, 1024
rid
input
1 - 18
rlast
input
1
rready
output
1
rresp
input
2
rvalid
input
1
wdata
output
8, 16, 32, 64, 128, 256, 512, 1024
wid
output
1 - 18
wlast
output
1
wready
input
1
wstrb
output
1, 2, 4, 8, 16, 32, 64, 128
wvalid
output
1
AXI Slave Interface Signal Types
Table 7-45: AXI Slave Interface Signal Types
Name
Direction
Width
araddr
input
1 - 64
arburst
input
2
Qsys Interconnect
Send Feedback
Altera Corporation
7-76
QII5V1
2014.12.15
AXI Slave Interface Signal Types
Name
Direction
Width
arcache
input
4
arid
input
1 - 18
arlen
input
4
arlock
input
2
arprot
input
3
arready
output
1
arsize
input
3
aruser
input
1 - 64
arvalid
input
1
awaddr
input
1 - 64
awburst
input
2
awcache
input
4
awid
input
1 - 18
awlen
input
4
awlock
input
2
awprot
input
3
awready
output
1
awsize
input
3
awuser
input
1 - 64
awvalid
input
1
bid
output
1 - 18
bready
input
1
bresp
output
2
bvalid
output
1
rdata
output
8, 16, 32, 64, 128, 256, 512, 1024
rid
output
1 - 18
rlast
output
1
rready
input
1
rresp
output
2
rvalid
output
1
wdata
input
8, 16, 32, 64, 128, 256, 512, 1024
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
AXI4 Master Interface Signal Types
Name
Direction
7-77
Width
wid
input
1 - 18
wlast
input
1
wready
output
1
wstrb
input
1, 2, 4, 8, 16, 32, 64, 128
wvalid
input
1
AXI4 Master Interface Signal Types
Table 7-46: AXI4 Master Interface Signal Types
Name
Direction
Width
araddr
output
1 - 64
arburst
output
2
arcache
output
4
arid
output
1 - 18
arlen
output
8
arlock
output
1
arprot
output
3
arready
input
1
arregion
output
1-4
arsize
output
3
aruser
output
1 - 64
arvalid
output
1
awaddr
output
1 - 64
awburst
output
2
awcache
output
4
awid
output
1 - 18
awlen
output
8
awlock
output
1
awprot
output
3
awqos
output
1-4
awready
input
1
awregion
output
1-4
Qsys Interconnect
Send Feedback
Altera Corporation
7-78
QII5V1
2014.12.15
AXI4 Slave Interface Signal Types
Name
Direction
Width
awsize
output
3
awuser
output
1 - 64
awvalid
output
1
bid
input
1 - 18
bready
output
1
bresp
input
2
buser
input
1 - 64
bvalid
input
1
rdata
input
8, 16, 32, 64, 128, 256, 512, 1024
rid
input
1 - 18
rlast
input
1
rready
output
1
rresp
input
2
ruser
input
1 - 64
rvalid
input
1
wdata
output
8, 16, 32, 64, 128, 256, 512, 1024
wid
output
1 - 18
wlast
output
1
wready
input
1
wstrb
output
1, 2, 4, 8, 16, 32, 64, 128
wuser
output
1 - 64
wvalid
output
1
AXI4 Slave Interface Signal Types
Table 7-47: AXI4 Slave Interface Signal Types
Name
Direction
Width
araddr
input
1 - 64
arburst
input
2
arcache
input
4
arid
input
1 - 18
arlen
input
8
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
AXI4 Slave Interface Signal Types
Name
Direction
Width
arlock
input
1
arprot
input
3
arqos
input
1-4
arready
output
1
arregion
input
1-4
arsize
input
3
aruser
input
1 - 64
arvalid
input
1
awaddr
input
1 - 64
awburst
input
2
awcache
input
4
awid
input
1 - 18
awlen
input
8
awlock
input
1
awprot
input
3
awqos
input
1-4
awready
output
1
awregion
inout
1-4
awsize
input
3
awuser
input
1 - 64
awvalid
input
1
bid
output
1 - 18
bready
input
1
bresp
output
2
bvalid
output
1
rdata
output
8, 16, 32, 64, 128, 256, 512, 1024
rid
output
1 - 18
rlast
output
1
rready
input
1
rresp
output
2
ruser
output
1 - 64
Qsys Interconnect
Send Feedback
7-79
Altera Corporation
7-80
QII5V1
2014.12.15
AXI4 Stream Master and Slave Interface Signal Types
Name
Direction
Width
rvalid
output
1
wdata
input
8, 16, 32, 64, 128, 256, 512, 1024
wlast
input
1
wready
output
1
wstrb
input
1, 2, 4, 8, 16, 32, 64, 128
wuser
input
1 - 64
wvalid
input
1
AXI4 Stream Master and Slave Interface Signal Types
Table 7-48: AXI4 Stream Master and Slave Interface Signal Types
Name
Width
Master Direction
Slave Direction
Required
tvalid
1
Output
Input
Yes
tready
1
Input
Output
No
tdata
8:4096
Output
Input
No
tstrb
1:512
Output
Input
No
tkeep
1:512
Output
Input
No
tid
1:8
Output
Input
No
tdest
1:4
Output
Input
No
tuser
1
Output
Input
No
tlast
1:4096
Output
Input
No
APB Interface Signal Types
Table 7-49: APB Interface Signal Types
Name
Width
Direction
Direction
APB Master
APB Slave
Required
paddr
[1:32]
output
input
yes
psel
[1:16]
output
input
yes
penable
1
output
input
yes
pwrite
1
output
input
yes
pwdata
[1:32]
output
input
yes
prdata
[1:32]
input
output
yes
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Avalon Memory-Mapped Interface Signal Types
Name
Width
Direction
Direction
APB Master
APB Slave
7-81
Required
pslverr
1
input
output
no
pready
1
input
output
yes
paddr31
1
output
input
no
Avalon Memory-Mapped Interface Signal Types
The following table lists the signal roles that constitute the Avalon-MM interface. The signal roles allow
you to create masters that use bursts for reads and writes. You can increase the throughput of your system
by initiating reads with multiple pipelined slave peripherals. In responding to reads, when a slave
peripheral has valid data it asserts readdatavalid . The interconnect enables the connection between the
master and slave pair.
This specification does not require all signals to exist in an Avalon-MM interface. In fact, there is no one
signal that is always required. The minimum requirements are readdata for a read-only interface or
writedata and write for a write-only interface.
Table 7-50: Avalon-MM Signals
All Avalon signals are active high. Avalon signals that can also be asserted low list _n versions of the signal in the
Signal role column.
Signal Role
Width
Direction
Description
Fundamental Signals
address
1 - 64
Master →
Slave
Masters: By default, the address signal
represents a byte address. The value of the
address must be aligned to the data width. To
write to specific bytes within a data word, the
master must use the byteenable signal. Refer
to the addressUnits interface property for
word addressing.
Slaves: By default, the interconnect translates
the byte address into a word address in the
slave’s address space. Each slave access is for a
word of data from the perspective of the slave.
For example, address= 0 selects the first word
of the slave. Address 1 selects the second word
of the slave. Refer to the addressUnits
interface property for byte addressing.
Qsys Interconnect
Send Feedback
Altera Corporation
7-82
QII5V1
2014.12.15
Avalon Memory-Mapped Interface Signal Types
Signal Role
byteenable
byteenable_n
Width
Direction
2, 4, 8, 16,
32, 64, 128
Master →
Slave
Description
Enables specific byte lane(s) during transfers on
ports of width greater than 8 bits. Each bit in
byteenable corresponds to a byte in
writedata and readdata. The master bit <n>
of byteenable indicates whether byte <n> is
being written to. During writes, byteenables
specify which bytes are being written to. Other
bytes should be ignored by the slave. During
reads, byteenables indicate which bytes the
master is reading. Slaves that simply return
readdata with no side effects are free to ignore
byteenables during reads. If an interface does
not have a byteenable signal, the transfer
proceeds as if all byteenables are asserted.
When more than one bit of the byteenable
signal is asserted, all asserted lanes are adjacent.
The number of adjacent lines must be a power
of 2. The specified bytes must be aligned on an
address boundary for the size of the data. For
example, the following values are legal for a 32bit slave:
•
•
•
•
•
•
•
1111 writes full 32 bits
0011 writes lower 2 bytes
1100 writes upper 2 bytes
0001 writes byte 0 only
0010 writes byte 1 only
0100 writes byte 2 only
1000 writes byte 3 only
Altera strongly recommends that you use the
byteenable signal in components that will be
used in systems with different word sizes. Using
byte enables avoids unintended side effects in
systems that include width adapters.
debugaccess
1
Master →
Slave
When asserted, allows internal memories that
are normally write-protected to be written. For
example, on-chip ROM memories can only be
written when debugaccess is asserted.
read
1
Master →
Slave
Asserted to indicate a read transfer. If present,
readdata is required.
8,16, 32,
64,
128, 256,
512, 1024
Slave →
Master
read_n
readdata
Altera Corporation
The readdata driven from the slave to the
master in response to a read transfer.
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Avalon Memory-Mapped Interface Signal Types
Signal Role
response
Width
Direction
2
Slave →
Master
(optional)
7-83
Description
The response signal indicates the status of a
transaction, as follows:
• 00: OKAY—Successful response for a
transaction.
• 01: RESERVED—Encoding is reserved.
• 10: SLAVEERROR—Error from an endpoint
slave. Indicates an unsuccessful transaction.
• 11: DECODEERROR—Indicates attempted
access to an undefined location.
Every readdata in a burst receives a read
response.
To support read response, the interface must be
read capable.
When a read response returns an error, the
slave determines the readdata value, and the
master ignores the readdata value.
All read transactions must return a response if
the component supports read response.
write
1
Master →
Slave
Asserted to indicate a write transfer. If present,
writedata is required.
8,16, 32,
64,
128, 256,
512, 1024
Master →
Slave
Data for write transfers. The width must be the
same as the width of readdata if both are
present.
write_n
writedata
Wait-State Signals
Qsys Interconnect
Send Feedback
Altera Corporation
7-84
QII5V1
2014.12.15
Avalon Memory-Mapped Interface Signal Types
Signal Role
lock
Width
Direction
1
Master →
Slave
Description
lock ensures that once a master wins arbitra‐
tion, it maintains access to the slave for
multiple transactions. It is asserted coincident
with the first read or write of a locked
sequence of transactions. It is deasserted on the
final transaction of a locked sequence of
transactions. lock assertion does not guarantee
that arbitration will be won. After the lockasserting master has been granted, it retains
grant until it is deasserted.
A master equipped with lock cannot be a burst
master. Arbitration priority values for lockequipped masters are ignored.
lock is particularly useful for read-modifywrite (RMW) operations. The typical readmodify-write operation includes the following
steps:
1. Master A reads 32-bit data that has multiple
bit fields.
2. Master A changes one bit field and writes
the 32-bit data back.
prevents master B from performing a
write between Master A’s read and write. lock
also ensures that master A does not overwrite
master B’s changes.
lock
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Avalon Memory-Mapped Interface Signal Types
Signal Role
waitrequest
Width
Direction
1
Slave →
Master
waitrequest_n
7-85
Description
Asserted by the slave when it is unable to
respond to a read or write request. Forces the
master to wait until the interconnect is ready to
proceed with the transfer. At the start of all
transfers, a master initiates the transfer and
waits until waitrequest is deasserted. A master
must make no assumption about the assertion
state of waitrequest when the master is idle:
waitrequest may be high or low, depending
on system properties.
When waitrequest is asserted, master control
signals to the slave to remain constant with the
exception of beginbursttransfer. For a
timing diagram illustrating the beginbursttransfer signal, refer to the figure in Read
Bursts.
An Avalon-MM slave may assert waitrequest
during idle cycles. An Avalon-MM master may
initiate a transaction when waitrequest is
asserted and wait for that signal to be
deasserted. To avoid system lockup, a slave
device should assert waitrequest when in
reset.
Pipeline Signals
readdatavalid
readdatavalid_n
1
Slave →
Master
Used for variable-latency, pipelined read
transfers. When asserted, indicates that the
readdata signal contains valid data. A slave
with readdatavalid must assert this signal for
one cycle for each read access received. There
must be at least one cycle of latency between
acceptance of the read and assertion of
readdatavalid. For a timing diagram
illustrating the readdatavalid signal, refer to
Pipelined Read Transfer with Variable Latency.
A slave may assert readdatavalid to transfer
data to the master independently of whether or
not the slave is stalling a new command with
waitrequest.
Required if the master supports pipelined
reads. Bursting masters with read functionality
must include the readdatavalid signal.
Burst Signals
Qsys Interconnect
Send Feedback
Altera Corporation
7-86
QII5V1
2014.12.15
Avalon Streaming Interface Signals
Signal Role
burstcount
Width
Direction
1 – 11
Master →
Slave
Description
Used by bursting masters to indicate the
number of transfers in each burst. The value of
the maximum burstcount parameter must be
a power of 2. A burstcount port of width <n>
can encode a max burst of size 2(<n>-1). For
example, a 4-bit burstcount signal can support
a maximum burst count of 8. The minimum
burstcount is 1. The constantBurst property
controls the timing of the burstcount signal.
Bursting masters with read functionality must
include the readdatavalid signal.
For bursting masters and slaves, the following
restriction applies to the width of the address:
<address_w> >= <burstcount_w> +
floor(log2(<symbols_per_word_of_
interface>))
beginbursttransfer
1
Interconnect Asserted for the first cycle of a burst to indicate
→ Slave
when a burst transfer is starting. This signal is
deasserted after one cycle regardless of the
value of waitrequest. The interconnect fabric
automatically generates this signal for slaves
when requested. For a timing diagram
illustrating beginbursttransfer, refer to the
figure in Read Bursts.
beginbursttransfer is optional. A slave can
always internally calculate the start of the next
write burst transaction by counting data
transfers.
Altera recommends that you do not use this
signal. This signal exists to support legacy
memory controllers.
Avalon Streaming Interface Signals
Each signal in an Avalon-ST source or sink interface corresponds to one Avalon-ST signal role. An
Avalon-ST interface may contain only one instance of each signal role. All Avalon-ST signal roles apply to
both sources and sinks and have the same meaning for both.
Table 7-51: Avalon-ST Interface Signals
In the following table, all signal roles are active high.
Signal Role
Width
Direction
Description
Fundamental Signals
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Avalon Clock Source Signal Roles
Signal Role
channel
Width
Direction
1 – 128
Source → The channel number for data being transferred on the
Sink
current cycle.
7-87
Description
If an interface supports the channel signal, it must also
define the maxChannel parameter.
data
1 – 4,096 Source → The data signal from the source to the sink, typically
Sink
carries the bulk of the information being transferred.
The contents and format of the data signal is further
defined by parameters.
error
1 – 256
ready
1
Source → A bit mask used to mark errors affecting the data being
Sink
transferred in the current cycle. A single bit in error is
used for each of the errors recognized by the component, as
defined by the errorDescriptor property.
Sink →
Source
Asserted high to indicate that the sink can accept data.
ready is asserted by the sink on cycle <n> to mark cycle <n
+ readyLatency> as a ready cycle. The source may only
assert valid and transfer data during ready cycles.
Sources without a ready input cannot be backpressured.
Sinks without a ready output never need to backpressure.
valid
1
Source → Asserted by the source to qualify all other source to sink
Sink
signals. The sink samples data other source-to-sink signals
on ready cycles where valid is asserted. All other cycles are
ignored.
Sources without a valid output implicitly provide valid
data on every cycle that they are not being backpressured.
Sinks without a valid input expect valid data on every
cycle that they are not backpressuring.
Packet Transfer Signals
empty
1–8
Source → Indicates the number of symbols that are empty during
Sink
cycles that contain the end of a packet. The empty signal is
not used on interfaces where there is one symbol per beat.
If endofpacket is not asserted, this signal is not
interpreted.
endofpacket
1
Source → Asserted by the source to mark the end of a packet.
Sink
startofpacket
1
Source → Asserted by the source to mark the beginning of a packet.
Sink
Avalon Clock Source Signal Roles
An Avalon Clock source interface drives a clock signal out of a component.
Qsys Interconnect
Send Feedback
Altera Corporation
7-88
QII5V1
2014.12.15
Avalon Clock Sink Signal Roles
Table 7-52: Clock Source Signal Roles
Signal Role
clk
Width
Direction
Require
d
1
Output
Yes
Description
An output clock signal.
Avalon Clock Sink Signal Roles
A clock sink provides a timing reference for other interfaces and internal logic.
Table 7-53: Clock Input Signal Roles
Signal Role
clk
Width
Direction
Require
d
1
Input
Yes
Description
A clock signal. Provides synchronization for internal
logic and for other interfaces.
Avalon Conduit Signals
Table 7-54: Conduit Signal Roles
Signal Role
Width
Direction
<any>
<n>
In, out, or
bidirectional
Description
A conduit interface consists of one or more input, output, or
bidirectional signals of arbitrary width. Conduits can have any
user-specified role. You can connect compatible Conduit
interfaces inside a Qsys system provided the roles and widths
match and the directions are opposite.
Avalon Tristate Conduit Signals
The following table lists the signal defined for the Avalon Tristate Conduit interface. All Avalon-TC
signals apply to both masters and slaves and have the same meaning for both
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Avalon Tristate Conduit Signals
7-89
Table 7-55: Tristate Conduit Interface Signal Roles
Signal Role
Width
Direction
Require
d
request
1
Master →
Slave
Yes
Description
The meaning of request depends on the state of
the grant signal, as the following rules dictate.
When request is asserted and grant is deasserted,
request is requesting access for the current cycle.
When request is asserted and grant is asserted,
request is requesting access for the next cycle.
Consequently, request should be deasserted on
the final cycle of an access.
The request is deasserted in the last cycle of a bus
access. It can be reasserted immediately following
the final cycle of a transfer. This protocol makes
both rearbitration and continuous bus access
possible if no other masters are requesting access.
Once asserted, request must remain asserted until
granted. Consequently, the shortest bus access is 2
cycles. Refer to Tristate Conduit Arbitration
Timing for an example of arbitration timing.
grant
1
Slave →
Master
Yes
When asserted, indicates that a tristate conduit
master has been granted access to perform transac‐
tions. grant is asserted in response to the request
signal. It remains asserted until 1 cycle following
the deassertion of request.
The design of the Avalon-TC Interface does not
allow a default Avalon-TC master to be granted
access when no masters are requesting.
<name>_in
<name>_
out
<name>_
outen
Qsys Interconnect
Send Feedback
1 – 1024
Slave →
Master
No
The input signal of a logical tristate signal.
1 – 1024
Master →
Slave
No
The output signal of a logical tristate signal.
1
Master →
Slave
No
The output enable for a logical tristate signal.
Altera Corporation
7-90
QII5V1
2014.12.15
Avalon Tri-State Slave Interface Signal Types
Avalon Tri-State Slave Interface Signal Types
Table 7-56: Tri-state Slave Interface Signal Types
Name
address
read
Width
Direction
Required
1 - 32
input
No
Address lines to the slave
port. Specifies a byte offset
into the slave’s address space.
1
input
No
Read-request signal. Not
required if the slave port
never outputs data.
read_n
Description
If present, data must also be
used.
write
1
input
No
write_n
Write-request signal. Not
required if the slave port
never receives data from a
master.
If present, data must also be
present, and writebyteenable cannot be present.
chipselect
1
input
No
When present, the slave port
ignores all Avalon-MM
signals unless chipselect is
asserted. chipselect is
always present in combina‐
tion with read or write
1
input
Yes
Output-enable signal. When
deasserted, a tri-state slave
port must not drive its data
lines otherwise data
contention may occur.
8,16, 32, 64,
128, 256, 512,
1024
bidir
No
Bidirectional data. During
write transfers, the FPGA
drives the data lines. During
read transfers the slave device
drives the data lines, and the
FPGA captures the data
signals and provides them to
the master.
chipselect_n
outputenable
outputenable_n
data
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Avalon Tri-State Slave Interface Signal Types
Name
byteenable
Width
Direction
Required
2, 4, 8,16, 32,
64, 128
input
No
byteenable_n
7-91
Description
Enables specific byte lane(s)
during transfers.
Each bit in byteenable
corresponds to a byte lane in
data. During writes, byteenables specify which bytes the
master is writing to the slave.
During reads, byteenables
indicates which bytes the
master is reading. Slaves that
simply return data with no
side effects are free to ignore
byteenables during reads.
When more than one byte
lane is asserted, all asserted
lanes are guaranteed to be
adjacent. The number of
adjacent lines must be a
power of 2, and the specified
bytes must be aligned on an
address boundary for the size
of the data. The are legal
values for a 32-bit slave:
1111
32 bits
0011
2 bytes
1100
2 bytes
0001
only
0010
only
0100
only
1000
only
writebyteenable
writes lower
writes upper
writes byte 0
writes byte 1
writes byte 2
writes byte 3
2,4,8,16, 32,
64,128
input
No
Equivalent to the logical AND
of the byteenable and write
signals. When used, the write
signal is not used.
1
input
No
Asserted for the first cycle of
each transfer.
writebyteenable_n
begintransfer1
writes full
Note: All Avalon signals are active high. Avalon signals that can also be asserted low list both
versions in the Signal Role column.
Qsys Interconnect
Send Feedback
Altera Corporation
7-92
QII5V1
2014.12.15
Avalon Interrupt Sender Signal Roles
Avalon Interrupt Sender Signal Roles
Table 7-57: Interrupt Sender Signal Roles
Signal Role
Width
Direction
Require
d
1
Output
Yes
irq
irq_n
Description
Interrupt Request. A slave asserts irq when it needs
service.
Avalon Interrupt Receiver Signal Roles
Table 7-58: Interrupt Receiver Signal Roles
Signal Role
irq
Width
Direction
Require
d
1–32
Input
Yes
Description
irq is an <n>-bit vector, where each bit corresponds
directly to one IRQ sender. The interrupt sender
connected to interrupt receiver 0 is the highest priority
with sequential receivers being successively lower
priority.
Document Revision History
The table below indicates edits made to the Qsys Interconnect content since its creation.
Table 7-59: Document Revision History
Date
Version
Changes
December 2014
14.1.0
• Fixed Priority Arbitration.
• Read error responses, Avalon Memory-Mapped Interface
Signal, response.
• Burst Adapter Implementation Options: Generic converter
(slower, lower area), Per-burst-type converter (faster, higher
area).
August 2014
14.0a10.0
• Updated Qsys Packet Format for Memory-Mapped Master
and Slave Interfaces table, Protection.
• Streaming Interface renamed to Avalon Streaming
Interfaces.
• Added Response Merging under Memory-Mapped Interfaces.
Altera Corporation
Qsys Interconnect
Send Feedback
QII5V1
2014.12.15
Document Revision History
Date
Version
7-93
Changes
June 2014
14.0.0
•
•
•
•
•
AXI4-Lite support.
AXI4-Stream support.
Avalon-ST adapter parameters.
IRQ Bridge.
Handling Read Side Effects note added.
November 2013
13.1.0
• HSSI clock support.
• Reset Sequencer.
• Interconnect pipelining.
May 2013
13.0.0
• AMBA APB support.
• Auto-inserted Avalon-ST adapters feature.
• Moved Address Span Extender to the Qsys System Design
Components chapter.
November 2012
12.1.0
• AMBA AXI4 support.
June 2012
12.0.0
• AMBA AXI3 support.
• Avalon-ST adapters.
• Address Span Extender.
November 2011
11.0.1
Template update.
May 2011
11.0.0
Removed beta status.
December 2010
10.1.0
Initial release.
Related Information
Quartus II Handbook Archive
Qsys Interconnect
Send Feedback
Altera Corporation
8
Optimizing Qsys System Performance
2014.06.30
QII5V1
Subscribe
Send Feedback
You can optimize system interconnect performance for Altera designs that you create with the Qsys
system integration tool.
®
The foundation of any system is the interconnect logic that connects hardware blocks or components.
Creating interconnect logic is prone to errors, is time consuming to write, and is difficult to modify when
design requirements change. The Qsys system integration tool addresses these issues and provides an
automatically generated and optimized interconnect designed to satisfy your system requirements.
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.
Note: Recommended Altera practices may improve clock frequency, throughput, logic utilization, or
power consumption of your Qsys design. When you design a Qsys system, use your knowledge of
your design intent and goals to further optimize system performance beyond the automated
optimization available in Qsys.
Related Information
•
•
•
•
•
Avalon Interface Specifications
AMBA Protocol Specifications
Creating a System with Qsys on page 5-1
Creating Qsys Components on page 6-1
Qsys Interconnect on page 7-1
Designing with Avalon and AXI Interfaces
Qsys Avalon and AXI interconnect for memory-mapped interfaces is flexible, partial crossbar logic that
connects master and slave interfaces.
Avalon Streaming (Avalon-ST) links connect point-to-point, unidirectional interfaces and are typically
used in data stream applications. Each a pair of components is connected without any requirement to
arbitrate between the data source and sink.
Because Qsys supports multiplexed memory-mapped and streaming connections, you can implement
systems that use multiplexed logic for control and streaming for data in a single design.
Related Information
• Creating Qsys Components on page 6-1
© 2014 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
8-2
Designing Streaming Components
QII5V1
2014.06.30
Designing Streaming Components
When you design streaming component interfaces, you must consider integration and communication for
each component in the system. One common consideration is buffering data internally to accommodate
latency between components.
For example, if the component’s Avalon-ST output or source of streaming data is back-pressured because
the ready signal is de-asserted, then the component must back-pressure its input or sink interface to avoid
overflow.
You can use a FIFO to back-pressure internally on the output side of the component so that the input can
accept more data even if the output is back-pressured. Then, you can use the FIFO almost full flag to
back-pressure the sink interface or input data when the FIFO has only enough space to satisfy the internal
latency. You can drive the data valid signal of the output or source interface with the FIFO not empty flag
when that data is available.
Designing Memory-Mapped Components
When designing with memory-mapped components, you can implement any component that contains
multiple registers mapped to memory locations, for example, a set of four output registers to support
software read back from logic. Components that implement read and write memory-mapped transactions
require three main building blocks: an address decoder, a register file, and a read multiplexer.
The decoder enables the appropriate 32-bit or 64-bit register for writes. For reads, the address bits drive
the multiplexer selection bits. The read signal registers the data from the multiplexer, adding a pipeline
stage so that the component can achieve a higher clock frequency.
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Using Hierarchy in Systems
8-3
Figure 8-1: Control and Status Registers (CSR) in a Slave Component
Avalon-MM
Slave Port
Read Multiplexer
readdata[31:0]
Q
D
s
EN
read
address[1:0]
Register File
D
Decode
2:4
Q
User
Logic
EN
0
D
Q
EN
1
D
address[1:0]
Q
EN
2
D
write
EN
Q
EN
3
writedata[31:0]
This slave component has write wait states and one read wait state. Alternatively, if you want high
throughput, you may set both the read and write wait states to zero, and then specify a read latency of one,
because the component also supports pipelined reads.
Using Hierarchy in Systems
You can use hierarchy to sub-divide a system into smaller subsystems that you can then connect in a toplevel Qsys system. Additionally, If a design contains one or more identical functional units, the functional
unit can be defined as a subsystem and instantiated multiple times within a top-level system.
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-4
QII5V1
2014.06.30
Using Hierarchy in Systems
Hierarchy can simplify verification control of slaves connected to each master in a memory-mapped
system. Before you implement subsystems in your design, you should plan the system hierarchical blocks
at the top-level, using the following guidelines:
• Plan shared resources—Determine the best location for shared resources in the system hierarchy. For
example, if two subsystems share resources, add the components that use those resources to a higherlevel system for easy access.
• Plan shared address space between subsystems—Planning the address space ensures you can set
appropriate sizes for bridges between subsystems.
• Plan how much latency you may need to add to your system—When you add a pipeline bridge
between subsystems, you may add latency to the overall system. You can reduce the added latency by
parameterizing the pipeline bridge with zero cycles of latency.
Figure 8-2: Passing Messages Between Subsystems
Top-Level System
Subsystem
Subsystem
Nios II
Processor
Nios II
Processor
M
Pipeline Bridges
M
Arbiter
M
M
Arbiter
Arbiter
Arbiter
S
S
S
S
S
S
S
S
On-Chip
Memory
PIO
UART
Mutex
Shared
Memory
On-Chip
Memory
PIO
UART
Shared Resources for Message Passing
In this example, two Nios II processor subsystems share resources for message passing. Bridges in each
subsystem export the Nios II data master to the top-level system that includes the mutex (mutual
exclusion component) and shared memory component (which could be another on-chip RAM, or a
controller for an off-chip RAM device).
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Using Hierarchy in Systems
8-5
Figure 8-3: Multi Channel System
Input Data Stream
Channel 1 System
Output Data Stream
Input Data Stream
Channel 2 System
Output Data Stream
Input Data Stream
Channel N System
Output Data Stream
Nios II
Processor
M
M
Arbiter
S
S
S
On-Chip
Memory
Input Data
Stream
Input Data
Stream
You can also design systems that process multiple data channels by instantiating the same subsystem for
each channel. This approach is easier to maintain than a larger, non-hierarchical system. Additionally,
such systems are easier to scale because you can calculate the required resources as a multiple of the
subsystem requirements.
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-6
Using Concurrency in Memory-Mapped Systems
QII5V1
2014.06.30
Using Concurrency in Memory-Mapped Systems
Qsys interconnect uses parallel hardware in FPGAs, which allows you to design concurrency into your
system and process transactions simultaneously.
Implementing Concurrency With Multiple Masters
Implementing concurrency requires multiple masters in a Qsys system. Systems that include a processor
contain at least two master interfaces because the processors include separate instruction and data
masters. You can catagorize master components as follows:
• General purpose processors, such as Nios II processors
• DMA (direct memory access) engines
• Communication interfaces, such as PCI Express
Because Qsys generates an interconnect with slave-side arbitration, every master interface in a system can
issue transfers concurrently, as long as they are not posting transfers to the same slave. Concurrency is
limited by the number of master interfaces sharing any particular slave interface. If a design requires
higher data throughput, you can increase the number of master and slave interfaces to increase the
number of transfers that occur simultaneously. The example below shows a system with three master
interfaces.
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
8-7
Implementing Concurrency With Multiple Masters
Figure 8-4: Avalon Multiple Master Parallel Access
In this Avalon example, the DMA engine operates with Avalon-MM read and write masters. However, an
AXI DMA interface typically has only one master, because in the AXI standard, the write and read
channels on the master are independent and can process transactions simultaneously. The yellow lines
represent active simultaneously connections.
N ios II
P rocessor
M
AXI DMA
Engine
M
S
S
Dual-Port On-Chip
Memory
M
A va lon Mas ter P ort
S
A va lon S lave P ort
M
PCI Express
Interface
M
S
M
Arbiter
Arbiter
S
S
External Memory
Controller
External Memory
Controller
Concurrent Access Possible
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-8
QII5V1
2014.06.30
Implementing Concurrency With Multiple Slaves
Figure 8-5: AXI Multiple Master Parallel Access
In this example, the DMA engine operates with a single master, because in AXI, the write and read
channels on the master are independent and can process transactions simultaneously. There is
concurrency between the read and write channels, with the yellow lines representing concurrent data
paths.
Nios II
Processor
M
DMA
Engine
M
M
Read
S
S
Dual-Port On-Chip
Memory
M
Avalon Master Port
S
PCI Express
Interface
S
M
Write
Arbiter
Arbiter
S
S
External Memory
Controller
External Memory
Controller
Avalon Slave Port
Concurrent Access Possible
Implementing Concurrency With Multiple Slaves
You can create multiple slave interfaces for a particular function to increase concurrency in your design.
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Implementing Concurrency with DMA Engines
8-9
Figure 8-6: Single Interface Versus Multiple Interfaces
Single Channel Access
Channel Processor
Host 1
M
Compute
Engine 1
Data Channel 1
Host 2
M
Compute
Engine 2
Data Channel 2
Arbiter
S
Host 3
M
Compute
Engine 3
Data Channel 3
Host 4
M
Compute
Engine 4
Data Channel 4
Multiple Channel Access
Channel Processor
Host 1
M
S
Compute
Engine 1
Data Channel 1
Host 2
M
S
Compute
Engine 2
Data Channel 2
Host 3
M
S
Compute
Engine 3
Data Channel 3
Host 4
M
S
Compute
Engine 4
Data Channel 4
In this example, there are two channel processing systems. In the first, four hosts must arbitrate for the
single slave interface of the channel processor. In the second, each host drives a dedicated slave interface,
allowing all master interfaces to simultaneously access the slave interfaces of the component. Arbitration
is not necessary when there is a single host and slave interface.
Implementing Concurrency with DMA Engines
In some systems, you can use DMA engines to increase throughput. You can use a DMA engine to
transfer blocks of data between interfaces, which then frees the CPU from doing this task. A DMA engine
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-10
QII5V1
2014.06.30
Implementing Concurrency with DMA Engines
transfers data between a programmed start and end address without intervention, and the data
throughput is dictated by the components connected to the DMA. Factors that affect data throughput
include data width and clock frequency.
Figure 8-7: Single or Dual DMA Channels
Single DMA Channel
Maximum of One Read & One Write Per Clock Cycle
DMA
Engine
M
M
S
S
S
S
Read
Buffer 1
Read
Buffer 2
Write
Buffer 1
Write
Buffer 2
Dual DMA Channels
Maximum of two Reads & Two Writes Per Clock Cycle
DMA
Engine 2
DMA
Engine 1
M
M
M
M
S
S
S
S
Read
Buffer 1
Write
Buffer 1
Read
Buffer 2
Write
Buffer 2
In this example, the system can sustain more concurrent read and write operations by including more
DMA engines. Accesses to the read and write buffers in the top system are split between two DMA
engines, as shown in the Dual DMA Channels at the bottom of the figure.
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Inserting Pipeline Stages to Increase System Frequency
8-11
The DMA engine operates with Avalon-MM write and read masters. An AXI DMA typically has only one
master, because in AXI, the write and read channels on the master are independent and can process
transactions simultaneously.
Inserting Pipeline Stages to Increase System Frequency
Qsys provides the Limit interconnect pipeline stages to option on the Project Settings tab to
automatically add pipeline stages to the Qsys interconnect when you generate a system.
You can specify between 0 to 4 pipeline stages, where 0 means that the interconnect has a combinational
data path. You can specify a unique interconnect pipeline stage value for each subsystem.
Adding pipeline stages may increase the fMAX of the design by reducing the combinational logic depth, at
the cost of additional latency and logic utilization.
The insertion of pipeline stages requires certain interconnect components. For example, in a system with
a single slave interface, there is no multiplexer; therefore multiplexer pipelining does not occur. When
there is an Avalon or AXI single-master to single-slave system, no pipelining occurs, regardless of the
Limit interconnect pipeline stages to option.
Related Information
• Creating a System with Qsys on page 5-1
Using Bridges
You can use bridges to increase system frequency, minimize generated Qsys logic, minimize adapter logic,
and to structure system topology when you want to control where Qsys adds pipelining. You can also use
bridges with arbiters when there is concurrency in the system.
An Avalon bridge has an Avalon-MM slave interface and an Avalon-MM master interface. You can have
many components connected to the bridge slave interface, or many components connected to the bridge
master interface. You can also have a single component connected to a single bridge slave or master
interface.
You can configure the data width of the bridge, which can affect how Qsys generates bus sizing logic in
the interconnect. Both interfaces support Avalon-MM pipelined transfers with variable latency, and can
also support configurable burst lengths.
Transfers to the bridge slave interface are propagated to the master interface, which connects to
components downstream from the bridge. When you need greater control over interconnect pipelining,
you can use bridges instead of the Limit Interconnect Pipeline Stages to option.
Note: You can use Avalon bridges between AXI interfaces, and between Avalon domains. Qsys automati‐
cally creates interconnect logic between the AXI and Avalon interfaces, so you do not have to
explicitly instantiate bridges between these domains. For more discussion about the benefits and
disadvantages of shared and separate domains, refer to the Qsys Interconnect.
Related Information
• Creating a System with Qsys on page 5-1
• Qsys Interconnect on page 7-1
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-12
QII5V1
2014.06.30
Using Bridges to Increase System Frequency
Using Bridges to Increase System Frequency
In Qsys, you can introduce interconnect pipeline stages or pipeline bridges to increase clock frequency in
your system. Bridges control the system interconnect topology and allow you to subdivide the
interconnect, giving you more control over pipelining and clock crossing functionality.
Inserting Pipeline Bridges
You can insert an Avalon-MM pipeline bridge to insert registers in the path between the bridges and its
master and slaves. If a critical register-to-register delay occurs in the interconnect, a pipeline bridge can
help reduce this delay and improve system fMAX.
The Avalon-MM pipeline bridge component integrates into any Qsys system. The pipeline bridge options
can increase logic utilization and read latency. The change in topology may also reduce concurrency if
multiple masters arbitrate for the bridge. You can use the Avalon-MM pipeline bridge to control topology
without adding a pipeline stage. A pipeline bridge that does not add a pipeline stage is optimal in some
latency-sensitive applications. For example, a CPU may benefit from minimal latency when accessing
memory.
Figure 8-8: Avalon-MM Pipeline Bridge
Avalon-MM Pipeline Bridge
D
Master-to-Slave
Signals
Q
Master-to-Slave
Pipeline
D
Q
Master-to-Slave
Signals
ENA
waitrequest
Pipeline
waitrequest
Connects to an
Avalon-MM
Slave Interface
Wait Request
Logic
waitrequest
Master
I/F
Slave
I/F
D
Slave-to-Master
Signals
Connects to an
Avalon-MM
Master Interface
Q
Slave-to-Master
Signals
Slave-to-Master
Pipeline
Implementing Command Pipelining (Master-to-Slave)
When multiple masters share a slave device, you can use command pipelining to improve performance.
The arbitration logic for the slave interface must multiplex the address, writedata, and burstcount
signals. The multiplexer width increases proportionally with the number of masters connecting to a single
slave interface. The increased multiplexer width may become a timing critical path in the system. If a
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Implementing Response Pipelining (Slave-to-Master)
8-13
single pipeline bridge does not provide enough pipelining, you can instantiate multiple instances of the
bridge in a tree structure to increase the pipelining and further reduce the width of the multiplexer at the
slave interface.
Figure 8-9: Tree of Bridges
Master 1
Master 2
Master 3
Master 4
M
M
M
M
arb
arb
S
S
Pipeline Bridge
Pipeline Bridge
M
M
arb
S
Shared
Slave
Read Data
Write Data &
Control Signals
Implementing Response Pipelining (Slave-to-Master)
When masters connect to multiple slaves that support read transfers, you can use slave-to-master
pipelining to improve performance.
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-14
Using Clock Crossing Bridges
QII5V1
2014.06.30
The interconnect inserts a multiplexer for every read data path back to the master. As the number of
slaves supporting read transfers connecting to the master increases, the width of the read data multiplexer
also increases. If the performance increase is insufficient with one bridge, you can use multiple bridges in
a tree structure to improve fMAX.
Using Clock Crossing Bridges
The clock crossing bridge contains a pair of clock crossing FIFOs, which isolate the master and slave
interfaces in separate, asynchronous clock domains. Transfers to the slave interface are propagated to the
master interface.
When you use a FIFO clock crossing bridge for the clock domain crossing, you add data buffering.
Buffering allows pipelined read masters to post multiple reads to the bridge, even if the slaves downstream
from the bridge do not support pipelined transfers.
You can also use a clock crossing bridge to place high and low frequency components in separate clock
domains. If you limit the fast clock domain to the portion of your design that requires high performance,
you may achieve a higher fMAX for this portion of the design. For example, the majority of processor
peripherals in embedded designs do not need to operate at high frequencies, therefore, you do not need to
use a high-frequency clock for these components. When you compile a design with the Quartus II
software, compilation may take more time when the clock frequency requirements are difficult to meet
because the Fitter needs more time to place registers to achieve the required fMAX. To reduce the amount
of effort that the Fitter uses on low priority and low performance components, you can place these behind
a clock crossing bridge operating at a lower frequency, allowing the Fitter to increase the effort placed on
the higher priority and higher frequency data paths.
Using Bridges to Minimize Design Logic
Bridges can reduce interconnect logic by reducing the amount of arbitration and multiplexer logic that
Qsys generates. This reduction occurs because bridges limit the number of concurrent transfers that can
occur.
Avoiding Speed Optimizations That Increase Logic
You can add an additional pipeline stage with a pipeline bridge between masters and slaves to reduces the
amount of combinational logic between registers, which can increase system performance. If you can
increase the fMAX of your design logic, you may be able to turn off the Quartus II software optimization
settings, such as the Perform register duplication setting. Register duplication creates duplicate registers
in two or more physical locations in the FPGA to reduce register-to-register delays. You may also want to
choose Speed for the optimization method, which typically results in higher logic utilization due to logic
duplication. By making use of the registers or FIFOs available in the bridges, you can increase the design
speed and avoid needless logic duplication or speed optimizations, thereby reducing the logic utilization
of the design.
Limiting Concurrency
The amount of logic generated for the interconnect often increases as the system becomes larger because
Qsys creates arbitration logic for every slave interface that is shared by multiple master interfaces. Qsys
inserts multiplexer logic between master interfaces that connect to multiple slave interfaces if both
support read data paths.
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Limiting Concurrency
8-15
Most embedded processor designs contain components that are either incapable of supporting high data
throughput, or do not need to be accessed frequently. These components can contain master or slave
interfaces. Because the interconnect supports concurrent accesses, you may want to limit concurrency by
inserting bridges into the data path to limit the amount of arbitration and multiplexer logic generated.
For example, if a system contains three master and three slave interfaces that are interconnected, Qsys
generates three arbiters and three multiplexers for the read data path. If these masters do not require a
significant amount of simultaneous throughput, you can reduce the resources that your design consumes
by connecting the three masters to a pipeline bridge. The bridge controls the three slave interfaces and
reduces the interconnect into a bus structure. Qsys creates one arbitration block between the bridge and
the three masters, and a single read data path multiplexer between the bridge and three slaves, and
prevents concurrency. This implementation is similar to a standard bus architecture.
You should not use this method for high throughput data paths to ensure that you do not limit overall
system performance.
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-16
QII5V1
2014.06.30
Using Bridges to Minimize Adapter Logic
Figure 8-10: Differences Between Systems With and Without a Pipeline Bridge
Concurrency
No Concurrency
M
M
M
M
M
M
M
Arbiter
S
Bridge
Arbiter
Arbiter
Arbiter
S
S
S
Write Data & Control Signals
Read Data
M
S
S
S
Using Bridges to Minimize Adapter Logic
Qsys generates adapter logic for clock crossing, width adaptation, and burst support when there is a
mismatch between the clock domains, widths, or bursting capabilities of the master and slave interface
pairs.
Qsys creates burst adapters when the maximum burst length of the master is greater than the master burst
length of the slave. The adapter logic creates extra logic resources, which can be substantial when your
system contains master interfaces connected to many components that do not share the same characteris‐
tics. By placing bridges in your design, you can reduce the amount of adapter logic that Qsys generates.
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Determining Effective Placement of Bridges
8-17
Determining Effective Placement of Bridges
To determine the effective placement of a bridge, you should initially analyze each master in your system
to determine if the connected slave devices support different bursting capabilities or operate in a different
clock domain. The maximum burstcount of a component is visible as the burstcount signal in the HDL
file of the component. The maximum burst length is 2 (width(burstcount -1)), therefore, if the burstcount
width is four bits, the maximum burstcount is eight. If no burstcount signal is present, the component
does not support bursting or has a burst length of 1.
To determine if the system requires a clock crossing adapter between the master and slave interfaces,
check the Clock column for the master and slave interfaces. If the clock is different for the master and
slave interfaces, Qsys inserts a clock crossing adapter between them. To avoid creating multiple adapters,
you can place the components containing slave interfaces behind a bridge so that Qsys creates a single
adapter. By placing multiple components with the same burst or clock characteristics behind a bridge, you
limit concurrency and the number of adapters.
You can also use a bridge to separate AXI and Avalon domains to minimize burst adaptation logic. For
example, if there are multiple Avalon slaves that are connected to an AXI master, you can consider
inserting a bridge to access the adaptation logic once before the bridge, instead of once per slave. This
implementation results in latency, and you would also lose concurrency between reads and writes.
Changing the Response Buffer Depth
When you use automatic clock-crossing adapters, Qsys determines the required depth of FIFO buffering
based on the slave properties. If a slave has a high Maximum Pending Reads parameter, the resulting deep
response buffer FIFO that Qsys inserts between the master and slave can consume a lot of device
resources. To control the response FIFO depth, you can use a clock crossing bridge and manually adjust
its FIFO depth to trade off throughput with smaller memory utilization.
For example, if you have masters that cannot saturate the slave, you do not need response buffering. Using
a bridge reduces the FIFO memory depth and reduces the Maximum Pending Reads available from the
slave.
Considering the Effects of Using Bridges
Before you use pipeline or clock crossing bridges in a design, you should carefully consider their effects.
Bridges can have any combination of consequences on your design, which could be positive or negative.
Benchmarking your system before and after inserting bridges can help you to determine the impact to the
design.
Increased Latency
Adding a bridge to a design has an effect on the read latency between the master and the slave. Depending
on the system requirements and the type of master and slave, this latency increase may or may not be
acceptable in your design.
Acceptable Latency Increase
For a pipeline bridge, Qsys adds a cycle of latency for each pipeline option that is enabled. The buffering
in the clock crossing bridge also adds latency. If you use a pipelined or burst master that posts many read
transfers, the increase in latency does not impact performance significantly because the latency increase is
very small compared to the length of the data transfer.
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-18
QII5V1
2014.06.30
Unacceptable Latency Increase
For example, if you use a pipelined read master such as a DMA controller to read data from a component
with a fixed read latency of four clock cycles, but only perform a single word transfer, the overhead is
three clock cycles out of the total of four. This is true when there is no additional pipeline latency in the
interconnect. The read throughput is only 25%.
Figure 8-11: Low-Efficiency Read Transfer
Read Latency
Read Latency
Overhead
Overhead
A0
A1
clk
address
read
waitrequest
readdata
D0
D1
However, if 100 words of data are transferred without interruptions, the overhead is three cycles out of the
total of 103 clock cycles. This corresponds to a read efficiency of approximately 97% when there is no
additional pipeline latency in the interconnect. Adding a pipeline bridge to this read path adds two extra
clock cycles of latency. The transfer requires 105 cycles to complete, corresponding to an efficiency of
approximately 94%. Although the efficiency decreased by 3%, adding the bridge may increase the fMAX by
5%. For example, if the clock frequency can be increased, the overall throughput would improve. As the
number of words transferred increases, the efficiency increases to nearly 100%, whether or not a pipeline
bridge is present.
Figure 8-12: High Efficiency Read Transfer
Read Latency
Overhead
clk
address
A0
A1
A2
A3
A4
A5
A6
A7
A8
A9
A10
A11
A12
D0
D1
D2
D3
D4
D5
D6
D7
D8
read
waitrequest
readdatavalid
readdata
Unacceptable Latency Increase
Processors are sensitive to high latency read times and typically retrieve data for use in calculations that
cannot proceed until the data arrives. Before adding a bridge to the data path of a processor instruction or
data master, determine whether the clock frequency increase justifies the added latency.
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Limited Concurrency
8-19
A Nios II processor instruction master has a cache memory with a read latency of four cycles, which is
eight sequential words of data return for each read. At 100 MHz, the first read takes 40 ns to complete.
Each successive word takes 10 ns so that eight reads complete in 110 ns.
Figure 8-13: Performance of a Nios II Processor and Memory Operating at 100 MHz
110 ns
40 ns
clk
A0
address
A1
A2
A3
A4
A5
A6
A7
D0
D1
D2
D3
read
waitrequest
readdatavalid
readdata
D4
D5
D6
D7
Adding a clock crossing bridge allows the memory to operate at 125 MHz. However, this increase in
frequency is negated by the increase in latency because if the clock crossing bridge adds six clock cycles of
latency at 100 MHz, then the memory continues to operate with a read latency of four clock cycles.
Consequently, the first read from memory takes 100 ns, and each successive word takes 10 ns because
reads arrive at the frequency of the processor, which is 100 MHz. In total, eight reads complete after 170
ns. Although the memory operates at a higher clock frequency, the frequency at which the master
operates limits the throughput.
Figure 8-14: Performance of a Nios II Processor and Eight Reads with Ten Cycles Latency
170 ns
100 ns
clk
address
A0
A1 A2
A3 A4
A5 A6 A7
read
waitrequest
readdatavalid
readdata
D0 D1
D2 D3
D4 D5
D6 D7
Limited Concurrency
Placing a bridge between multiple master and slave interfaces limits the number of concurrent transfers
your system can initiate. This limitation is the same when connecting multiple master interfaces to a
single slave interface. The slave interface of the bridge is shared by all the masters and, as a result, Qsys
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-20
QII5V1
2014.06.30
Limited Concurrency
creates arbitration logic. If the components placed behind a bridge are infrequently accessed, this
concurrency limitation may be acceptable.
Bridges can have a negative impact on system performance if you use them inappropriately. For example,
if multiple memories are used by several masters, you should not place the memory components behind a
bridge. The bridge limits memory performance by preventing concurrent memory accesses. Placing
multiple memory components behind a bridge can cause the separate slave interfaces to appear as one
large memory to the masters accessing the bridge; all masters must access the same slave interface.
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Limited Concurrency
8-21
Figure 8-15: Inappropriate Use of a Bridge in a Hierarchical System
Nios II
Processor
M
DMA
M
M
Arbiter
Qsys Subsystem
M
Bottleneck
S
Bridge
M
S
S
S
S
DDR
SDRAM
DDR
SDRAM
DDR
SDRAM
DDR
SDRAM
A memory subsystem with one bridge that acts as a single slave interface for the Avalon-MM Nios II and
DMA masters, which results in a bottleneck architecture. The bridge acts as a bottleneck between the two
masters and the memories.
If the fMAX of your memory interfaces is low and you want to use a pipeline bridge between subsystems,
you can place each memory behind its own bridge, which increases the fMAX of the system without
sacrificing concurrency.
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-22
QII5V1
2014.06.30
Address Space Translation
Figure 8-16: Efficient Memory Pipelining Without a Bottleneck in a Hierarchical System
Subsystem
Nios II
Processor
M
M
Subsystem
DMA
M
M
Arbiter
Arbiter
Arbiter
Arbiter
S
S
S
S
Bridge
Bridge
Bridge
Bridge
M
M
M
M
S
S
S
S
DDR
SDRAM
DDR
SDRAM
DDR
SDRAM
DDR
SDRAM
Address Space Translation
The slave interface of a pipeline or clock crossing bridge has a base address and address span. You can set
the base address, or allow Qsys to set it automatically. The address of the slave interface is the base offset
address of all the components connected to the bridge. The address of components connected to the
bridge is the sum of the base offset and the address of that component.
The master interface of the bridge drives only the address bits that represent the offset from the base
address of the bridge slave interface. Any time a master accesses a slave through a bridge, both addresses
must be added together, otherwise the transfer fails. The Address Map tab displays the addresses of the
slaves connected to each master and includes address translations caused by system bridges.
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
8-23
Address Coherency
Figure 8-17: Bridge Address Translation
Nios II Processor
Bridge
0x102C
M
Peripheral
0x2C
S
M
0x2C
Base = 0x1000
Address
Decoder
0xC
S
Base = 0x20
Address Translation
Address Translation
In this example, the Nios II processor connects to a bridge located at base address 0x1000, a slave connects
to the bridge master interface at an offset of 0x20, and the processor performs a write transfer to the
fourth 32-bit or 64-bit word within the slave. Nios II drives the address 0x102C to interconnect, which is
within the address range of the bridge. The bridge master interface drives 0x2C, which is within the
address range of the slave, and the transfer completes.
Address Coherency
To simplify the system design, all masters should access slaves at the same location. In many systems, a
processor passes buffer locations to other mastering components, such as a DMA controller. If the
processor and DMA controller do not access the slave at the same location, Qsys must compensate for the
differences.
Figure 8-18: Slaves at Different Addresses and Complicating the System
Nios II Processor
M
Peripheral
0x20
Arbiter
0x0
Address
Decoder
Base = 0x20
Masters Drive
Different Addresses
DMA
S
Bridge
M
0x1020
S
0x20
M
0x20
Base = 0x1000
Address Translation
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-24
QII5V1
2014.06.30
Increasing Transfer Throughput
A Nios II processor and DMA controller access a slave interface located at address 0x20. The processor
connects directly to the slave interface. The DMA controller connects to a pipeline bridge located at
address 0x1000, which then connects to the slave interface. Because the DMA controller accesses the
pipeline bridge first, it must drive 0x1020 to access the first location of the slave interface. Because the
processor accesses the slave from a different location, you must maintain two base addresses for the slave
device.
To avoid the requirement for two addresses, you can add an additional bridge to the system, set its base
address to 0x1000, and then disable all the pipelining options in the second bridge so that the bridge has
minimal impact on system timing and resource utilization. Because this second bridge has the same base
address as the original bridge, the processor and DMA controller access the slave interface with the same
address range.
Figure 8-19: Address Translation Corrected With Bridge
Address Translation
Nios II Processor
Bridge
M
0x1020
S
0x20
M
Arbiter
Base = 0x1000
DMA
Peripheral
0x20
S
0x0
Address
Decoder
Base = 0x20
Bridge
M
0x1020
S
0x20
M
0x20
Base = 0x1000
Address Translation
Increasing Transfer Throughput
Increasing the transfer efficiency of the master and slave interfaces in your system increases the
throughput of your design. Designs with strict cost or power requirements benefit from increasing the
transfer efficiency because you can then use less expensive, lower frequency devices. Designs requiring
high performance also benefit from increased transfer efficiency because increased efficiency improves the
performance of frequency–limited hardware.
Throughput is the number of symbols (such as bytes) of data that Qsys can transfer in a given clock cycle.
Read latency is the number of clock cycles between the address and data phase of a transaction. For
example, a read latency of two means that the data is valid two cycles after the address is posted. If the
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Using Pipelined Transfers
8-25
master must wait for one request to finish before the next begins, such as with a processor, then the read
latency is very important to the overall throughput.
You can measure throughput and latency in simulation by observing the waveforms, or using the verifica‐
tion IP monitors.
Related Information
• Avalon Verification IP Suite User Guide
®
• Mentor Verification IP Altera Edition AMBA AXI3/4 User Guide
Using Pipelined Transfers
Pipelined transfers increase the read efficiency by allowing a master to post multiple reads before data
from an earlier read returns. Masters that support pipelined transfers post transfers continuously, relying
on the readdatavalid signal to indicate valid data. Slaves support pipelined transfers by including the
readdatavalid signal or operating with a fixed read latency.
AXI masters declare how many outstanding writes and reads it can issue with the writeIssuingCapability and readIssuingCapability parameters. In the same way, a slave can declare how many reads it
can accept with the readAcceptanceCapability parameter. AXI masters with a read issuing capability
greater than one are pipelined in the same way as Avalon masters and the readdatavalid signal.
Using the Maximum Pending Reads Parameter
If you create a custom component with a slave interface supporting variable-latency reads, you must
specify the Maximum Pending Reads parameter in the Component Editor. Qsys uses this parameter to
generate the appropriate interconnect and represent the maximum number of read transfers that your
pipelined slave component can process. If the number of reads presented to the slave interface exceeds the
Maximum Pending Reads parameter, then the slave interface must assert waitrequest.
Optimizing the value of the Maximum Pending Reads parameter requires an understanding of the
latencies of your custom components. This parameter should be based on the component’s highest read
latency for the various logic paths inside the component. For example, if your pipelined component has
two modes, one requiring two clock cycles and the other five, set the Maximum Pending Reads
parameter to 5 to allow your component to pipeline five transfers, and eliminating dead cycles after the
initial five-cycle latency.
You can also determine the correct value for the Maximum Pending Reads parameter by monitoring the
number of reads that are pending during system simulation or while running the hardware. To use this
method, set the parameter to a high value and use a master that issues read requests on every clock. You
can use a DMA for this task as long as the data is written to a location that does not frequently assert
waitrequest. If you implement this method, you can observe your component with a logic analyzer or
built-in monitoring hardware.
Choosing the correct value for the Maximum Pending Reads parameter of your custom pipelined read
component is important. If you underestimate the parameter value, you may cause a master interface to
stall with a waitrequest until the slave responds to an earlier read request and frees a FIFO position.
The Maximum Pending Reads parameter controls the depth of the response FIFO inserted into the
interconnect for each master connected to the slave. This FIFO does not use significant hardware
resources. Overestimating the Maximum Pending Reads parameter results in a slight increase in
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-26
QII5V1
2014.06.30
Arbitration Shares and Bursts
hardware utilization. For these reasons, if you are not sure of the optimal value, you should overestimate
this value.
If your system includes a bridge, you must set the Maximum Pending Reads parameter on the bridge as
well. To allow maximum throughput, this value should be equal to or greater than the Maximum
Pending Reads value for the connected slave that has the highest value. You can limit the maximum
pending reads of a slave and reduce the buffer depth by reducing the parameter value on the bridge if the
high throughput is not required. If you do not know the Maximum Pending Reads value for all the slave
components, you can monitor the number of reads that are pending during system simulation while
running the hardware. To use this method, set the Maximum Pending Reads parameter to a high value
and use a master that issues read requests on every clock, such as a DMA. Then, reduce the number of
maximum pending reads of the bridge until the bridge reduces the performance of any masters accessing
the bridge.
Arbitration Shares and Bursts
Arbitration shares provide control over the arbitration process. By default, the arbitration algorithm
allocates evenly, with all masters receiving one share.
You can adjust the arbitration process by assigning a larger number of shares to the masters that need
greater throughput. The larger the arbitration share, the more transfers are allocated to the master to
access a slave. The masters gets uninterrupted access to the slave for its number of shares, as long as the
master is reading or writing.
If a master cannot post a transfer and other masters are waiting to gain access to a particular slave, the
arbiter grants another master access. This mechanism prevents a master from wasting arbitration cycles if
it cannot post back-to-back transfers. A bursting transaction contains multiple beats (or words) of data,
starting from a single address. Bursts allow a master to maintain access to a slave for more than a single
word transfer. If a bursting master posts a write transfer with a burst length of eight, it is guaranteed
arbitration for eight write cycles.
You can assign arbitration shares to an Avalon-MM bursting master and AXI masters (which are always
considered a bursting master). Each share consists of one burst transaction (such as multi-cycle write),
and allows a master to complete a number of bursts before arbitration switches to the next master.
Related Information
• Avalon Interface Specifications
• AMBA Protocol Specification
Differences Between Arbitration Shares and Bursts
The following three key characteristics distinguish arbitration shares and bursts:
• Arbitration Lock
• Sequential Addressing
• Burst Adapters
Arbitration Lock
When a master posts a burst transfer, the arbitration is locked for that master; consequently, the bursting
master should be capable of sustaining transfers for the duration of the locked period. If, after the fourth
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Choosing Avalon-MM Interface Types
8-27
write, the master deasserts the write signal (Avalon-MM write or AXI wvalid) for fifty cycles, all other
masters continue to wait for access during this stalled period.
To avoid wasted bandwidth, your master designs should wait until a full burst transfer is ready before
requesting access to a slave device. Alternatively, you can avoid wasted bandwidth by posting
burstcounts equal to the amount of data that is ready. For example, if you create a custom bursting write
master with a maximum burstcount of eight, but only three words of data are ready, you can present a
burstcount of three. This strategy does not result in optimal use of the system band width if the slave is
capable of handling a larger burst; however, this strategy prevents stalling and allows access for other
masters in the system.
Sequential Addressing
An Avalon-MM burst transfer includes a base address and a burstcount, which represents the number of
words of data that are transferred, starting from the base address and incrementing sequentially. Burst
transfers are common for processors, DMAs, and buffer processing accelerators; however, sometimes a
master must access non-sequential addresses. Consequently, a bursting master must set the burstcount
to the number of sequential addresses, and then reset the burstcount for the next location.
The arbitration share algorithm has no restrictions on addresses; therefore, your custom master can
update the address it presents to the interconnect for every read or write transaction.
Burst Adapters
Qsys allows you to create systems that mix bursting and non-bursting master and slave interfaces. This
design strategy allows you to connect bursting master and slave interfaces that support different
maximum burst lengths, with Qsys generating burst adapters when appropriate.
Qsys inserts a burst adapter whenever a master interface burst length exceeds the burst length of the slave
interface, or if the master issues a burst type that the slave cannot support. For example, if you connect an
AXI master to an Avalon slave, a burst adapter is inserted. Qsys assigns non-bursting masters and slave
interfaces a burst length of one. The burst adapter divides long bursts into shorter bursts. As a result, the
burst adapter adds logic to the address and burstcount paths between the master and slave interfaces.
Related Information
Qsys Interconnect on page 7-1
AMBA Protocol Specification
Choosing Avalon-MM Interface Types
To avoid inefficient Avalon-MM transfers, custom master or slave interfaces must use the appropriate
simple, pipelined, or burst interfaces.
Simple Avalon-MM Interfaces
Simple interface transfers do not support pipelining or bursting for reads or writes; consequently, their
performance is limited. Simple interfaces are appropriate for transfers between masters and infrequently
used slave interfaces. In Qsys, the PIO, UART, and Timer include slave interfaces that use simple
transfers.
Pipelined Avalon-MM Interfaces
Pipelined read transfers allow a pipelined master interface to start multiple read transfers in succession
without waiting for prior transfers to complete. Pipelined transfers allow master-slave pairs to achieve
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-28
QII5V1
2014.06.30
Burst Avalon-MM Interfaces
higher throughput, even though the slave port may require one or more cycles of latency to return data
for each transfer.
In many systems, read throughput becomes inadequate if simple reads are used and pipelined transfers
can increase throughput. If you define a component with a fixed read latency, Qsys automatically provides
the pipelining logic necessary to support pipelined reads. You can use fixed latency pipelining as the
default design starting point for slave interfaces. If your slave interface has a variable latency response
time, use the readdatavalid signal to indicate when valid data is available. The interconnect implements
read response FIFO buffering to handle the maximum number of pending read requests.
To use components that support pipelined read transfers, and to use a pipelined system interconnect
efficiently, your system must contain pipelined masters. You can use pipelined masters as the default
starting point for new master components. Use the readdatavalid signal for these master interfaces.
Because master and slaves sometimes have mismatched pipeline latency, interconnect contains logic to
reconcile the differences.
Table 8-1: Pipeline Latency in a Master-Slave Pair
Master
Slave
Pipeline Management Logic Structure
No pipeline
No Pipeline
Qsys interconnect does not instantiate logic to handle pipeline
latency.
No pipeline
Pipelined with Qsys interconnect forces the master to wait through any slavefixed or
side latency cycles. This master-slave pair gains no benefits from
variable latency pipelining, because the master waits for each transfer to complete
before beginning a new transfer. However, while the master is
waiting, the slave can accept transfers from a different master.
Pipelined
No pipeline
Qsys interconnect carries out the transfer as if neither master nor
slave were pipelined, causing the master to wait until the slave
returns data. An example of a non-pipeline slave is an asynchro‐
nous off-chip interface.
Pipelined
Pipelined with
fixed latency
Qsys interconnect allows the master to capture data at the exact
clock cycle when data from the slave is valid, to enable maximum
throughput. An example of a fixed latency slave is an on-chip
memory.
Pipelined
Pipelined with The slave asserts a signal when its readdata is valid, and the
variable latency master captures the data. The master-slave pair can achieve
maximum throughput if the slave has variable latency. Examples
of variable latency slaves include SDRAM and FIFO memories.
Burst Avalon-MM Interfaces
Burst transfers are commonly used for latent memories such as SDRAM and off-chip communication
interfaces, such as PCI Express. To use a burst-capable slave interface efficiently, you must connect to a
bursting master. Components that require bursting to operate efficiently typically have an overhead
penalty associated with short bursts or non-bursting transfers.
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Avalon-MM Burst Master Example
8-29
You can use a burst-capable slave interface if you know that your component requires sequential transfers
to operate efficiently. Because SDRAM memories incur a penalty when switching banks or rows, perform‐
ance improves when SDRAM memories are accessed sequentially with bursts.
Architectures that use the same signals to transfer address and data also benefit from bursting. Whenever
an address is transferred over shared address and data signals, the throughput of the data transfer is
reduced. Because the address phase adds overhead, using large bursts increases the throughput of the
connection.
Avalon-MM Burst Master Example
Figure 8-20: Avalon Bursting Write Master
This example shows the architecture of a bursting write master that receives data from a FIFO and writes
the contents to memory. You can use a bursting master as a starting point for your own bursting
components, such as custom DMAs, hardware accelerators, or off-chip communication interfaces.
start_address[31:0]
go
increment_address
d
load
Up
Counter
q
master_address[31:0]
1
0 s
D
Q
VCC
count enable
byteenable[3:0]
EN
burst_begin
done
transfer_length[31:0]
go
increment_address
d
load
q
length[31:0]
master_burstcount[2:0]
Down
Counter
count enable
Tracking Logic/
State Machine
fifo_used[]
burst_begin
burst_count[2:0]
write
increment_address
waitrequest
user_data[31:0]
q
user_data_full
full
user_data_write
write
used[]
Look-Ahead FIFO
d
read acknowledge
writedata[31:0]
increment_address
The master performs word accesses and writes to sequential memory locations. When go is asserted, the
start_address and transfer_length are registered. On the next clock cycle, the control logic asserts
burst_begin, which synchronizes the internal control signals in addition to the master_address and
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-30
QII5V1
2014.06.30
Reducing Logic Utilization
master_burstcount presented to the interconnect. The timing of these two signals is important because
during bursting write transfers, byteenable, and burstcount must be held constant for the entire burst.
To avoid inefficient writes, the master posts a burst when enough data is buffered in the FIFO. To
maximize the burst efficiency, the master should stall only when a slave asserts waitrequest. In this
example, the FIFO’s used signal tracks the number of words of data that are stored in the FIFO and
determines when enough data has been buffered.
The address register increments after every word transfer, and the length register decrements after every
word transfer. The address remains constant throughout the burst. Because a transfer is not guaranteed to
complete on burst boundaries, additional logic is necessary to recognize the completion of short bursts
and complete the transfer.
Related Information
• Avalon Memory-Mapped Master Templates
Reducing Logic Utilization
You can minimize logic size of Qsys systems. Typically, there is a trade-off between logic utilization and
performance. Reducing logic utilization applies to both Avalon and AXI interfaces.
Minimizing Interconnect Logic to Reduce Logic Unitization
In Qsys, changes to the connections between master and slave reduce the amount of interconnect logic
required in the system.
Related Information
Limited Concurrency on page 8-19
Creating Dedicated Master and Slave Connections to Minimize Interconnect Logic
You can create a system where a master interface connects to a single slave interface. This configuration
eliminates address decoding, arbitration, and return data multiplexing, which simplifies the interconnect.
Dedicated master-to-slave connections attain the same clock frequencies as Avalon-ST connections.
Typically, these one-to-one connections include an Avalon memory-mapped bridge or hardware acceler‐
ator. For example, if you insert a pipeline bridge between a slave and all other master interfaces, the logic
between the bridge master and slave interface is reduced to wires. If a hardware accelerator connects only
to a dedicated memory, no system interconnect logic is generated between the master and slave pair.
Removing Unnecessary Connections to Minimize Interconnect Logic
The number of connections between master and slave interfaces affects the fMAX of your system. Every
master interface that you connect to a slave interface increases the width of the multiplexer width. As a
multiplexer width increases, so does the logic depth and width that implements the multiplexer in the
FPGA. To improve system performance, connect masters and slaves only when necessary.
When you connect a master interface to many slave interfaces, the multiplexer for the read data signal
grows. Avalon typically uses a readdata signal. AXI read data signals add a response status and last
indicator to the read response channel using rdata, rresp, and rlast. Additionally, bridges help control
the depth of multiplexers.
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Simplifying Address Decode Logic
8-31
Related Information
Implementing Command Pipelining (Master-to-Slave) on page 8-12
Simplifying Address Decode Logic
If address code logic is in the critical path, you may be able to change the address map to simplify the
decode logic. Experiment with different address maps, including a one-hot encoding, to see if results
improve.
Minimizing Arbitration Logic by Consolidating Multiple Interfaces
As the number of components in a design increases, the amount of logic required to implement the
interconnect also increases. The number of arbitration blocks increases for every slave interface that is
shared by multiple master interfaces. The width of the read data multiplexer increases as the number of
slave interfaces supporting read transfers increases on a per master interface basis. For these reasons,
consider implementing multiple blocks of logic as a single interface to reduce interconnect logic utiliza‐
tion.
Logic Consolidation Trade-Offs
You should consider the following trade-offs before making modifications to your system or interfaces:
• Consider the impact on concurrency that results when you consolidate components. When a system
has four master components and four slave interfaces, it can initiate four concurrent accesses. If you
consolidate the four slave interfaces into a single interface, then the four masters must compete for
access. Consequently, you should only combine low priority interfaces such as low speed parallel I/O
devices if the combination does not impact the performance.
• Determine whether consolidation introduces new decode and multiplexing logic for the slave interface
that the interconnect previously included. If an interface contains multiple read and write address
locations, the interface already contains the necessary decode and multiplexing logic. When you
consolidate interfaces, you typically reuse the decoder and multiplexer blocks already present in one of
the original interfaces; however, combining interfaces may simply move the decode and multiplexer
logic, rather than eliminate duplication.
• Consider whether consolidating interfaces makes the design complicated. If so, you should not
consolidate interfaces.
Related Information
Using Concurrency in Memory-Mapped Systems on page 8-6
Consolidating Interfaces
The Nios II/e core maintains communication between the Nios II /f core and external processors. The
Nios II/f core supports a maximum burst size of eight. The external processor interface supports a
maximum burst length of 64. The Nios II/e core does not support bursting. The memory in the system is
SDRAM with an Avalon maximum burst length of two.
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-32
QII5V1
2014.06.30
Consolidating Interfaces
Figure 8-21: Mixed Bursting System
Nios II/f Core
Nios II/e Core
M
M
M
M
8
8
64
8
B
1
M
8
8
B
Host Processor
Interface
B
1
8
B
1
8
64
B
B
1
1
8
B
2
B
2
Arbiter
Arbiter
Arbiter
Arbiter
Arbiter
2
S
S
S
S
S
PIO
System ID
Timer
Mutex
DDR
SDRAM
B
Burst Adapter
8
Maximum Burst Count
64
2
In this example a system with a mix of components with different burst capabilities with a Nios II/e core,
a Nios II/f core, and an external processor, which off-loads some processing tasks to the Nios II/f core.
Qsys automatically inserts burst adapters to compensate for burst length mismatches. The adapters reduce
bursts to a single transfer, or the length of two transfers. For the external processor interface connecting to
DDR SDRAM, a burst of 64 words is divided into 32 burst transfers, each with a burst length of two.
When you generate a system, Qsys inserts burst adapters based on maximum burstcount values;
consequently, the interconnect logic includes burst adapters between masters and slave pairs that do not
require bursting, if the master is capable of bursts.
In this example, Qsys inserts a burst adapter between the Nios II processors and the timer, system ID, and
PIO peripherals. These components do not support bursting and the Nios II processor performs a single
word read and write accesses to these components.
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Reducing Logic Utilization With Multiple Clock Domains
8-33
Figure 8-22: Mixed Bursting System with Bridges
To reduce the number of adapters, you can add pipeline bridges. The pipeline bridge, between the Nios
II/f core and the peripherals that do not support bursts, eliminates three burst adapters from the previous
example. A second pipeline bridge between the Nios II/f core and the DDR SDRAM, with its maximum
burst size set to eight, eliminates another burst adapter, as shown below.
Nios II/e Core
M
Nios II/f Core
M
M
Host Processor
Interface
M
M
8
8
64
8
64
64
B
1
B
1
S
B
8
8
2
S
Bridge
Bridge
M
M
8
B
2
Arbiter
Arbiter
Arbiter
Arbiter
Arbiter
2
S
S
S
S
S
PIO
System ID
Timer
Mutex
DDR
SDRAM
B
Burst Adapter
8
Maximum Burst Count
Reducing Logic Utilization With Multiple Clock Domains
You specify clock domains in Qsys on the System Contents tab. Clock sources can be driven by external
input signals to Qsys, or by PLLs inside Qsys. Clock domains are differentiated based on the name of the
clock. You can create multiple asynchronous clocks with the same frequency.
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-34
QII5V1
2014.06.30
Reducing Logic Utilization With Multiple Clock Domains
Qsys generates Clock Domain Crossing Logic (CDC) that hides the details of interfacing components
operating in different clock domains. The interconnect supports the memory-mapped protocol with each
port independently, and therefore masters do not need to incorporate clock adapters in order to interface
to slaves on a different domain. Qsys interconnect logic propagates transfers across clock domain
boundaries automatically.
Clock-domain adapters provide the following benefits:
• Allows component interfaces to operate at different clock frequencies.
• Eliminates the need to design CDC hardware.
• Allows each memory-mapped port to operate in only one clock domain, which reduces design
complexity of components.
• Enables masters to access any slave without communication with the slave clock domain.
• Allows you to focus performance optimization efforts on components that require fast clock speed.
A clock domain adapter consists of two finite state machines (FSM), one in each clock domain, that use a
hand-shaking protocol to propagate transfer control signals (read_request, write_request, and the
master waitrequest signals) across the clock boundary.
Figure 8-23: Clock Crossing Adapter
Receiver Clock Domain
Sender Clock Domain
CDC Logic
control
waitrequest
Receiver
Port
Receiver
Handshake
FSM
transfer
request
Synchronizer
acknowledge
Synchronizer
control
Sender
Handshake
FSM
waitrequest
Sender
Port
address
readdata
readdata
writedata & byte enable
This example illustrates a clock domain adapter between one master and one slave. The synchronizer
blocks use multiple stages of flip flops to eliminate the propagation of meta-stable events on the control
signals that enter the handshake FSMs. The CDC logic works with any clock ratio.
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Duration of Transfers Crossing Clock Domains
8-35
The typical sequence of events for a transfer across the CDC logic is as follows:
• The master asserts address, data, and control signals.
• The master handshake FSM captures the control signals and immediately forces the master to wait.
The FSM uses only the control signals, not address and data. For example, the master simply holds the
address signal constant until the slave side has safely captured it.
• The master handshake FSM initiates a transfer request to the slave handshake FSM.
• The transfer request is synchronized to the slave clock domain.
• The slave handshake FSM processes the request, performing the requested transfer with the slave.
• When the slave transfer completes, the slave handshake FSM sends an acknowledge back to the master
handshake FSM. The acknowledge is synchronized back to the master clock domain.
• The master handshake FSM completes the transaction by releasing the master from the wait condition.
Transfers proceed as normal on the slave and the master side, without a special protocol to handle
crossing clock domains. From the perspective of a slave, there is nothing different about a transfer
initiated by a master in a different clock domain. From the perspective of a master, a transfer across clock
domains simply requires extra clock cycles. Similar to other transfer delay cases (for example, arbitration
delay or wait states on the slave side), the Qsys forces the master to wait until the transfer terminates. As a
result, pipeline master ports do not benefit from pipelining when performing transfers to a different clock
domain.
Qsys automatically determines where to insert CDC logic based on the system and the connections
between components, and places CDC logic to maintain the highest transfer rate for all components. Qsys
evaluates the need for CDC logic for each master and slave pair independently, and generates CDC logic
wherever necessary.
Related Information
Avalon Memory-Mapped Design Optimizations
Duration of Transfers Crossing Clock Domains
CDC logic extends the duration of master transfers across clock domain boundaries. In the worst case,
which is for reads, each transfer is extended by five master clock cycles and five slave clock cycles.
Assuming the default value of 2 for the master domain synchronizer length and the slave domain
synchronizer length, the components of this delay are the following:
• Four additional master clock cycles, due to the master-side clock synchronizer.
• Four additional slave clock cycles, due to the slave-side clock synchronizer.
• One additional clock in each direction, due to potential metastable events as the control signals cross
clock domains.
Note: Systems that require a higher performance clock should use the Avalon-MM clock crossing bridge
instead of the automatically inserted CDC logic. The clock crossing bridge includes a buffering
mechanism so that multiple reads and writes can be pipelined. After paying the initial penalty for
the first read or write, there is no additional latency penalty for pending reads and writes,
increasing throughput by up to four times, at the expense of added logic resources.
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-36
QII5V1
2014.06.30
Reducing Power Consumption
Reducing Power Consumption
Qsys provides various low power design changes that enable you to reduce the power consumption of the
interconnect and custom components.
Reducing Power Consumption With Multiple Clock Domains
When you use multiple clock domains, you should put non-critical logic in the slower clock domain. Qsys
automatically reconciles data crossing over asynchronous clock domains by inserting clock crossing logic
(handshake or FIFO).
You can use clock crossing in Qsys to reduce the clock frequency of the logic that does not require a high
frequency clock, which allows you to reduce power consumption. You can use either handshaking clock
crossing bridges or handshaking clock crossing adapters to separate clock domains.
You can use the clock crossing bridge to connect master interfaces operating at a higher frequency to slave
interfaces running at a lower frequency. Only connect low throughput or low priority components to a
clock crossing bridge that operates at a reduced clock frequency. The following are examples of low
throughput or low priority components:
•
•
•
•
•
•
•
•
PIOs
UARTs (JTAG or RS-232)
System identification (SysID)
Timers
PLL (instantiated within Qsys)
Serial peripheral interface (SPI)
EPCS controller
Tristate bridge and the components connected to the bridge
By reducing the clock frequency of the components connected to the bridge, you reduce the dynamic
power consumption of the design. Dynamic power is a function of toggle rates and decreasing the clock
frequency decreases the toggle rate.
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
8-37
Reducing Power Consumption With Multiple Clock Domains
Figure 8-24: Reducing Power Utilization Using a Bridge to Separate Clock Domains
Nios II
Processor
M
Arbiter
Arbiter
S
S
DDR
SDRAM
On-Chip
Memory
M
Arbiter
200 MHz
S
Clock
Crossing
Bridge
M
5 MHz
S
S
S
S
S
S
S
PIO
UART
System ID
Timer
PLL
SPI
EPCS
Controller
S
Tristate
Conduit
M
Low-Frequency Components
S
Flash
Qsys automatically inserts clock crossing adapters between master and slave interfaces that operate at
different clock frequencies. You can choose the type of clock crossing adapter in the Qsys Project Settings
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-38
Reducing Power Consumption by Minimizing Toggle Rates
QII5V1
2014.06.30
tab. Adapters do not appear in the Connections column because you do not insert them. The following
clock crossing adapter types are available in Qsys:
• Handshake—Uses a simple handshaking protocol to propagate transfer control signals and responses
across the clock boundary. This adapter uses fewer hardware resources because each transfer is safely
propagated to the target domain before the next transfer begins. The Handshake adapter is appropriate
for systems with low throughput requirements.
• FIFO—Uses dual-clock FIFOs for synchronization. The latency of the FIFO adapter is approximately
two clock cycles more than the handshake clock crossing component, but the FIFO-based adapter can
sustain higher throughput because it supports multiple transactions simultaneously. The FIFO adapter
requires more resources, and is appropriate for memory-mapped transfers requiring high throughput
across clock domains.
• Auto—Qsys specifies the appropriate FIFO adapter for bursting links and the Handshake adapter for
all other links.
Because the clock crossing bridge uses FIFOs to implement the clock crossing logic, it buffers transfers
and data. Clock crossing adapters are not pipelined, so that each transaction is blocking until the transac‐
tion completes. Blocking transactions may lower the throughput substantially; consequently, if you want
to reduce power consumption without limiting the throughput significantly, you should use the clock
crossing bridge or the FIFO clock crossing adapter. However, if the design requires single read transfers, a
clock crossing adapter is preferable because the latency is lower.
The clock crossing bridge requires few logic resources other than on-chip memory. The number of onchip memory blocks used is proportional to the address span, data width, buffering depth, and bursting
capabilities of the bridge. The clock crossing adapter does not use on-chip memory and requires a
moderate number of logic resources. The address span, data width, and the bursting capabilities of the
clock crossing adapter determine the resource utilization of the device.
When you decide to use a clock crossing bridge or clock crossing adapter, you must consider the effects of
throughput and memory utilization in the design. If on-chip memory resources are limited, you may be
forced to choose the clock crossing adapter. Using the clock crossing bridge to reduce the power of a
single component may not justify using more resources. However, if you can place all of the low priority
components behind a single clock crossing bridge, you may reduce power consumption in the design.
Related Information
Power Optimization
Reducing Power Consumption by Minimizing Toggle Rates
A Qsys system consumes power whenever logic transitions between on and off states. When the state is
held constant between clock edges, no charging or discharging occurs. You can use the following design
methodologies to reduce the toggle rates of your design:
• Registering component boundaries
• Using clock enable signals
• Inserting bridges
Qsys interconnect is uniquely combinational when no adapters or bridges are present and there is no
interconnect pipelining. When a slave interface is not selected by a master, various signals may toggle and
propagate into the component. By registering the boundary of your component at the master or slave
interface, you can minimize the toggling of the interconnect and your component. In addition, registering
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Reducing Power Consumption by Minimizing Toggle Rates
8-39
boundaries can improve operating frequency. When you register the signals at the interface level, you
must ensure that the component continues to operate within the interface standard specification.
Avalon-MM waitrequest is a difficult signal to synchronize when you add registers to your component.
The waitrequest signal must be asserted during the same clock cycle that a master asserts read or write
to in order to prolong the transfer. A master interface can read the waitrequest signal too early and post
more reads and writes prematurely.
Note: There is no direct AXI equivalent for waitrequest and burstcount, though the AMBA Protocol
Specification implies that the AXI ready signal cannot depend combinatorially on the AXI valid
signal. Therefore, Qsys typically buffers AXI component boundaries for the ready signal.
For slave interfaces, the interconnect manages the begintransfer signal, which is asserted during the
first clock cycle of any read or write transfer. If the waitrequest is one clock cycle late, you can logically
OR the waitrequest and the begintransfer signals to form a new waitrequest signal that is properly
synchronized. Alternatively, the component can assert waitrequest before it is selected, guaranteeing
that the waitrequest is already asserted during the first clock cycle of a transfer.
Figure 8-25: Variable Latency
Avalon-MM
Slave Port
writedata
write
Remaining
Component
Logic
readdata
read
waitrequest
ready
(synchronous)
begintransfer
Using Clock Enables
You can use clock enables to hold the logic in a steady state, and the write and read signals as clock
enables for slave components. Even if you add registers to your component boundaries, the interface can
potentially toggle without the use of clock enables. You can also use the clock enable to disable combina‐
tional portions of the component.
For example, you can use an active high clock enable to mask the inputs into the combinational logic to
prevent it from toggling when the component is inactive. Before preventing inactive logic from toggling,
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-40
QII5V1
2014.06.30
Reducing Power Consumption by Disabling Logic
you must determine if the masking causes the circuit to function differently. If masking causes a
functional failure, it may be possible to use a register stage to hold the combinational logic constant
between clock cycles.
Inserting Bridges
You can use bridges to reduce toggle rates, if you do not want to modify the component by using
boundary registers or clock enables. A bridge acts as a repeater where transfers to the slave interface are
repeated on the master interface. If the bridge is not accessed, the components connected to its master
interface are also not accessed. The master interface of the bridge remains idle until a master accesses the
bridge slave interface.
Bridges can also reduce the toggle rates of signals that are inputs to other master interfaces. These signals
are typically readdata, readdatavalid, and waitrequest. Slave interfaces that support read accesses
drive the readdata, readdatavalid, and waitrequest signals. A bridge inserts either a register or clock
crossing FIFO between the slave interface and the master to reduce the toggle rate of the master input
signals.
Related Information
• AMBA Protocol Specification
• Power Optimization
Reducing Power Consumption by Disabling Logic
There are typically two types of low power modes: volatile and non-volatile. A volatile low power mode
holds the component in a reset state. When the logic is reactivated, the previous operational state is lost. A
non-volatile low power mode restores the previous operational state. You can use either softwarecontrolled or hardware-controlled sleep modes to disable a component in order to reduce power
consumption.
Software-Controlled Sleep Mode
To design a component that supports software-controlled sleep mode, create a single memory-mapped
location that enables and disables logic by writing a zero or one. You can use the register’s output as a
clock enable or reset, depending on whether the component has non-volatile requirements. The slave
interface must remain active during sleep mode so that the enable bit is set when the component needs to
be activated.
If multiple masters can access a component that supports sleep mode, you can use the mutex core to
provide mutually exclusive accesses to your component. You can also build in the logic to re-enable the
component on the very first access by any master in your system. If the component requires multiple
clock cycles to re-activate, then it must assert a wait request to prolong the transfer as it exits sleep mode.
Hardware-Controlled Sleep Mode
Alternatively, you can implement a timer in your component that automatically causes the component to
enter a sleep mode based on a timeout value specified in clock cycles between read or write accesses. Each
access resets the timer to the timeout value. Each cycle with no accesses decrements the timeout value by
one. If the counter reaches zero, the hardware enters sleep mode until the next access.
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Optimizing Qsys System Performance Design Examples
8-41
Figure 8-26: Hardware-Controlled Sleep Components
Timeout Value
read
write
countq
d
= 0?
reset
Down
Counter
wake
load
count enable
waitrequest
sleep_n
busy
This example provides a schematic for the hardware-controlled sleep mode. If restoring the component to
an active state takes a long time, use a long timeout value so that the component is not continuously
entering and exiting sleep mode. The slave interface must remain functional while the rest of the
component is in sleep mode. When the component exits sleep mode, the component must assert the
waitrequest signal until it is ready for read or write accesses.
Related Information
• Mutex Core
• Power Optimization
Optimizing Qsys System Performance Design Examples
Avalon Pipelined Read Master Example on page 8-41
Multiplexer Examples on page 8-43
Related Information
Avalon Interface Specifications
Avalon Pipelined Read Master Example
For a high throughput system using the Avalon-MM standard, you can design a pipelined read master
that allows a system to issue multiple read requests before data returns. Pipelined read masters hide the
latency of read operations by posting reads as frequently as every clock cycle. You can use this type of
master when the address logic is not dependent on the data returning.
Avalon Pipelined Read Master Example Design Requirements
You must carefully design the logic for the control and data paths of pipelined read masters. The control
logic must extend a read cycle whenever the waitrequest signal is asserted. This logic must also control
the master address, byteenable, and read signals. To achieve maximum throughput, pipelined read
masters should post reads continuously as long as waitrequest is de-asserted. While read is asserted, the
address presented to the interconnect is stored.
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-42
QII5V1
2014.06.30
Expected Throughput Improvement
The data path logic includes the readdata and readdatavalid signals. If your master can accept data on
every clock cycle, you can register the data with the readdatavalid as an enable bit. If your master
cannot process a continuous stream of read data, it must buffer the data in a FIFO. The control logic must
stop issuing reads when the FIFO reaches a predetermined fill level to prevent FIFO overflow.
Expected Throughput Improvement
The throughput improvement that you can achieve with a pipelined read master is typically directly
proportional to the pipeline depth of the interconnect and the slave interface. For example, if the total
latency is two cycles, you can double the throughput by inserting a pipelined read master, assuming the
slave interface also supports pipeline transfers. If either the master or slave does not support pipelined
read transfers, then the interconnect asserts waitrequest until the transfer completes. You can also gain
throughput when there are some cycles of overhead before a read response.
Where reads are not pipelined, the throughput is reduced. When both the master and slave interfaces
support pipelined read transfers, data flows in a continuous stream after the initial latency. You can use a
pipelined read master that stores data in a FIFO to implement a custom DMA, hardware accelerator, or
off-chip communication interface.
Figure 8-27: Pipelined Read Master
start_address[31:0]
go
increment_address
d
load
Up
Counter
master_address[31:0]
q
VCC
count enable
byteenable[3:0]
done
transfer_length[31:0]
go
increment_address
d
load
q
length[31:0]
read
Down
Counter
count enable
readdatavalid
Tracking Logic/
State Machine
increment_address
fifo_used[]
waitrequest
Altera Corporation
user_data[31:0]
q
user_data_empty
empty
user_data_read
read acknowledge
used[]
Look-Ahead FIFO
d
write
writedata[31:0]
readdatavalid
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Multiplexer Examples
8-43
This example shows a pipelined read master that stores data in a FIFO. The master performs word
accesses that are word-aligned and reads from sequential memory addresses. The transfer length is a
multiple of the word size.
When the go bit is asserted, the master registers the start_address and transfer_length signals. The
master begins issuing reads continuously on the next clock cycle until the length register reaches zero. In
this example, the word size is four bytes so that the address always increments by four, and the length
decrements by four. The read signal remains asserted unless the FIFO fills to a predetermined level. The
address register increments and the length register decrements if the length has not reached 0 and a read
is posted.
The master posts a read transfer every time the read signal is asserted and the waitrequest is deasserted.
The master issues reads until the entire buffer has been read or waitrequest is asserted. An optional
tracking block monitors the done bit. When the length register reaches zero, some reads are outstanding.
The tracking logic prevents assertion of done until the last read completes, and monitors the number of
reads posted to the interconnect so that it does not exceed the space remaining in the readdata FIFO.
This example includes a counter that verifies that the following conditions are met:
• If a read is posted and readdatavalid is deasserted, the counter increments.
• If a read is not posted and readdatavalid is asserted, the counter decrements.
When the length register and the tracking logic counter reach zero, all the reads have completed and the
done bit is asserted. The done bit is important if a second master overwrites the memory locations that the
pipelined read master accesses. This bit guarantees that the reads have completed before the original data
is overwritten.
Multiplexer Examples
You can combine adapters with streaming components to create data paths whose input and output
streams have different properties. The following examples demonstrate datapaths in which the output
stream exhibits higher performance than the input stream.
Figure 8-28: Data Path that Doubles the Clock Frequency
Data Source
Input
src
30% Channel Utilization
8 Bits at 100 MHz
Data Source
Input
src
80% Channel Utilization
8 Bits at 100 MHz
On-Chip FIFO Memory
Dual Clock
sink
src
sink
src
On-Chip FIFO Memory
Dual Clock
sink
27.3% Sample Rate
120 MHz
src
72.7% Sample Rate
110 MHz
100% Channel Utilization
Output 110 MHz
sink
The diagram below illustrates a data path that uses the dual clock version of the on-chip FIFO memory
and Avalon-ST channel multiplexer to merge the 100 MHz input from two streaming data sources into a
single 200 MHz streaming output. This example shows an output with double the throughput of each
interface with a corresponding doubling of the clock frequency.
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
8-44
QII5V1
2014.06.30
Document Revision History
Figure 8-29: Data Path to Double Data Width and Maintain Original Frequency
Data Source
Input
8 Bits at 100 MHz
src
sink
Data Format
Adapter
src
16 Bits at 100 MHz
sink
src
Data Source
Input
8 Bits at 100 MHz
src
sink
Data Format
Adapter
src
16 Bits at 100 MHz
16 Bits
at 100 MHz
sink
The diagram below llustrates a data path that uses the data format adapter and Avalon-ST channel
multiplexer to convert two 8-bit inputs running at 100 MHz to a single 16-bit output at 100 MHz.
Figure 8-30: Data Path to Boost the Clock Frequency
Data Source
Input
src
On-Chip FIFO Memory
Dual Clock
100 MHz
Data Source
Input
src
sink
src
200 MHz
sink
src
On-Chip FIFO Memory
Dual Clock
100 MHz
sink
src
200 MHz
Output
200 MHz
sink
The diagram below illustrates a data path that uses the dual clock version of the on-chip FIFO memory to
boost the frequency of input data from 100 MHz to 110 MHz by sampling two input streams at differen‐
tial rates. The on-chip FIFO memory has an input clock frequency of 100 MHz, and an output clock
frequency of 110 MHz. The channel multiplexer runs at 110 MHz and samples one input stream 27.3
percent of the time, and the second 72.7 percent of the time. You do not need to know what the typical
and maximum input channel utilizations are before for this type of design. For example, if the first
channel hits 50% utilization, the output stream exceeds 100% utilization.
Document Revision History
The table below indicates edits made to the Optimizing Qsys System Performance content since its
creation.
Altera Corporation
Optimizing Qsys System Performance
Send Feedback
QII5V1
2014.06.30
Document Revision History
8-45
Table 8-2: Document Revision History
Date
Version
Changes
May 2013
13.0.0
AMBA APB support.
November 2012
12.1.0
AMBA AXI4 support.
June 2012
12.0.0
AMBA AXI3 support.
November 2011
11.1.0
New document release.
Related Information
Quartus II Handbook Archive
Optimizing Qsys System Performance
Send Feedback
Altera Corporation
Component Interface Tcl Reference
9
2014.12.15
QII5V1
Subscribe
Send Feedback
Tcl commands allow you to perform a wide range of functions in Qsys. Command descriptions contain
the Qsys phases where you can use the command, for example, main program, elaboration, composition,
or fileset callback.
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.
For more information about procedures for creating IP component _hw.tcl files in the Qsys Component
Editor, and supported interface standards, refer to Creating Qsys Components and Qsys Interconnect in
volume 1 of the Quartus II Handbook.
If you are developing an IP component to work with the Nios II processor, refer to Publishing Component
Information to Embedded Software in section 3 of the Nios II Software Developer's Handbook, which
describes how to publish hardware IP component information for embedded software tools, such as a C
compiler and a Board Support Package (BSP) generator.
Related Information
Avalon Interface Specifications
AMBA Protocol Specifications
Creating Qsys Components on page 6-1
Qsys Interconnect on page 7-1
Publishing Component Information to Embedded Software
•
•
•
•
•
Qsys _hw.tcl Command Reference
To use the current version of the Tcl commands, include the following command at the top of your script:
package require -exact qsys <version>
© 2014 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
9-2
Interfaces and Ports
QII5V1
2014.12.15
Interfaces and Ports
add_interface on page 9-3
add_interface_port on page 9-5
get_interfaces on page 9-7
get_interface_assignment on page 9-8
get_interface_assignments on page 9-9
get_interface_ports on page 9-10
get_interface_properties on page 9-11
get_interface_property on page 9-12
get_port_properties on page 9-13
get_port_property on page 9-14
set_interface_assignment on page 9-15
set_interface_property on page 9-17
set_port_property on page 9-18
set_interface_upgrade_map on page 9-19
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
add_interface
9-3
add_interface
Description
Adds an interface to your module. An interface represents a collection of related signals that are managed
together in the parent system. These signals are implemented in the IP component's HDL, or exported
from an interface from a child instance. As the IP component author, you choose the name of the
interface.
Availability
Discovery, Main Program, Elaboration, Composition
Usage
add_interface <name> <type> <direction> [<associated_clock>]
Returns
No returns value.
Arguments
name
A name you choose to identify an interface.
type
The type of interface.
direction
The interface direction.
associated_clock (optional)
(deprecated) For interfaces requiring associated clocks, use: set_interface_property
<interface> associatedClock <clockInterface> For interfaces requiring associated
resets, use: set_interface_property <interface> associatedReset
<resetInterface>
Example
add_interface mm_slave avalon slave
add_interface my_export conduit end
set_interface_property my_export EXPORT_OF uart_0.external_connection
Notes
By default, interfaces are enabled. You can set the interface property ENABLED to false to disable an
interface. If an interface is disabled, it is hidden and its ports are automatically terminated to their default
values. Active high signals are terminated to 0. Active low signals are terminated to 1.
If the IP component is composed of child instances, the top-level interface is associated with a child
instance's interface with set_interface_property interface EXPORT_OF
child_instance.interface.
The following direction rules apply to Qsys-supported interfaces.
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-4
QII5V1
2014.12.15
add_interface
Interface Type
Direction
avalon
master, slave
axi
master, slave
tristate_conduit
master, slave
avalon_streaming
source, sink
interrupt
sender, receiver
conduit
end
clock
source, sink
reset
source, sink
nios_custom_instruction
slave
Related Information
•
•
•
•
Altera Corporation
add_interface_port on page 9-5
get_interface_assignments on page 9-9
get_interface_properties on page 9-11
get_interfaces on page 9-7
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
add_interface_port
9-5
add_interface_port
Description
Adds a port to an interface on your module. The name must match the name of a signal on the top-level
module in the HDL of your IP component. The port width and direction must be set before the end of the
elaboration phase. You can set the port width as follows:
• In the Main program, you can set the port width to a fixed value or a width expression.
• If the port width is set to a fixed value in the Main program, you can update the width in the elabora‐
tion callback.
Availability
Main Program, Elaboration
Usage
add_interface_port <interface> <port> [<signal_type> <direction> <width_expression>]
Returns
Arguments
interface
The name of the interface to which this port belongs.
port
The name of the port. This name must match a signal in your top-level HDL for this IP
component.
signal_type (optional)
The type of signal for this port, which must be unique. Refer to the Avalon Interface
Specifications for the signal types available for each interface type.
direction (optional)
The direction of the signal. Refer to Direction Properties.
width_expression (optional)
The width of the port, in bits. The width may be a fixed value, or a simple arithmetic
expression of parameter values.
Example
fixed width:
add_interface_port mm_slave s0_rdata readdata output 32
width expression:
add_parameter DATA_WIDTH INTEGER 32
add_interface_port s0 rdata readdata output "DATA_WIDTH/2"
Related Information
• add_interface on page 9-3
• get_port_properties on page 9-13
• get_port_property on page 9-14
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-6
add_interface_port
QII5V1
2014.12.15
• get_port_property on page 9-14
• Direction Properties on page 9-99
• Avalon Interface Specifications
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_interfaces
9-7
get_interfaces
Description
Returns a list of top-level interfaces.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation,
Parameter Upgrade
Usage
get_interfaces
Returns
A list of the top-level interfaces exported from the system.
Arguments
No arguments.
Example
get_interfaces
Related Information
add_interface on page 9-3
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-8
get_interface_assignment
QII5V1
2014.12.15
get_interface_assignment
Description
Returns the value of the specified assignment for the specified interface
Availability
Main Program, Elaboration, Validation, Composition
Usage
get_interface_assignment <interface> <assignment>
Returns
The value of the assignment.
Arguments
interface
The name of a top-level interface.
assignment
The name of an assignment.
Example
get_interface_assignment s1 embeddedsw.configuration.isFlash
Related Information
• add_interface on page 9-3
• get_interface_assignments on page 9-9
• get_interfaces on page 9-7
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_interface_assignments
9-9
get_interface_assignments
Description
Returns the value of all interface assignments for the specified interface.
Availability
Main Program, Elaboration, Validation, Composition
Usage
get_interface_assignments <interface>
Returns
A list of assignment keys.
Arguments
interface
The name of the top-level interface whose assignment is being retrieved.
Example
get_interface_assignments s1
Related Information
• add_interface on page 9-3
• get_interface_assignment on page 9-8
• get_interfaces on page 9-7
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-10
get_interface_ports
QII5V1
2014.12.15
get_interface_ports
Description
Returns the names of all of the ports that have been added to a given interface. If the interface name is
omitted, all ports for all interfaces are returned.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation,
Parameter Upgrade
Usage
get_interface_ports [<interface>]
Returns
A list of port names.
Arguments
interface (optional)
The name of a top-level interface.
Example
get_interface_ports mm_slave
Related Information
• add_interface_port on page 9-5
• get_port_property on page 9-14
• set_port_property on page 9-18
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_interface_properties
9-11
get_interface_properties
Description
Returns the names of all the interface properties for the specified interface as a space separated list
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation,
Parameter Upgrade
Usage
get_interface_properties <interface>
Returns
A list of properties for the interface.
Arguments
interface
The name of an interface.
Example
get_interface_properties interface
Notes
The properties for each interface type are different. Refer to the Avalon Interface Specifications for more
information about interface properties.
Related Information
• get_interface_property on page 9-12
• set_interface_property on page 9-17
• Avalon Interface Specifications
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-12
QII5V1
2014.12.15
get_interface_property
get_interface_property
Description
Returns the value of a single interface property from the specified interface.
Availability
Discovery, Main Program, Elaboration, Composition, Fileset Generation
Usage
get_interface_property <interface> <property>
Returns
Arguments
interface
The name of an interface.
property
The name of the property whose value you want to retrieve. Refer to Interface Properties.
Example
get_interface_property mm_slave linewrapBursts
Notes
The properties for each interface type are different. Refer to the Avalon Interface Specifications for more
information about interface properties.
Related Information
• get_interface_properties on page 9-11
• set_interface_property on page 9-17
• Avalon Interface Specifications
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_port_properties
9-13
get_port_properties
Description
Returns a list of port properties.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation,
Parameter Upgrade
Usage
get_port_properties
Returns
A list of port properties. Refer to Port Properties.
Arguments
No arguments.
Example
get_port_properties
Related Information
•
•
•
•
add_interface_port on page 9-5
get_port_property on page 9-14
set_port_property on page 9-18
Port Properties on page 9-97
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-14
get_port_property
QII5V1
2014.12.15
get_port_property
Description
Returns the value of a property for the specified port.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation,
Parameter Upgrade
Usage
get_port_property <port> <property>
Returns
The value of the property.
Arguments
port
The name of the port.
property
The name of a port property. Refer to Port Properties.
Example
get_port_property rdata WIDTH_VALUE
Related Information
•
•
•
•
Altera Corporation
add_interface_port on page 9-5
get_port_properties on page 9-13
set_port_property on page 9-18
Port Properties on page 9-97
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
set_interface_assignment
9-15
set_interface_assignment
Description
Sets the value of the specified assignment for the specified interface.
Availability
Main Program, Elaboration, Validation, Composition
Usage
set_interface_assignment <interface> <assignment> [<value>]
Returns
No return value.
Arguments
interface
The name of the top-level interface whose assignment is being set.
assignment
The assignment whose value is being set.
value (optional)
The new assignment value.
Example
set_interface_assignment s1 embeddedsw.configuration.isFlash 1
Notes
Assignments for Nios II Software Build Tools
Interface assignments provide extra data for the Nios II Software Build Tools working with the generated
system.
Assignments for Qsys Tools
There are several assignments that guide behavior in the Qsys tools.
qsys.ui.export_name:
qsys.ui.connect:
ui.blockdiagram.direction:
Component Interface Tcl Reference
Send Feedback
If present, this interface should always be exported when an instance is
added to a Qsys system. The value is the requested name of the exported
interface in the parent system.
If present, this interface should be auto-connected when an instance is
added to a Qsys system. The value is a comma-separated list of other
interfaces on the same instance that should be connected with this
interface.
If present, the direction of this interface in the block diagram is set by the
user. The value is either "output" or "input".
Altera Corporation
9-16
set_interface_assignment
QII5V1
2014.12.15
Related Information
• add_interface on page 9-3
• get_interface_assignment on page 9-8
• get_interface_assignments on page 9-9
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
set_interface_property
9-17
set_interface_property
Description
Sets the value of a property on an exported top-level interface. You can use this command to set the
EXPORT_OF property to specify which interface of a child instance is exported via this top-level interface.
Availability
Main Program, Elaboration, Composition
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
set_interface_property mm_slave linewrapBursts false
Notes
The properties for each interface type are different. Refer to the Avalon Interface Specifications for more
information about interface properties.
Related Information
•
•
•
•
get_interface_properties on page 9-11
get_interface_property on page 9-12
Interface Properties on page 9-90
Avalon Interface Specifications
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-18
set_port_property
QII5V1
2014.12.15
set_port_property
Description
Sets a port property.
Availability
Main Program, Elaboration
Usage
set_port_property <port> <property> [<value>]
Returns
The new value.
Arguments
port
The name of the port.
property
One of the supported properties. Refer to Port Properties.
value (optional)
The value to set.
Example
set_port_property rdata WIDTH 32
Related Information
• add_interface_port on page 9-5
• get_port_properties on page 9-13
• set_port_property on page 9-18
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
set_interface_upgrade_map
9-19
set_interface_upgrade_map
Description
Maps the interface name of an older version of an IP core to the interface name for the current IP core.
The interface type must be the same between the older and newer versions of the IP cores. This allows
system connections and properties to maintain proper functionality. By default, if the older and newer
versions of IP core have the same name and type, then Qsys maintains all properties and connections
automatically.
Availability
Parameter Upgrade
Usage
set_interface_upgrade_map { <old_interface_name> <new_interface_name>
<old_interface_name_2> <new_interface_name_2> … }
Returns
No return value.
Arguments
{ <old_interface_name> <new_interface_name>}
List of mappings between between names of older and newer interfaces.
Example
set_interface_upgrade_map { avalon_master_interface new_avalon_master_interface }
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-20
Parameters
QII5V1
2014.12.15
Parameters
add_parameter on page 9-21
get_parameters on page 9-22
get_parameter_properties on page 9-23
get_parameter_property on page 9-24
get_parameter_value on page 9-25
get_string on page 9-26
load_strings on page 9-28
set_parameter_property on page 9-29
set_parameter_value on page 9-30
decode_address_map on page 9-31
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
add_parameter
9-21
add_parameter
Description
Adds a parameter to your IP component.
Availability
Main Program
Usage
add_parameter <name> <type> [<default_value> <description>]
Returns
Arguments
name
The name of the parameter.
type
The data type of the parameter Refer to Parameter Type Properties.
default_value (optional)
The initial value of the parameter in a new instance of the IP component.
description (optional)
Explains the use of the parameter.
Example
add_parameter seed INTEGER 17 "The seed to use for data generation."
Notes
Most parameter types have a single GUI element for editing the parameter value. string_list and
integer_list parameters are different, because they are edited as tables. A multi-column table can be
created by grouping multiple into a single table. To edit multiple list parameters in a single table, the
display items for the parameters must be added to a group with a TABLE hint:
add_parameter coefficients INTEGER_LIST add_parameter positions INTEGER_LIST
add_display_item "" "Table Group" GROUP TABLE add_display_item "Table Group"
coefficients PARAMETER add_display_item "Table Group" positions PARAMETER
Related Information
•
•
•
•
•
•
get_parameter_properties on page 9-23
get_parameter_property on page 9-24
get_parameter_value on page 9-25
set_parameter_property on page 9-29
set_parameter_value on page 9-30
Parameter Type Properties on page 9-95
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-22
get_parameters
QII5V1
2014.12.15
get_parameters
Description
Returns the names of all the parameters in the IP component.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation,
Parameter Upgrade
Usage
get_parameters
Returns
A list of parameter names
Arguments
No arguments.
Example
get_parameters
Related Information
•
•
•
•
•
Altera Corporation
add_parameter on page 9-21
get_parameter_property on page 9-24
get_parameter_value on page 9-25
get_parameters on page 9-22
set_parameter_property on page 9-29
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_parameter_properties
9-23
get_parameter_properties
Description
Returns a list of all the parameter properties as a list of strings. The get_parameter_property and
set_parameter_property commands are used to get and set the values of these properties, respectively.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation,
Parameter Upgrade
Usage
get_parameter_properties
Returns
A list of parameter property names. Refer to Parameter Properties.
Arguments
No arguments.
Example
set property_summary [ get_parameter_properties ]
Related Information
•
•
•
•
•
•
add_parameter on page 9-21
get_parameter_property on page 9-24
get_parameter_value on page 9-25
get_parameters on page 9-22
set_parameter_property on page 9-29
Parameter Properties on page 9-92
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-24
QII5V1
2014.12.15
get_parameter_property
get_parameter_property
Description
Returns the value of a property of a parameter.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation,
Parameter Upgrade
Usage
get_parameter_property <parameter> <property>
Returns
The value of the property.
Arguments
parameter
The name of the parameter whose property value is being retrieved.
property
The name of the property. Refer to Parameter Properties.
Example
set enabled [ get_parameter_property parameter1 ENABLED ]
Related Information
•
•
•
•
•
•
•
Altera Corporation
add_parameter on page 9-21
get_parameter_properties on page 9-23
get_parameter_value on page 9-25
get_parameters on page 9-22
set_parameter_property on page 9-29
set_parameter_value on page 9-30
Parameter Properties on page 9-92
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_parameter_value
9-25
get_parameter_value
Description
Returns the current value of a parameter defined previously with the add_parameter command.
Availability
Discovery, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation, Parameter
Upgrade
Usage
get_parameter_value <parameter>
Returns
The value of the parameter.
Arguments
parameter
The name of the parameter whose value is being retrieved.
Example
set width [ get_parameter_value fifo_width ]
Notes
If AFFECTS_ELABORATION is false for a given parameter, get_parameter_value is not available for that
parameter from the elaboration callback. If AFFECTS_GENERATION is false then it is not available from the
generation callback.
Related Information
•
•
•
•
•
add_parameter on page 9-21
get_parameter_property on page 9-24
get_parameters on page 9-22
set_parameter_property on page 9-29
set_parameter_value on page 9-30
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-26
QII5V1
2014.12.15
get_string
get_string
Description
Returns the value of an externalized string previously loaded by the load_strings command.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation,
Parameter Upgrade
Usage
get_string <identifier>
Returns
The externalized string.
Arguments
identifier
The string identifer.
Example
hw.tcl:
load_strings test.properties
set_module_property NAME test
set_module_property VERSION [get_string VERSION]
set_module_property DISPLAY_NAME [get_string DISPLAY_NAME]
add_parameter firepower INTEGER 0 ""
set_parameter_property firepower DISPLAY_NAME [get_string PARAM_DISPLAY_NAME]
set_parameter_property firepower TYPE INTEGER
set_parameter_property firepower DESCRIPTION [get_string PARAM_DESCRIPTION]
test.properties:
DISPLAY_NAME = Trogdor!
VERSION = 1.0
PARAM_DISPLAY_NAME = Firepower
PARAM_DESCRIPTION = The amount of force to use when breathing fire.
Notes
Use uppercase words separated with underscores to name string identifiers. If you are externalizing
module properties, use the module property name for the string identifier:
set_module_property DISPLAY_NAME [get_string DISPLAY_NAME]
If you are externalizing a parameter property, qualify the parameter property with the parameter name,
with uppercase format, if needed:
set_parameter_property my_param DISPLAY_NAME [get_string MY_PARAM_DISPLAY_NAME]
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_string
9-27
If you use a string to describe a string format, end the identifier with _FORMAT.
set formatted_string [ format
"arg2" ]
[ get_string TWO_ARGUMENT_MESSAGE_FORMAT ] "arg1"
Related Information
load_strings on page 9-28
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-28
QII5V1
2014.12.15
load_strings
load_strings
Description
Loads strings from an external .properties file.
Availability
Discovery, Main Program
Usage
load_strings <path>
Returns
No return value.
Arguments
path
The path to the properties file.
Example
hw.tcl:
load_strings test.properties
set_module_property NAME test
set_module_property VERSION [get_string VERSION]
set_module_property DISPLAY_NAME [get_string DISPLAY_NAME]
add_parameter firepower INTEGER 0 ""
set_parameter_property firepower DISPLAY_NAME [get_string PARAM_DISPLAY_NAME]
set_parameter_property firepower TYPE INTEGER
set_parameter_property firepower DESCRIPTION [get_string PARAM_DESCRIPTION]
test.properties:
DISPLAY_NAME = Trogdor!
VERSION = 1.0
PARAM_DISPLAY_NAME = Firepower
PARAM_DESCRIPTION = The amount of force to use when breathing fire.
Notes
Refer to the Java Properties File for properties file format. A .properties file is a text file with KEY=value
pairs. For externalized strings, the KEY is a string identifier and the value is the externalized string.
For example:
TROGDOR = A dragon with a big beefy arm
Related Information
• get_string on page 9-26
• Java Properties File
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
set_parameter_property
9-29
set_parameter_property
Description
Sets a single parameter property.
Availability
Main Program, Edit, Elaboration, Validation, Composition
Usage
set_parameter_property <parameter> <property> <value>
Returns
Arguments
parameter
The name of the parameter that is being set.
property
The name of the property. Refer to Parameter Properties.
value
The new value for the property.
Example
set_parameter_property BAUD_RATE ALLOWED_RANGES {9600 19200 38400}
Related Information
•
•
•
•
add_parameter on page 9-21
get_parameter_properties on page 9-23
set_parameter_property on page 9-29
Parameter Properties on page 9-92
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-30
set_parameter_value
QII5V1
2014.12.15
set_parameter_value
Description
Sets a parameter value. The value of a derived parameter can be updated by the IP component in the
elaboration callback or the edit callback. Any changes to the value of a derived parameter in the edit
callback will not be preserved.
Availability
Edit, Elaboration, Validation, Composition, Parameter Upgrade
Usage
set_parameter_value <parameter> <value>
Returns
No return value.
Arguments
parameter
The name of the parameter that is being set.
value
Specifies the new parameter value.
Example
set_parameter_value half_clock_rate [ expr { [ get_parameter_value clock_rate ] /
2 } ]
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
decode_address_map
9-31
decode_address_map
Description
Converts an XML–formatted address map into a list of Tcl lists. Each inner list is in the correct format for
conversion to an array. The XML code that describes each slave includes: its name, start address, and end
address.
Availability
Elaboration, Generation, Composition
Usage
decode_address_map <address_map_XML_string>
Returns
No return value.
Arguments
address_mapXML_string
An XML string that describes the address map of a master.
Example
In this example, the code describes the address map for the master that accesses the ext_ssram,
sys_clk_timer and sysid slaves. The format of the string may differ from the example below; it may
have different white space between the elements and include additional attributes or elements. Use the
decode_address_map command to decode the code that represents a master’s address map to ensure that
your code works with future versions of the address map.
<address-map>
<slave name='ext_ssram' start='0x01000000' end='0x01200000' />
<slave name='sys_clk_timer' start='0x02120800' end='0x02120820' />
<slave name='sysid' start='0x021208B8' end='0x021208C0' />
</address-map>
Note: Altera recommends that you use the code provided below to enumerate over the IP components
within an address map, rather than writing your own parser.
set address_map_xml [get_parameter_value my_map_param]
set address_map_dec [decode_address_map $address_map_xml]
foreach i $address_map_dec {
array set info $i
send_message info "Connected to slave $info(name)"
}
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-32
Display Items
QII5V1
2014.12.15
Display Items
add_display_item on page 9-33
get_display_items on page 9-35
get_display_item_properties on page 9-36
get_display_item_property on page 9-37
set_display_item_property on page 9-38
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
add_display_item
9-33
add_display_item
Description
Specifies the following aspects of the IP component display:
• Creates logical groups for a IP component's parameters. For example, to create separate groups for the
IP component's timing, size, and simulation parameters. An IP component displays the groups and
parameters in the order that you specify the display items in the _hw.tcl file.
• Groups a list of parameters to create multi-column tables.
• Specifies an image to provide representation of a parameter or parameter group.
• Creates a button by adding a display item of type action. The display item includes the name of the
callback to run.
Availability
Main Program
Usage
add_display_item <parent_group> <id> <type> [<args>]
Returns
Arguments
parent_group
Specifies the group to which a display item belongs
id
The identifier for the display item. If the item being added is a parameter, this is the
parameter name. If the item is a group, this is the group name.
type
The type of the display item. Refer to Display Item Kind Properties.
args (optional)
Provides extra information required for display items.
Example
add_display_item "Timing" read_latency PARAMETER
add_display_item "Sounds" speaker_image_id ICON speaker.jpg
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-34
QII5V1
2014.12.15
add_display_item
Notes
The following examples illustrate further illustrate the use of arguments:
• add_display_item groupName id icon path-to-image-file
• add_display_item groupName parameterName parameter
• add_display_item groupName id text "your-text"
The your-text argument is a block of text that is displayed in the GUI. Some simple HTML formatting
is allowed, such as <b> and <i>, if the text starts with <html>.
• add_display_item parentGroupName childGroupName group [tab]
The tab is an optional parameter. If present, the group appears in separate tab in the GUI for the
instance.
• add_display_item parentGroupName actionName action buttonClickCallbackProc
Related Information
•
•
•
•
•
Altera Corporation
get_display_item_properties on page 9-36
get_display_item_property on page 9-37
get_display_items on page 9-35
set_display_item_property on page 9-38
Display Item Kind Properties on page 9-101
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_display_items
9-35
get_display_items
Description
Returns a list of all items to be displayed as part of the parameterization GUI.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation,
Parameter Upgrade
Usage
get_display_items
Returns
List of display item IDs.
Arguments
No arguments.
Example
get_display_items
Related Information
•
•
•
•
add_display_item on page 9-33
get_display_item_properties on page 9-36
get_display_item_property on page 9-37
set_display_item_property on page 9-38
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-36
QII5V1
2014.12.15
get_display_item_properties
get_display_item_properties
Description
Returns a list of names of the properties of display items that are part of the parameterization GUI.
Availability
Main Program
Usage
get_display_item_properties
Returns
A list of display item property names. Refer to Display Item Properties.
Arguments
No arguments.
Example
get_display_item_properties
Related Information
•
•
•
•
Altera Corporation
add_display_item on page 9-33
get_display_item_property on page 9-37
set_display_item_property on page 9-38
Display Item Properties on page 9-100
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_display_item_property
9-37
get_display_item_property
Description
Returns the value of a specific property of a display item that is part of the parameterization GUI.
Availability
Main Program, Elaboration, Validation, Composition
Usage
get_display_item_property <display_item> <property>
Returns
The value of a display item property.
Arguments
display_item
The id of the display item.
property
The name of the property. Refer to Display Item Properties.
Example
set my_label [get_display_item_property my_action DISPLAY_NAME]
Related Information
•
•
•
•
•
add_display_item on page 9-33
get_display_item_properties on page 9-36
get_display_items on page 9-35
set_display_item_property on page 9-38
Display Item Properties on page 9-100
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-38
QII5V1
2014.12.15
set_display_item_property
set_display_item_property
Description
Sets the value of specific property of a display item that is part of the parameterization GUI.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Composition
Usage
set_display_item_property <display_item> <property> <value>
Returns
No return value.
Arguments
display_item
The name of the display item whose property value is being set.
property
The property that is being set. Refer to Display Item Properties.
value
The value to set.
Example
set_display_item_property my_action DISPLAY_NAME "Click Me"
set_display_item_property my_action DESCRIPTION "clicking this button runs the
click_me_callback proc in the hw.tcl file"
Related Information
•
•
•
•
Altera Corporation
add_display_item on page 9-33
get_display_item_properties on page 9-36
get_display_item_property on page 9-37
Display Item Properties on page 9-100
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
Module Definition
9-39
Module Definition
add_documentation_link on page 9-40
get_module_assignment on page 9-41
get_module_assignments on page 9-42
get_module_ports on page 9-43
get_module_properties on page 9-44
get_module_property on page 9-45
send_message on page 9-46
set_module_assignment on page 9-47
set_module_property on page 9-48
add_hdl_instance on page 9-49
package on page 9-50
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-40
QII5V1
2014.12.15
add_documentation_link
add_documentation_link
Description
Allows you to link to documentation for your IP component.
Availability
Discovery, Main Program
Usage
add_documentation_link <title> <path>
Returns
No return value.
Arguments
title
The title of the document for use on menus and buttons.
path
A path to the IP component documentation, using a syntax that provides the entire URL,
not a relative path. For example: http://www.mydomain.com/
my_memory_controller.html or file:///datasheet.txt
Example
add_documentation_link "Avalon Verification IP Suite User Guide" http://
www.altera.com/literature/ug/ug_avalon_verification_ip.pdf
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_module_assignment
9-41
get_module_assignment
Description
This command returns the value of an assignment. You can use the get_module_assignment and
set_module_assignment and the get_interface_assignment and set_interface_assignment
commands to provide information about the IP component to embedded software tools and applications.
Availability
Main Program, Elaboration, Validation, Composition
Usage
get_module_assignment <assignment>
Returns
The value of the assignment
Arguments
assignment
The name of the assignment whose value is being retrieved
Example
get_module_assignment embeddedsw.CMacro.colorSpace
Related Information
• get_module_assignments on page 9-42
• set_module_assignment on page 9-47
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-42
get_module_assignments
QII5V1
2014.12.15
get_module_assignments
Description
Returns the names of the module assignments.
Availability
Main Program, Elaboration, Validation, Composition
Usage
get_module_assignments
Returns
A list of assignment names.
Arguments
No arguments.
Example
get_module_assignments
Related Information
• get_module_assignment on page 9-41
• set_module_assignment on page 9-47
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_module_ports
9-43
get_module_ports
Description
Returns a list of the names of all the ports which are currently defined.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation,
Parameter Upgrade
Usage
get_module_ports
Returns
A list of port names.
Arguments
No arguments.
Example
get_module_ports
Related Information
• add_interface on page 9-3
• add_interface_port on page 9-5
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-44
get_module_properties
QII5V1
2014.12.15
get_module_properties
Description
Returns the names of all the module properties as a list of strings. You can use the get_module_property
and set_module_property commands to get and set values of individual properties. The value returned
by this command is always the same for a particular version of Qsys
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation,
Parameter Upgrade
Usage
get_module_properties
Returns
List of strings. Refer to Module Properties.
Arguments
No arguments.
Example
get_module_properties
Related Information
• get_module_property on page 9-45
• set_module_property on page 9-48
• Module Properties on page 9-103
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_module_property
9-45
get_module_property
Description
Returns the value of a single module property.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation,
Parameter Upgrade
Usage
get_module_property <property>
Returns
Various.
Arguments
property
The name of the property, Refer to Module Properties.
Example
set my_name [ get_module_property NAME ]
Related Information
• get_module_properties on page 9-44
• set_module_property on page 9-48
• Module Properties on page 9-103
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-46
QII5V1
2014.12.15
send_message
send_message
Description
Sends a message to the user of the IP component. The message text is normally interpreted as HTML. You
can use the <b> element to provide emphasis. If you do not want the message text to be interpreted as
HTML, then pass a list as the message level, for example, { Info Text }.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation,
Parameter Upgrade
Usage
send_message <level> <message>
Returns
No return value .
Arguments
level
The following message levels are supported:
• ERROR--Provides an error message. The Qsys system cannot be generated with existing
error messages.
• WARNING--Provides a warning message.
• INFO--Provides an informational message.
• PROGRESS--Reports progress during generation.
• 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!"
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
set_module_assignment
9-47
set_module_assignment
Description
Sets the value of the specified assignment.
Availability
Main Program, Elaboration, Validation, Composition
Usage
set_module_assignment <assignment> [<value>]
Returns
No return value.
Arguments
assignment
The assignment whose value is being set
value (optional)
The value of the assignment
Example
set_module_assignment embeddedsw.CMacro.colorSpace CMYK
Related Information
• get_module_assignment on page 9-41
• get_module_assignments on page 9-42
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-48
set_module_property
QII5V1
2014.12.15
set_module_property
Description
Allows you to set the values for module properties.
Availability
Discovery, Main Program
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 VERSION 10.0
Related Information
• get_module_properties on page 9-44
• get_module_property on page 9-45
• Module Properties on page 9-103
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
add_hdl_instance
9-49
add_hdl_instance
Description
Adds an instance of a predefined module, referred to as a child or child instance. The HDL entity
generated from this instance can be instantiated and connected within this IP component's HDL.
Availability
Main Program, Elaboration, Composition
Usage
add_hdl_instance <entity_name> <ip_core_type> [<version>]
Returns
The entity name of the added instance.
Arguments
entity_name
Specifies a unique local name that you can use to manipulate the instance. This name is used
in the generated HDL to identify the instance.
ip_core_type
The 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, the latest
version is used.
Example
add_hdl_instance my_uart altera_avalon_uart
Related Information
•
•
•
•
get_instance_parameter_value on page 9-67
get_instance_parameters on page 9-65
get_instances on page 9-57
set_instance_parameter_value on page 9-70
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-50
QII5V1
2014.12.15
package
package
Description
Allows you to specify a particular version of the Qsys software to avoid software compatibility issues, and
to determine which version of the _hw.tcl API to use for the IP component. You must use the package
command at the beginning of your _hw.tcl file.
Availability
Main Program
Usage
package require -exact qsys <version>
Returns
No return value
Arguments
version
The version of Qsys that you require, such as 14.1.
Example
package require -exact qsys 14.1
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
Composition
9-51
Composition
add_instance on page 9-52
add_connection on page 9-52
get_connections on page 9-54
get_connection_parameters on page 9-55
get_connection_parameter_value on page 9-56
get_instances on page 9-57
get_instance_interfaces on page 9-58
get_instance_interface_ports on page 9-59
get_instance_interface_properties on page 9-60
get_instance_property on page 9-61
set_instance_property on page 9-62
get_instance_properties on page 9-63
get_instance_interface_property on page 9-64
get_instance_parameters on page 9-65
get_instance_parameter_property on page 9-66
get_instance_parameter_value on page 9-67
get_instance_port_property on page 9-68
set_connection_parameter_value on page 9-69
set_instance_parameter_value on page 9-70
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-52
QII5V1
2014.12.15
add_instance
add_instance
Description
Adds an instance of an IP component, referred to as a child or child instance to the subsystem. You can
use this command to create IP components that are composed of other IP component instances. The HDL
for this subsystem will be generated; no custom HDL will need to be written for the IP component.
Availability
Main Program, Composition
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. This name is used
in the generated HDL to identify the instance.
type
The type refers to a type available in the IP Catalog, for example altera_avalon_uart.
version (optional)
The required version of the specified type. If no version is specified, the highest available
version is used.
Example
add_instance my_uart altera_avalon_uart
add_instance my_uart altera_avalon_uart 14.1
Related Information
•
•
•
•
•
•
•
add_connection on page 9-52
get_instance_interface_property on page 9-64
get_instance_parameter_value on page 9-67
get_instance_parameters on page 9-65
get_instance_property on page 9-61
get_instances on page 9-57
set_instance_parameter_value on page 9-70
add_connection
Description
Connects the named interfaces on child instances together using an appropriate connection type. Both
interface names consist of a child instance name, followed by the name of an interface provided by that
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
add_connection
9-53
module. For example, mux0.out is the interface named out on the instance named mux0. Be careful to
connect the start to the end, and not the other way around.
Availability
Main Program, Composition
Usage
add_connection <start> [<end> <kind> <name>]
Returns
The name of the newly added connection in start.point/end.point format.
Arguments
start
The start interface to be connected, in <instance_name>.<interface_name> format.
end (optional)
The end interface to be connected, <instance_name>.<interface_name>.
kind (optional)
The type of connection, such as avalon or clock.
name (optional)
A custom name for the connection. If unspecified, the name will be
<start_instance>.<interface>.<end_instance><interface>
Example
add_connection dma.read_master sdram.s1 avalon
Related Information
• add_instance on page 9-52
• get_instance_interfaces on page 9-58
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-54
get_connections
QII5V1
2014.12.15
get_connections
Description
Returns a list of all connections in the composed subsystem.
Availability
Main Program, Composition
Usage
get_connections
Returns
A list of connections.
Arguments
No arguments.
Example
set all_connections [ get_connections ]
Related Information
add_connection on page 9-52
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_connection_parameters
9-55
get_connection_parameters
Description
Returns a list of parameters found on a connection.
Availability
Main Program, Composition
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
• add_connection on page 9-52
• get_connection_parameter_value on page 9-56
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-56
QII5V1
2014.12.15
get_connection_parameter_value
get_connection_parameter_value
Description
Returns the value of a parameter on the connection. Parameters represent aspects of the connection that
can be modified once the connection is created, such as the base address for an Avalon Memory Mapped
connection.
Availability
Composition
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
• add_connection on page 9-52
• get_connection_parameters on page 9-55
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_instances
9-57
get_instances
Description
Returns a list of the instance names for all child instances in the system.
Availability
Main Program, Elaboration, Validation, Composition
Usage
get_instances
Returns
A list of child instance names.
Arguments
No arguments.
Example
get_instances
Notes
This command can be used with instances created by either add_instance or add_hdl_instance.
Related Information
•
•
•
•
•
add_hdl_instance on page 9-49
add_instance on page 9-52
get_instance_parameter_value on page 9-67
get_instance_parameters on page 9-65
set_instance_parameter_value on page 9-70
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-58
QII5V1
2014.12.15
get_instance_interfaces
get_instance_interfaces
Description
Returns a list of interfaces found in a child instance. The list of interfaces can change if the
parameterization of the instance changes.
Availability
Validation, Composition
Usage
get_instance_interfaces <instance>
Returns
A list of interface names.
Arguments
instance
The name of the child instance.
Example
get_instance_interfaces pixel_converter
Related Information
• add_instance on page 9-52
• get_instance_interface_ports on page 9-59
• get_instance_interfaces on page 9-58
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_instance_interface_ports
9-59
get_instance_interface_ports
Description
Returns a list of ports found in an interface of a child instance.
Availability
Validation, Composition, Fileset Generation
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
set port_names [ get_instance_interface_ports cpu data_master ]
Related Information
• add_instance on page 9-52
• get_instance_interfaces on page 9-58
• get_instance_port_property on page 9-68
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-60
QII5V1
2014.12.15
get_instance_interface_properties
get_instance_interface_properties
Description
Returns the names of all of the properties of the specified interface
Availability
Validation, Composition
Usage
get_instance_interface_properties <instance> <interface>
Returns
List of property names.
Arguments
instance
The name of the child instance.
interface
The name of an interface on the instance.
Example
set properties [ get_instance_interface_properties cpu data_master ]
Related Information
• add_instance on page 9-52
• get_instance_interface_property on page 9-64
• get_instance_interfaces on page 9-58
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_instance_property
9-61
get_instance_property
Description
Returns the value of a single instance property.
Availability
Main Program, Elaboration, Validation, Composition, Fileset Generation
Usage
get_instance_property <instance> <property>
Returns
Various.
Arguments
instance
The name of the instance.
property
The name of the property. Refer to Instance Properties.
Example
set my_name [ get_instance_property myinstance NAME ]
Related Information
•
•
•
•
add_instance on page 9-52
get_instance_properties on page 9-63
set_instance_property on page 9-62
Instance Properties on page 9-91
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-62
set_instance_property
QII5V1
2014.12.15
set_instance_property
Description
Allows a user to set the properties of a child instance.
Availability
Main Program, Elaboration, Validation, Composition
Usage
set_instance_property <instance> <property> <value>
Returns
Arguments
instance
The name of the instance.
property
The name of the property to set. Refer to Instance Properties.
value
The new property value.
Example
set_instance_property myinstance SUPRESS_ALL_WARNINGS true
Related Information
•
•
•
•
Altera Corporation
add_instance on page 9-52
get_instance_properties on page 9-63
get_instance_property on page 9-61
Instance Properties on page 9-91
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_instance_properties
9-63
get_instance_properties
Description
Returns the names of all the instance properties as a list of strings. You can use the
get_instance_property and set_instance_property commands to get and set values of individual
properties. The value returned by this command is always the same for a particular version of Qsys
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation,
Parameter Upgrade
Usage
get_instance_properties
Returns
List of strings. Refer to Instance Properties.
Arguments
No arguments.
Example
get_instance_properties
Related Information
•
•
•
•
add_instance on page 9-52
get_instance_property on page 9-61
set_instance_property on page 9-62
Instance Properties on page 9-91
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-64
QII5V1
2014.12.15
get_instance_interface_property
get_instance_interface_property
Description
Returns the value of a property for an interface in a child instance.
Availability
Validation, Composition
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.
Example
set value [ get_instance_interface_property cpu data_master setupTime ]
Related Information
• add_instance on page 9-52
• get_instance_interfaces on page 9-58
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_instance_parameters
9-65
get_instance_parameters
Description
Returns a list of names of the parameters on a child instance that can be set using
set_instance_parameter_value. It omits parameters that are derived and those that have the
SYSTEM_INFO parameter property set.
Availability
Main Program, Elaboration, Validation, Composition
Usage
get_instance_parameters <instance>
Returns
A list of parameters in the instance.
Arguments
instance
The name of the child instance.
Example
set parameters [ get_instance_parameters instance ]
Notes
You can use this command with instances created by either add_instance or add_hdl_instance.
Related Information
•
•
•
•
•
add_hdl_instance on page 9-49
add_instance on page 9-52
get_instance_parameter_value on page 9-67
get_instances on page 9-57
set_instance_parameter_value on page 9-70
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-66
QII5V1
2014.12.15
get_instance_parameter_property
get_instance_parameter_property
Description
Returns the value of a property on a parameter in a child instance. Parameter properties are metadata
about how the parameter will be used by the Qsys tools.
Availability
Validation, Composition
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 instance parameter property
Related Information
• add_instance on page 9-52
• Parameter Properties on page 9-92
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_instance_parameter_value
9-67
get_instance_parameter_value
Description
Returns the value of a parameter in a child instance. You cannot use this command to get the value of
parameters whose values are derived or those that are defined using the SYSTEM_INFO parameter property.
Availability
Elaboration, Validation, Composition
Usage
get_instance_parameter_value <instance> <parameter>
Returns
The value of the parameter.
Arguments
instance
The name of the child instance.
parameter
Specifies the parameter whose value is being retrieved.
Example
set dpi [ get_instance_parameter_value pixel_converter input_DPI ]
Notes
You can use this command with instances created by either add_instance or add_hdl_instance.
Related Information
•
•
•
•
•
add_hdl_instance on page 9-49
add_instance on page 9-52
get_instance_parameters on page 9-65
get_instances on page 9-57
set_instance_parameter_value on page 9-70
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-68
QII5V1
2014.12.15
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.
Availability
Validation, Composition, Fileset Generation
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 property whose value is being retrieved. Only the following port properties can be
queried on ports of child instances: ROLE, DIRECTION, WIDTH, WIDTH_EXPR and VHDL_TYPE.
Refer to Port Properties.
Example
get_instance_port_property instance port property
Related Information
• add_instance on page 9-52
• get_instance_interface_ports on page 9-59
• Port Properties on page 9-97
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
set_connection_parameter_value
9-69
set_connection_parameter_value
Description
Sets the value of a parameter of the connection. The start and end are each interface names of the format
<instance>.<interface>. Connection parameters depend on the type of connection, for Avalon-MM
they include base addresses and arbitration priorities.
Availability
Main Program, Composition
Usage
set_connection_parameter_value <connection> <parameter> <value>
Returns
No return value.
Arguments
connection
Specifies the name of the connection as returned by the add_conectioncommand. It is of
the form start.point/end.point.
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
• add_connection on page 9-52
• get_connection_parameter_value on page 9-56
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-70
QII5V1
2014.12.15
set_instance_parameter_value
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 can not be set with this command.
Availability
Main Program, Elaboration, Composition
Usage
set_instance_parameter_value <instance> <parameter> <value>
Returns
Vo return value.
Arguments
instance
Specifies the name of the child instance.
parameter
Specifies the parameter that is being set.
value
Specifies the new parameter value.
Example
set_instance_parameter_value uart_0 baudRate 9600
Notes
You can use this command with instances created by either add_instance or add_hdl_instance.
Related Information
•
•
•
•
Altera Corporation
add_hdl_instance on page 9-49
add_instance on page 9-52
get_instance_parameter_value on page 9-67
get_instances on page 9-57
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
Fileset Generation
9-71
Fileset Generation
add_fileset on page 9-72
add_fileset_file on page 9-73
set_fileset_property on page 9-74
get_fileset_file_attribute on page 9-75
set_fileset_file_attribute on page 9-76
get_fileset_properties on page 9-77
get_fileset_property on page 9-78
get_fileset_sim_properties on page 9-79
set_fileset_sim_properties on page 9-80
create_temp_file on page 9-81
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-72
add_fileset
QII5V1
2014.12.15
add_fileset
Description
Adds a generation fileset for a particular target as specified by the kind. Qsys calls the target (SIM_VHDL,
SIM_VERILOG, QUARTUS_SYNTH, or EXAMPLE_DESIGN) when the specified generation target is requested.
You can define multiple filesets for each kind of fileset. Qsys passes a single argument to the specified
callback procedure. The value of the argument is a generated name, which you must use in the top-level
module or entity declaration of your IP component. To override this generated name, you can set the
fileset property TOP_LEVEL.
Availability
Main Program
Usage
add_fileset <name> <kind> [<callback_proc> <display_name>]
Returns
No return value.
Arguments
name
The name of the fileset.
kind
The kind of fileset. Refer to Fileset Properties.
callback_proc (optional)
A string identifying the name of the callback procedure. If you add files in the global section,
you can then specify a blank callback procedure.
display_name (optional)
A display string to identify the fileset.
Example
add_fileset my_synthesis_fileset QUARTUS_SYNTH mySynthCallbackProc "My Synthesis"
proc mySynthCallbackProc { topLevelName } { ... }
Notes
If using the TOP_LEVEL fileset property, all parameterizations of the component must use identical HDL.
Related Information
• add_fileset_file on page 9-73
• get_fileset_property on page 9-78
• Fileset Properties on page 9-105
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
add_fileset_file
9-73
add_fileset_file
Description
Adds a file to the generation directory. You can specify source file locations using either an absolute path,
or a path that is relative to the IP component's _hw.tcl file.
Availability
Main Program, Fileset Generation
Usage
add_fileset_file <output_file> <file_type> <file_source> <path_or_contents> [<attributes>]
Returns
No return value.
Arguments
output_file
Specifies the location to store the file after Qsys generation
file_type
The kind of file. Refer to File Kind Properties.
file_source
Specifies whether the file is being added by path, or by file contents. Refer to File Source
Properties.
path_or_contents
When the file_source is PATH, specifies the file to be copied to output_file. When the
file_source is TEXT, specifies the text contents to be stored in the file.
attributes (optional)
An optional list of file attributes. Typically used to specify that a file is intended for use only
in a particular simulator. Refer to File Attribute Properties.
Example
add_fileset_file "./implementation/rx_pma.sv" SYSTEM_VERILOG PATH synth_rx_pma.sv
add_fileset_file gui.sv SYSTEM_VERILOG TEXT "Customize your IP core"
Related Information
•
•
•
•
•
add_fileset on page 9-72
get_fileset_file_attribute on page 9-75
File Kind Properties on page 9-109
File Source Properties on page 9-110
File Attribute Properties on page 9-108
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-74
QII5V1
2014.12.15
set_fileset_property
set_fileset_property
Description
Allows you to set the properties of a fileset.
Availability
Main Program, Elaboration, Fileset Generation
Usage
set_fileset_property <fileset> <property> <value>
Returns
No return value.
Arguments
fileset
The name of the fileset.
property
The name of the property to set. Refer to Fileset Properties.
value
The new property value.
Example
set_fileset_property mySynthFileset TOP_LEVEL simple_uart
Notes
When a fileset callback is called, the callback procedure will be passed a single argument. The value of this
argument is a generated name which must be used in the top-level module or entity declaration of your IP
component. If set, the TOP_LEVEL specifies a fixed name for the top-level name of your IP component.
The TOP_LEVEL property must be set in the global section. It cannot be set in a fileset callback.
If using the TOP_LEVEL fileset property, all parameterizations of the IP component must use identical
HDL.
Related Information
• add_fileset on page 9-72
• Fileset Properties on page 9-105
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_fileset_file_attribute
9-75
get_fileset_file_attribute
Description
Returns the attribute of a fileset file.
Availability
Main Program, Fileset Generation
Usage
get_fileset_file_attribute <output_file> <attribute>
Returns
Value of the fileset File attribute.
Arguments
output_file
Location of the output file.
attribute
Specifies the name of the attribute Refer to File Attribute Properties.
Example
get_fileset_file_attribute my_file.sv ALDEC_SPECIFIC
Related Information
•
•
•
•
•
•
•
•
add_fileset on page 9-72
add_fileset_file on page 9-73
get_fileset_file_attribute on page 9-75
File Attribute Properties on page 9-108
add_fileset on page 9-72
add_fileset_file on page 9-73
get_fileset_file_attribute on page 9-75
File Attribute Properties on page 9-108
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-76
QII5V1
2014.12.15
set_fileset_file_attribute
set_fileset_file_attribute
Description
Sets the attribute of a fileset file.
Availability
Main Program, Fileset Generation
Usage
set_fileset_file_attribute <output_file> <attribute> <value>
Returns
The attribute value if it was set.
Arguments
output_file
Location of the output file.
attribute
Specifies the name of the attribute Refer to File Attribute Properties.
value
Value to set the attribute to.
Example
set_fileset_file_attribute my_file_pkg.sv COMMON_SYSTEMVERILOG_PACKAGE
my_file_package
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_fileset_properties
9-77
get_fileset_properties
Description
Returns a list of properties that can be set on a fileset.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Generation, Composition, Fileset Generation,
Parameter Upgrade
Usage
get_fileset_properties
Returns
A list of property names. Refer to Fileset Properties.
Arguments
No arguments.
Example
get_fileset_properties
Related Information
•
•
•
•
add_fileset on page 9-72
get_fileset_properties on page 9-77
set_fileset_property on page 9-74
Fileset Properties on page 9-105
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-78
get_fileset_property
QII5V1
2014.12.15
get_fileset_property
Description
Returns the value of a fileset property for a fileset.
Availability
Main Program, Elaboration, Fileset Generation
Usage
get_fileset_property <fileset> <property>
Returns
The value of the property.
Arguments
fileset
The name of the fileset.
property
The name of the property to query. Refer to Fileset Properties.
Example
get_fileset_property fileset property
Related Information
Fileset Properties on page 9-105
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_fileset_sim_properties
9-79
get_fileset_sim_properties
Description
Returns simulator properties for a fileset.
Availability
Main Program, Fileset Generation
Usage
get_fileset_sim_properties <fileset> <platform> <property>
Returns
The fileset simulator properties.
Arguments
fileset
The name of the fileset.
platform
The operating system for that applies to the property. Refer to Operating System Properties.
property
Specifies the name of the property to set. Refer to Simulator Properties.
Example
get_fileset_sim_properties my_fileset LINUX64 OPT_CADENCE_64BIT
Related Information
•
•
•
•
add_fileset on page 9-72
set_fileset_sim_properties on page 9-80
Operating System Properties on page 9-117
Simulator Properties on page 9-111
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-80
QII5V1
2014.12.15
set_fileset_sim_properties
set_fileset_sim_properties
Description
Sets simulator properties for a given fileset
Availability
Main Program, Fileset Generation
Usage
set_fileset_sim_properties <fileset> <platform> <property> <value>
Returns
The fileset simulator properties if they were set.
Arguments
fileset
The name of the fileset.
platform
The operating system that applies to the property. Refer to Operating System Properties.
property
Specifies the name of the property to set. Refer to Simulator Properties.
value
Specifies the value of the property.
Example
set_fileset_sim_properties my_fileset LINUX64 OPT_MENTOR_PLI "{libA} {libB}"
Related Information
• get_fileset_sim_properties on page 9-79
• Operating System Properties on page 9-117
• Simulator Properties on page 9-111
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
create_temp_file
9-81
create_temp_file
Description
Creates a temporary file, which you can use inside the fileset callbacks of a _hw.tcl file. This temporary file
is included in the generation output if it is added using the add_fileset_file command.
Availability
Fileset Generation
Usage
create_temp_file <path>
Returns
The path to the temporary file.
Arguments
path
The name of the temporary file.
Example
set filelocation [create_temp_file "./hdl/compute_frequency.v" ]
add_fileset_file compute_frequency.v VERILOG PATH ${filelocation}
Related Information
• add_fileset on page 9-72
• add_fileset_file on page 9-73
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-82
Miscellaneous
QII5V1
2014.12.15
Miscellaneous
check_device_family_equivalence on page 9-83
get_device_family_displayname on page 9-84
get_qip_strings on page 9-85
set_qip_strings on page 9-86
set_interconnect_requirement on page 9-87
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
check_device_family_equivalence
9-83
check_device_family_equivalence
Description
Returns 1 if the device family is equivalent to one of the families in the device families lis., Returns 0 if the
device family is not equivalent to any families. This command ignores differences in capitalization and
spaces.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Composition, Fileset Generation, Parameter
Upgrade
Usage
check_device_family_equivalence <device_family> <device_family_list>
Returns
1 if equivalent, 0 if not equivalent.
Arguments
device_family
The device family name that is being checked.
device_family_list
The list of device family names to check against.
Example
check_device_family_equivalence "CYLCONE III LS" { "stratixv" "Cyclone IV"
"cycloneiiils" }
Related Information
get_device_family_displayname on page 9-84
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-84
QII5V1
2014.12.15
get_device_family_displayname
get_device_family_displayname
Description
Returns the display name of a given device family.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Composition, Fileset Generation, Parameter
Upgrade
Usage
get_device_family_displayname <device_family>
Returns
The preferred display name for the device family.
Arguments
device_family
A device family name.
Example
get_device_family_displayname cycloneiiils ( returns: "Cyclone IV LS" )
Related Information
check_device_family_equivalence on page 9-83
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
get_qip_strings
9-85
get_qip_strings
Description
Returns a Tcl list of QIP strings for the IP component.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Composition, Parameter Upgrade
Usage
get_qip_strings
Returns
A Tcl list of qip strings set by this IP component.
Arguments
No arguments.
Example
set strings [ get_qip_strings ]
Related Information
set_qip_strings on page 9-86
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-86
QII5V1
2014.12.15
set_qip_strings
set_qip_strings
Description
Places strings in the Quartus II IP File (.qip) file, which Qsys passes to the command as a Tcl list. You add
the .qip file to your Quartus II project on the Files page, in the Settings dialog box. Successive calls to
set_qip_strings are not additive and replace the previously declared value.
Availability
Discovery, Main Program, Edit, Elaboration, Validation, Composition, Parameter Upgrade
Usage
set_qip_strings <qip_strings>
Returns
The Tcl list which was set.
Arguments
qip_strings
A space-delimited Tcl list.
Example
set_qip_strings {"QIP Entry 1" "QIP Entry 2"}
Notes
You can use the following macros in your QIP strings entry:
%entityName%
%libraryName%
%instanceName%
The generated name of the entity replaces this macro when the string is written to
the .qip file.
The compilation library this IP component was compiled into is inserted in place of
this macro inside the .qip file.
The name of the instance is inserted in place of this macro inside the .qip file.
Related Information
get_qip_strings on page 9-85
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
set_interconnect_requirement
9-87
set_interconnect_requirement
Description
Sets the value of an interconnect requirement for a system or an interface on a child instance.
Availability
Composition
Usage
set_interconnect_requirement <element_id> <name> <value>
Returns
No return value
Arguments
element_id
{$system} for system requirements, or qualified name of the interface of an instance, in
<instance>.<interface> format. Note that the system identifier has to be escaped in TCL.
name
The name of the requirement.
value
The new requirement value.
Example
set_interconnect_requirement {$system} qsys_mm.maxAdditionalLatency 2
Component Interface Tcl Reference
Send Feedback
Altera Corporation
9-88
Qsys _hw.tcl Property Reference
QII5V1
2014.12.15
Qsys _hw.tcl Property Reference
Script Language Properties on page 9-89
Interface Properties on page 9-90
Instance Properties on page 9-91
Parameter Properties on page 9-92
Parameter Type Properties on page 9-95
Parameter Status Properties on page 9-96
Port Properties on page 9-97
Direction Properties on page 9-99
Display Item Properties on page 9-100
Display Item Kind Properties on page 9-101
Display Hint Properties on page 9-102
Module Properties on page 9-103
Fileset Properties on page 9-105
Fileset Kind Properties on page 9-106
Callback Properties on page 9-107
File Attribute Properties on page 9-108
File Kind Properties on page 9-109
File Source Properties on page 9-110
Simulator Properties on page 9-111
Port VHDL Type Properties on page 9-112
System Info Type Properties on page 9-113
Design Environment Type Properties on page 9-115
Units Properties on page 9-116
Operating System Properties on page 9-117
Quartus.ini Type Properties on page 9-118
Altera Corporation
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
Script Language Properties
9-89
Script Language Properties
Name
TCL
Component Interface Tcl Reference
Send Feedback
Description
Implements the script in Tcl.
Altera Corporation
9-90
QII5V1
2014.12.15
Interface Properties
Interface Properties
Name
Description
CMSIS_SVD_FILE
Specifies the connection point's associated CMSIS file.
CMSIS_SVD_VARIABLES
Defines the variables inside a .svd file.
ENABLED
Specifies whether or not interface is enabled.
EXPORT_OF
For composed _hwl.tcl files, the EXPORT_OF property indicates which interface of
a child instance is to be exported through this interface. Before using this
command, you must have created the border interface using add_interface.
The interface to be exported is of the form <instanceName.interfaceName>.
Example: set_interface_property CSC_input EXPORT_OF my_colorSpaceConverter.input_port
PORT_NAME_MAP
A map of external port names to internal port names, formatted as a Tcl list.
Example: set_interface_property <interface name> PORT_NAME_MAP
"<new port name> <old port name> <new port name 2> <old port name
2>"
SVD_ADDRESS_GROUP
SVD_ADDRESS_OFFSET
Altera Corporation
Generates a CMSIS SVD file. Masters in the same SVD address group will write
register data of their connected slaves into the same SVD file
Generates a CMSIS SVD file. Slaves connected to this master will have their
base address offset by this amount in the SVD file.
Component Interface Tcl Reference
Send Feedback
QII5V1
2014.12.15
Instance Properties
9-91
Instance Properties
Name
HDLINSTANCE_GET_GENERATED_NAME
HDLINSTANCE_USE_GENERATED_NAME
SUPPRESS_ALL_INFO_MESSAGES
SUPPRESS_ALL_WARNINGS
Component Interface Tcl Reference
Send Feedback
Description
Qsys uses this property to get the auto-generated fixed name when
the instance property HDLINSTANCE_USE_GENERATED_NAME is set to
true, and only applies to fileSet callbacks.
If true, instances added with the add_hdl_instance command are
instructed to use unique auto-generated fixed names based on the
parameterization.
If true, allows you to suppress all Info messages that originate
from a child instance.
If true, allows you to suppress alL warnings that originate from a
child instance
Altera Corporation
9-92
QII5V1
2014.12.15
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, if that parameter has
set AFFECTS_ELABORATION=false, the elaboration phase (calling the
callback or hardware analysis) is not repeated, improving
performance. Because the default value of AFFECTS_ELABORATION is
true, the provided HDL file is normally re-analyzed to determine the
new port widths and configuration every time a parameter changes.
Boolean AFFECTS_GENERATION
The default value of AFFECTS_GENERATION is false if you provide a
top-level HDL module; it 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 marks whether a parameter's
value is used to set derived parameters, and whether the value affects
validation messages. When set to false, this may improve response
time in the parameter editor UI when the value is changed.
String[]
ALLOWED_RANGES
Indicates the range or ranges that the parameter value can have. For
integers, The ALLOWED_RANGES property is a list of ranges that the
parameter can take on, where each range is a single value, or a range
of values defined by a start and end value separated by a colon, such
as 11:15. This property can also specify legal values and display
strings for integers, such as {0:None 1:Monophonic 2:Stereo
4:Quadrophonic} meaning 0, 1, 2, and 4 are the legal values. You can
also assign display strings to be displayed in the parameter editor for
string variables. For example, ALLOWED_RANGES {"dev1:Cyclone IV
GX""dev2:Stratix V GT"}.
String
DEFAULT_VALUE
The default value.
Boolean DERIVED
When true, indi