The following table shows the typographic conventions that this document uses.
Visual CueMeaning
Bold Type with Initial Capital
Letters
bold type
Italic Type with Initial Capital Letters
Italic type
Initial Capital Letters
“Subheading Title”
Courier type
1., 2., 3., and
a., b., c., etc.
■ ■Bullets are used in a list of items when the sequence of the items is not important.
v The checkmark indicates a procedure that consists of one step only.
1 The hand points to information that requires special attention.
c
w
r The angled arrow indicates you should press the Enter key.
f The feet direct you to more information on a particular topic.
Command names, dialog box titles, checkbox options, and dialog box options are
shown in bold, initial capital letters. Example: Save As dialog box.
External timing parameters, directory names, project names, disk drive names, file
names, file name extensions, and software utility names are shown in bold type.
Examples: f
1. Introduction to the Quartus II Scripting
Reference Manual
The Quartus®II design software provides the FPGA industry’s easiest-to-use and
most powerful scripting environment available for command-line operation and tool
command language (Tcl) scripting. This scripting environment is offered in addition
to the Quartus II development software rich graphical user interface (GUI).
This overview covers the Quartus II design software support for command-line
operation and Tcl scripting.
Each stage of the Quartus II software design flow corresponds to a command-line
executable file. Many of these executable files also support industry-standard Tcl
scripting for custom functionality or processing beyond the GUI design flow.
Quartus II design software offers the following scripting support benefits, also known
as CAR:
■ Custom Analysis
■ Automation
■ Reproducibility
Custom analysis allows you to build test procedures into the script and change design
processing based on the test results. Scripts can automate design flows to perform on
multiple computers simultaneously and easily archive and restore projects.
Reproducibility ensures that scripts use the same project setup and assignments for
every compile, even when you transfer a project from one engineer to another. In
other words, you can use scripts as another level of design quality assurance.
The Quartus II Scripting Reference Manual is your reference guide to Quartus II
software command-line executables and Tcl commands, including command details,
usage, and examples.
All of the information included in the Quartus II Scripting Reference Manual, as well as
the most up-to-date list of commands, can also be found in the Quartus II software Tcl
API and command-line executable online help reference, Qhelp. To access this
information within Quartus II design software, type the following command at the
command prompt:
quartus_sh --qhelp r
Quartus II Software Command-Line Operation Support
1–2Introduction to the Quartus II Scripting Reference Manual
■ Incorporating third-party EDA executable files
■ Makefile operation
Overview
You can also group commands for Quartus II executable files into a script, batch file,
or in a makefile to automate design flows. The Quartus II software command-line
executables accept arguments to set project variables and access common settings.
Quartus II Software Tcl Scripting Support
Use Tcl scripting for:
■ Solving complex analysis
■ Making individual assignments
■ Generating custom reports
■ Creating custom solutions
Tcl is an EDA industry-standard scripting language used by Synopsys, Mentor
Graphics
®
, Synplicity, Altera, and others. The Tcl language supports control
structures, variables, procedures, network socket access, and application
programming interfaces (APIs). Altera's Tcl support is aligned with major EDA
vendor solutions. It has an API format similar to the Synopsys design constraint
(SDC) format used by the Synopsys PrimeTime and Design Compiler products.
Command-Line Executables
Quartus II software provides command-line executables for each stage in the design
flow. The software also provides additional executables for specific tasks.
Tab le 1 details the command-line executables and their respective descriptions.
Table 1. Quartus II Command-Line Executables and Descriptions (Part 1 of 3)
ExecutableDescription
Quartus II Analysis and Synthesis builds a single project database that integrates all the
Analysis and Synthesis
quartus_map
Fitter
quartus_fit
design files in a design entity or project hierarchy, performs logic synthesis to minimize the
logic of the design, and performs technology mapping to implement the design logic using
device resources such as logic elements.
The Quartus II Fitter performs place-and-route by fitting the logic of a design into a device.
The Fitter selects appropriate interconnection paths, pin assignments, and logic cell
assignments.
Quartus II Analysis and Synthesis must be run successfully before running the Fitter.
The Quartus II SSN Analyzer estimates the simultaneous switching noise contributions to
Signal Integrity
quartus_si
voltage and timing noise.
Quartus II Analysis & Synthesis and the Fitter must be run successfully before running the
Introduction to the Quartus II Scripting Reference Manual1–3
Overview
Table 1. Quartus II Command-Line Executables and Descriptions (Part 2 of 3)
ExecutableDescription
The Quartus II Assembler generates a device programming image, in the form of one or more
of the following from a successful fit (that is, place-and-route).
Programmer Object Files (.pof)
SRAM Object Files (.sof)
Hexadecimal (Intel-Format) Output Files (.hexout)
Tabular Text Files (.ttf)
Assembler
Raw Binary Files (.rbf)
quartus_asm
The .pof and .sof files are then processed by the Quartus II Programmer and downloaded to
the device with the MasterBlaster
TM
or the ByteBlaster
TM
II download cable, or the Altera
Programming Unit (APU). The Hexadecimal (Intel-Format) Output Files, Tabular Text Files,
and Raw Binary Files can be used by other programming hardware manufacturers that
provide support for Altera devices.
The Quartus II Fitter must be run successfully before running the Assembler.
The Quartus II Classic Timing Analyzer computes delays for the given design and device, and
annotates them on the netlist. Then, the Classic Timing Analyzer performs timing analysis,
allowing you to analyze the performance of all logic in your design. The quartus_tan
Classic Timing Analyzer
executable includes Tcl support.
quartus_tan
TimeQuest Timing Analyzer
quartus_sta
Design Assistant
quartus_drc
Compiler Database Interface
quartus_cdb
Quartus II Analysis and Synthesis or the Fitter must be run successfully before running the
Classic Timing Analyzer.
The Quartus II TimeQuest Timing Analyzer computes delays for the given design and device,
and annotates them on the netlist. Then, the TimeQuest Timing Analyzer performs timing
analysis, allowing you to analyze the performance of all logic in your design. The quartus_sta
executable includes Tcl support and SDC support.
Quartus II Analysis and Synthesis or the Fitter must be run successfully before running the
TimeQuest Timing Analyzer.
The Quartus II Design Assistant checks the reliability of a design based on a set of design
rules. The Design Assistant is especially useful for checking the reliability of a design before
converting the design for HardCopy
target any Altera device supported by the Quartus II software, except MAX
®
devices. The Design Assistant supports designs that
®
3000 and
MAX 7000 devices.
Quartus II Analysis and Synthesis or the Fitter must be run successfully before running the
Design Assistant.
The Quartus II Compiler Database Interface generates incremental netlists for use with
LogicLock
TM
back-annotation, or back-annotates device and resource assignments to
preserve the fit for future compilations. The quartus_cdb executable includes Tcl support.
Analysis and Synthesis must be run successfully before running the Compiler Database
Interface.
1–4Introduction to the Quartus II Scripting Reference Manual
Overview
Table 1. Quartus II Command-Line Executables and Descriptions (Part 3 of 3)
ExecutableDescription
The Quartus II EDA Netlist Writer generates netlist and other output files for use with other
EDA tools.
EDA Netlist Writer
quartus_eda
Analysis and Synthesis, the Fitter, or Timing Analyzer must be run successfully before
running the EDA Netlist Writer, depending on the arguments used.
The Quartus II Simulator tests and debugs the logical operation and internal timing of the
design entities in a project. The Simulator can perform two types of simulation: functional
simulation and timing simulation. The quartus_sim executable includes Tcl support.
Simulator
quartus_sim
Quartus II Analysis and Synthesis must be run successfully before running a functional
simulation.
The Timing Analyzer must be run successfully before running a timing simulation.
Power Analyzer
The Quartus II PowerPlay Power Analyzer estimates the thermal dynamic power and the
thermal static power consumed by the design. For newer families such as Stratix
MAX II, the power drawn from each power supply is also estimated.
®
II and
quartus_pow
Quartus II Analysis and Synthesis or the Fitter must be run successfully before running the
PowerPlay Power Analyzer.
The Quartus II Programmer programs Altera devices. The Programmer uses one of the
supported file formats:
Programmer Object Files (.pof)
SRAM Object Files (.sof)
Programmer
quartus_pgm
Jam File (.jam)
Jam Byte-Code File (.jbc)
Make sure you specify a valid programming mode, programming cable, and operation for a
specified device.
The Quartus II Convert Programming File module converts one programing file format to a
different possible format.
Convert Programming File
quartus_cpf
Make sure you specify valid options and an input programming file to generate the new
requested programming file format.
The Quartus II Shell acts as a simple Quartus II Tcl interpreter. The Shell has a smaller
Quartus Shell
quartus_sh
memory footprint than the other command-line executables that support Tcl. The Shell may
be started as an interactive Tcl interpreter (shell), used to run a Tcl script, or used as a quick
Tcl command evaluator, evaluating the remaining command-line arguments as one or more
Tcl commands.
This executable opens the Quartus II TimeQuest Timing Analyzer GUI. This is helpful because
you don’t have to open the entire Quartus II GUI for certain operations.
This executable opens up the programmer—a GUI to the quartus_pgm executable. This is
helpful because users don’t have to open the entire Quartus II GUI for certain operations
Introduction to the Quartus II Scripting Reference Manual1–5
Overview
Tcl Commands
The Quartus II software Tcl commands are grouped into Tcl packages and loaded on
demand. This reduces the run-time memory of executable files and makes memory
available to application. Tab le 2 describes each Tcl package.
Table 2. Tcl Packages
Package NamePackage Description
advanced_timingTraverse the timing netlist and get information about timing nodes
backannotateBack annotate assignments
chip_editorIdentify and modify resource usage and routing with the Chip Editor
deviceGet device and family information from the device database
flowCompile a project, run command-line executables and other common flows
insystem_memory_editRead and edit memory contents in Altera devices
jtagControl the jtag chain
logic_analyzer_interfaceQuery and modify the logic analyzer interface output pin state
logiclockCreate and manage LogicLock regions
miscPerform miscellaneous tasks
project
reportGet information from report tables, create custom reports
sdcSpecifies constraints and exceptions to the TimeQuest Analyzer
sdc_extAltera-specific SDC commands
simulatorConfigure and perform simulations
sta
stpRun the SignalTap
timingAnnotate timing netlist with delay information, compute and report timing paths
timing_assignment
timing_reportList timing paths
Create and manage projects and revisions, make any project assignments including timing
assignments
Contains the set of Tcl functions for obtaining advanced information from the TimeQuest
Timing Analyzer
®
II logic analyzer
Contains the set of Tcl functions for making project-wide timing assignments, including clock
assignments; all Tcl commands designed to process Classic Timing Analyzer assignments
have been moved to this package
1–6Introduction to the Quartus II Scripting Reference Manual
Overview
Tab le 3 lists the Quartus II Tcl packages available with Quartus II executables and
indicates whether a package is loaded by default ( ) or is available to be loaded as
necessary ( ). A clear circle ( ) means that the package is not available in that
executable.
Table 3. Tcl Package Availability by Quartus II Executable (Note 1), (2), (3)
(1) A dark circle ( ) indicates that the package is loaded automatically.
(2) A half-circle ( ) means that the package is available but not loaded automatically.
(3) A white circle ( ) means that the package is not available for that executable.
The Quartus® II Assembler generates a device programming image, in the form of one or more
Programmer Object Files (.pof), SRAM Object Files (.sof), Hexadecimal (Intel-Format) Output Files
(.hexout), Tabular Text Files (.ttf), and Raw Binary Files(.rbf), from a successful fit (that is, place and route).
The .pof and .sof files can then be processed by the Quartus II Programmer and the MasterBlaster
ByteBlaster
can be used by other programming hardware manufacturers that provide programming support for
Altera devices.
The Quartus II Fitter must be run successfully before running the Assembler.
™
II Download Cable, or the Altera® Programming Unit (APU). The .hexout, .ttf, and .rbf files
The Quartus® II Compiler Database Interface manages version-compatible database files and generates
incremental netlists for use with LogicLock
™
back-annotation, or back-annotates device and resource
assignments to preserve the fit for future compilations. The quartus_cdb executable includes Tcl support.
Analysis & Synthesis must be run successfully before running the Compiler Database Interface.
Option to back-annotate to the current Quartus II Settings File (.qsf) according to the specified demotion
type. The back-annotation process retains the current resource and device assignments for future
compilations. The demotion type is used to select the assignments that you want to back-annotate. The
demotion type can be specified in one of the following forms:
Demotion TypeDescriptions
deviceFor device assignments
pin_deviceFor pin device assignments
lcFor logic cell assignments
routingFor routing assignments
labFor LAB assignments
megalabFor MegaLAB assignments
megalab_rowFor MegaLAB row assignments
megalab_columnFor MegaLAB column assignments
rowFor row assignments
Note: Not all demotion types are relevant for all device families. The demotion type "routing" applies only
to the Cyclone
®
, Stratix® , and Stratix GX device families.
--bottom_up_scripts_output_directory[=<value>]
Specifies the output directory for scripts and makefiles. If none is set, the project directory is used by
default.
Specifies a delay, in nanoseconds, used to constrain all paths from any of the newly created virtual input
pins in the lower-levels. This is to help guide the lower-level placement and produce a better quality
top-level result.
The value represents the maximum acceptable delay for an inter-partition signal to arrive at the project's
virtual input pin from another module. The value helps guide lower-level placement.
Specifies a delay, in nanoseconds, used to constrain all paths to any newly created virtual output pins in
the lower-levels. This helps guide the lower-level placement and produces a better quality top-level result.
The value represents the maximum acceptable delay for an inter-partition signal driven by the virtual
output pin to arrive at its destination. The value helps guide lower-level placement.
--create_companion[=<companion revision>]
Creates a HardCopy companion revision based on the current revision.
If <companion revision> is specified, it is used to create the HardCopy companion revision. Otherwise, the
default companion revision name is used unless the COMPANION_REVISION_NAME assignment is
found in the current revision's Quartus II Settings File (.qsf).
Reverse migration also supported when the originating revision is a HardCopy device (HardCopy II or
newer). The companion created will be targeted to FPGA revision with a proper companion name if the
<companion revision> is not specified and the COMPANION_REVISION_NAME assignment is not
found.
The current revision should be fully compiled for this option to migrate all pin locations.
Note that <companion revision> is the new current revision after executing this option.
Examples
## The following example illustrates the option usage using
## Stratix II and HardCopy II migration scenario
## Compile the Stratix II revision
quartus_sh --flow compile myproject -c myfpga
## Create a HardCopy II revision named "myhcii" based on "myfpga"
quartus_cdb myproject -c myfpga --create_companion=myhcii
## Compile the HardCopy II revision
quartus_sh --flow compile myproject -c myhcii
## **********************************
## Or you can simply do the following
## **********************************
## Compile the Stratix II revision
quartus_sh --flow compile myproject
## The following command will create the
## HardCopy II revision named "myproject_hcii"
## unless the COMPANION_REVISION_NAME assignment
## is found in myproject.qsf.
quartus_cdb myproject --create_companion
This tool is designed for use with a top-level project containing incremental compilation design partitions.
When run, it generates scripts and makefiles which allow an easy conversion from top-down design
methodology (all partitions in one project) to a bottom-up design methodology (separate projects for each
partition).
One Tcl script is generated for each partition. The Tcl script will contain all top-level assignments relevant
to the given partition, and optionally contains commands to create the lower-level project for the partition
if it does not exist. The scripts also contain optionally generated commands that can help guide the
lower-level placement so that better results can be achieved when exporting to the top-level project. You
can customize the content of the Tcl scripts by using any of the options described later.
In addition to generating Tcl scripts, you can also generate makefiles that can be used to create the
lower-level projects with the auto-generated Tcl scripts and maintain them as source files change. The tool
also builds a 'master_makefile' which builds all lower-level projects, exports the results to the top-level
project and performs a top-level compilation. The makefiles are auto-generated and are designed for use
with GNU make. The makefiles also support parallel compilation of the the lower-level projects by using
the '-j' option of GNU make on systems with multiple processors.
As mentioned above, you can customize the content of the Tcl files with any of the following command
line directives. Each is explained in more detail in their own help sections.
--include_makefiles_with_bottom_up_scripts=<on|off>
Default is on.
--include_project_creation_in_bottom_up_scripts=<on|off>
Default is on.
--include_virtual_pins_in_bottom_up_scripts=<on|off>
Default is on.
--include_virtual_input_pin_timing_in_bottom_up_scripts=<on|off>
Default is on.
--include_virtual_output_pin_timing_in_bottom_up_scripts=<on|off>
Default is on.
--include_virtual_pin_locations_in_bottom_up_scripts=<on|off>
Default is on.
--include_logiclock_regions_in_bottom_up_scripts=<on|off>
Default is on.
--include_all_logiclock_regions_in_bottom_up_scripts=<on|off>
Default is on.
--include_global_signal_promotion_in_bottom_up_scripts=<on|off>
Default is off.
--include_pin_locations_in_bottom_up_scripts=<on|off>
Default is on.
--include_timing_assignments_in_bottom_up_scripts=<on|off>
Default is on.
--include_design_partitions_in_bottom_up_scripts=<on|off>
Default is on.
--remove_existing_regions_in_bottom_up_scripts=<on|off>
Default is on.
--disable_auto_global_promotion_in_bottom_up_scripts=<on|off>
Default is off.
--bottom_up_scripts_output_directory=<output_directory>
Default is current project directory.
--bottom_up_scripts_virtual_input_pin_delay=<delay_in_ns>
No default. Must provide if including virtual input pin timing.
--bottom_up_scripts_virtual_output_pin_delay=<delay_in_ns>
No default. Must provide if including virtual output pin timing.
--generate_hc_files
Generates HardCopy Handoff files to an output directory.
The output directory is "hc_output" under the current project directory unless the output directory is
specified by the HC_OUTPUT_DIR assignment in the Quartus II Settings File (.qsf).
--generate_hc_pll_delay
Returns the PLL annotated delay.
Ggenerates the PLL annotated delay for both commercial and industrial speed grades of HardCopy
devices. This option only returns the PLL annotated delay and does not update the collection.sdc file.
Archives HardCopy Handoff Files into the specified output file name.
The Quartus II Archive File <output file>.qar is generated by this option. By default, if the output file
name is not specified, the file name <current revision>.qar is used.
The current revision and its companion revision should be fully compiled for this option to properly
archive all necessary files. The companion revision is obtained from the
COMPANION_REVISION_NAME assignment in the Quartus II Settings File (.qsf) for the current
revision.
## The following example illustrates the option usage using
## Stratix II and HardCopy II migration scenario
## Run Analysis & Synthesis for Stratix II revision
quartus_map myproject -c myfpga
## Run HardCopy Design Readiness Check for Stratix II revision
quartus_cdb myproject -c myfpga --hc_ready
## Create a HardCopy II revision named "myhcii" based on "myfpga"
quartus_cdb myproject -c myfpga --create_companion=myhcii
## Run Analysis & Synthesis for HardCopy II revision
quartus_map myproject -c myhcii
## Run HardCopy Design Readiness Check for HardCopy II revision
quartus_cdb myproject -c myhcii --hc_ready
--hc_review
Generates a HardCopy Handoff Report.
The current revision and its companion revision should be fully compiled for this option to properly
review all necessary files. The companion revision is obtained from the COMPANION_REVISION_NAME
assignment in the Quartus II Settings File (.qsf) for the current revision.
When this option is enabled, every generated Tcl script contains all of the top-level LogicLock regions.
Regions with logic not associated with the script's target partition act as placeholders and are empty. This
command helps describes for the lower-level project the way it fits into the final, top-level design.
The option is ignored if --include_logiclock_regions_in_bottom_up_scripts=off is used.
This option is enabled by default. Add the flag --include_all_logiclock_regions_in_bottom_up_scripts=off
to disable.
When this option is enabled, generated Tcl scripts contain commands that force any signals promoted to
'global' in the top-level to be promoted in the lower-level.
This option is enabled by default. Add the flag
--include_global_signal_promotion_in_bottom_up_scripts=off to disable.
When this option is enabled, generated Tcl scripts contain the top-level LogicLock regions associated with
this partition. This helps ensure the lower-level project places its logic where the top-level project expects
it.
This option is enabled by default. Add the flag --include_logiclock_regions_in_bottom_up_scripts=off to
disable.
Option to generate makefiles for lower-level projects in addition to the Tcl scripts. One makefile is
generated for each lower-level project, for the top-level project and for the overall design (known as the
master_makefile). The master makefile simply invokes all other makefiles.
Makefiles are designed to work with GNU make and support the '-j' option which allows parallel
compilation of the lower-level projects. The master makefile is all that needs to be called by the user to
ensure the lower-level projects are up to date and that the top-level project has imported the latest versions
of the lower-level projects. You can invoke the master makefile as follows (you must not turn off
--include_project_creation_in_bottom_up_scripts for this to work without modification):
gnumake -f master_makefile.mak -j2
<The '-j2' means there are 2 processors to use.>
Makefiles are placed in the directory of the project they control if project creation is enabled and
appropriate directories are automatically filled in. If you elect not to have the tool create projects for you,
all makefiles are placed in the specified output directory and the user must fill in the directory variables at
the top of each makefile so that the tool knows where the lower-level projects can be found. In both cases
you must add the source file dependencies for each lower-level project's makefile if maintainance of the
project after initial compilation is desired. By default no dependencies are created (other than one on the
auto-generated Tcl script for that partition) and so after the first c ompilation, the rule is be up to date.
By default, makefile generation is enabled. Add the flag --include_makefiles_with_bottom_up_scripts=off
to disable.
When this option is enabled, generated Tcl scripts contain commands that lock any lower-level pins
connected directly to IOs in the top-level to the IO location they were placed at in the top-level. This helps
keep a consistent pin placement amongst projects.
This option is enabled by default. Add the flag --include_pin_locations_in_bottom_up_scripts=off to
disable.
When this option is enabled, generated Tcl scripts contain commands to create the lower-level projects if
the projects do not exist. The tool creates projects in subdirectories under the output directory, named
according to name of the corresponding partition.
By default, project creation is enabled. Add the flag --include_project_creation_in_bottom_up_scripts=off
to disable.
When this option is enabled, generated Tcl scripts contain INPUT_MAX_DELAY to constrain all paths to
the newly created virtual input pins (see --include_virtual_pins_in_bottom_up_scripts). The value for this
option is the inter-partition delay of paths driving the virtual inputs. For more information about the
meaning of theseassignments, please see the Quartus II Help topics relating to INPUT_MAX_DELAY.
The option is ignored if --include_virtual_pins_in_bottom_up_scripts=off is used.
If you use this option, you must also specify the delay (in nanoseconds) to be used in the constraints with
the --bottom_up_scripts_virtual_input_pin_delay option.
When this option is enabled, generated Tcl scripts contain OUTPUT_MAX_DELAY to constrain all paths
to the newly created virtual output pins (see --include_virtual_pins_in_bottom_up_scripts). Specify the
inter-partition delay seen by paths driven by the virtual outputs. For more information about the meaning
of theseassignments, please see the Quartus II Help topics relating to OUTPUT_MAX_DELAY.
The option is ignored if --include_virtual_pins_in_bottom_up_scripts=off is used.
If you use this option, you must also specify the delay (in nanoseconds) to be used in the constraints with
the --bottom_up_scripts_virtual_output_pin_delay=<delay> command.
This option is enabled by default. Add the flag
--include_virtual_output_pin_timing_in_bottom_up_scripts=off to disable.
When this option is enabled, generated Tcl scripts contain location constraints on newly created virtual
pins (see --include_virtual_pins_in_bottom_up_scripts). The pins are locked to their top-level source (for
input pins) or sink (for output pins) location.
The option is ignored if --include_virtual_pins_in_bottom_up_scripts=off is used.
This option is enabled by default. Add the flag --include_virtual_pin_locations_in_bottom_up_scripts=off
to disable.
When enabled, this means that generated Tcl scripts contain commands to mark all lower-level pins that
connect to other design entities in the top-level (i.e. not directly to IOs) as virtual pins. This helps prevent
overuse of IOs and leads to a more accurate representation of the lower-level project.
This option is enabled by default. Add the flag --include_virtual_pins_in_bottom_up_scripts=off to
disable.
--incremental_compilation_export[=<.qxp file>]
Exports a design partition into a Quartus II Exported Partition (.qxp) file. The .qxp file contains the
compilation results of the specified partition, and can be imported into one or more design partitions of
another project.
The value <output file> is optional. If unspecified, the value specified by the
INCREMENTAL_COMPILATION_EXPORT_FILE global assignment is used if present. Otherwise, a
default file name is generated.
Other options you may use to control how the operation is performed include:
This option must be used with the --incremental_compilation_export option. The values POST_FIT and
POST_SYNTH are used to direct the software to export the post-fit and the post-synthesis netlist,
respectively. If this option is omitted, the value specified by the
INCREMENTAL_COMPILATION_EXPORT_NETLIST_TYPE global assignment is used if present.
Otherwise, the top-level partition is exported by default.
This option must be used with the --incremental_compilation_export option. Use this option to specify the
name of the partition to be exported. If this option is omitted, or if an empty value is provided, the value
specified by the INCREMENTAL_COMPILATION_EXPORT_PARTITION_NAME global assignment is
used if present. Otherwise, the top-level partition is exported by default.
--incremental_compilation_export_routing[=on|off]
This option must be used with the --incremental_compilation_export option. The value specifies whether
routing is to be exported. The option only has an effect when a post-fit netlist is exported, because a
post-synthesis netlist does not contain routing information. If this option is omitted, the value specified
with the INCREMENTAL_COMPILATION_EXPORT_ROUTING global assignment is used if present.
Otherwise, the default is to export routing unless the currently specified device family does not support it.
--incremental_compilation_import[=on|off]
Imports one or more Quartus II Exported Partition (.qxp) files into the design partitions of the current
project.
The option uses the following partition assignments to determine the location of the Quartus II Exported
Partition files, and how importation should be performed, on a per-partition basis:
Merges all design partitions to prepare a netlist for the Fitter based on the current Partition Netlist Type
assignments.
--mif_dependency=<mif_check>
Run the Memory Initialization File dependency check script.
If your design has RAM without a Memory Initialization File, then the Memory Initialization File
dependency script creates an extra revision called <rev_name>_mif_dependency with the ASM option
(use checkerboard pattern) turned on to ensure that the design has no initialization dependency.
## Run Analysis & Synthesis for Stratix II revision
quartus_map myproject -c myfpga
## Run Fitter for Stratix II revision
quartus_fit myproject -c myfpga
## Run MIF Dependency Check for Stratix II revision
quartus_cdb myproject -c myfpga --mif_dependency=mif_check
## Run MIF Dependency Check cleanup for Stratix II revision
quartus_cdb myproject -c myfpga --mif_dependency=cleanup
--netlist_type=<map|cmp|asm>
Loads the specified atom netlist type. This option is used in combination with the "-write_equation_file"
option. Use "map" to specify the post Analysis & Synthesis netlist. Use "cmp" to specify the post Fitter
netlist. Use "asm" to specify the post Assembler netlist. The post Assembler netlist is only supported for
designs using the HardCopy device family.
--override_partition_netlist_type=<value>
Overrides the netlist type setting for the specified Design Partition for this compililation. The option must
be used with the --merge option.
<value> takes the form of "<partition name>=<netlist type>", including the double quotes. For example, to
use netlist type POST_SYNTH for a partition named "alu", use the following argument:
For non-imported partitions, the following netlist type values can be used:
POST_SYNTH
POST_FIT
STRICT_POST_FIT
EMPTY
For imported partitions, the following netlist type values can be used:
IMPORT
IMPORT_BASED_POST_FIT
EMPTY
To override the netlist type for more than one partition, use the override_partition_netlist_type option as
many times as needed.
--post_map[=on|off]
Limits the --export_database and --import_database options to only export and import the output of
Analysis and Synthesis (quartus_map) to and from the version-compatible database.
Note: This option must be used with either the --export_database or the --import_database option.
When this option is enabled, generated Tcl scripts contain commands that remove any LogicLock regions
that exist in the project the script is being called within.
This option is enabled by default. Add the flag --remove_existing_regions_in_bottom_up_scripts=off to
disable.
Option to update memory content from the Memory Initialization File (.mif) or Hexadecimal
(Intel-Format) File (.hex) for all RAM or CAM atoms.
This option is useful for quickly changing memory contents without requiring a full compilation. After
using this option, run the Assembler (quartus_asm) to generate new programming files for the device.
--vqm[=<.vqm file>]
Option to generate a Verilog Quartus Mapping File (.vqm) netlist.
You must specify the .vqm file name unless the name can be taken from the
LOGICLOCK_INCREMENTAL_COMPILE_FILE assignment in the Quartus II Settings File (.qsf).
This option overrides the settings specified in the .qsf.
--write_eqn_file[=<.eqn file>]
Writes equation file to the specified filename. If filename is not specified, the filename used is: <revision
name>.<map or fit>.eqn.
The netlist type must be specified using "--netlist_type" option. The valid netlist types are "map" and
"cmp".
Use "map" to specify the post synthesis netlist and use "cmp" for the post fitter netlist.
Examples
##Write the post synthesis equation file (using default filename.)
quartus_cdb <revision name> --write_eqn_file --netlist_type=map
##Write the post fitter equation file (using default filename.)
quartus_cdb <revision name> --write_eqn_file --netlist_type=cmp
##Write post synthesis equation file to the file "my_mapper_results.eqn".
quartus_cdb <revision name> --write_eqn_file=my_mapper_results.eqn
--netlist_type=map
--write_rcf_for_vqm[=on|off]
Option to write the Routing Constraints File (.rcf) for the Verilog Quartus Mapping File (.vqm) netlist.
The Quartus® II Convert Programming Files converts one programming file format to a different possible
format.
Make sure you specify valid options and an input programming file to generate the new requested
programming file format. Refer to help topics for more information and examples.
Usage
quartus_cpf [-h | --help[=<option|topic>] | -v]
quartus_cpf -c [options] <input_file> <output_file> --- to convert file
quartus_cpf -w <option_filename> --- to create option file for configuration device
jam ............................................................................................................................................................ 2–22
Refer to the help for --frequency=<frequency with units> on page 2–19
-s=<device name>
Refer to the help for --sfl_device=<device name> on page 2–20
-u=<up|down>
Refer to the help for --count_dir=<up|down> on page 2–18
-w
Refer to the help for --write on page 2–20
--configuration_mode=<PS|AP|FPP|PPA|PPS>
Option to specify the configuration mode to be used. Use this option only if you want to generate a Raw
Binary File (.rbf), Tabular Text File (.ttf) or a Hexadecimal (Intel-Format) Output File (.hexout).
ValueOptions
PSPassive Serial
APActive Parallel
FPPFast Passive Parallel
PPAPassive Parallel Asynchronous
PPSPassive Parallel Synchronous
--convert
Option to convert input file(s) to output file format.
# To convert a .sof into a .pof, .jic, .rbf, .ttf or .hexout
quartus_cpf -c [options or option_file] <input_sof_file> <output file type (pof | jic |
rbf | ttf | hexout)>
# To convert multiple files into a .pof, .jic, .rbf, .ttf, or .hexout,
# use a Conversion Setup File (.cof) created with the
# Convert Programming Files dialog box in the UI
quartus_cpf -c <input_cof_file>
# To convert multiple filesinto a .jam, .jbc, .svf or .isc,
# use a Chain Description File (.cdf) created with the
# Programmer tool in the UI
quartus_cpf -c <input_cdf_file> <output file type (jam | jbc | svf | isc)>
--count_dir=<up|down>
Option to specify the direction for the address for the Hexadecimal (Intel-Format) Output File (.hexout).
Use this option only with the "-h" or "--hexout" option.
--device=<device name>
Option to specify the name for the configuration device.
Option to specify the JTAG TCK clock frequency. Use this option only if you want to generate a Serial
Vector Format (.svf) for the output file.
Example
# To create an SVF for programming with a 10MHz JTAG TCK clock frequency
quartus_cpf -c -q 10.0MHz -n p <input_pof_file> <output_svf_file>
--key=<filename and key id>
Option to specify a key (or keys) to be used for generating secured configuration bitstreams or the
Encryption Key Programming File (.ekp).
Use the following format to specify key values:
<keyfile>:<keyid>[:<keyid2>]
in which keyfile is a valid Key File (.key), keyid is a valid id for a key in the specified file, and keyid2 is a
valid id for a key in the specified file.
Examples
# To convert .sof to a secured configuration bitstream .rbf
# using a single key file
quartus_cpf --key <keyfile>:<keyid1>:<keyid2> <input_sof_file> <output_rbf_file>
# To generate an Encryption Key Programming File (.ekp)
# using two key files
quartus_cpf --key <keyfile1>:<keyid1> --key <keyfile2>:<keyid2> <input_sof_file>
<output_ekp_file>
--operation=<pb|v|p>
Option to specify the programming options. Use this option only if you want to generate a Serial Vector
Format File (.svf) for the output file.
ValueOptions
pprogram
vverify
pbprogram and blank check
Example
# To create an SVF for programming
quartus_cpf -c -n p <input_pof_file> <output_svf_file>
--option=<filename>
Option to create the configuration device file using the specified input option file.
You can create the option file using any text editor. Use the strings and the values listed below or use the
"quartus_cpf -w" command to generate the strings in the text file automatically.
Use the following format to specify string values:
The following are valid strings and values for the option file:
StringDescription
compression=on|offTurns the compression on or off for enhanced configuration devices.
clock_divisor=1 to 16|1.5|2.5Specifies the value of the clock divisor for enhanced configuration devices.
clock_source=internal|externalSpecifies the clock source for enhanced configuration devices.
clock_frequencySpecifies the clock frequency for enhanced configuration devices. Internal values:
10|33|50|66 MHz External values: 1 Hz to 133.0 MHz
jtag_usercodeSpecifies the JTAG user code value, which must be stored as a hexadecimal number,
for example, jtag_usercode=abcd1234.
disable_pullups=on|offDisables the nCS and OE internal pull-ups on the configuration device.
memory_map_file=on|offTurns the memory map file generation on or off.
auto_usercode=on|offTurns the auto usercode option on or off.
auto_jtag_usercode_inc=on|offAutomatically increments JTAG user code in the second and subsequent
configuration devices if the target device requires multiple configuration devices.
use_low_voltage=on|offAllows an EPC1 configuration device to operate in a 3.3-V environment.
bitstream_compression=on|offTurns the bitstream compression on or off for a Cyclone device.
--sfl_device=<device name>
Option to specify the serial flash loader device name. Only the Cyclone device family supports serial flash
loader.
--start_address=<hexadecimal number>
Option to specify the start address for the Hexadecimal (Intel-Format) Output File (.hexout). Use this
option only with the "-h" or "--hexout" option.
--voltage=<voltage>
Option to specify the VCC level. Use this option only if you want to generate a Serial Vector Format File
(.svf) for the output file.
Example
# To create an SVF for programming with a 3.3V supply
quartus_cpf -c -g 3.3 -n p <input_pof_file> <output_svf_file>
--write
Option to write the option file for the configuration device(s).
design_security
For families that support Design Security, use the 'key' option to specify the keys to be used for generating
secured configuration bitstreams or the Encryption Key Programming File (.ekp).
in which keyfile is a valid Key File (.key), keyid is a valid id for a key in the specified file, and keyid2 is a
valid id for a key in the specified file.
Examples
# To convert .sof to a secured configuration bitstream .rbf
# using a single key file
quartus_cpf --key <keyfile>:<keyid1>:<keyid2> <input_sof_file> <output_rbf_file>
# To generate an Encryption Key Programming File (.ekp)
# using two key files
quartus_cpf --key <keyfile1>:<keyid1> --key <keyfile2>:<keyid2> <input_sof_file>
<output_ekp_file>
hexout
To generate a Hexadecimal (Intel-Format) Output File (.hexout), specify the input file name and output file
name. Make sure the file extension of the output file is .hexout. The input file can be either an SRAM
Object File (.sof) or a Programmer Object File (.pof).
You can use optional arguments to specify the data start address and count direction. These arguments are
not legal if you are trying to convert an enhanced configuration device .pof to a .hexout.
Optional arguments are as follows:
StringDescription
-u | --count_dirSpecifies the count direction for the data.
-a | --start_addressSpecifies the start address of the data. Make sure to enter the address as a
hexadecimal number.
Examples
# To convert .sof to .hexout
quartus_cpf -c <input_file> <output_hexout_file>
#start address = 0x200, data count direction = up
quartus_cpf -c -u up -a 0x200 <input_file> <output_hexout_file>
#start address = 0x0fffff, data count direction = down
quartus_cpf -c -u down -a 0x0fffff <input_file> <output_hexout_file>
# To use a Conversion Setup File (.cof) created with
# the Convert Programming Files dialog box in the UI
quartus_cpf -c <input_cof_file>
isc
To generate an In System Configuration File (.isc), specify the input file name and output file name. The
ISC File is generated for IEEE-1532 compliant or compatible devices. Make sure the file extension of the
output file is .isc. The input file can be either a Programmer Object File (.pof) or a Chain Description File
(.cdf).
To generate a JEDEC STAPL Format File (.jam), specify the input file name and output file name. Make
sure the file extension of the output file is .jam. The input file must be either an SRAM Object File (.sof), a
Programmer Object File (.pof), or a Chain Description File (.cdf). Use the .cdf to generate the .jam for a
multi-device chain.
To generate a Jam STAPL Byte Code 2.0 File (.jbc), specify the input file name and output file name. Make
sure the file extension of the output file is .jbc. The input file must be either an SRAM Object File (.sof), a
Programmer Object File (.pof), or a Chain Description File (.cdf). Use a .cdf to generate the .jbc for a
multi-device chain.
To convert an SRAM Object File (.sof) to a JTAG Indirect Configuration Device Programming File (.jic),
specify the input file name, configuration device name, serial flash loader device name, and output file
name. Make sure the file extension of the output file is .jic. You can also generate a .jic using a Conversion
Setup File (.cof) created with the Convert Programming Files dialog box in the UI. A .cof contains all the
options for the configuration device along with the output .jic name.
The configuration device must be an Altera
®
serial configuration device and the serial flash loader device
must be a Cyclone device.
Examples
# To convert .sof to .jic
quartus_cpf -c -d <config_device_name> -s <serial_flash_loader_device_name>
<input_sof_file> <output_jic_file>
# To use option file
quartus_cpf -c -o <option_file> -d <config_device_name>
To convert an SRAM Object File (.sof) to a Programmer Object File (.pof), specify the input file name,
configuration device name and output file name. Make sure the file extension of the output file is .pof. You
can also generate a .pof using a Conversion Setup File (.cof) created with the Convert Programming Files
dialog box in the UI. A .cof contains all the options for the configuration device along with the output .pof
name.
Alternatively, you can change configuration device options using an ASCII text option file. Refer to the
help for the "-o" option for more information about the option file. If you do not specify an option file and
a .cof, default values are used, or values are read from a .cof.
Examples
# To convert .sof to .pof
quartus_cpf -c -d <config_device_name> <input_sof_file> <output_pof_file>
# To use option file
quartus_cpf -c -o <option_file> -d <config_device_name> <input_sof_file>
<output_pof_file>
# To use .cof
quartus_cpf -c <input_cof_file>
rbf
To generate a Raw Binary File (.rbf), specify the input file name and output file name. Make sure file
extension of the output file is .rbf. The input file can be only an SRAM Object File (.sof).
Examples
# To convert .sof to .rbf
quartus_cpf -c <input_sof_file> <output_rbf_file>
# To use a Conversion Setup File (.cof) created with
# the Convert Programming Files dialog box in the UI
quartus_cpf -c <input_cof_file>
rpd
To generate a Raw Programming Data File (.rpd), specify the input file name and output file name. Make
sure the file extension of the output file is .rpd. The input file can be only a Programmer Object File (.pof).
Examples
# To convert .pof to .rpd
quartus_cpf -c <input_pof_file> <output_rpd_file>
# To use a Conversion Setup File (.cof) created with
# the Convert Programming Files dialog box in the UI
quartus_cpf -c <input_cof_file>
svf
To generate a Serial Vector Format File (.svf), you must use three arguments: "-q" ("--frequency") to specify
the JTAG TCK clock frequency, "-g" ("--voltage") to specify the VCC level, and "-n" ("--operation") to specify
the programming operation.
Make sure to specify the units for frequency and voltage.
Use a Chain Description File (.cdf) to generate the .svf for a multi-device chain.
Examples
# To use 4.5 MHz TCK, 3.3V supply, and programming option
quartus_cpf -c -q 4.5MHz -g 3.3 -n p <input_pof_file> <output_svf_file>
# To use 10 MHz TCK, 3.3V supply, and verify option
quartus_cpf -c -q 10MHz -g 3.3 -n v <input_sof_file> <output_svf_file>
# To use 45 KHz TCK, 1.8V supply, and programming+blank_check option
quartus_cpf -c -q 45KHz -g 1.8 -n pb <input_cdf_file> <output_svf_file>
To generate a Tabular Text File (.ttf), specify the input file name and output file name. Make sure the file
extension of the output file is .ttf. The input file can be only an SRAM Object File (.sof).
Examples
# To convert .sof to .ttf
quartus_cpf -c <input_sof_file> <output_ttf_file>
# To use a Conversion Setup File (.cof) created with
# the Convert Programming Files dialog box in the UI
quartus_cpf -c <input_cof_file>
The Quartus II Design Assistant checks the reliability of a design based on a set of design rules. The Design
Assistant is especially useful for checking the reliability of a design before converting the design for
HardCopy devices.
The Design Assistant supports designs that target any Altera device supported by the Quartus II software.
Quartus II Analysis & Synthesis or the Fitter must be run successfully before running the Design Assistant.
The Quartus II EDA Netlist Writer generates netlist and other output files for use with other EDA tools.
Quartus II Analysis & Synthesis, the Fitter, or Timing Analyzer must be run successfully before running
the EDA Netlist Writer, depending on the arguments used.
The options are grouped into two levels: top-level options and secondary options. A top-level option
specifies a single task. You can specify only one top-level option.
The following top-level options are supported: --simulation, --timing_analysis, --formal_verification,
A top-level option that indicates that all other options specified on the command line are meant for board
level boundary scan-related file generation.
The exact type of output file(s) are specified by the secondary options --format=bsdl, and
--output_directory The --output_directory option is optional.
--board_signal_integrity[=on|off]
A top-level option that indicates that all other options specified on the command line are meant for board
level signal integrity related file generation.
The exact type of output file(s) are specified by the secondary options --format=ibis and --format=hspice,
and --output_directory The --output_directory option is optional.
--board_symbol[=on|off]
A top-level option that indicates that all other options specified on the command line are meant for board
level symbol related file generation.
The exact type of output file(s) are specified by the "--tool=viewdraw" and "--output_directory" options.
The --output_directory option is optional.
--board_timing[=on|off]
A top-level option that indicates that all other options specified on the command line are meant for board
level timing related file generation.
The exact type of output file(s) are specified by the "--format=stamp" and "--output_directory" options.
The --output_directory option is optional.
--formal_verification[=on|off]
A top-level option that indicates that all other options specified on the command line are meant for formal
verification-related file generation.
The exact type of output file(s) are specified by the "--tool" and the "--output_directory" option. The
--output_directory option is optional.
--format=<NONE>
Option to specify the format of a netlist or a test bench. This option is usually used with the "--tool" option.
The following format values are supported:
■ verilog
■ vhdl
■ ibis
■ hspice
■ stamp
■ psdf
■ bsdl
This option overrides the settings specified in the Quartus II Settings File (.qsf).
Option that tells the EDA Netlist Writer to generate a simulation command script for third-party EDA
simulation tools.
This option can take three possible values:
rtl
gate_level
rtl_and_gate_level
The location of pre-compiled simulation library is specified with the option "--user_compiled_simlib_dir".
This option is optional.
For more information on this option, use "--help=<option>".
This option overrides the settings specified in the Quartus II Settings File (.qsf).
--gen_testbench
A top-level option that indicates that all other options specified on the command line are meant for HDL
test bench-related file generation.
The exact type of output file(s) are specified by secondary options. These include:
--tool
--format
--vector_source
--testbench_file
--check_outputs
All options are always optional, except "--tool" and "--format". The "--tool" and "--format" options may or
may not be optional.
The "--vector_source", "--testbench_file", and “--check_outputs” options cannot be used unless the
“--gen_testbench” option is used.
For more information on each option, use "--help=<option>".
--glitch_filtering[=on|off]
Option to specify that output netlists and .sdo file be generated for glitch filtering. This option can only be
used with the top-level option "--simulation".
This option overrides the settings specified in the Quartus II Settings File (.qsf).
--output_directory=<NONE>
Option to specify the directory for generated output files.
This option overrides the settings specified in the Quartus II Settings File (.qsf).
--resynthesis[=on|off]
A top-level option that indicates that all other options specified on the command line are meant for
resynthesis- related file generation.
The exact type of output file(s) are specified by the "--tool" option.
A top-level option that indicates that all other options specified on the command line are meant for
simulation-related file generation.
The exact type of output file(s) are specified by secondary options. These include:
--tool
--format
--output_directory
--glitch_filtering
--no_top_vhdl_entity
--disable_bidir_input_timing_checks
--vhdl_architecture
--vcd_tb_design_instance_name
--vcd_type
--functional
--maintain_design_hierarchy
--map_illegal_characters
--short_hpath
--timescale
--flatten_buses
--device_controls_as_ports
--user_compiled_simlib_dir
All options are always optional, except “--tool” and “--format”. The “--tool” and “--format” options may
or may not be optional.
For more information on each option, use "--help=<option>".
--timing_analysis[=on|off]
A top-level option that indicates that all other options specified on the command line are meant for timing
analysis- related file generation.
The exact type of output file(s) are specified by secondary options. These include:
--tool
--format
--output_directory
--map_illegal_characters
--short_hpath
--flatten_buses
All options are always optional, except "--tool" and "--format". The "--tool" and "--format" options may or
may not be optional.
For more information on each option, use "--help=<option>".
--tool=<3rd-party eda tool>
Option to tell the EDA Netlist Writer to write out a netlist for the specified third-party EDA tool. You can
choose the third-party EDA tool from one of the three categories of available tools: simulation, timing
analysis, or board level design and analysis.
This option overrides the settings specified in the Quartus II Settings File (.qsf).
Both the tool name and format must be specified in order to generate a netlist. Available tools and their
corresponding options are listed below:
The Quartus® II Fitter performs place and route by fitting the logic of a design into a device. The Fitter
selects appropriate interconnection paths, pin assignments, and logic cell assignments.
Quartus II Analysis & Synthesis must be run successfully before running the Fitter.
Option to run until I/O placement is determined. This process includes placing all blocks in the periphery,
such as PLLs, serializers, deserializers, and gigabit transceiver blocks (GXB).
The report file and the floorplan display I/O placement results. If all pins cannot be placed, the report file
and floorplan display partial placement, results, and error messages to indicate why placement failed.
The "--check_ios" option should not be used when you use the "--io_smart_recompile" option. For
example, after doing a complete place and route, if you change an I/O standard, it is advisable to use the
"--io_smart_recompile" option, because the "--check_ios" option destroys the original place and route
results.
--check_netlist
Option to run only legality checking on the current netlist. Analysis & Synthesis (quartus_map) must be
run successfully before you use this option. Currently changes made to placement or routing are not
verified -- only functional changes (for example, I/O standards) are checked.
This option can be used to verify that the netlist is legal after you make changes using the Chip Editor.
Option to run an Early Timing Estimate. An Early Timing Estimate is an estimate of timing results for your
design before performing full placement and routing. This feature runs the fitter up to 10 times faster than
a full fit and generates a full timing report based on estimated delays for the design. The fit is not fully
optimized or routed, and hence the timing report is only an estimate. Typically, the estimated delays are
within 20% of what a full compilation can achieve.
The following table describes the types of timing estimates:
ValueDescription
realisticEstimates delays that will likely be close to a full compilation's results. (default value)
optimisticEstimates delays that are lower than those likely to be achieved by a full compilation.
This makes the estimate of performance optimistic.
pessimisticEstimates delays that are higher than those likely to be achieved by a full compilation.
This makes the estimate of performance pessimistic.
All Early Timing Estimate types have the same reduction of compilation time.
After successfully running "quartus_fit --early_timing_estimate," "quartus_tan --timing_analysis_only"
must be run to generate a timing report.
--effort=<standard|fast|auto>
Option to specify the level of effort you want the Fitter to use.
The following table describes level of effort values:
ValueDescription
standardDirects the Fitter not to decrease effort. Preserves fmax but does not decrease
compilation time.
fastDirects the Fitter to decrease effort. Decreases compilation time by up to 50%, with a
possible reduction in fmax.
autoDirects the Fitter to reduce effort after meeting timing requirements. Decreases
compilation time only when timing and fitting requirements can be met.
--fmax=<time unit>
Option to specify the fmax time value.
Fmax is the minimum acceptable clock frequency, that is, the maximum clock frequency that can be
achieved without violating internal setup and hold time requirements.
Example usage:
quartus_fit one_wire --fmax=155.55mhz
The format is "<floating point time value><time unit>". In this example, "155.55" is the <floating point
time value> and "mhz" is the <time unit>.
The following table displays possible time units:
Time UnitDescription
ssecond(s)
msmillisecond(s)
usmicrosecond(s)
nsnanosecond(s)
pspicosecond(s)
fsfemtosecond(s)
hzhertz
khzkilohertz
mhzmegahertz
ghzgigahertz
--incremental_signaltap
Option to perform an incremental SignalTap® II compilation. Use this option when only SignalTap settings
have changed since the last compilation.
This option cannot be used with most of the other quartus_fit options.
--inner_num=<value>
Option to specify a value for the loop multiplier "inner_num" used during placement. Analysis &
Synthesis (quartus_map) must be run successfully before you use this option. Use of a higher value
increases compilation time, but may increase the quality of placement.
Option to recompile the design for changed I/O assignments without repeating the entire Fitter flow.
Analysis & Synthesis (quartus_map) must be run successfully before you use this option. You can
recompile only with I/O assignment changes.
This option allows you to recompile the design quickly because only I/O changes and legality checks are
run to determine if the new I/O assignments are compatible with the current post-fitting netlist.
--one_fit_attempt[=on|off]
Option to perform only one fitting attempt, giving a no fit if that attempt fails. When this option is turned
off, the Fitter may perform additional attempts.
--optimize_io_register_for_timing[=on|off]
Option to optimize I/O register placement for timing. This option is used for timing-driven compilation.
This option overrides the settings specified in the Quartus II Settings File (.qsf) or the part used in Analysis
& Synthesis (quartus_map). The specified part must be in the same device family used in Analysis &
Synthesis.
--seed=<value>
Option to use the specified seed value.
The Fitter uses the seed as the initial placement configuration when attempting to optimize the design's
timing requirements, including fmax.
--signalprobe
Option to perform an incremental SignalProbe™ compilation. Use this option when only SignalProbe
settings have changed since the last compilation.
This option cannot be used with most of the other quartus_fit options.
--tco=<time unit>
Option to specify the tco time value.
Tco is the maximum acceptable clock to output delay to the output pin. The clock to output delay is the
time required to obtain a valid output at an output pin that is fed by a register after a clock signal
transition on an input pin that clocks the register. This time always represents an external pin-to-pin delay.
Example usage:
quartus_fit one_wire --tco=10.55ns
The format is "<floating point time value><time unit>". In the example, "10.55" is the <floating point time
value> and "ns" is the <time unit>.
The following table displays possible time units:
Time UnitDescription
ssecond(s)
msmillisecond(s)
usmicrosecond(s)
nsnanosecond(s)
pspicosecond(s)
fsfemtosecond(s)
hzhertz
khzkilohertz
mhzmegahertz
ghzgigahertz
--tdc[=on|off]
Option to use timing-driven compilation. This option optimizes place and route based on timing
information.
Tpd is the maximum acceptable input to non-registered output delay, that is, the time required for a signal
from an input pin to propagate through combinatorial logic and appear at an output pin.
Example usage:
quartus_fit one_wire --tpd=20.55ns
The format is "<floating point time value><time unit>". In this example, "20.55" is the <floating point time
value> and "ns" is the <time unit>.
The following table displays possible time units:
Time UnitDescription
ssecond(s)
msmillisecond(s)
usmicrosecond(s)
nsnanosecond(s)
pspicosecond(s)
fsfemtosecond(s)
hzhertz
khzkilohertz
mhzmegahertz
ghzgigahertz
--tsu=<time unit>
Option to specify the tsu time value.
Tsu is the maximum acceptable clock setup time for the input (data) pin. The setup time is the length of
time for which data that feeds a register via its data or enable input(s) must be present at an input pin
before the clock signal that clocks the register is asserted at the clock pin.
Example usage:
quartus_fit one_wire --tsu=7.55ns
The format is "<floating point time value><time unit>". In this example, "7.55" is the <floating point time
value> and "ns" is the <time unit>.
Quartus® II Analysis & Synthesis builds a single project database that integrates all the design files in a
design entity or project hierarchy. Analysis & Synthesis includes Quartus II Integrated Synthesis, which
provides comprehensive Verilog HDL and VHDL language support, as well as support for Altera-specific
languages such as AHDL.
Refer to the help for --lib_path=<path> on page 2–48
--analysis_and_elaboration
Option to check all the design files in a design for syntax and semantic errors, and perform a netlist
extraction.
--analyze_file=<design file>
Option to check the specified design file for syntax and semantic errors.
--convert_bdf_to_verilog=<.bdf file>
Option to create a Verilog Design File (.v) for the specified Block Design File (.bdf).
--convert_bdf_to_vhdl=<.bdf file>
Option to create a VHDL Design File (.vhd) for the specified Block Design File (.bdf).
--effort=<auto|fast>
Option to select synthesis effort level.
The following table displays available values:
ValueDescription
autoMaximum synthesis effort. This is the default value.
fastSynthesis process is streamlined to improve runtime at the cost of design performace and/or
resource usage. Use this option when the Fitter early_timing_estimate mode is used, or when a
fast-synthesis compilation is needed without the need to run the Fitter. When this option is used
with the regular Fitter, Fitter performance may decrease as fast-synthesis netlists take longer to
route.
--enable_wysiwyg_resynthesis[=on|off]
Option to unmap WYSIWYG primitives during synthesis and remap the gates back to WYSIWYG LCELL
primitives.
Option to target the specified device family. If the "--part" option is not used, the part is set to Auto.
The family name should not contain any spaces, for example, --family=APEXII. If you need to add space
between words in the family name, make sure that you enclose the words in double quotation marks "", for
example, --family="APEX II".
--generate_cmp_file=<design file>
Option to create a default VHDL Component File (.cmp) that represents the entities in the specified Text
Design File (.tdf), VHDL Design File (.vhd), Verilog Design File (.v), EDIF Input File (.edf), or Block Design
File (.bdf), CusP file (.cpp) and MATLAB File (.mdl).
--generate_functional_sim_netlist
Option to prepare the databases necessary for functional simulation.
--generate_inc_file=<design file>
Option to create a default AHDL Include File (.inc) that represents the entities in the specified Text Design
File (.tdf), VHDL Design File (.vhd), Verilog Design File (.v), EDIF Input File (.edf), or Block Design File
(.bdf).
--generate_inst_file=<design file>
Option to create a default Verilog Instantiation File (.inst) that represents the entities in the specified Text
Design File (.tdf), VHDL Design File (.vhd), Verilog Design File (.v), EDIF Input File (.edf), Block Design
File (.bdf), CusP file (.cpp) or MATLAB file (.mdl).
--generate_symbol=<design file>
Option to create a Block Symbol File (.bsf) that represents the entities in the specified Text Design File
(.tdf), VHDL Design File (.vhd), Verilog Design File (.v), EDIF Input File (.edf), or Block Design File (.bdf).
--ignore_carry_buffers[=on|off]
Option to ignore CARRY_SUM buffers that are instantiated in the design. (This option also applies to
MAX+PLUS II-style CARRY buffers.)
--ignore_cascade_buffers[=on|off]
Option to ignore CASCADE buffers that are instantiated in the design.
incremental_synthesisTurn on incremental compilation for synthesis only. Also known as incremental
synthesis which is previously the incr_synth option.
full_incremental_compilationTurn on full incremental compilation.
quartus_map
--lib_path=<path>
Option to use the specified library paths to find the design files of the project. For multiple library paths,
use --lib_path=path1 --lib_path=path2 or --lib_path="path1;path2".
--optimize=<area|speed|balanced>
Option to optimize the design to achieve maximum speed performance, minimum area usage, or high
speed performance with miminal area cost during synthesis.
The following table displays available values:
ValueDescription
areaMakes the design as small as possible in order to minimize resource usage.
speedChooses a design implementation that has the fastest fmax.
balancedChooses a design implementation that has a high-speed performance with minimal
logic usage.
Note that the current version of the Quartus
following devices:
II software does not support the "balanced" setting for the
--parallel[=on|off]
Runs quartus_map in a mode that enables parallel synthesis of partitions using the number of processors
specified by the Quartus II parallel compilation option.
--part=<device>
Option to target the specified device. This option overrides the "--family" option or family assignment.
--partition=<NONE>
Specifies a partition to synthesize manually. This option overrides the netlist type and preservation level
of the partition and disables any automatic resynthesis of other partitions, even if they require synthesis
because of changes to your design.
You can specify a partition ID or name. For example, the root partition has ID 0 and name “Top”. To
synthesize multiple partitions, use a separate option for each partition.
Option to set the state machine processing style used to compile a state machine.
The following table displays available values:
ValueDescription
autoAllows Analysis & Synthesis to choose the best encoding for the state machine.
minimal_bitsUses the minimal number of bits to encode the state machine.
one_hotEncodes the state machine in the one-hot style.
user_encodedEncodes the state machine in the manner specified by the user.
--update_wysiwyg_parameters
Option to update, when possible, the parameters of a changed WYSIWYG PLL or CDR primitive in the
Compiler netlists. This option assumes that the previous compilation was successful.
When you use this option, the quartus_map executable gives a message stating the next executable you
need to run in order to complete a compilation, quartus_fit or quartus_asm. If it is not possible to update
the parameters, the quartus_map executable runs normally and gives a message that you need to run
quartus_fit.
When you use this option, all assignment changes you made since the last compilation are lost.
--verilog_macro=<NONE>
Option to set a Verilog macro. Use the following format:
--verilog_macro="my_macro=2"
--verilog_macro="SUM(a,b)=(a+b)"
--verilog_macro="my_str_macro=\"string2\""
Those are equivalent to the following `define statements:
The Quartus® II Programmer programs Altera® devices. The Programmer uses one of the valid supported
file formats: Programmer Object Files (.pof), SRAM Object Files (.sof), Jam File (.jam), or Jam Byte-Code
File (.jbc).
Make sure you specify a valid programming mode, programming cable, and operation for a given device.
Usage
quartus_pgm [-h | --help[=<option|topic>] | -v]
quartus_pgm -c <cable name> filname.cdf --- If you want to use cdf file
quartus_pgm -c <cable name> -m <programming mode> -o <value> [-o <value>...] --- If you
want to use individual programming file(s)
quartus_pgm -l --- to display the list of available hardware
quartus_pgm -c <cable name> -a --- to display the list of devices connected to the cable
This command supports the following options:
OptionPage
-a ............................................................................................................................................................... 2–51
Refer to the help for --cable=<cable name> on page 2–51
-i
Refer to the help for --initcfg on page 2–52
-l
Refer to the help for --list on page 2–52
-m=<programming mode>
Refer to the help for --mode=<programming mode> on page 2–52
-o=<programming operation>
Refer to the help for --operation=<programming operation> on page 2–52
-z
Refer to the help for --haltcc on page 2–52
--auto
Option to detect and display all the devices in the device chain.
--bgp
Allows a MAX II device to continue to run in-system while new programming data loads into the
configuration flash memory (CFM). When you turn on this option, programming data loaded into the
CFM does not immediately configure the device.
--cable=<cable name>
Option to specify which programming hardware or cable to use.
The full syntax is as follows (depending on whether the hardware is on your local machine or a remote
machine):
"<cable_name> [<port>]"
"<cable_name> on <host_name/IP_address> [<port>]"
You don't need to specify the hostname or port if they are unambiguous so just specifying the name of the
cable will be sufficient if there is only one cable of that type available (on a local or remote machine).
ByteBlasterMV
"byteblaster [lpt1]"
"USB-Blaster on remote-machine [com1]"
APU
--haltcc
Halts the on-chip auto-configuration controller of the device to allow programming via the JTAG interface.
--initcfg
Specifies that configuration devices will configure attached devices automatically after the Programmer
finishes programming the configuration devices.
--list
Option to display all the available programming hardware cables.
--mode=<programming mode>
Option to specify which programming mode to use.
Use one of the following programming mode values:
ValueMode
JTAGJTAG programming
PSPassive Serial programming
ASActive Serial programming
SDIn-Socket programming
--operation=<programming operation>
Option to specify which programming operation(s) to perform on the device(s).
Use the following syntax for each device in a device chain:
-o <options>;<input_file>@<device_index>
NOTE: The device index starts with 1.
Exceptions to this syntax occur when you use the following options:
-o E;<output_file>;<device_name>@<device_index>
-o S;<device_name/input_file>@<device_index>
<options> must be one of the following combinations:
* Serial FLASH Loader option only
** Cannot be used in combination with other options
Note: Specifying a <device_index> is optional, but if you specify a <device_index> for one device, you
must specify a <device_index> for all devices. You cannot specify a <device_index> for devices in a
Passive Serial chain. Each device in a multi-device chain must have a corresponding -o construction.
The Quartus II PowerPlay Power Analyzer estimates the thermal dynamic power and the thermal static
power consumed by the design. For newer families such as Stratix II and MAX II, the current drawn
from each power supply is also estimated.
Quartus II Analysis & Synthesis and the Fitter must be run successfully before running the PowerPlay
Power Analyzer.
Option to specify a default toggle rate to be used on input I/O pin signals during power analysis. This
value is used if an input I/O pin's toggle rate is not specified by some other mean such as an input file or
user assignment. To specify a default toggle rate for all other signals in the design use the
--default_toggle_rate command line option.
This value can be specified as a percenatge or an absolute value. If specified as an absolute value, the unit
is transitions/s.
This command line option can only appear once. If this command line option is not used, then the value
stored in the Quartus II Settings File (.qsf) is used to determine the default input I/O pin toggle rate.
Note: The default static probability value used by the PowerPlay Power Analyzer is 0.5.
--default_toggle_rate=<toggle rate value>
Option to specify a default toggle rate to be used for all output signals except input I/O pin signals during
power analysis. This value is used if a signal's toggle rate is not specified by some other mean such as an
input file or user assignment and vectorless estimation should not be used.
This value is specified as a percenatge or as an absolute value. If specified as an absolute value, the unit is
transitions/s.
Examples
--default_toggle_rate=12.5%
--default_toggle_rate=150000transitions/s
--default_toggle_rate="150000 transitions/s"
This command line option can only appear once. If this command line option is not used, then the value
stored in the Quartus II Settings File (.qsf) is used to determine the default toggle rate.
Note: The default static probability value used by the PowerPlay Power Analyzer is 0.5.
--estimate_power[=on|off]
Option to specify whether a power estimate should be produced.
Specifying a value of "off" reduces processing time. For example, specify the value "off" for this option if
the only desired action is to process a Value Change Dump (VCD) file to produce a Signal Activity File
(SAF).
By default, a power estimate is produced.
--input_saf[=<SAF Filename>]
Option to use the specified Signal Activity File (.saf) as input. The SAF contains toggle rates and static
probabilities for output signals in the design. If no filename is specified then the filename stored in the
Quartus II Settings File (.qsf) is used or if no filename exists in thethe QSF, then <revision name>.saf is
used. This command line option can only appear once.
The input_saf option should not be used if either the no_input_file or input_vcd option is specified. If
neither the no_input_file, input_saf or input_vcd option is specified, then the settings in the QSF are used
to determine the behavior of the Power Analyzer.
quartus_pow
--input_vcd[=<VCD Filename>]
Option to use the specified VCD File (.vcd) as input. If no filenames are specified then the filenames stored
in the Quartus II Settings File (.qsf) are used or if no filenames exist in the QSF, then <revision name>.vcd
will be used. This command line option can appear multiple times in the case that multiple VCD files are
required.
The input_vcd option should not be used if either the no_input_file or input_saf option is specified. If
none of the no_input_file, input_saf or input_vcd option is specified, then the settings in the QSF are used
to determine the behavior of the Power Analyzer.
--no_input_file
Option to instruct the Power Analyzer not to use an input file to initialize the toggle rates and static
probabilities for output signals in the design.
The no_input_file option should not be used if either the input_saf or input_vcd option is specified. If
neither the no_input_file, input_saf or input_vcd option is specified, then the settings in the Quartus II
Settings File (.qsf) are used to determine the behavior of the Power Analyzer.
--output_epe=<EPE Filename>
Option to write an Early Power Estimation file, summarizing the resources used by the design. The file
can be used to import design information into the PowerPlay Early Power Estimator spreadsheet available
from the Altera website.
The design must be compiled before the Early Power Estimator file can be written.
This command line option may only appear once.
--output_saf=<SAF Filename>
Option to write out the toggle rates and static probabilities used by the Power Analyzer during the power
analysis to the specified Signal Activity File (.saf). This command line option can only appear once.
--use_vectorless_estimation[=on|off]
Option to specify whether or not vectorless estimation should be used to calculate unspecified toggle rates
and static probabilities for the output signals in the design. If set to "on" then vectorless estimation is used
by the PowerPlay Power Analyzer and the --default_toggle_rate command line option or the value stored
in the Quartus II Settings File (.qsf) will be ignored. If set to "off" then the PowerPlay Power Analyzer uses
the value specified by the command line option --default_toggle_rate or the value stored in the Quartus II
Settings File (.qsf) as the default toggle rate.
This command line option can only appear once. If this command line option is not used, then the value
stored in the Quartus II Settings File (.qsf) is used to determine whether or not vectorless estimation is
used. This command line option only applies to the Stratix II and MAX II families and is ignored for all
other families. For all other families the behaviour is equivalent to this command line option being set to
"off".
Note: Regardless of the setting of this option, all unspecified toggle rates for input I/O pin signals use the
default toggle rate specified by either the command line option --default_input_io_toggle_rate or the value
stored in the Quartus II Settings File (.qsf).
The default static probability value used by the PowerPlay Power Analyzer is 0.5.
--vcd_filter_glitches[=on|off]
Option to use glitch filtering when reading VCD Files (.vcd) as input. This command line option can only
appear once. If this command line option is not used, the value stored in the Quartus II Settings File (.qsf)
is used to determine whether or not glitch filtering is used when reading VCD Files. This option has no
effect if the "input_vcd" option is not used.
--voltage=<value_in_mV>
Option to specify the device voltage (mV) when running the PowerPlay Power Analyzer.
The Quartus® II Shell is a simple Quartus II Tcl interpreter. The Shell has a smaller memory footprint than
the other command-line executables that support Tcl: quartus_tan, quartus_cdb, and quartus_sim. The
Shell can be started with a Tcl script to evaluate, used as an interactive Tcl interpreter (shell), or used as a
quick Tcl command evaluator, evaluating the remaining command-line arguments as one or more Tcl
commands.
Option to generate a Quartus II Archive File (.qar) for your project that contains specific sets of files.
Usage
quartus_sh --archive [<options>] <project name>
Available options
-use_file_set <value>Specify the archive file set ID to use. By default, the "basic" file set ID is used. Use the
-list_file_sets option to view the list of possible file sets.
-list_file_setsList available archive file sets.
-list_filesList files to be archived. If not specified, a Quartus II Archive file is generated.
-ascii <file name>When combined with -list_files, this option generates the specified <file name>
containing a newline-delimited list of files to be archived.
-no_discoverOption not to run Analysis & Elaboration. By default, Analysis & Elaboration is run
unless the compiler database already exists for the revision.
-forceForces the archiver to run Analysis & Elaboration and overwrite the compiler
database for the revision.
-exportExport version-compatible database and include it in the archive file.
-include_outputInclude full compilation database and output files.
-output <value>Specify the output file name. By default, <revision name>.qar is used. If the file
already exists, it is overwritten.
-input <value>Specify the input file name containing a new-line delimited list of files to archive. This
option can only be combined with the -output option.
-readmeDisplay the readme file.
-self_testRun a short test on the Quartus II Archive (.qar) file after it is created. The test
ensures that the .qar file contains a valid, complete and compilable design.
-fix_qsfModify the <revision>.qsf file to include all the necessary files in order to properly
archive, restore and compile the design. A <revision>.archive.qip file is generated and
specified in the <revision>.qsf file.
-all_revisionsCreate an archive (named <revision>.qar) for each revision in the project.
-revision <value>Specify the revision name. By default, the current project revision is archived.
2. Adds all files discovered or required by the compiler into your <revision>.qsf file:
quartus_sh --archive -fix_qsf top
You do not need to use the -fix_qsf option again unless you modify the design and add more design files.
The .qsf file is now complete with all the required design files. Unless you add new files to the project, you
can ask the archive project to always skip Analysis & Elaboration by passing the -no_discover option:
quartus_sh --archive -no_discover top
Examples
# Generate top.qar
quartus_sh --archive top
# Export the version-compatible database files
# and include them in the top.qar archive
quartus_sh --archive -export -output top.qar top
# Generate my_files.qar containing the files listed in my_files.txt
quartus_sh --archive -input my_files.txt -output my_files.qar
# Generate top.qar and run a short test to make sure
# top.qar contains a valid, complete and compilable design.
quartus_sh --archive -self_test top
# Generate top.txt containing a list of files to
# archive for the 'top' design.
quartus_sh --archive -ascii top.txt -list_files top
--determine_smart_action
Option to open a project and determine the smart action jump.
The smart action is defined as the earliest module in the Compiler flow that needs to be run based on
current assignment files.
This option writes out a .chg file depending on what has changed in the source files. For a given
quartus_<exe_name>, the associated .chg file name has the format <exe_name>.chg. For example, if
quartus_map needs to be rerun, a file named map.chg is created.
If a timing requirement is changed, one of the following files is created or updated:
■ fit.chg if timing-driven compilation is turned ON, which means that the Fitter subsequent modules
need to be rerun
■ tan.chg if timing-driven compilation is turned OFF and only the Timing Analyzer needs to be rerun
This option can be used to write a makefile that jumps to the correct module based on changed
assignments. For example, the following makefile rules can be used:
The Design Space Explorer (DSE) is a tool for exploring the complex flow parameters in the Quartus
software. DSE takes the guess work out of selecting parameter values and helps you determine the
optimal Quartus II software settings for a design.
Version
9.0
Synopsis
Usage
quartus_sh --dse [options]
Options:
-archive
-concurrent-compiles [0..6]
-custom-file <filename>
-decision-column <"column name">
-exploration-space <"space">
-ignore-failed-base
-llr-restructuring
-lower-priority
-lsf-queue <queue name>
-nogui
-optimization-goal <"goal">
-project <project name>
-report-all-resource-usage
-revision <revision name>
-run-power
-search-method <"method">
-seeds <seed list>
-skip-base
-slaves <"slave list">
-stop-after-time <dd:hh:mm>
-stop-after-zero-failing-paths
-use-lsf
Note: To use DSE in command-line mode, specify the "-nogui" option. If you do not specify this option, the
DSE graphical user interface (GUI) starts, regardless of the other command-line options used.
®
II
quartus_sh --dse
This command launches the DSE GUI.
quartus_sh --dse -nogui -project main
This command starts a default command-line exploration. The default seeds are used along with the
default exploration space, optimization goal, and search method.
quartus_sh --dse -nogui -project main -seeds 2,4,8-10
-exploration-space "Extra Effort Search"
This command starts a command-line exploration of an "Extra Effort Search" space using the seeds 2, 4, 8
through 10, the default optimization goal, and the default search method.
Instructs DSE to archive all points during exploration. Without this option turned on, DSE archives only
the best compilation. Archives are stored below the design directory in the sub-folder dse/result. In
addition to the archive files, a set of *-dse-result.xml files hold the results for each compilation DSE
performs on the design. These XML result files are for the internal use of DSE only.
-concurrent-compiles [0..6]
Changes the number of current compilations performed by DSE on your local system. By default DSE
performs one compile at a time on your local system; increasing the number of concurrent local
compilations can reduce the time it takes to explore a design space but requires additional computing
resources and Quartus II licenses. Setting this option to zero prevents DSE from using your local system
when running in distributed mode. When running DSE in standalone mode, setting this option to zero has
the same effect as setting this option to one.
-custom-file <filename>
Loads the exploration space from a file instead of using a predefined exploration space. See the chapter
entitled "Design Space Explorer" in the Quartus II Handbook for more information on custom exploration
spaces. This option must be used with the following option:
-exploration-space "Custom Space"
If you do not use this option, the custom space file is ignored.
-decision-column <"column name">
Instructs DSE to use an the <column name> column from the DSE result table when it looks for values to
make better/worse decisions. The default column is "Worst-case Slack".
-exploration-space <"space">
Changes the exploration space used by DSE. The default exploration space is "Seed Sweep". To see a list of
available exploration spaces, enter an invalid exploration space name (like "foo") or check the list of
exploration spaces for your project on the "Advanced" tab in the DSE graphical user interface.
-ignore-failed-base
Instructs DSE to continue exploring the space even if the base compilation fails. This is useful if the design
does not fit into a device, and you want to use DSE to explore area-reducing options in the Quartus II
software.
-llr-restructuring
Instructs DSE to try softening and even removing LogicLock regions from the design before exploring the
space in an effort to maximize the effectiveness of Quartus II synthesis and fitting options.
-lower-priority
Lowers the priority of any thread spawned by DSE to compile a point in your design. This can reduce the
impact DSE has on CPU resources while it is exploring a design space.
-lsf-queue <queue name>
Instructs DSE to use a non-default LSF queue at your site when distributing the search of the exploration
space. For detailed information on using LSF to distribute the search of an exploration space, please see the
chapter entitled "Design Space Explorer" in the Quartus II Handbook.
-nogui
Instructs DSE to operate in command-line mode instead of graphical user interface mode.
Changes the optimization goal used by DSE. The default optimization goal is "Optimize for Speed". To see
a list of available optimization goals, enter an invalid optimization goal name (like "foo") or check the list
of optimization goals for your project on the "Advanced" tab in the DSE graphical user interface.
-project <project name>
The name of the Quartus II project to use while exploring a space.
-report-all-resource-usage
Instructs DSE to extract all the resouce usage information from your project and report it in the DSE report
tables. If this option is not used DSE reports very few resource usage statistics in its tables.
-revision <revision name>
The name of the project revision to use while exploring a space. If left unspecified, DSE will use the default
revision in the project.
-run-power
Runs the Quartus II PowerPlay Power Analyzer during exploration to produce power dissipation
estimates for the project on every point in the design space. Ensuring that accurate signal activity and
operating conditions have been specified for your project is essential to obtaining accurate power
estimates for a design. For more information on specifying signal activity and operating conditions please
see the chapter entitled "PowerPlay Power Analyzer" in the Quartus II Handbook.
-search-method <method>
Change the search method used by DSE. The default search method is "Accelerated Seach of Exploration
Space". The available search methods are:
■ "Exhaustive Search of Exploration Space"—This method performs an exhaustive search of all
combinations of all Quartus II settings in a design space to find the best combination for your project.
■ "Accelerated Search of Exploration Space"—This method performs intelligent pruning of an
exploration space to arrive at the optimal combination of Quartus II settings for your project using
fewer compiles.
-seeds <seed list>
A list of seeds to sweep as part of the exploration space. DSE accepts a comma separated list and
hyphenated ranges of integer seed values. For example:
-seeds 1,2,8-10
would sweep seeds 1 and 2, and seeds 8, 9, and 10.
-skip-base
Instructs DSE to test your base project before trying to analyze or compile the specified revision. If the
revision has already been compiled successfully, DSE will skip its own compilation of the base project. If
DSE cannot determine if the base compilation can be skipped, it will issue a warning and proceed to
compile the revision for you.
-slaves <slave list>
A list of computers on the local area network to distribute DSE compiles to and search the exploration
space. Provide a comma-separate list of host names and/or IP addresses of computers that are running
Quartus II qSlave instances. For more information on distributed DSE compiles, please see the "Design
Space Explorer" chapter in the Quartus II Handbook.
Instructs DSE to stop exploring the space after a specified time has elapsed. The time value is specified in
format "dd:hh:mm". Where "dd" is the number of days, "hh" is the number of hours and "mm" is the
number of minutes to allow before the search is halted.
-stop-after-zero-failing-paths
Instructs DSE to stop exploring the space after it encounters any point, including the base point, that has
zero failing paths. DSE uses the failing path count reported in the 'All Failing Paths' report column to make
this decision.
-use-lsf
Instructs DSE to use the LSF resources available at your site when performing a distributed search of an
exploration space. Specifying that DSE should use LSF resources automatically enters DSE into distributed
search mode. For more information on distributed DSE compiles, please see the chapter entitled "Design
Space Explorer" in the Quartus II Handbook.
Applying Dse Optimizations
After you run Design Space Explorer, it writes its recommended optimization settings in a table to both the
screen and to the <projectname>.dse.rpt output file. The recommended optimization settings are of the
form:
To implement the recommended optimizations when working in command-line mode, enter each
optimization at the command prompt in a Tcl window in the form:
<set_global_assignment> is the name of a Tcl command
<-name ASSIGNMENT_NAME> is the name of an assignment setting
<ASSIGNMENT_VALUE> is a valid value for the specified assignment setting
Examples
set_global_assignment -name STRATIX_OPTIMIZATION_TECHNIQUE SPEED
set_global_assignment -name ADV_NETLIST_OPT_SYNTH_GATE_RETIME ON
set_global_assignment -name ADV_NETLIST_OPT_SYNTH_WYSIWYG_REMAP ON
set_global_assignment -name AUTO_PACKED_REGISTERS_STRATIX OFF
set_global_assignment -name PHYSICAL_SYNTHESIS_COMBO_LOGIC ON
set_global_assignment -name PHYSICAL_SYNTHESIS_REGISTER_DUPLICATION OFF
set_global_assignment -name PHYSICAL_SYNTHESIS_REGISTER_RETIMING OFF
set_global_assignment -name PHYSICAL_SYNTHESIS_EFFORT NORMAL
set_global_assignment -name INNER_NUM 5
Note:
PHYSICAL_SYNTHESIS_EFFORT and INNER_NUM can only be applied through the Tcl window.
PHYSICAL_SYNTHESIS_EFFORT makes the physical synthesis algorithms try harder.
INNER_NUM controls the Fitter effort level.
See Also
For more information please see the Design Space Explorer book in the Quartus II Help. Press the <F1>
key to access this help from the DSE graphical user interface.
Additional information is also available in the "Design Space Explorer" chapter in the Quartus II
Handbook, which is available at the Literature section of the Altera website (http://www.altera.com).
Licensing
This script is copyrighted by Altera Corporation and provided subject to the rights granted by the Altera
Legal Notice found in the file: quartus/common/tcl/apps/dse/dse.tcl.
--dtw
Option to call a predefined Tcl/Tk script with a simple Graphical User Interface (GUI) wizard that can be
used to define timing requirements for a DDR/DDR2-SDRAM memory interface.
Usage
quartus_sh --dtw [<options>]
Use "quartus_sh --dtw -h" for help on the available options.
Example
Run the wizard. The wizard will query the user for the project and all necessary parameters, then apply
the necessary timing requirements for the memory interface to the project.
quartus_sh --dtw
Licensing
This script is copyrighted by Altera Corporation and provided subject to the rights granted by the Altera
Legal Notice found in the file quartus/common/tcl/apps/gui/dtw/dtw.tcl
--flow
Option to open a project and execute the specified flow.
# You can do the same manually (assuming migration
# creates top_hardcopy_optimization)
quartus_sh --flow compile top
quartus_sh --flow migrate_to_hardcopy
cd top_hardcopy_optimization
quartus_sh --flow compile top
# Get an early timing estimate by running fast synthesis,
# followed by early timing estimate and timing analysis
quartus_sh --flow early_timing_estimate_with_synthesis top
# If synthesis has been run before you can run
# early timing estimate and timing analysis alone
quartus_sh --flow early_timing_estimate top
quartus_sh
--prepare
Option to create or open a project and make some assignments in order to prepare the project for
compilation.
This option is intended to set up a project before compilation with the "--flow" option.
Usage
quartus_sh --prepare [<options>] <project_name>
Use "quartus_sh --prepare -?" for help on the available options.
Examples
# Set project and compile for Stratix
quartus_sh --prepare -f Stratix top
quartus_sh --flow compile top
# Set project and compile for Stratix using a revision
quartus_sh --prepare -r rev1 -f Stratix top
quartus_sh --flow compile top -c rev1
# Set project to compile a specified top-level entity
quartus_sh --prepare -t MyTopEntity top
quartus_sh --flow compile top
--qboard
QBoard is a Tk based Graphical User Interface (GUI) that allows the user create project templates based on
DevKits.
Licensing
This script is copyrighted by Altera Corporation and provided subject to the rights granted by the Altera
Legal Notice found in the file quartus/common/tcl/apps/qboard/qboard_script.tcl
--qhelp
Option to call a predefined Tk script with a simple Graphical User Interface (GUI) that can be used to
browse command-line executable and Tcl API help.
Licensing
This script is copyrighted by Altera Corporation and provided subject to the rights granted by the Altera
Legal Notice found in the file quartus/common/tcl/apps/qflow/qhelp.tcl
A utility to start the Distributed Master/Slave Toolkit's slave daemon on the slave host. The slave daemon
must be started on each slave host in order to listen for job requests from the master host.
Options [optional]:
port=<port_number> defaults to 1977
jobslimit=<jobs_limit_number> defaults to 1
workdir=<working_directory> defaults to current directory
Examples
quartus_sh --qslave
This command starts the Distributed Master/Slave Toolkit’s slave daemon in command-line mode.
quartus_sh --qslave port=1977
This command starts the Distributed Master/Slave Toolkit’s slave daemon to listen at port 1977.
quartus_sh --qslave jobslimit=1
This command starts the Distributed Master/Slave Toolkit’s slave daemon to listen by setting the jobs
limit to 1. This means the maximum number of jobs this slave host can accept is one. If this slave host
receives more than one job, the second job is rejected.
This command starts the Distributed Master/Slave Toolkit’s slave daemon and set the working directory
to "d:/slave". The working directory stores the temporary directories that are used by the slave while
running the jobs. These temporary directories are deleted when the jobs are released successfully. If the
jobs fail to be released for some reasons, you may need to delete these temporary directories manually to
save disk space.
Licensing
This script is copyrighted by Altera Corporation and provided subject to the rights granted by the Altera
Legal Notice found in the file quartus/common/tcl/apps/qslave/qslave.tcl.
--relcon
Option to call a predefined Tcl script that can be used to place logic registers relative to user-defined pin
locations. One application of this script is to optimize timing margins for DDR/DDR2-SDRAM memory
interfaces on Stratix II.
Usage
quartus_sh --relcon [<options>]
Use "quartus_sh --relcon -?" for help on the available options.
Example
# Place the read postamble registers in the LABs adjacent to the
# DQS pins to optimize read postamble setup margin.
quartus_sh --relcon -project top -pin_name "mem_dqs[*]" -reg_name
"*|postamble_en_pos_2x[*]" -row_offset 1 -apply
# Place the read resync registers in the LABs adjacent to
# the DQ pins to optimize read resync setup and hold margins.
quartus_sh --relcon -project top -pin_name "mem_dq[*]" -reg_name "*|rdata_p_ams[*]"
This script is copyrighted by Altera Corporation and provided subject to the rights granted by the Altera
Legal Notice found in the file quartus/common/tcl/apps/relcon/relative_constraint.tcl
--restore
Option to restore the specified Quartus II Archive File (.qar).
Usage
quartus_sh --restore [<options>] <.qar file name>
Available options
OptionDescription
-contentList the contents of the specified Quartus II Archive file.
-ascii <file name>When combined with the -content option, this option generates the specified <file
name> containing a newline-delimited list of files contained in the specified Quartus
II Archive file.
# Make SMART_RECOMPILE=ON assignment
quartus_sh --set SMART_RECOMPILE=ON top
# Same as above but on revision rev1
quartus_sh --set -rev rev1 SMART_RECOMPILE=ON top
# Remove CUT_CLEAR_AND_PRESET assignment
quartus_sh --set -remove CUT_CLEAR_AND_PRESET top
--simlib_comp
Launches the Altera Simulation Library Compiler to compile Verilog and VHDL simulation libraries for all
supported third-party simulators. Make sure the appropriate simulation tools are already installed and
paths to the tools are either specified in the Quartus II software in the EDA Tool Options page of the
Options dialog box, or are in the search path.
Required option. Specifies the device family for which you are compiling libraries. This will result in the
compilation of all libraries required for RTL and gate-level simulations.
Note: The family name should be specified in all lowercase, with no spaces.
-tool <simulation tool name>
Required option. Specify one of the following tool names:
modelsim
vcs
vcsmx
ncsim
activehdl
rivierapro
Note: No libraries are generated for VCS. Instead a VCS options file, simlib_comp.vcs, is generated that
specifies the library source files.
Note: Global libraries are created for for Active HDL, but not for Riviera-PRO
-language <language>
Required option. This must be either verilog or vhdl.
-directory <directory>
Not a required option. The directory in which to create the compiled library directories. If not specified the
default is the current directory ( ./ )
The libraries are compiled into a single directory (verilog_libs or vhdl_libs) containing subdirectories for
each of the compiled libraries. The subdirectory names for Verilog libraries are always suffixed with _ver,
whereas the VHDL library directories have no suffix.
For example, the Verilog version of the altera_mf library would be:
<directory>/verilog_libs/altera_mf_ver
and the VHDL version would be:
<directory>/vhdl_libs/altera_mf
-log <filename>
Not a required option. Specifies the file to store all messages issued during the compilation that were not
suppressed using the -suppress_messages option. If this option is not specified then no log file is used.
Not a required option. Specifies whether or not to suppress simulator specific information and warning
messages issued during compilation. This option does not apply to tool specific error messages. Messages
that are suppressed do not appear in a log file, if one was specified. If this option is not specified, then no
messages are suppressed.
-gui
Not a required option.This will launch the simlib_comp graphical user interface (GUI) regardless of the
other command-line options used.
See Also
For more information please see the EDA simulation tool specfic chapters of the verification volume in
Quartus II Handbook which is available in the Literature section of the Altera website.
Licensing
This script is copyrighted by Altera Corporation and provided subject to the rights granted by the Altera
Legal Notice found in the file: quartus/common/tcl/internal/simlib_comp.tcl.
The Quartus® II Simulator tests and debugs the logical operation and internal timing of the design entities
in a project. The Simulator can perform two types of simulation: functional simulation and timing
simulation. The quartus_sim executable includes Tcl support.
You must generate a functional simulation netlist successfully before running a functional simulation. You
can generate a functional simulation netlist with the Generate Functional Simulation Netlist command
(Processing menu) or with the quartus_map --generate_functional_sim_netlist <project> command at the
command prompt.
The Timing Analyzer must be run successfully before running a timing simulation.