Click File > New Project Wizard to quickly setup and create a new design project.
When you open a project, a unified GUI displays integrated project information. The project encapsulates information about your design hierarchy, libraries, constraints, and project settings.
You can save multiple revisions of your project to experiment with settings that achieve your design goals. Intel® Quartus® Prime projects support team-based, distributed work flows and a scripting interface.
|File Type||Contains||To Edit||Format|
|Project file||Project and revision name||File > New Project Wizard||Intel® Quartus® Prime Project File (.qpf)|
|Project settings||Lists design files, entity settings, target device, synthesis directives, placement constraints||Assignments > Settings||Intel® Quartus® Prime Settings File (.qsf)|
|Project database||Compilation results||Project > Export Database||Exported Partition File (.qxp)|
|Timing constraints||Clock properties, exceptions, setup/hold||Tools > Timing Analyzer||Synopsys Design Constraints File (.sdc)|
|Logic design files||RTL and other design source files||File > New||All supported HDL files|
|Programming files||Device programming image and information||Tools > Programmer||SRAM Object File (.sof)Programmer Object File (.pof)|
|Project library||Project and global library information||Tools > Options > Libraries||
|IP core files||IP core logic, synthesis, and simulation information||Tools > IP Catalog||Intel® Quartus® Prime IP File (.qip)|
|Platform Designer (Standard) system files||Platform Designer (Standard) system and IP core files||Tools > Platform Designer (Standard)||Platform Designer (Standard) System File (.qsys)|
|EDA tool files||Generated for third-party EDA tools||Assignments > Settings > EDA Tool Settings||Verilog
Output File (.vo)
VHDL Output File (.vho)
Verilog Quartus Mapping File (.vqm)
|Archive files||Complete project as single compressed file||Project > Archive Project||Intel® Quartus® Prime Archive File (.qar)|
|Project Navigator Tab||Description|
|Files||Lists all design files in the current project.
Right-click design files in this tab to run these commands:
|Hierarchy||Provides a visual representation of the project hierarchy, specific resource usage information, and device and device family information. Right-click items in the hierarchy to Locate, Set as Top-Level Entity, or define Logic Lock regions or design partitions.|
|Design Units||Displays the design units in the project. Right-click a design unit to Locate in Design File.|
|IP Components||Displays the design files that make up the IP instantiated in the project, including Intel® FPGA IP, Platform Designer (Standard) components, and third-party IP. Click Launch IP Upgrade Tool from this tab to upgrade outdated IP components. Right-click any IP component to Edit in Parameter Editor.|
|Revisions||Displays the current project revisions.|
To access the Compilation Report, click (Processing > Compilation Report).
- Analysis & Synthesis reports
- Fitter reports
- Timing analysis reports
- Power analysis reports
- Signal integrity reports
Analyze the detailed project information in these reports to determine correct implementation. Right-click report data to locate and edit the source in project files.
- Processing tab—displays messages from the most recent process
- System tab—displays messages unrelated to design processing
- Search—locates specific messages
Messages are written to stdout when you use command-line executables.
You can suppress display of unimportant messages so they do not obscure valid messages.
- Suppress Message—suppresses all messages matching exact text
- Suppress Messages with Matching ID—suppresses all messages matching the message ID number, ignoring variables
- Suppress Messages with Matching Keyword—suppresses all messages matching keyword or hierarchy
- You cannot suppress error or Intel legal agreement messages.
- Suppressing a message also suppresses any submessages.
- Message suppression is project revision-specific. Derivative project revisions inherit any suppression.
- You cannot edit messages or suppression rules during compilation.
Setting and Project File Best Practices
Be very careful if you edit any Intel® Quartus® Prime data files, such as the Intel® Quartus® Prime Project File (.qpf), Intel® Quartus® Prime Settings File (.qsf), Quartus IP File (.qip), or Platform Designer (Standard) System File (.qsys). Typos in these files can cause software errors. For example, the software may ignore settings and assignments.
Every Intel® Quartus® Prime project revision automatically includes a supporting .qpf that preserves various project settings and constraints that you enter in the GUI or add with Tcl commands. This file contains basic information about the current software version, date, and project-wide and entity level settings. Due to dependencies between the .qpf and .qsf, avoid manually editing .qsf files.
Do not compile multiple projects into the same directory. Instead, use a separate directory for each project.
By default, the Intel® Quartus® Prime software saves all project output files, such as Text-Format Report Files (.rpt), in the project directory. Instead of manually moving project output files, change your project compilation settings to save them in a separate directory.
To save these files into a different directory choose Assignments > Settings > Compilation Process Settings. Turn on Save project output files in specified directory and specify a directory for the output files.
Project Archive and Source Control Best Practices
Click Project > Archive Project to archive your project for revision control.
As you develop your design, your Intel® Quartus® Prime project directory contains a variety of source and settings files, compilation database files, output, and report files. You can archive these files using the Archive feature and save the archive for later use or place it under revision control.
- Choose Project > Archive Project > Advanced to open the Advanced Archive Settings dialog box.
- Choose a file set to archive. For example, choose File set > Source control with incremental compilation and Rapid Recompile database to save the source and database file required to re-create your project with your Rapid Recompile revisions.
- Add additional files by clicking Add (optional).
To restore your archived project, choose Project > Restore Archived Project. Restore your project into a new, empty directory.
IP Core Best Practices
- Do not manually edit or write your own .qsys, .ip, or .qip file. Use the
Quartus® Prime software tools to create and edit these files.
Note: When generating IP cores, do not generate files into a directory that has a space in the directory name or path. Spaces are not legal characters for IP core paths or names.
- When you generate an IP core using the IP Catalog, the Intel® Quartus® Prime software generates a .qsys (for Platform Designer (Standard)-generated IP cores) or a .ip file (for Intel® Quartus® Prime Pro Edition) or a .qip file. The Intel® Quartus® Prime Pro Edition software automatically adds the generated .ip to your project. In the Intel® Quartus® Prime Standard Edition software, add the .qip to your project. Do not add the parameter editor generated file (.v or .vhd) to your design without the .qsys or .qip file. Otherwise, you cannot use the IP upgrade or IP parameter editor feature.
- Plan your directory structure ahead of time. Do not change the relative path between a .qsys file and it's generation output directory. If you must move the .qsys file, ensure that the generation output directory remains with the .qsys file.
- Do not add IP core files directly from the /quartus/libraries/megafunctions directory in your project. Otherwise, you must update the files for each subsequent software release. Instead, use the IP Catalog and then add the .qip to your project.
- Do not use IP files that the Intel® Quartus® Prime software generates for RAM or FIFO blocks targeting older device families (even though the Intel® Quartus® Prime software does not issue an error). The RAM blocks that Intel® Quartus® Prime generates for older device families are not optimized for the latest device families.
- When generating a ROM function, save the resulting .mif or .hex file in the same folder as the corresponding IP core's .qsys or .qip file. For example, moving all of your project's .mif or .hex files to the same directory causes relative path problems after archiving the design.
- Always use the Intel® Quartus® Prime ip-setup-simulation and ip-make-simscript utilities to generate simulation scripts for each IP core or Platform Designer (Standard) system in your design. These utilities produce a single simulation script that does not require manual update for upgrades to Intel® Quartus® Prime software or IP versions.
On the Tasks pane, click Settings to access global project settings, including:
- Project files list
- Synthesis directives and constraints
- Logic options and compiler effort levels
- Placement constraints
- Timing constraint files
- Operating temperature limits and conditions
- File generation for other EDA tools
- Target a device (click Device)
- Target a development kit
The .qsf stores each project revision’s project settings. The Intel® Quartus® Prime Default Settings File (<revision name> _assignment_defaults.qdf) stores the default settings and constraints for each new project revision.
The Assignment Editor (Tools > Assignment Editor) provides a spreadsheet-like interface for assigning all instance-specific settings and constraints.
The Intel® Quartus® Prime software includes several advisors to help you optimize your design and reduce compilation time. The advisors listed in the Tools > Advisors menu can provide recommendations based on your project settings and design constraints.
DSE II attempts multiple seeds to identify one meeting your requirements. DSE II can run different compilations on multiple computers in parallel to streamline timing closure.
Each revision captures a unique set of project settings and constraints, but does not capture any logic design file changes. Use revisions to experiment with different settings while preserving the original. Optimize different revisions for various applications. Use revisions for the following:
- Create a unique revision to optimize a design for different criteria, such as by area in one revision and by fMAX in another revision.
- When you create a new revision the default Intel® Quartus® Prime settings initially apply.
- Create a revision of a revision to experiment with settings and constraints. The child revision includes all the assignments and settings of the parent revision.
You create, delete, and edit revisions in the Revisions dialog box. Each time you create a new project revision, the Intel® Quartus® Prime software creates a new .qsf using the revision name.
To compare each revision’s synthesis, fitting, and timing analysis results side-by-side, click Project > Revisions and then click Compare.
In addition to viewing the compilation results of each revision, you can also compare the assignments for each revision. This comparison reveals how different optimization options affect your design.
The project copy includes all design files, any .qsf files, and project revisions. Use this technique to optimize project copies for different applications. For example, optimize one project to interface with a 32-bit data bus, and optimize a project copy to interface with a 64-bit data bus.
The Compiler maps the elements of your design to specific device and resource during fitting. Following compilation, you can copy the Compiler's device and resource assignments to the .qsf to preserve that same implementation in subsequent compilations.
Click Assignments > Back-Annoate Assignments to apply the device resource assignments to the .qsf. Select the back-annotation type in the Back-annotation type list.
The Intel® Quartus® Prime software includes full-featured schematic and text editors, as well as HDL templates to accelerate your design work. The Intel® Quartus® Prime software supports VHDL Design Files (.vhd), Verilog HDL Design Files (.v), SystemVerilog (.sv) and schematic Block Design Files (.bdf). The Intel® Quartus® Prime software also supports Verilog Quartus Mapping (.vqm) design files generated by other design entry and synthesis tools. In addition, you can combine your logic design files with Intel and third-party IP core design files, including combining components into a Platform Designer (Standard) system (.qsys).
The New Project Wizard prompts you to identify logic design files. Add or remove project files by clicking Project > Add/Remove Files in Project. View the project’s logic design files in the Project Navigator.
Right-click files in the Project Navigator to:
- Open and edit the file
- Remove File from Project
- Set as Top-Level Entity for the project revision
- Create a Symbol File for Current File for display in schematic editors
- Edit file Properties
The quartus2.ini file stores global library information.
- Click Assignment > Settings.
- Click Libraries and specify the Project Library name or Global Library name. Alternatively, you can specify project libraries with SEARCH_PATH in the .qsf, and global libraries in the quartus2.ini file.
Specify timing constraints in the Timing Analyzer (Tools > Timing Analyzer), or in an .sdc file. Specify constraints for clock characteristics, timing exceptions, and external signal setup and hold times before running analysis. Timing Analyzer reports the detailed information about the performance of your design compared with constraints in the Compilation Report panel.
Save the constraints you specify in the GUI in an industry-standard Synopsys Design Constraints File (.sdc). You can subsequently edit the text-based .sdc file directly. If you refer to multiple .sdc files in a parent .sdc file, the Timing Analyzer reads the .sdc files in the order you list.
The Intel® Quartus® Prime software installation includes the Intel® FPGA IP library. Integrate optimized and verified Intel® FPGA IP cores into your design to shorten design cycles and maximize performance. The Intel® Quartus® Prime software also supports integration of IP cores from other sources. Use the IP Catalog (Tools > IP Catalog) to efficiently parameterize and generate synthesis and simulation files for your custom IP variation. The Intel® FPGA IP library includes the following types of IP cores:
- Basic functions
- DSP functions
- Interface protocols
- Low power functions
- Memory interfaces and controllers
- Processors and peripherals
This document provides basic information about parameterizing, generating, upgrading, and simulating stand-alone IP cores in the Intel® Quartus® Prime software.
- Filter IP Catalog to Show IP for active device family or Show IP for all device families. If you have no project open, select the Device Family in IP Catalog.
- Type in the Search field to locate any full or partial IP core name in IP Catalog.
- Right-click an IP core name in IP Catalog to display details about supported devices, to open the IP core's installation folder, and for links to IP documentation.
- Click Search for Partner IP to access partner IP information on the web.
The parameter editor generates a top-level Quartus IP file (.qip) for an IP variation in Intel® Quartus® Prime Standard Edition projects. These files represent the IP variation in the project, and store parameterization information.
- Use the Presets window to apply preset parameter values for specific applications (for select cores).
- Use the Details window to view port and parameter descriptions, and click links to documentation.
- Click Generate > Generate Testbench System to generate a testbench system (for select cores).
- Click Generate > Generate Example Design to generate an example design (for select cores).
The IP Catalog is also available in Platform Designer (View > IP Catalog). The Platform Designer IP Catalog includes exclusive system interconnect, video and image processing, and other system-level IP that are not available in the Intel® Quartus® Prime IP Catalog. Refer to Creating a System with Platform Designer or Creating a System with Platform Designer (Standard) for information on use of IP in Platform Designer (Standard) and Platform Designer, respectively.
The Intel® Quartus® Prime software installs IP cores in the following locations by default:
|<drive>:\intelFPGA_pro\quartus\ip\altera||Intel® Quartus® Prime Pro Edition||Windows®|
|<drive>:\intelFPGA\quartus\ip\altera||Intel® Quartus® Prime Standard Edition||Windows|
|<home directory>:/intelFPGA_pro/quartus/ip/altera||Intel® Quartus® Prime Pro Edition||Linux®|
|<home directory>:/intelFPGA/quartus/ip/altera||Intel® Quartus® Prime Standard Edition||Linux|
- Simulate the behavior of a licensed Intel® FPGA IP core in your system.
- Verify the functionality, size, and speed of the IP core quickly and easily.
- Generate time-limited device programming files for designs that include IP cores.
- Program a device with your IP core and verify your design in hardware.
Intel® FPGA IP Evaluation Mode supports the following operation modes:
- Tethered—Allows running the design containing the licensed Intel® FPGA IP indefinitely with a connection between your board and the host computer. Tethered mode requires a serial joint test action group (JTAG) cable connected between the JTAG port on your board and the host computer, which is running the Intel® Quartus® Prime Programmer for the duration of the hardware evaluation period. The Programmer only requires a minimum installation of the Intel® Quartus® Prime software, and requires no Intel® Quartus® Prime license. The host computer controls the evaluation time by sending a periodic signal to the device via the JTAG port. If all licensed IP cores in the design support tethered mode, the evaluation time runs until any IP core evaluation expires. If all of the IP cores support unlimited evaluation time, the device does not time-out.
- Untethered—Allows running the design containing the licensed IP for a limited time. The IP core reverts to untethered mode if the device disconnects from the host computer running the Intel® Quartus® Prime software. The IP core also reverts to untethered mode if any other licensed IP core in the design does not support tethered mode.
When the evaluation time expires for any licensed Intel® FPGA IP in the design, the design stops functioning. All IP cores that use the Intel® FPGA IP Evaluation Mode time out simultaneously when any IP core in the design times out. When the evaluation time expires, you must reprogram the FPGA device before continuing hardware verification. To extend use of the IP core for production, purchase a full production license for the IP core.
You must purchase the license and generate a full production license key before you can generate an unrestricted device programming file. During Intel® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit.
Intel® licenses IP cores on a per-seat, perpetual basis. The license fee includes first-year maintenance and support. You must renew the maintenance contract to receive updates, bug fixes, and technical support beyond the first year. You must purchase a full production license for Intel® FPGA IP cores that require a production license, before generating programming files that you may use for an unlimited time. During Intel® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit. To obtain your production license keys, visit the Self-Service Licensing Center or contact your local Intel FPGA representative.
The Intel® FPGA Software License Agreements govern the installation and use of licensed IP cores, the Intel® Quartus® Prime design software, and all unlicensed IP cores.
- In the IP Catalog (Tools > IP Catalog), locate and double-click the name of the IP core to customize. The parameter editor appears.
- Specify a top-level name and output HDL file type for your IP variation. This name identifies the IP core variation files in your project. Click OK. Do not include spaces in IP variation names or paths.
- Specify the parameters and options for your IP variation in the parameter editor. Refer to your IP core user guide for information about specific IP core parameters.
Generate (depending on the parameter editor
version). The parameter editor generates the files for your IP variation
according to your specifications. Click
Exit if prompted when generation is complete.
The parameter editor adds the top-level
.qip file to the current project
Note: For devices released prior to Intel® Arria® 10 devices, the generated .qip and .sip files must be added to your project to represent IP and Platform Designer systems. To manually add an IP variation generated with legacy parameter editor to a project, click Project > Add/Remove Files in Project and add the IP variation .qip file.
|File > Open||Select the top-level HDL (.v, or .vhd) IP variation file to launch the parameter editor and modify the IP variation. Regenerate the IP variation to implement your changes.|
|View > Utility Windows > Project Navigator > IP Components||Double-click the IP variation to launch the parameter editor and modify the IP variation. Regenerate the IP variation to implement your changes.|
|Project > Upgrade IP Components||Select the IP variation and click Upgrade in Editor to launch the parameter editor and modify the IP variation. Regenerate the IP variation to implement your changes.|
Icons in the Upgrade IP Components dialog box indicate when IP upgrade is required, optional, or unsupported for an IP variation in the project. Upgrade IP variations that require upgrade before compilation in the current version of the Intel® Quartus® Prime software.
|IP Core Status||Description|
||Indicates that your IP variation uses the latest version of the Intel® FPGA IP core.|
|IP Component Outdated
||Indicates that your IP variation uses an outdated version of the IP core.|
|IP Upgrade Optional
||Indicates that upgrade is optional for this IP variation in the current version of the Intel® Quartus® Prime software. You can upgrade this IP variation to take advantage of the latest development of this IP core. Alternatively, you can retain previous IP core characteristics by declining to upgrade. Refer to the Description for details about IP core version differences. If you do not upgrade the IP, the IP variation synthesis and simulation files are unchanged and you cannot modify parameters until upgrading.|
|IP Upgrade Required
||Indicates that you must upgrade the IP variation before compiling in the current version of the Intel® Quartus® Prime software. Refer to the Description for details about IP core version differences.|
|IP Upgrade Unsupported
||Indicates that upgrade of the IP variation is not supported in the current version of the Intel® Quartus® Prime software due to incompatibility with the current version of the Intel® Quartus® Prime software. The Intel® Quartus® Prime software prompts you to replace the unsupported IP core with a supported equivalent IP core from the IP Catalog. Refer to the Description for details about IP core version differences and links to Release Notes.|
|IP End of Life
||Indicates that Intel designates the IP core as end-of-life status. You may or may not be able to edit the IP core in the parameter editor. Support for this IP core discontinues in future releases of the Intel® Quartus® Prime software.|
|IP Upgrade Mismatch Warning
||Provides warning of non-critical IP core differences in migrating IP to another device family.|
| IP has incompatible subcores
||Indicates that the current version of the Intel® Quartus® Prime software does not support compilation of your IP variation, because the IP has incompatible subcores|
|Compilation of IP Not Supported
||Indicates that the current version of the Intel® Quartus® Prime software does not support compilation of your IP variation. This can occur if another edition of the Intel® Quartus® Prime software generated this IP. Replace this IP component with a compatible component in the current edition.|
Follow these steps to upgrade IP cores:
In the latest version of the
Quartus® Prime software, open the
Quartus® Prime project containing an outdated IP core variation. The
Upgrade IP Components dialog box
automatically displays the status of IP cores in your project, along with
instructions for upgrading each core. To access this dialog box manually, click
Project > Upgrade IP Components.
- To upgrade one or more IP cores that support automatic upgrade, ensure that you turn on the Auto Upgrade option for the IP cores, and click Perform Automatic Upgrade. The Status and Version columns update when upgrade is complete. Example designs that any Intel® FPGA IP core provides regenerate automatically whenever you upgrade an IP core.
To manually upgrade an individual IP core, select the IP core
and click Upgrade in Editor (or simply
double-click the IP core name). The parameter editor opens, allowing you to
adjust parameters and regenerate the latest version of the IP core.
Figure 19. Upgrading IP Cores
Note: Intel® FPGA IP cores older than Intel® Quartus® Prime software version 12.0 do not support upgrade. Intel verifies that the current version of the Intel® Quartus® Prime software compiles the previous two versions of each IP core. The Intel® FPGA IP Core Release Notes reports any verification exceptions for Intel® FPGA IP cores. Intel does not verify compilation for IP cores older than the previous two releases.
- To upgrade a single IP core at the command-line, type the following command:
quartus_sh –ip_upgrade –variation_files <my_ip>.<qsys,.v, .vhd> <quartus_project> Example: quartus_sh -ip_upgrade -variation_files mega/pll25.qsys hps_testx
- To simultaneously upgrade multiple IP cores at the command-line, type the
quartus_sh –ip_upgrade –variation_files “<my_ip1>.<qsys,.v, .vhd>>; <my_ip_filepath/my_ip2>.<hdl>” <quartus_project> Example: quartus_sh -ip_upgrade -variation_files "mega/pll_tx2.qsys;mega/pll3.qsys" hps_testx
- To display the IP cores that require migration, click Project > Upgrade IP Components. The Description field provides migration instructions and version differences.
- To migrate one or more IP cores that support automatic upgrade, ensure that the Auto Upgrade option is turned on for the IP cores, and click Perform Automatic Upgrade. The Status and Version columns update when upgrade is complete.
- To migrate an IP core that does not support automatic upgrade, double-click the IP core name, and click OK. The parameter editor appears. If the parameter editor specifies a Currently selected device family, turn off Match project/default, and then select the new target device family.
- Click Generate HDL, and confirm the Synthesis and Simulation file options. Verilog HDL is the default output file format. If you specify VHDL as the output format, select VHDL to retain the original output format.
- Click Finish to complete migration of the IP core. Click OK if the software prompts you to overwrite IP core files. The Device Family column displays the new target device name when migration is complete.
To ensure correctness, review the latest parameters in the
parameter editor or generated HDL.
Note: IP migration may change ports, parameters, or functionality of the IP variation. These changes may require you to modify your design or to re-parameterize your IP variant. During migration, the IP variation's HDL generates into a library that is different from the original output location of the IP core. Update any assignments that reference outdated locations. If a symbol in a supporting Block Design File schematic represents your upgraded IP core, replace the symbol with the newly generated <my_ip> .bsf. Migration of some IP cores requires installed support for the original and migration device families.
The Intel® Quartus® Prime software provides integration with many simulators and supports multiple simulation flows, including your own scripted and custom simulation flows. Whichever flow you choose, IP core simulation involves the following steps:
- Generate simulation model, testbench (or example design), and simulator setup script files.
- Set up your simulator environment and any simulation scripts.
- Compile simulation model libraries.
- Run your simulator.
- To specify your supported simulator and options for IP simulation file generation, click Assignment > Settings > EDA Tool Settings > Simulation.
- To parameterize a new IP variation, enable generation of simulation files, and generate the IP core synthesis and simulation files, click Tools > IP Catalog.
- To edit parameters and regenerate synthesis or simulation files for an existing IP core variation, click View > Utility Windows > Project Navigator > IP Components.
|File Type||Description||File Name|
|Simulator setup scripts||Vendor-specific scripts to compile, elaborate, and simulate Intel® FPGA IP models and simulation model library files. Optionally, generate a simulator setup script for each vendor that combines the individual IP core scripts into one file. Source the combined script from your top-level simulation script to eliminate script maintenance.||
|Simulation IP File ( Intel® Quartus® Prime Standard Edition)||Contains IP core simulation library mapping information. To use NativeLink, add the .qip and .sip files generated for IP to your project.||<design name>.sip|
|IP functional simulation models ( Intel® Quartus® Prime Standard Edition)||IP functional simulation models are cycle-accurate VHDL or Verilog HDL models a that the Intel® Quartus® Prime software generates for some Intel FPGA IP cores. IP functional simulation models support fast functional simulation of IP using industry-standard VHDL and Verilog HDL simulators.||
|IEEE encrypted models ( Intel® Quartus® Prime Standard Edition)||Intel provides Arria® V, Cyclone® V, Stratix® V, and newer simulation model libraries and IP simulation models in Verilog HDL and IEEE-encrypted Verilog HDL. Your simulator's co-simulation capabilities support VHDL simulation of these models. IEEE encrypted Verilog HDL models are significantly faster than IP functional simulation models. The Intel® Quartus® Prime Pro Edition software does not support these models.||<my_ip>.v|
- Click Project > Upgrade IP Components > Generate Simulator Script for IP (or run the ip-setup-simulation utility) to generate or regenerate a combined simulator setup script for all IP for each simulator.
Use the templates in the generated script to source the
combined script in your top-level simulation script. Each simulator's combined
script file contains a rudimentary template that you adapt for integration of
the setup script into a top-level simulation script.
This technique eliminates manual update of simulation scripts if you modify or upgrade the IP variation.
- Generation of simulator-specific files and simulation scripts.
- Compilation of simulation libraries.
- Launches your simulator automatically following Intel® Quartus® Prime Analysis & Elaboration, Analysis & Synthesis, or after a full compilation.
- Open an Intel® Quartus® Prime Standard Edition project.
Click Tools > Options and specify the location
of your simulator executable file.
Table 11. Execution Paths for EDA Simulators Simulator Path Mentor Graphics ModelSim-AE <drive letter>:\<simulator install path>\win32aloem (Windows)
/<simulator install path>/bin (Linux)
Mentor Graphics ModelSim Mentor Graphics QuestaSim <drive letter>:\<simulator install path>\win32 (Windows)
<simulator install path>/bin (Linux)
Synopsys VCS/VCS MX <simulator install path>/bin (Linux) Cadence Incisive Enterprise <simulator install path>/tools/bin (Linux) Aldec Active-HDL Aldec Riviera-PRO <drive letter>:\<simulator install path>\bin (Windows)
<simulator install path>/bin (Linux)
- Click Assignments > Settings and specify options on the Simulation page and the More NativeLink Settings dialog box. Specify default options for simulation library compilation, netlist and tool command script generation, and for launching RTL or gate-level simulation automatically following compilation.
- If your design includes a testbench, turn on Compile test bench. Click Test Benches to specify options for each testbench. Alternatively, turn on Use script to compile testbench and specify the script file.
- To use a script to setup a simulation, turn on Use script to setup simulation.
- Turn on the Generate Simulation Model option when parameterizing the IP core.
When you simulate your design, compile only the .vo or .vho for these IP cores
in your simulator. Do not compile the corresponding HDL file. The encrypted HDL
file supports synthesis by only the
- Intel® FPGA IP cores that do not require IP functional simulation models for simulation, do not provide the Generate Simulation Model option in the IP core parameter editor.
- Many recently released Intel® FPGA IP cores support RTL simulation using IEEE Verilog HDL encryption. IEEE encrypted models are significantly faster than IP functional simulation models. Simulate the models in both Verilog HDL and VHDL designs.
The area and timing estimation netlist describes the IP core connectivity and architecture, but does not include details about the true functionality. This information enables certain third-party synthesis tools to better report area and timing estimates. In addition, synthesis tools can use the timing information to achieve timing-driven optimizations and improve the quality of results.
The Intel® Quartus® Prime software generates the <variant name>_syn.v netlist file in Verilog HDL format, regardless of the output file format you specify. If you use this netlist for synthesis, you must include the IP core wrapper file <variant name> .v or <variant name> .vhd in your Intel® Quartus® Prime project.
module MF_top (a, b, sel, datab, clock, result); input [31:0] a, b, datab; input clock, sel; output [31:0] result; wire [31:0] wire_dataa; assign wire_dataa = (sel)? a : b; altfp_mult inst1 (.dataa(wire_dataa), .datab(datab), .clock(clock), .result(result)); defparam inst1.pipeline = 11, inst1.width_exp = 8, inst1.width_man = 23, inst1.exception_handling = "no"; endmodule
library ieee; use ieee.std_logic_1164.all; library altera_mf; use altera_mf.altera_mf_components.all; entity MF_top is port (clock, sel : in std_logic; a, b, datab : in std_logic_vector(31 downto 0); result : out std_logic_vector(31 downto 0)); end entity; architecture arch_MF_top of MF_top is signal wire_dataa : std_logic_vector(31 downto 0); begin wire_dataa <= a when (sel = '1') else b; inst1 : altfp_mult generic map ( pipeline => 11, width_exp => 8, width_man => 23, exception_handling => "no") port map ( dataa => wire_dataa, datab => datab, clock => clock, result => result); end arch_MF_top;
The Intel® Quartus® Prime software manages EDA tool files and provides the following integration capabilities:
- Automatically generate files for synthesis and simulation and automatically launch other EDA tools (Assignments > Settings > EDA Tool Settings > NativeLink Settings ). The Intel® Quartus® Prime Pro Edition software does not support NativeLink.
- Compile all RTL and gate-level simulation model libraries for your device, simulator, and design language automatically (Tools > Launch Simulation Library Compiler).
- Include files generated by other EDA design entry or synthesis tools in your project as synthesized design files (Project > Add/Remove File from Project) .
- Automatically generate optional files for board-level verification (Assignments > Settings > EDA Tool Settings).
The Intel® Quartus® Prime software maintains a database of compilation results for each project revision. The database file stores the compilation results. Do not edit these files directly. However, you can use the database files in the following ways:
- Preserve compilation results for migration to a new version of the Intel® Quartus® Prime software. Export a post-synthesis or post-fit, version-compatible database (Project > Export Database), and then import it into a newer version of the Intel® Quartus® Prime software (Project > Import Database), or into another project.
- Optimize and lock down the compilation results for individual blocks. Export the post-synthesis or post-fit netlist as a Intel® Quartus® Prime Exported Partition File (.qxp) (Project > Export Design Partition). You can then import the partition as a new project design file.
- Purge the content of the project database (Project > Clean Project) to remove unwanted previous compilation results at any time.
- Project Files—project settings (.qsf, quartus2.ini), design files, and timing constraints (.sdc). Any setting that changes the number of processors during compilation can impact compilation results.
- Hardware—CPU architecture, not including hard disk or memory size differences. Windows XP x32 results are not identical to Windows XP x64 results. Linux x86 results is not identical to Linux x86_64.
- Intel® Quartus® Prime Software Version—including build number and installed interim updates. Click Help > About to obtain this information.
- Operating System—Windows or Linux operating system, excluding version updates. For example, Windows XP, Windows Vista, and Windows 7 results are identical. Similarly, Linux RHEL, CentOS 4, and CentOS 5 results are identical.
To preserve compilation results for migration to a newer version of the Intel® Quartus® Prime software, export a version-compatible database file, and then import it into the later version of the Intel® Quartus® Prime software.
- Open the project for exporting the compilation results in the Intel® Quartus® Prime software.
- Generate the project
database and netlist with one of the following:
- Click Processing > Start > Start Analysis & Synthesis to generate a post-synthesis netlist.
- Click Processing > Start Compilation to generate a post-fit netlist.
- Click Project > Export Database and specify the Export directory.
- In a newer version of the Intel® Quartus® Prime software, click New Project Wizard and create a new project with the same top-level design entity name as the database.
- Click Project > Import Database and select the
<project directory>/export_db/ exported database
Quartus® Prime software opens the
compiled project and displays compilation results.
The Timing analysis mode option is only available for Intel® Arria® 10 designs. The option disables legality checks for certain configuration rules that may have changed from prior versions of the Intel® Quartus® Prime software. Use this option only if you cannot successfully import your design without it. After you have imported a design in timing analysis mode, you cannot use it to generate programming files.
- Click Project > Clean Project.
- Select All revisions to remove the databases for all revisions of the current project, or specify a Revision name to remove only that revision’s database.
- Click OK. A message indicates when the database is clean.
The .qar preserves logic design, project, and settings files required to restore the project.
Use this technique to share projects between designers, or to transfer your project to a new version of the Intel® Quartus® Prime software, or to Intel support. Optionally add compilation results, Platform Designer (Standard) system files, and third-party EDA tool files to the archive. If you restore the archive in a different version of the Intel® Quartus® Prime software, you must include the original .qdf in the archive to preserve original compilation results.
- Click Project > Archive Project and specify the archive file name.
- Click Advanced.
- Select the File set for archive or select Custom. Turn on File subsets for archive.
- Click Add and select Platform Designer (Standard) system or EDA tool files. Click OK.
- Click Archive.
- Export the project database.
- Click Project > Archive Project and specify the archive file name.
- Click Advanced.
- Under File subsets, turn on Version-compatible database files and click OK.
- Click Archive.
To restore an archive containing a version-compatible database, follow these steps:
- Click Project > Restore Archived Project.
- Select the archive name and destination folder and click OK.
- After restoring the archived project, click Project > Import Database and import the version-compatible database.
To identify and include appropriate archive files for an Intel service request:
- Click Project > Archive Project and specify the archive file name.
- Click Advanced.
- In File
set, select Service
request to include files for Intel Support.
- Project source and setting files (.v, .vhd, .vqm, .qsf, .sdc, .qip, .qpf, .cmp)
- Automatically detected source files (various)
- Programming output files (.jdi, .sof, .pof)
- Report files (.rpt, .pin, .summary, .smsg)
- Platform Designer system and IP files (.qsys, .qip)
- Click OK, and then click Archive.
While Intel® Quartus® Prime project revisions preserve various project setting and constraint combinations, external revision control systems can also track and merge RTL source code, simulation testbenches, and build scripts. External revision control supports design file version experimentation through branching and merging different versions of source code from multiple designers. Refer to your external revision control documentation for setup information.
- Logic design files (.v, .vdh, .bdf, .edf, .vqm)
- Timing constraint files (.sdc)
- Quartus project settings and constraints (.qdf, .qpf, .qsf)
- IP files (.ip, .v, .sv, .vhd, .qip, .sip, .qsys)
- Platform Designer (Standard)-generated files (.qsys, .ip, .sip)
- EDA tool files (.vo, .vho )
Generate or modify these files manually if you use a scripted design flow. If you use an external source code control system, check-in project files anytime you modify assignments and settings.
- Use appropriate case for your platform in file path references.
- Use a character set common to both platforms.
- Do not change the forward‑slash (/) and back‑slash (\) path separators in the .qsf. The Intel® Quartus® Prime software automatically changes all back‑slash (\) path separators to forward‑slashes (/ )in the .qsf.
- Observe the target platform’s file name length limit.
- Use underscore instead of spaces in file and directory names.
- Change library absolute path references to relative paths in the .qsf.
- Ensure that any external project library exists in the new platform’s file system.
- Specify file and directory paths as relative to the project directory. For example, for a project titled foo_design, specify the source files as: top.v, foo_folder /foo1.v, foo_folder /foo2.v, and foo_folder/bar_folder/bar1.vhdl.
- Ensure that all the subdirectories are in the same hierarchical structure and relative path as in the original platform.
For example, in the directory structure shown you can specify top.v as ../source/top.v and foo1.v as ../source/foo_folder/foo1.v.
- The project directory takes precedence over the project libraries.
- For Linux, the Intel® Quartus® Prime software creates the file in the altera.quartus directory under the <home> directory.
- All library files are relative to the libraries. For example, if you specify the user_lib1 directory as a project library and you want to add the /user_lib1/foo1.v file to the library, you can specify the foo1.v file in the .qsf as foo1.v. The Intel® Quartus® Prime software includes files in specified libraries.
- If the directory is outside of the project directory, an absolute path is created by default. Change the absolute path to a relative path before migration.
- When copying projects that
include libraries, you must either copy your project library files along with
the project directory or ensure that your project library files exist in the
- On Windows, the Intel® Quartus® Prime software searches for the quartus2.ini file in the following directories and order:
- USERPROFILE, for example, C:\Documents and Settings\<user name>
- Directory specified by the TMP environmental variable
- Directory specified by the TEMP environmental variable
- Root directory, for example, C:\
- Create a text file with the extension.tcl that contains your assignments in Tcl format.
- Source the Tcl script file by adding the following line to the .qsf: set_global_assignment -name SOURCE_TCL_SCR IPT_FILE <file name> .
create_revision <name> -based_on <revision_name> -copy_results -set_current
|based_on (optional)||Specifies the revision name on which the new revision bases its settings.|
|copy_results||Copies the results from the "based_on" revision.|
|set_current (optional)||Sets the new revision as the current revision.|
The -force option enables you to open the revision that you specify under revision name and overwrite the compilation database if the database version is incompatible.
set_current_revision -force <revision name>
delete_revision <revision name>
Use the following command to create a Intel® Quartus® Prime archive:
You can specify the following other options:
- -all_revisions - Includes all revisions of the current project in the archive.
- -auto_common_directory - Preserves original project directory structure in archive
- -common_directory /<name> - Preserves original project directory structure in specified subdirectory
- -include_libraries - Includes libraries in archive
- -include_outputs - Includes output files in archive
- -use_file_set <file_set> - Includes specified fileset in archive
- -version_compatible_database - Includes version-compatible database files in archive
Use the following Tcl command to restore a Quartus project:
project_restore <name>.qar -destination restored -overwrite
This example restores to a destination directory named "restored".
Use the following commands for managing Quartus project databases :
Use the following commands to import or export a version-compatible database:
- import_database <directory>
- export_database <directory>
The following are Tcl commands from the flow package to import or export version-compatible databases. If you use the flow package, you must specify the database directory variable name. flow and database_manager packages contain commands to manage version‑compatible databases.
- set_global_assignment -name VER_COMPATIBLE_DB_DIR <directory>
- execute_flow –flow export_database
- execute_flow –flow import_database
Use the following commands to generate a version-compatible database after compilation:
- set_global_assignment -name AUTO_EXPORT_VER_COMPATIBLE_DB ON
- set_global_assignment-name VER_COMPATIBLE_DB_DIR <directory>
Use the following commands to manage version-compatible databases:
- quartus_cdb <project> -c <revision> --export_database=<directory>
- quartus_cdb <project> -c <revision> --import_database=<directory>
- quartus_sh –flow export_database <project> -c \ <revision>
- quartus_sh –flow import_database <project> -c \ <revision>
In Tcl, use commands in the :: quartus ::project package to specify project libraries, and the set_global_assignment command.
Use the following commands to script project library changes:
- set_global_assignment -name SEARCH_PATH "../other_dir/library1"
- set_global_assignment -name SEARCH_PATH "../other_dir/library2"
- set_global_assignment -name SEARCH_PATH "../other_dir/library3"
To report any project libraries specified for a project and any global libraries specified for the current installation of the Quartus software, use the get_global_assignment and get_user_option Tcl commands.
Use the following commands to report specified project libraries:
- get_global_assignment -name SEARCH_PATH
- get_user_option -name SEARCH_PATH
|2016.05.03||16.0.0||Removed statements about serial equivalence when using multiple processors.|
|2015.11.02||15.1.0||Changed instances of Quartus II to Intel® Quartus® Prime .|
|November 2011||10.1.1||Template update.|
Before reading the design planning guidelines discussed in this chapter, consider your design priorities. More device features, density, or performance requirements can increase system cost. Signal integrity and board issues can impact I/O pin locations. Power, timing performance, and area utilization all affect each other. Compilation time is affected when optimizing these priorities.
The Intel® Quartus® Prime software optimizes designs for the best overall results; however, you can change the settings to better optimize one aspect of your design, such as power utilization. Certain tools or debugging options can lead to restrictions in your design flow. Your design priorities help you choose the tools, features, and methodologies to use for your design.
After you select a device family, to check if additional guidelines are available, refer to the design guidelines section of the appropriate device documentation.
In addition, creating a test plan helps you to design for verification and ease of manufacture. For example, you might need to validate interfaces incorporated in your design. To perform any built-in self-test functions to drive interfaces, you can use a UART interface with a Nios® II processor inside the FPGA device.
If more than one designer works on your design, you must consider a common design directory structure or source control system to make design integration easier. Consider whether you want to standardize on an interface protocol for each design block.
The Intel® FPGA IP Evaluation Mode, which is available for many IP cores, allows you to program the FPGA to verify your design in the hardware before you purchase the IP license. The evaluation supports the following modes:
- Untethered—the design runs for a limited time.
- Tethered—the design requires an Intel serial JTAG cable connected between the JTAG port on your board and a host computer running the Intel® Quartus® Prime Programmer for the duration of the hardware evaluation period.
Because system design tools change the design entry methodology, you must plan to start developing your design within the tool. Ensure all design blocks use appropriate standard interfaces from the beginning of the design cycle so that you do not need to make changes later.
Platform Designer (Standard) components use Avalon® standard interfaces for the physical connection of components, and you can connect any logical device (either on-chip or off-chip) that has an Avalon interface. The Avalon Memory-Mapped interface allows a component to use an address mapped read or write protocol that enables flexible topologies for connecting master components to any slave components. The Avalon Streaming interface enables point-to-point connections between streaming components that send and receive data using a high-speed, unidirectional system interconnect between source and sink ports.
In addition to enabling the use of a system integration tool such as Platform Designer (Standard), using standard interfaces ensures compatibility between design blocks from different design teams or vendors. Standard interfaces simplify the interface logic to each design block and enable individual team members to test their individual design blocks against the specification for the interface protocol to ease system integration.
Choose the device family that best suits your design requirements. Families differ in cost, performance, logic and memory density, I/O density, power utilization, and packaging. You must also consider feature requirements, such as I/O standards support, high-speed transceivers, global or regional clock networks, and the number of phase-locked loops (PLLs) available in the device.
Each device family has complete documentation, including a data sheet, which documents device features in detail. You can also see a summary of the resources for each device in the Device dialog box in the Intel® Quartus® Prime software.
Carefully study the device density requirements for your design. Devices with more logic resources and higher I/O counts can implement larger and more complex designs, but at a higher cost. Smaller devices use lower static power. Select a device larger than what your design requires if you want to add more logic later in the design cycle to upgrade or expand your design, and reserve logic and memory for on-chip debugging. Consider requirements for types of dedicated logic blocks, such as memory blocks of different sizes, or digital signal processing (DSP) blocks to implement certain arithmetic functions.
If you have older designs that target an Intel device, you can use their resources as an estimate for your design. Compile existing designs in the Intel® Quartus® Prime software with the Auto device selected by the Fitter option in the Settings dialog box. Review the resource utilization to learn which device density fits your design. Consider coding style, device architecture, and the optimization options used in the Intel® Quartus® Prime software, which can significantly affect the resource utilization and timing performance of your design.
Selecting a migration device impacts pin placement because some pins may serve different functions in different device densities or package sizes. If you make pin assignments in the Intel® Quartus® Prime software, the Pin Migration View in the Pin Planner highlights pins that change function between your migration devices.
You can select a development kit for your new Intel® Quartus® Prime project from the New Project Wizard, or for an existing project by clicking Assignments > Device.
Follow the steps below to select a development kit for a new Intel® Quartus® Prime project:
- To open the New Project Wizard, click File > New Project Wizard.
- Click the Board tab from Family, Device & Board Settings page.
- Select the Family and Development Kit lists to narrow your board search. The Available boards table lists all the available boards for the selected Family and Development Kit type.
- To view the development kit details for each of the listed boards, click the icons to the left of the boards in the Available boards table. The Development Kit Details dialog box appears, displaying all the board details.
- Select the desired board from the Available boards table.
- To set the selected board design as top-level entity, click the Create top-level design file checkbox. This option automatically sets up the pin assignments for the selected board. If you choose to uncheck this option, the Intel® Quartus® Prime software creates the design for the board and stores the design in <current_project_dir>/devkits/<design_name>.
Figure 27. Selecting the Desired Board from New Project Wizard
- To open your existing project, click File > Open Project.
- To open the Device Setting Dialog Box, click Assignments > Device.
- Select the desired development kit from the Board tab and click OK.
- If there are existing pin assignments in your current project, a message box appears, prompting to remove all location assignments. Click Yes to remove the Location and I/O Standard pin assignments. The Intel® Quartus® Prime software creates the kit's baseline design and stores the design in <current_project_dir>/devkits/<design_name>. To retain all your existing pin assignments, click No.
Repeat the above steps to change the development kit of an existing project.
The <design_name> folder contains the platform_setup.tcl file that stores all the pin assignments and the baseline example designs for the board. In addition, the Intel® Quartus® Prime software creates a .qdf file in the <current_project_dir> folder, which stores all the default values for the pin assignments.
To manually set up the pin assignments:
- Click View > Utility Windows > Tcl Console.
At the Tcl console command prompt, type the command:
At the Tcl console command prompt, type the command:
setup_projectThis command populates all assignments available in the setup_platform.tcl file to your .qsf file.
The device family documentation describes the configuration options available for a device family. For information about programming CPLD devices, refer to your device documentation.
You must accurately estimate device power consumption to develop an appropriate power budget and to design the power supplies, voltage regulators, heat sink, and cooling system. Power estimation and analysis helps you satisfy two important planning requirements:
- Thermal—ensure that the cooling solution is sufficient to dissipate the heat generated by the device. The computed junction temperature must fall within normal device specifications.
- Power supply—ensure that the power supplies provide adequate current to support device operation.
The Early Power Estimator (EPE) spreadsheet allows you to estimate power utilization for your design.
You can manually enter data into the EPE spreadsheet, or use the Intel® Quartus® Prime software to generate device resource information for your design.
To manually enter data into the EPE spreadsheet, enter the device resources, operating frequency, toggle rates, and other parameters for your design. If you do not have an existing design, estimate the number of device resources used in your design, and then enter the data into the EPE spreadsheet manually.
If you have an existing design or a partially completed design, you can use the Intel® Quartus® Prime software to generate the Early Power Estimator File (.txt, .csv) to assist you in completing the EPE spreadsheet.
The EPE spreadsheet includes the Import Data macro that parses the information in the EPE File and transfers the information into the spreadsheet. If you do not want to use the macro, you can manually transfer the data into the EPE spreadsheet. For example, after importing the EPE File information into the EPE spreadsheet, you can add device resource information. If the existing Intel® Quartus® Prime project represents only a portion of your full design, manually enter the additional device resources you use in the final design.
Estimating power consumption early in the design cycle allows planning of power budgets and avoids unexpected results when designing the PCB.
When you complete your design, perform a complete power analysis to check the power consumption more accurately. The Power Analyzer tool in the Intel® Quartus® Prime software provides an accurate estimation of power, ensuring that thermal and supply limitations are met.
You can create a preliminary pin-out for an Intel FPGA with the Intel® Quartus® Prime Pin Planner before you develop the source code, based on standard I/O interfaces (such as memory and bus interfaces) and any other I/O requirements for your system. The Intel® Quartus® Prime I/O Assignment Analysis checks that the pin locations and assignments are supported in the target FPGA architecture. You can then use I/O Assignment Analysis to validate I/O-related assignments that you create or modify throughout the design process. When you compile your design in the Intel® Quartus® Prime software, I/O Assignment Analysis runs automatically in the Fitter to validate that the assignments meet all the device requirements and generates error messages.
Early in the design process, before creating the source code, the system architect has information about the standard I/O interfaces (such as memory and bus interfaces), the IP cores in your design, and any other I/O-related assignments defined by system requirements. You can use this information with the Early Pin Planning feature in the Pin Planner to specify details about the design I/O interfaces. You can then create a top-level design file that includes all I/O information.
The Pin Planner interfaces with the IP core parameter editor, which allows you to create or import custom IP cores that use I/O interfaces. You can configure how to connect the functions and cores to each other by specifying matching node names for selected ports. You can create other I/O-related assignments for these interfaces or other design I/O pins in the Pin Planner, as described in this section. The Pin Planner creates virtual pin assignments for internal nodes, so internal nodes are not assigned to device pins during compilation.
After analysis and synthesis of the newly generated top-level wrapper file, use the generated netlist to perform I/O Analysis with the Start I/O Assignment Analysis command.
You can use the I/O analysis results to change pin assignments or IP parameters even before you create your design, and repeat the checking process until the I/O interface meets your design requirements and passes the pin checks in the Intel® Quartus® Prime software. When you complete initial pin planning, you can create a revision based on the Intel® Quartus® Prime-generated netlist. You can then use the generated netlist to develop the top-level design file for your design, or disregard the generated netlist and use the generated Intel® Quartus® Prime Settings File (.qsf) with your design.
During this early pin planning, after you have generated a top-level design file, or when you have developed your design source code, you can assign pin locations and assignments with the Pin Planner.
With the Pin Planner, you can identify I/O banks, voltage reference (VREF) groups, and differential pin pairings to help you through the I/O planning process. If you selected a migration device, the Pin Migration View highlights the pins that have changed functions in the migration device when compared to the currently selected device. Selecting the pins in the Device Migration view cross-probes to the rest of the Pin Planner, so that you can use device migration information when planning your pin assignments. You can also configure board trace models of selected pins for use in “board-aware” signal integrity reports generated with the Enable Advanced I/O Timing option . This option ensures that you get accurate I/O timing analysis. You can use a Microsoft Excel spreadsheet to start the I/O planning process if you normally use a spreadsheet in your design flow, and you can export a Comma-Separated Value File (.csv) containing your I/O assignments for spreadsheet use when you assign all pins.
When you complete your pin planning, you can pass pin location information to PCB designers. The Pin Planner is tightly integrated with certain PCB design EDA tools, and can read pin location changes from these tools to check suggested changes. Your pin assignments must match between the Intel® Quartus® Prime software and your schematic and board layout tools to ensure the FPGA works correctly on the board, especially if you must make changes to the pin-out. The system architect uses the Intel® Quartus® Prime software to pass pin information to team members designing individual logic blocks, allowing them to achieve better timing closure when they compile their design.
Start FPGA planning before you complete the HDL for your design to improve the confidence in early board layouts, reduce the chance of error, and improve the overall time to market of the design. When you complete your design, use the Fitter reports for the final sign-off of pin assignments. After compilation, the Intel® Quartus® Prime software generates the Pin-Out File (.pin), and you can use this file to verify that each pin is correctly connected in board schematics.
Intel provides tools for SSN analysis and estimation, including SSN characterization reports, an Early SSN Estimator (ESE) spreadsheet tool, and the SSN Analyzer in the Intel® Quartus® Prime software. SSN often leads to the degradation of signal integrity by causing signal distortion, thereby reducing the noise margin of a system. You must address SSN with estimation early in your system design, to minimize later board design changes. When your design is complete, verify your board design by performing a complete SSN analysis of your FPGA in the Intel® Quartus® Prime software.
Different synthesis tools may give different results for each design. To determine the best tool for your application, you can experiment by synthesizing typical designs for your application and coding style. Perform placement and routing in the Intel® Quartus® Prime software to get accurate timing analysis and logic utilization results.
The synthesis tool you choose may allow you to create a Intel® Quartus® Prime project and pass constraints, such as the EDA tool setting, device selection, and timing requirements that you specified in your synthesis project. You can save time when setting up your Intel® Quartus® Prime project for placement and routing.
Tool vendors frequently add new features, fix tool issues, and enhance performance for Intel devices, you must use the most recent version of third-party synthesis tools.
Use the simulator version that your Intel® Quartus® Prime software version supports for best results. You must also use the model libraries provided with your Intel® Quartus® Prime software version. Libraries can change between versions, which might cause a mismatch with your simulation netlist.
Using a formal verification tool can impact performance results because performing formal verification requires turning off certain logic optimizations, such as register retiming, and forces you to preserve hierarchy blocks, which can restrict optimization. Formal verification treats memory blocks as black boxes. Therefore, you must keep memory in a separate hierarchy block so other logic does not get incorporated into the black box for verification. If formal verification is important to your design, plan for limitations and restrictions at the beginning of the design cycle rather than make changes later.
In-system debugging tools offer different advantages and trade-offs. A particular debugging tool may work better for different systems and designers. Consider the following debugging requirements when you plan your design:
- JTAG connections—required to perform in-system debugging with JTAG tools. Plan your system and board with JTAG ports that are available for debugging.
- Additional logic resources (ALR)—required to implement JTAG hub logic. If you set up the appropriate tool early in your design cycle, you can include these device resources in your early resource estimations to ensure that you do not overload the device with logic.
- Reserve device memory—required if your tool uses device memory to capture data during system operation. To ensure that you have enough memory resources to take advantage of this debugging technique, consider reserving device memory to use during debugging.
- Reserve I/O pins—required if you use the Logic Analyzer Interface (LAI) or Signal Probe tools, which require I/O pins for debugging. If you reserve I/O pins for debugging, you do not have to later change your design or board. The LAI can multiplex signals with design I/O pins if required. Ensure that your board supports a debugging mode, in which debugging signals do not affect system operation.
- Instantiate an IP core in your HDL code—required if your debugging tool uses an Intel FPGA IP core.
- Instantiate the Signal Tap Logic Analyzer IP core—required if you want to manually
connect the Signal Tap Logic Analyzer to
nodes in your design and ensure that the tapped node names do not change during
Note: You can add the Signal Tap Logic Analyzer as a separate design partition for incremental compilation to minimize recompilation times.
Table 13. Factors to Consider When Using Debugging Tools During Design Planning Stages Design Planning Factor Signal Tap
System Console In-System Memory
Logic Analyzer Interface (LAI) Signal Probe In-System Sources
Virtual JTAG IP Core JTAG connections Yes Yes Yes Yes — Yes Yes Additional logic resources — Yes — — — — Yes Reserve device memory Yes Yes — — — — — Reserve I/O pins — — — Yes Yes — — Instantiate IP core in your HDL code — — — — — Yes Yes
In a synchronous design, a clock signal triggers all events. When you meet all register timing requirements, a synchronous design behaves in a predictable and reliable manner for all process, voltage, and temperature (PVT) conditions. You can easily target synchronous designs to different device families or speed grades.
Clock signals have a large effect on the timing accuracy, performance, and reliability of your design. Problems with clock signals can cause functional and timing problems in your design. Use dedicated clock pins and clock routing for best results, and if you have PLLs in your target device, use the PLLs for clock inversion, multiplication, and division. For clock multiplexing and gating, use the dedicated clock control block or PLL clock switchover feature instead of combinational logic, if these features are available in your device. If you must use internally-generated clock signals, register the output of any combinational logic used as a clock signal to reduce glitches.
The Design Assistant in the Intel® Quartus® Prime software is a design-rule checking tool that enables you to verify design issues. The Design Assistant checks your design for adherence to Intel-recommended design guidelines. You can also use third-party lint tools to check your coding style. The Design Assistant does not support Max 10 and Intel® Arria® 10 devices.
Consider the architecture of the device you choose so that you can use specific features in your design. For example, the control signals should use the dedicated control signals in the device architecture. Sometimes, you might need to limit the number of different control signals used in your design to achieve the best results.
If you design memory and DSP functions, you must understand the target architecture of your device so you can use the dedicated logic block sizes and configurations. Follow the coding guidelines for inferring megafunctions and targeting dedicated device hardware, such as memory and DSP blocks.
Designers commonly use a synchronization chain to minimize the occurrence of metastable events. Ensure that your design accounts for synchronization between any asynchronous clock domains. Consider using a synchronizer chain of more than two registers for high-frequency clocks and frequently-toggling data signals to reduce the chance of a metastability failure.
You can use the Intel® Quartus® Prime software to analyze the average mean time between failures (MTBF) due to metastability when a design synchronizes asynchronous signals, and optimize your design to improve the metastability MTBF. The MTBF due to metastability is an estimate of the average time between instances when metastability could cause a design failure. A high MTBF (such as hundreds or thousands of years between metastability failures) indicates a more robust design. Determine an acceptable target MTBF given the context of your entire system and the fact that MTBF calculations are statistical estimates.
The Intel® Quartus® Prime software can help you determine whether you have enough synchronization registers in your design to produce a high enough MTBF at your clock and data frequencies.
Your source code can have hierarchy, but the Intel® Quartus® Prime software flattens your design during compilation and synthesizes all the design source code and fits in the target device whenever the software recompile your design after any change in your design. By processing the entire design, the software performs all available logic and placement optimizations on the entire design to improve area and performance. You can use debugging tools in an incremental design flow, such as the Signal Tap Logic Analyzer, but you do not specify any design partitions to preserve design hierarchy during compilation.
The flat compilation flow is easy to use; you do not have to plan any design partitions. However, because the Intel® Quartus® Prime software recompiles the entire design whenever you change your design, compilation times can be slow for large devices. Additionally, you may find that the results for one part of the design change when you change a different part of your design. You run Rapid Recompile to preserve portions of previous placement and routing in subsequent compilations. This option can reduce your compilation time in a flat or partitioned design when you make small changes to your design.
Incremental compilation preserves the compilation results and performance of unchanged partitions in the design, greatly reducing design iteration time by focusing new compilations on changed design partitions only. Incremental compilation then merges new compilation results with the previous compilation results from unchanged design partitions. Additionally, you can target optimization techniques to specific design partitions, while leaving other partitions unchanged. You can also use empty partitions to indicate that parts of your design are incomplete or missing, while you compile the rest of your design.
Third-party IP designers can also export logic blocks to be integrated into the top-level design. Team members can work on partitions independently, which can simplify the design process and reduce compilation time. With exported partitions, the system architect must provide guidance to designers or IP providers to ensure that each partition uses the appropriate device resources. Because the designs may be developed independently, each designer has no information about the overall design or how their partition connects with other partitions. This lack of information can lead to problems during system integration. The top-level project information, including pin locations, physical constraints, and timing requirements, must be communicated to the designers of lower-level partitions before they start their design.
The system architect plans design partitions at the top level and allows third-party designs to access the top-level project framework. By designing in a copy of the top-level project (or by checking out the project files in a source control environment), the designers of the lower-level block have full information about the entire project, which helps to ensure optimal results.
When you plan your design code and hierarchy, ensure that each design entity is created in a separate file so that the entities remain independent when you make source code changes in the file. If you use a third-party synthesis tool, create separate Verilog Quartus Mapping or EDIF netlists for each design partition in your synthesis tool. You may have to create separate projects in your synthesis tool, so that the tool synthesizes each partition separately and generates separate output netlist files. The netlists are then considered the source files for incremental compilation.
For example, registering partition I/O boundaries keeps critical timing paths inside one partition that can be optimized independently. When you specify the design partitions, you can use the Incremental Compilation Advisor to ensure that partitions meet Intel’s recommendations.
If you have timing-critical partitions that are changing through the design flow, or partitions exported from another Intel® Quartus® Prime project, you can create design floorplan assignments to constrain the placement of the affected partitions. Good partition and floorplan design helps partitions meet top-level design requirements when integrated with the rest of your design, reducing time you spend integrating and verifying the timing of the top-level design.
If you synthesize with the Intel® Quartus® Prime software, you can choose to perform a Fast synthesis, which reduces the compilation time, but may give reduced quality of results.
If you design individual design blocks or partitions separately, you can use the Fast synthesis and early timing estimate features as you develop your design. Any issues highlighted in the lower-level design blocks are communicated to the system architect. Resolving these issues might require allocating additional device resources to the individual partition, or changing the timing budget of the partition.
Expert designers can also use fast synthesis to prototype the entire design. Incomplete partitions are marked as empty in an incremental compilation flow, while the rest of the design is compiled to detect any problems with design integration.
|2016.05.03||16.0.0||Added information about Development Kit selection.|
|2015.11.02||15.1.0||Changed instances of Quartus II to Intel® Quartus® Prime .|
|2015.05.04||15.0.0||Remove support for Early Timing Estimate feature.|
|2014.06.30||14.0.0||Updated document format.|
|November 2013||13.1.0||Removed HardCopy device information.|
|November, 2012||12.1.0||Update for changes to early pin planning feature|
|June 2012||12.0.0||Editorial update.|
|November 2011||11.0.1||Template update.|
The ability to iterate rapidly through FPGA design and debugging stages is critical. The Intel® Quartus® Prime software introduced the FPGA industry’s first true incremental design and compilation flow, with the following benefits:
- Preserves the results and performance for unchanged logic in your design as you make changes elsewhere.
- Reduces design iteration time by an average of 75% for small changes in large designs, so that you can perform more design iterations per day and achieve timing closure efficiently.
- Facilitates modular hierarchical and team-based design flows, as well as design reuse and intellectual property (IP) delivery.
Intel® Quartus® Prime incremental compilation supports the Arria®, Stratix®, and Cyclone® series of devices.
You can use a flat compilation flow for small designs, such as designs in CPLD devices or low-density FPGA devices, when the timing requirements are met easily with a single compilation. A flat design is satisfactory when compilation time and preserving results for timing closure are not concerns.
If you use the incremental compilation feature at any point in your design flow, it is easier to accommodate the guidelines for partitioning a design and creating a floorplan if you start planning for incremental compilation at the beginning of your design cycle.
Incremental compilation is recommended for large designs and high resource densities when preserving results is important to achieve timing closure. The incremental compilation feature also facilitates team-based design flows that allow designers to create and optimize design blocks independently, when necessary.
To take advantage of incremental compilation, start by splitting your design along any of its hierarchical boundaries into design blocks to be compiled incrementally, and set each block as a design partition. The Intel® Quartus® Prime software synthesizes each individual hierarchical design partition separately, and then merges the partitions into a complete netlist for subsequent stages of the compilation flow. When recompiling your design, you can use source code, post-synthesis results, or post-fitting results to preserve satisfactory results for each partition.
In a team-based environment, part of your design may be incomplete, or it may have been developed by another designer or IP provider. In this scenario, you can add the completed partitions to the design incrementally. Alternatively, other designers or IP providers can develop and optimize partitions independently and the project lead can later integrate the partitions into the top-level design.
Impact of Incremental Compilation with Design Partitions
Compilation Time Savings
Typically saves an average of 75% of compilation time for small design changes in large designs when post-fit netlists are preserved; there are savings in both Intel® Quartus® Prime Integrated Synthesis and the Fitter. 1
Excellent performance preservation when timing critical paths are contained within a partition, because you can preserve post‑fitting information for unchanged partitions.
Node Name Preservation
Preserves post‑fitting node names for unchanged partitions.
The area (logic resource utilization) might increase because cross-boundary optimizations are limited, and placement and register packing are restricted.
The design’s maximum frequency might be reduced because cross‑boundary optimizations are limited. If the design is partitioned and the floorplan location assignments are created appropriately, there might be no negative impact on fMAX.
- Achieving timing closure for the full design may be more difficult if you compile partitions independently without information about other partitions in the design. This problem may be avoided by careful timing budgeting and special design rules, such as always registering the ports at the module boundaries.
- Resource budgeting and allocation may be required to avoid resource conflicts and overuse. Creating a floorplan with LogicLock regions is recommended when design partitions are developed independently in separate Intel® Quartus® Prime projects.
- Maintaining consistency of assignments and timing constraints can be more difficult if there are separate Intel® Quartus® Prime projects. The project lead must ensure that the top-level design and the separate projects are consistent in their assignments.
For timing-critical partitions being developed and optimized by another designer, it is important that each designer has complete information about the top-level design in order to maintain timing closure during integration, and to obtain the best results. When you want to integrate partitions from separate Intel® Quartus® Prime projects, the project lead can perform most of the design planning, and then pass the top-level design constraints to the partition designers. Preferably, partition designers can obtain a copy of the top-level design by checking out the required files from a source control system. Alternatively, the project lead can provide a copy of the top-level project framework, or pass design information using Intel® Quartus® Prime-generated design partition scripts. In the case that a third-party designer has no information about the top-level design, developers can export their partition from an independent project if required.
For an interactive introduction to implementing an incremental compilation design flow, refer to the Getting Started Tutorial on the Help menu in the Intel® Quartus® Prime software.
- Elaborate your design, or run any compilation flow (such as a full compilation) that includes the elaboration step. Elaboration is the part of the synthesis process that identifies your design’s hierarchy.
- Designate specific instances in the design hierarchy as design partitions.
- If required for your design flow, create a floorplan with LogicLock regions location assignments for timing-critical partitions that change with future compilations. Assigning a partition to a physical region on the device can help maintain quality of results and avoid conflicts in certain situations.
The Design Partitions window also lists recommendations at the bottom of the window with links to the Incremental Compilation Advisor, where you can view additional recommendations about partitions. The Color column indicates the color of each partition as it appears in the Design Partition Planner and Chip Planner.
You can right-click a partition in the window to perform various common tasks, such as viewing property information about a partition, including the time and date of the compilation netlists and the partition statistics.
When you create a partition, the Intel® Quartus® Prime software automatically generates a name based on the instance name and hierarchy path. You can edit the partition name in the Design Partitions Window so that you avoid referring to them by their hierarchy path, which can sometimes be long. This is especially useful when using command-line commands or assignments, or when you merge partitions to give the partition a meaningful name. Partition names can be from 1 to 1024 characters in length and must be unique. The name can consist of alphanumeric characters and the pipe ( | ), colon ( : ), and underscore ( _ ) characters.
The Design Partition Planner displays a visual representation of design connectivity and hierarchy, as well as partitions and entity relationships. You can explore the connectivity between entities in the design, evaluate existing partitions with respect to connectivity between entities, and try new partitioning schemes in "what if" scenarios.
When you extract design blocks from the top-level design and drag them into the Design Partition Planner, connection bundles are drawn between entities, showing the number of connections existing between pairs of entities. In the Design Partition Planner, you can then set extracted design blocks as design partitions.
The Design Partition Planner also has an Auto-Partition feature that creates partitions based on the size and connectivity of the hierarchical design blocks.
Use the flow in this example to update the source file in one partition without having to recompile the other parts of the design. To reduce the compilation time, instruct the software to reuse the post-fit netlists for the unchanged partitions. This flow also preserves the performance of these blocks, which reduces additional timing closure efforts.
Perform the following steps to update a single source file:
- Apply and save the fix to the HDL source file.
- On the Assignments menu, open the Design Partitions window.
- Change the netlist type of
each partition, including the top-level entity, to
to preserve as much as possible for the next compilation.
- The Intel® Quartus® Prime software recompiles partitions by default when changes are detected in a source file. You can refer to the Partition Dependent Files table in the Analysis and Synthesis report to determine which partitions were recompiled. If you change an assignment but do not change the logic in a source file, you can set the netlist type to Source File for that partition to instruct the software to recompile the partition's source design files and its assignments.
- Click Start Compilation to incrementally compile the fixed HDL code. This compilation should take much less time than the initial full compilation.
- Simulate the design to ensure that the error is fixed, and use the Timing Analyzer report to ensure that timing results have not degraded.
Use the flow in this example to optimize the results of one partition when the other partitions in the design have already met their requirements. You can use this flow iteratively to lock down the performance of one partition, and then move on to optimization of another partition.
Perform the following steps to preserve the results for partitions that meet their timing requirements, and to recompile a timing-critical partition with new optimization settings:
- Open the Design Partitions window.
- For the partition in question, set the
netlist type to Source File.
- If you change a setting that affects only the Fitter, you can save additional compilation time by setting the netlist type to Post-Synthesis to reuse the synthesis results and refit the partition.
- For the remaining partitions (including
the top-level entity), set the netlist type to Post-Fit.
- You can optionally set the Fitter Preservation Level on the Advanced tab in the Design Partitions Properties dialog box to Placement to allow for the most flexibility during routing.
- Apply the desired optimization settings.
- Click Start Compilation to perform incremental compilation on the design with the new settings. During this compilation, the Partition Merge stage automatically merges the critical partition’s new synthesis netlist with the post-fit netlists of the remaining partitions. The Fitter then refits only the required partition. Because the effort is reduced as compared to the initial full compilation, the compilation time is also reduced.
- Repeat steps 1–3 of the previous procedure.
- Save the project and run Design Space Explorer II.
Use this flow to compile a timing-critical partition or partitions in isolation, optionally with extra optimizations turned on. After timing closure is achieved for the critical logic, you can preserve its content and placement and compile the remaining partitions with normal or reduced optimization levels. For example, you may want to compile an IP block that comes with instructions to perform optimization before you incorporate the rest of your custom logic.
To implement this design flow, perform the following steps:
- Partition the design and create floorplan location assignments. For best results, ensure that the top-level design includes the entire project framework, even if some parts of the design are incomplete and are represented by an empty wrapper file.
- For the partitions to be compiled first, in the Design Partitions window, set the netlist type to Source File.
- For the remaining partitions, set the netlist type to Empty.
- To compile with the desired optimizations turned on, click Start Compilation.
- Check the Timing Analyzer reports to ensure that timing requirements are met. If so, proceed to step 6. Otherwise, repeat steps 4 and 5 until the requirements are met.
- In the Design Partitions window, set the netlist type to Post-Fit for the first partitions. You can set the Fitter Preservation Level on the Advanced tab in the Design Partitions Properties dialog box to Placement to allow more flexibility during routing if exact placement and routing preservation is not required.
- Change the netlist type from Empty to Source File for the remaining partitions, and ensure that the completed source files are added to the project.
- Set the appropriate level of optimizations and compile the design. Changing the optimizations at this point does not affect any fitted partitions, because each partition has its netlist type set to Post-Fit.
- Check the Timing Analyzer reports to ensure that timing requirements are met. If not, make design or option changes and repeat step 8 and step 9 until the requirements are met.
The flow in this example is similar to design flows in which a module is implemented separately and is later merged into the top-level. Generally, optimization in this flow works only if each critical path is contained within a single partition. Ensure that if there are any partitions representing a design file that is missing from the project, you create a placeholder wrapper file to define the port interface.
Use this flow to reduce compilation times when you add the logic analyzer to debug your design, or when you want to modify the configuration of the Signal Tap File without modifying your design logic or its placement.
It is not necessary to create design partitions in order to use the Signal Tap incremental compilation feature. The Signal Tap Logic Analyzer acts as its own separate design partition.
Perform the following steps to use the Signal Tap Logic Analyzer in an incremental compilation flow:
- Open the Design Partitions window.
- Set the netlist type to
Post-fit for all partitions to preserve their
- The netlist type for the top-level partition defaults to Source File, so be sure to change this “Top” partition in addition to any design partitions that you have created.
- If you have not already compiled the design with the current set of partitions, perform a full compilation. If the design has already been compiled with the current set of partitions, the design is ready to add the Signal Tap Logic Analyzer.
- Set up your SignalTap II File using the post-fitting filter in the Node Finder to add signals for logic analysis. This allows the Fitter to add the SignalTap II logic to the post-fit netlist without modifying the design results.
To add signals from the pre-synthesis netlist, set the partition’s netlist type to Source File and use the presynthesis filter in the Node Finder. This allows the software to resynthesize the partition and to tap directly to the pre‑synthesis node names that you choose. In this case, the partition is resynthesized and refit, so the placement is typically different from previous fitting results.
The functional safety separation flow supports only Cyclone IV and Cyclone V device families.
When you make modifications to the safety IP in your design, you must use the design creation flow.
The design creation flow becomes active when you have a valid safety IP partition in your Intel® Quartus® Prime project and that safety IP partition does not have place and route data from a previous compile. In the design creation flow, the Assembler generates a Partial Settings Mask (.psm) file for each safety IP partition. Each .psm file contains a list of programming bits for its respective safety IP partition.
The Intel® Quartus® Prime software determines whether to use the design creation flow or design modification flow on a per partition basis. It is possible to have multiple safety IP partitions in a design where some are running the design creation flow and others are running the design modification flow.
To reset the complete design to the design creation flow, remove the previous place and route data by cleaning the project (removing the dbs). Alternatively, use the partition import flow, to selectively reset the design. You can remove the netlists for the imported safety IP partitions individually using the Design Partitions window.
Use the design modification flow only after you qualify your design in the design creation flow.
When the design modification flow is active for a safety IP partition, the Fitter runs in Strict Preservation mode for that partition. The Assembler performs run-time checks that compare the Partial Settings Mask information matches the .psm file generated in the design creation flow. If the Assembler detects a mismatch, a "Bad Mask!" or "ASM_STRICT_PRESERVATION_BITS_UTILITY::compare_masked_byte_array failed" internal error message is shown. If you see either error message while compiling your design, contact Altera support for assistance.
When a change is made to any HDL source file that belongs to a safety IP, the default behavior of the Intel® Quartus® Prime software is to resynthesize and perform a clean place and route for that partition, which then activates the design creation flow for that partition. To change this default behavior and keep the design modification flow active, do the following:
- Use the partition export/import flow.
- Use the Design Partitions window to modify the design partition properties and turn on Ignore changes in source files and strictly use the specified netlist, if available.
The Fitter applies the same design flow to all partitions that belong to the same safety IP. If more than one safety IP is used in the design, the Fitter may evoke different flows for different safety IPs.
set_global_assignment -name PARTITION_ENABLE_STRICT_PRESERVATION <ON/OFF> -section_id <partition_name>
When this global assignment is designated as ON for a partition, the partition is protected from recompilation, exported as a safety IP, and included in the safety IP POF mask. Specifying the value as ON for any partition turns on the functional safety separation flow.
When this global assignment is designated as OFF, the partition is considered as standard IP or as not having a PARTITION_ENABLE_STRICT_PRESERVATION assignment at all. Logic that is not assigned to a partition is considered as part of the top partition and treated as standard logic.
A partition assigned to safety IP can contain safety logic only. If the parent partition is assigned to a safety IP, then all the child partitions for this parent partition are considered as part of the safety IP. If you do not explicitly specify a child partition as a safety IP, a critical warning notifies you that the child partition is treated as part of a safety IP.
A design can contain several safety IPs. All the partitions containing logic that implements a single safety IP function should belong with the same top-level parent partition.
You can also turn on the functional safety separation flow from the Design Partition Properties dialog box. Click the Advanced tab and turn on Allow partition to be strictly preserved for safety.
When the functional safety separation flow is active, you can view which partitions in your design have the Strict Preservation property turned on. The Design Partitions window displays a on or off value for safety IP in your design (in the Strict Preservation column).
Use the following global assignment to assign a pin to a safety IP partition:
set_instance_assignment -name ENABLE_STRICT_PRESERVATION ON/OFF -to <hpath> -section_id <region_name>
- <hpath> refers to an I/O pin (pad).
- <region_name> refers to the top-level safety IP partition name.
A value of ON indicates that the pin is a safety pin that should be preserved with the safety IP block. A value of OFF indicates that the pin that connects to the safety IP, should be treated as a standard pin, and is not preserved with the safety IP.
You also turn on strict preservation for I/O pins in the Design Partition Properties dialog box. Click the Advanced tab and choose On for I/O pins that you want to preserve.
If an IO_REG group contains a pin that is assigned to a safety IP partition, all of the pins in the IO_REG group are reserved for the safety IP partition. All pins in the IO_REG group must be assigned to the same safety IP partition, and none of the pins in the group can be assigned to standard signals.
- An internal clock source, such as a PLL, should be implemented in a safe partition.
- An I/O pin driving the external clock should be indicated as a safety pin.
- To export a safety IP containing several partitions, the top-level partition for the safety IP should be exported. A safety IP containing several partitions is flattened and converted into a single partition during export. This hierarchical safety IP is flattened to enure bit-level settings are preserved.
- Hard blocks implemented in a safe partition needs to stay with the safe partition.
- Safety IP name defined as the name of the top-level safety IP partition
- Effective design flow for the safety IP
- Names of all partitions that belong to the safety IP
- Number of safety/standard inputs to the safety IP
- Number of safety/standard outputs to the safety IP
- LogicLock region names along with size and locations for the regions
- I/O pins used for the respective safety IP in your design
- Safety-related error messages
- quartus_cpf --genppb safe1.psm design.sof safe1.rbf.ppb
- quartus_cpf -c safe1.psm safe1.rbf.ppb
The .ppb file is generated in two steps.
- Generation of partial SOF.
- Generation of .ppb file using the partial SOF.
The .psm file, .ppb file, and MD5 hash signature (.md5.sign) file created during partial bitstream generation should be archived for use in future design modification flow compiles.
Safety IP Partition Export
After you have successfully compiled the safety IP(s) in the Intel® Quartus® Prime software, save the safety IP partition place and route information for use in any subsequent design modification flow. Saving the partition information allows the safety IP to be imported to a clean Intel® Quartus® Prime project where no previous compilation results have been removed (even if the version of the Intel® Quartus® Prime software being used is newer than the Intel® Quartus® Prime software version with which the safety IP was originally compiled). Use the Design Partitions window to export the design partition. Verify that only the post-fit netlist and export routing options are turned on when you generate the .qxp file for each safety IP. The .qxp files should be archived along with the partial bitstream files for use in later design modification flow compiles.
Safety IP Partition Import
You can import a previously exported safety IP partition into your Intel® Quartus® Prime project. There are two use-cases for this.
- (Optional) Import into the original project to ensure that any potential source code changes do not trigger the design creation flow unintentionally.
- Import into a new or clean project where you want to use the design modification flow for the safety IP. As the exported partition is independent of your Intel® Quartus® Prime software version, you can import the .qxp into a future Intel® Quartus® Prime software release.
To import a previously exported design partition, use the Design Partitions window and import the .qxp.
It is a common design practice to create modular or hierarchical designs in which you develop each design entity separately, and then instantiate them in a higher‑level entity, forming a complete design. The Intel® Quartus® Prime software does not automatically consider each design entity or instance to be a design partition for incremental compilation; instead, you must designate one or more design hierarchies below the top-level project as a design partition. Creating partitions might prevent the Compiler from performing optimizations across partition boundaries. However, this allows for separate synthesis and placement for each partition, making incremental compilation possible.
Partitions must have the same boundaries as hierarchical blocks in the design because a partition cannot be a portion of the logic within a hierarchical entity. You can merge partitions that have the same immediate parent partition to create a single partition that includes more than one hierarchical entity in the design. When you declare a partition, every hierarchical instance within that partition becomes part of the same partition. You can create new partitions for hierarchical instances within an existing partition, in which case the instances within the new partition are no longer included in the higher-level partition, as described in the following example.
In the figure below, a complete design is made up of instances A, B, C, D, E, F, and G. The shaded boxes in Representation i indicate design partitions in a “tree” representation of the hierarchy. In Representation ii, the lower-level instances are represented inside the higher-level instances, and the partitions are illustrated with different colored shading. The top‑level partition, called “Top”, automatically contains the top-level entity in the design, and contains any logic not defined as part of another partition. The design file for the top level may be just a wrapper for the hierarchical instances below it, or it may contain its own logic. In this example, partition B contains the logic in instances B, D, and E. Entities F and G were first identified as separate partitions, and then merged together to create a partition F-G. The partition for the top-level entity A, called “Top”, includes the logic in one of its lower-level instances, C, because C was not defined as part of any other partition.
You can create partition assignments to any design instance. The instance can be defined in HDL or schematic design, or come from a third-party synthesis tool as a VQM or EDIF netlist instance.
To take advantage of incremental compilation when source files change, create separate design files for each partition. If you define two different entities as separate partitions but they are in the same design file, you cannot maintain incremental compilation because the software would have to recompile both partitions if you changed either entity in the design file. Similarly, if two partitions rely on the same lower-level entity definition, changes in that lower-level affect both partitions.
The remainder of this section provides information to help you choose which design blocks you should assign as partitions.
Whenever possible, register all inputs and outputs of each partition. This helps avoid any delay penalty on signals that cross partition boundaries and keeps each register‑to-register timing path within one partition for optimization. In addition, minimize the number of paths that cross partition boundaries. If there are timing‑critical paths that cross partition boundaries, rework the partitions to avoid these inter-partition paths. Including as many of the timing-critical connections as possible inside a partition allows you to effectively apply optimizations to that partition to improve timing, while leaving the rest of the design unchanged.
Avoid constant partition inputs and outputs. You can also merge two or more partitions to allow cross-boundary optimizations for paths that cross between the partitions, as long as the partitions have the same parent partition. Merging related logic from different hierarchy blocks into one partition can be useful if you cannot change the design hierarchy to accommodate partition assignments.
If critical timing paths cross partition boundaries, you can perform timing budgeting and make timing assignments to constrain the logic in each partition so that the entire timing path meets its requirements. In addition, because each partition is optimized independently during synthesis, you may have to perform resource allocation to ensure that each partition uses an appropriate number of device resources. If design partitions are compiled in separate Intel® Quartus® Prime projects, there may be conflicts related to global routing resources for clock signals when the design is integrated into the top-level design. You can use the Global Signal logic option to specify which clocks should use global or regional routing, use the ALTCLK_CTRL IP core to instantiate a clock control block and connect it appropriately in both the partitions being developed in separate Intel® Quartus® Prime projects, or find the compiler-generated clock control node in your design and make clock control location assignments in the Assignment Editor.
Cross-boundary optimizations are implemented top-down from the parent partition into the child partition, but not vice-versa. Also, cross-boundary optimizations cannot be enabled for partitions that allow multiple personas (partial reconfiguration partitions).
If you preserve the compilation results using a Post‑Fit netlist, it is not necessary for you to back‑annotate or make any location assignments for specific logic nodes. You should not use the incremental compilation and logic placement back‑annotation features in the same Intel® Quartus® Prime project. The incremental compilation feature does not use placement “assignments” to preserve placement results; it simply reuses the netlist database that includes the placement information.
You can assign design partitions to physical regions in the device floorplan using LogicLock region assignments. In the Intel® Quartus® Prime software, LogicLock regions are used to constrain blocks of a design to a particular region of the device. Altera recommends using LogicLock regions for timing-critical design blocks that will change in subsequent compilations, or to improve the quality of results and avoid placement conflicts in some cases.
Using incremental synthesis within your synthesis tool ensures that only those sections of a design that have been updated are resynthesized when the design is compiled, reducing synthesis run time and preserving the results for the unchanged blocks. You can change and resynthesize one section of a design without affecting other sections of the design.
The Partition Merge Partition Statistics report lists statistics about each partition. The statistics for each partition (each row in the table) include the number of logic cells it contains, as well as the number of input and output pins it contains, and how many are registered or unconnected.
You can also view post-compilation statistics about the resource usage and port connections for a particular partition on the Statistics tab in the Design Partition Properties dialog box.
The Partition Timing Overview report shows the total number of failing paths for each partition and the worst-case slack for any path involving the partition.
The Partition Timing Details report shows the number of failing partition-to-partition paths and worst-case slack for partition-to-partition paths, to provide a more detailed breakdown of where the critical paths in the design are located with respect to design partitions.
Recommendations are split into General Recommendations, Timing Recommendations, and Team-Based Design Recommendations that apply to design flows in which partitions are compiled independently in separate Intel® Quartus® Prime projects before being integrated into the top-level design. Each recommendation provides an explanation, describes the effect of the recommendation, and provides the action required to make a suggested change. In some cases, there is a link to the appropriate Intel® Quartus® Prime settings page where you can make a suggested change to assignments or settings. For some items, if your design does not follow the recommendation, the Check Recommendations operation creates a table that lists any nodes or paths in your design that could be improved. The relevant timing-independent recommendations for the design are also listed in the Design Partitions window and the LogicLock Regions window.
To verify that your design follows the recommendations, go to the Timing Independent Recommendations page or the Timing Dependent Recommendations page, and then click Check Recommendations. For large designs, these operations can take a few minutes.
After you perform a check operation, symbols appear next to each recommendation to indicate whether the design or project setting follows the recommendations, or if some or all of the design or project settings do not follow the recommendations. Following these recommendations is not mandatory to use the incremental compilation feature. The recommendations are most important to ensure good results for timing-critical partitions.
For some items in the Advisor, if your design does not follow the recommendation, the Check Recommendations operation lists any parts of the design that could be improved. For example, if not all of the partition I/O ports follow the Register All Non-Global Ports recommendation, the advisor displays a list of unregistered ports with the partition name and the node name associated with the port.
When the advisor provides a list of nodes, you can right-click a node, and then click Locate to cross-probe to other Intel® Quartus® Prime features, such as the RTL Viewer, Chip Planner, or the design source code in the text editor.
When you choose to preserve a post-fit compilation netlist, the default level of Fitter preservation is the highest degree of placement and routing preservation supported by the device family. The advanced Fitter Preservation Level setting allows you to specify the amount of information that you want to preserve from the post-fit netlist file.
Intel® Quartus® Prime Software Behavior for Partition During Compilation
Always compiles the partition using the associated design source file(s). 2
Use this netlist type to recompile a partition from the source code using new synthesis or Fitter settings.
Preserves post-synthesis results for the partition and reuses the post-synthesis netlist when the following conditions are true:
Compiles the partition from the source files if resynthesis is initiated or if a post-synthesis netlist is not available. 2
Use this netlist type to preserve the synthesis results unless you make design changes, but allow the Fitter to refit the partition using any new Fitter settings.
Preserves post-fit results for the partition and reuses the post-fit netlist when the following conditions are true:
When a post-fit netlist is not available, the software reuses the post-synthesis netlist if it is available, or otherwise compiles from the source files. Compiles the partition from the source files if resynthesis is initiated. 2
The Fitter Preservation Level specifies what level of information is preserved from the post‑fit netlist.
Assignment changes, such as Fitter optimization settings, do not cause a partition set to Post-Fit to recompile.
Uses an empty placeholder netlist for the partition. The partition's port interface information is required during Analysis and Synthesis to connect the partition correctly to other logic and partitions in the design, and peripheral nodes in the source file including pins and PLLs are preserved to help connect the empty partition to the rest of the design and preserve timing of any lower-level non-empty partitions within empty partitions. If the source file is not available, you can create a wrapper file that defines the design block and specifies the input, output, and bidirectional ports. In Verilog HDL: a module declaration, and in VHDL: an entity and architecture declaration.
You can use this netlist type to skip the compilation of a partition that is incomplete or missing from the top-level design. You can also set an empty partition if you want to compile only some partitions in the design, such as to optimize the placement of a timing-critical block such as an IP core before incorporating other design logic, or if the compilation time is large for one partition and you want to exclude it.
If the project database includes a previously generated post-synthesis or post-fit netlist for an unchanged Empty partition, you can set the netlist type from Empty directly to Post-Synthesis or Post-Fit and the software reuses the previous netlist information without recompiling from the source files.
You can change the advanced Fitter Preservation Level setting to provide more flexibility in the Fitter during placement and routing. You can set the Fitter Preservation Level on the Advanced tab in the Design Partitions Properties dialog box.
Fitter Preservation Level
Intel® Quartus® Prime Behavior for Partition During Compilation
Placement and Routing
Preserves the design partition’s netlist atoms and their placement and routing.
This setting reduces compilation times compared to Placement only, but provides less flexibility to the router to make changes if there are changes in other parts of the design.
By default, the Fitter preserves the usage of high-speed programmable power tiles contained within the selected partition, for devices that support high-speed and low-power tiles. You can turn off the Preserve high-speed tiles when preserving placement and routing option on the Advanced tab in the Design Partitions Properties dialog box.
Preserves the netlist atoms and their placement in the design partition. Reroutes the design partition and does not preserve high-speed power tile usage.
Preserves the netlist atoms of the design partition, but replaces and reroutes the design partition. A post-fit netlist with the atoms preserved can be different than the Post‑Synthesis netlist because it contains Fitter optimizations; for example, Physical Synthesis changes made during a previous Fitting.
You can use this setting to:
If you archive or reproduce the project in another location, you can use a Intel® Quartus® Prime Archive File (.qar). Include the incremental compilation database files to preserve post-synthesis or post-fit compilation results.
To manually create a project archive that preserves compilation results without keeping the incremental compilation database, you can keep all source and settings files, and create and save a Intel® Quartus® Prime Settings File (.qxp) for each partition in the design that will be integrated into the top-level design.
The following list explains the changes that initiate a partition’s automatic resynthesis when the netlist type is set to Post-Synthesis or Post-Fit:
- The device family setting has changed.
- Any dependent source design file has changed.
- The partition boundary was changed by an addition, removal, or change to the port boundaries of a partition (for example, a new partition has been defined for a lower‑level instance within this partition).
- A dependent source file was compiled into a different library (so it has a different -library argument).
- A dependent source file was added or removed; that is, the partition depends on a different set of source files.
- The partition’s root instance has a different entity binding. In VHDL, an instance may be bound to a specific entity and architecture. If the target entity or architecture changes, it triggers resynthesis.
- The partition has different parameters on its root hierarchy or on an internal AHDL hierarchy (AHDL automatically inherits parameters from its parent hierarchies). This occurs if you modified the parameters on the hierarchy directly, or if you modified them indirectly by changing the parameters in a parent design hierarchy.
- You have moved the project and compiled database between a Windows and Linux system. Due to the differences in the way new line feeds are handled between the operating systems, the internal checksum algorithm may detect a design file change in this case.
The software reuses the post-synthesis results but re-fits the design if you change the device setting within the same device family. The software reuses the post-fitting netlist if you change only the device speed grade.
Synthesis and Fitter assignments, such as optimization settings, timing assignments, or Fitter location assignments including pin assignments, do not trigger automatic recompilation in the incremental compilation flow. To recompile a partition with new assignments, change the netlist type for that partition to one of the following:
- Source File to recompile with all new settings
- Post-Synthesis to recompile using existing synthesis results but new Fitter settings
- Post-Fit with the Fitter Preservation Level set to Placement to rerun routing using existing placement results, but new routing settings (such as delay chain settings)
You can use the LogicLock Origin location assignment to change or fine-tune the previous Fitter results from a Post-Fit netlist.
For example, if a design has file A.v that contains entity A, B.v that contains entity B, and C.v that contains entity C, then the Partition Dependent Files table for the partition containing entity A lists file A.v, the table for the partition containing entity B lists file B.v, and the table for the partition containing entity C lists file C.v. Any dependencies are transitive, so if file A.v depends on B.v, and B.v depends on C.v, the entities in file A.v depend on files B.v and C.v. In this case, files B.v and C.v are listed in the report table as dependent files for the partition containing entity A.
If you define module parameters in a higher‑level module, the Intel® Quartus® Prime software checks the parameter values when determining which partitions require resynthesis. If you change a parameter in a higher‑level module that affects a lower‑level module, the lower‑level module is resynthesized. Parameter dependencies are tracked separately from source file dependencies; therefore, parameter definitions are not listed in the Partition Dependent Files list.
If a design contains common files, such as an includes.v file that is referenced in each entity by the command include includes.v, all partitions are dependent on this file. A change to includes.v causes the entire design to be recompiled. The VHDL statement use work.all also typically results in unnecessary recompilations, because it makes all entities in the work library visible in the current entity, which results in the current entity being dependent on all other entities in the design.
To avoid this type of problem, ensure that files common to all entities, such as a common include file, contain only the set of information that is truly common to all entities. Remove use work.all statements in your VHDL file or replace them by including only the specific design units needed for each entity.
To force the Fitter to use a previously generated netlist even when there are changes to the source files, right-click the partition in the Design Partitions window and then click Design Partition Properties. On the Advanced tab, turn on the Ignore changes in source files and strictly use the specified netlist, if available option.
Turning on this option can result in the generation of a functionally incorrect netlist when source design files change, because source file updates will not be recompiled. Use caution when setting this option.
To enable team-based development and third-party IP delivery, you can design and optimize partitions in separate copies of the top-level Intel® Quartus® Prime project framework, or even in isolation. If the designers have access to the top-level project framework through a source control system, they can access project files as read-only and develop their partition within the source control system. If designers do not have access to a source control system, the project lead can provide the designer with a copy of the top-level project framework to use as they develop their partitions. The project lead also has the option to generate design partition scripts to manage resource and timing budgets in the top-level design when partitions are developed outside the top-level project framework.
The exported compilation results of completed partitions are given to the project lead, preferably using a source control system, who is then responsible for integrating them into the top-level design to obtain a fully functional design. This type of design flow is required only if partition designers want to optimize their placement and routing independently, and pass their design to the project lead to reuse placement and routing results. Otherwise, a project lead can integrate source HDL from several designers in a single Intel® Quartus® Prime project, and use the standard incremental compilation flow described previously.
The figure below illustrates the team-based incremental compilation design flow using a methodology in which partitions are compiled in separate Intel® Quartus® Prime projects before being integrated into the top-level design. This flow can be used when partitions are developed by other designers or IP providers.
In the top-level design, create project-wide settings, for example, device selection, global assignments for clocks and device I/O ports, and any global signal constraints to specify which signals can use global routing resources.
Next, create the appropriate design partition assignments and set the netlist type for each design partition that will be developed in a separate Intel® Quartus® Prime project to Empty. It may be necessary to constrain the location of partitions with LogicLock region assignments if they are timing-critical and are expected to change in future compilations, or if the designer or IP provider wants to place and route their design partition independently, to avoid location conflicts.
Finally, provide the top-level project framework to the partition designers, preferably through a source control system.
When a netlist type is set to Empty, peripheral nodes including pins and PLLs are preserved and all other logic is removed. The peripheral nodes including pins help connect the empty partition to the design, and the PLLs help preserve timing of non‑empty partitions within empty partitions.
When you set a design partition to Empty, a design file is required during Analysis and Synthesis to specify the port interface information so that it can connect the partition correctly to other logic and partitions in the design. If a partition is exported from another project, the .qxp contains this information. If there is no .qxp or design file to represent the design entity, you must create a wrapper file that defines the design block and specifies the input, output, and bidirectional ports. For example, in Verilog HDL, you should include a module declaration, and in VHDL, you should include an entity and architecture declaration.
- If partition designers have
access to the top-level project framework, the project will already include all
the settings and constraints needed for the design. This framework should
include PLLs and other interface logic if this information is important to
- If designers are part of the same design environment, they can check out the required project files from the same source control system. This is the recommended way to share a set of project files.
- Otherwise, the project lead can provide a copy of the top-level project framework so that each design develops their partition within the same project framework.
- If a partition designer does not have access to the top-level project framework, the project lead can give the partition designer a Tcl script or other documentation to create the separate Intel® Quartus® Prime project and all the assignments from the top-level design.
If the partition designers provide the project lead with a post-synthesis .qxp and fitting is performed in the top-level design, integrating the design partitions should be quite easy. If you plan to develop a partition in a separate Intel® Quartus® Prime project and integrate the optimized post-fitting results into the top-level design, use the following guidelines to improve the integration process:
- Ensure that a LogicLock region constrains the partition placement and uses only the resources allocated by the project lead.
- Ensure that you know which
clocks should be allocated to global routing resources so that there are no
resource conflicts in the top-level design.
- Set the Global Signal assignment to On for the high fan-out signals that should be routed on global routing lines.
- To avoid other signals
being placed on global routing lines, turn off
Auto Global Clock and Auto Global Register
More Settings on the Fitter page in the
Settings dialog box. Alternatively, you can
set the Global Signal assignment to
Off for signals that should not be placed on
global routing lines.
Placement for LABs depends on whether the inputs to the logic cells within the LAB use a global clock. You may encounter problems if signals do not use global lines in the partition, but use global routing in the top-level design.
- Use the Virtual Pin assignment to indicate pins of a partition that do not drive pins in the top-level design. This is critical when a partition has more output ports than the number of pins available in the target device. Using virtual pins also helps optimize cross-partition paths for a complete design by enabling you to provide more information about the partition ports, such as location and timing assignments.
- When partitions are compiled independently without any information about each other, you might need to provide more information about the timing paths that may be affected by other partitions in the top-level design. You can apply location assignments for each pin to indicate the port location after incorporation in the top-level design. You can also apply timing assignments to the I/O ports of the partition to perform timing budgeting.
- Determine which assignments should be propagated from the top-level design to the partitions. This requires detailed knowledge of which assignments are required to set up low-level designs.
- Communicate the top-level assignments to the partitions. This requires detailed knowledge of Tcl or other scripting languages to efficiently communicate project constraints.
- Determine appropriate timing and location assignments that help overcome the limitations of team-based design. This requires examination of the logic in the partitions to determine appropriate timing constraints.
- Perform final timing closure and resource conflict avoidance in the top-level design. Because the partitions have no information about each other, meeting constraints at the lower levels does not guarantee they are met when integrated at the top-level. It then becomes the project lead’s responsibility to resolve the issues, even though information about the partition implementation may not be available.
Design partition scripts automate the process of transferring the top-level project framework to partition designers in a flow where each design block is developed in separate Intel® Quartus® Prime projects before being integrated into the top-level design. If the project lead cannot provide each designer with a copy of the top-level project framework, the Intel® Quartus® Prime software provides an interface for managing resources and timing budgets in the top-level design. Design partition scripts make it easier for partition designers to implement the instructions from the project lead, and avoid conflicts between projects when integrating the partitions into the top‑level design. This flow also helps to reduce the need to further optimize the designs after integration.
You can use options in the Generate Design Partition Scripts dialog box to choose which types of assignments you want to pass down and create in the partitions being developed in separate Intel® Quartus® Prime projects.
A designer developing a timing-critical partition or who wants to optimize their partition on their own would opt to export their completed partition with a post-fit netlist, allowing for the partition to more reliably meet timing requirements after integration. In this case, you must ensure that resources are allocated appropriately to avoid conflicts. If the placement and routing optimization can be performed in the top-level design, exporting a post-synthesis netlist allows the most flexibility in the top-level design and avoids potential placement or routing conflicts with other partitions.
When designing the partition logic to be exported into another project, you can add logic around the design block to be exported as a design partition. You can instantiate additional design components for the Intel® Quartus® Prime project so that it matches the top-level design environment, especially in cases where you do not have access to the full top-level design project. For example, you can include a top-level PLL in the project, outside of the partition to be exported, so that you can optimize the design with information about the frequency multipliers, phase shifts, compensation delays, and any other PLL parameters. The software then captures timing and resource requirements more accurately while ensuring that the timing analysis in the partition is complete and accurate. You can export the partition for the top-level design without any auxiliary components that are instantiated outside the partition being exported.
If your design team uses makefiles and design partition scripts, the project lead can use the make command with the master_makefile command created by the scripts to export the partitions and create .qxp files. When a partition has been compiled and is ready to be integrated into the top-level design, you can export the partition with option on the Export Design Partition dialog box, available from the Project menu.
The .qxp contains the design block exported from the partition and has the same name as the partition. When you instantiate the design block into a top-level design and include the .qxp as a source file, the software adds the exported netlist to the database for the top-level design. The .qxp port names are case sensitive if the original HDL of the partition was case sensitive.
When you use a .qxp as a source file in this way, you can choose whether you want the .qxp to be a partition in the top-level design. If you do not designate the .qxp instance as a partition, the software reuses just the post-synthesis compilation results from the .qxp, removes unconnected ports and unused logic just like a regular source file, and then performs placement and routing.
If you assigned the .qxp instance as a partition, you can set the netlist type in the Design Partitions Window to choose the level of results to preserve from the .qxp. To preserve the placement and routing results from the exported partition, set the netlist type to Post-Fit for the .qxp partition in the top-level design. If you assign the instance as a design partition, the partition boundary is preserved.
- If you want LogicLock regions in your top-level design (.qsf)—If you have regions in your partitions that are not also in the top-level design, the regions will be added to your .qsf during the import process.
- If you want different settings or placement for different instantiations of the same entity—You can control the setting import process with the advanced import options, and specify different settings for different instances of the same .qxp design block.
When you use the Import Design Partition dialog box to integrate a partition into the top-level design, the import process sets the partition’s netlist type to Imported in the Design Partitions window.
After you compile the entire design, if you make changes to the place-and-route results (such as movement of an imported LogicLock region), use the Post-Fit netlist type on subsequent compilations. To discard an imported netlist and recompile from source code, you can compile the partition with the netlist type set to Source File and be sure to include the relevant source code in the top‑level design. The import process sets the partition’s Fitter Preservation Level to the setting with the highest degree of preservation supported by the imported netlist. For example, if a post-fit netlist is imported with placement information, the Fitter Preservation Level is set to Placement, but you can change it to the Netlist Only value.
When you import a partition from a .qxp, the .qxp itself is not part of the top‑level design because the netlists from the file have been imported into the project database. Therefore if a new version of a .qxp is exported, the top-level designer must perform another import of the .qxp.
When you import a partition into a top-level design with the Import Design Partition dialog box, the software imports relevant assignments from the partition into the top‑level design. If required, you can change the way some assignments are imported, as described in the following subsections.
The LogicLock Member State assignment is set to Locked to signify that it is a preserved region.
LogicLock back-annotation and node location data is not imported because the .qxp contains all of the relevant placement information. Altera strongly recommends that you do not add to or delete members from an imported LogicLock region.
Use this flow to package a full design as a single source file to send to an end customer or another design location.
As the sender in this scenario perform the following steps to export a design block:
- Provide the device family name to the recipient. If you send placement information with the synthesized netlist, also provide the exact device selection so they can set up their project to match.
- Create a black box wrapper file that defines the port interface for the design block and provide it to the recipient for instantiating the block as an empty partition in the top-level design.
- Create a Intel® Quartus® Prime project for the design block, and complete the design.
- Export the level of
hierarchy into a single .qxp. Following a successful compilation of the
project, you can generate a .qxp from the GUI, the command-line, or with
Tcl commands, as described in the following:
- If you are using the Intel® Quartus® Prime GUI, use the Export Design Partition dialog box.
- If you are using command-line executables, run quartus_cdb with the --incremental_compilation_export option.
- If you are using Tcl commands, use the following command: execute_flow -incremental_compilation_export.
- Select the option to include just the Post-synthesis netlist if you do not have to send placement information. If the recipient wants to reproduce your exact Fitter results, you can select the Post-fitting netlist option, and optionally enable Export routing.
- If a partition contains sub-partitions, then the sub-partitions are automatically flattened and merged into the partition netlist before exporting. You can change this behavior and preserve the sub-partition hierarchy by turning off the Flatten sub-partitions option on the Export Design Partition dialog box. Optionally, you can use the -dont_flatten sub-option for the export_partition Tcl command.
- Provide the .qxp to the recipient. Note that you do not have to send any of your design source code.
As the recipient in this example, first create a Intel® Quartus® Prime project for your top-level design and ensure that your project targets the same device (or at least the same device family if the .qxp does not include placement information), as specified by the IP designer sending the design block. Instantiate the design block using the port information provided, and then incorporate the design block into a top‑level design.
Add the .qxp from the IP designer as a source file in your Intel® Quartus® Prime project to replace any empty wrapper file. If you want to use just the post-synthesis information, you can choose whether you want the file to be a partition in the top‑level design. To use the post-fit information from the .qxp, assign the instance as a design partition and set the netlist type to Post-Fit.
Use this design flow to create a precompiled IP block (sometimes known as a hard‑wired macro) that can be instantiated in a top-level design. This flow provides the ability to export a design block with post‑synthesis or placement (and, optionally, routing) information and to import any number of copies of this pre-compiled block into another design.
The customer first specifies which Altera device is being used for this project and provides the design specifications.
As the IP provider in this example, perform the following steps to export a preplaced IP core (or hard macro):
- Create a black box wrapper file that defines the port interface for the IP core and provide the file to the customer to instantiate as an empty partition in the top-level design.
- Create a Intel® Quartus® Prime project for the IP core.
Create a LogicLock
region for the design hierarchy to be exported.
Using a LogicLock region for the IP core allows the customer to create an empty placeholder region to reserve space for the IP in the design floorplan and ensures that there are no conflicts with the top-level design logic. Reserved space also helps ensure the IP core does not affect the timing performance of other logic in the top-level design. Additionally, with a LogicLock region, you can preserve placement either absolutely or relative to the origin of the associated region. This is important when a .qxp is imported for multiple partition hierarchies in the same project, because in this case, the location of at least one instance in the top-level design does not match the location used by the IP provider.
- If required, add any logic (such as PLLs or other logic defined in the customer’s top-level design) around the design hierarchy to be exported. If you do so, create a design partition for the design hierarchy that will exported as an IP core.
- Optimize the design and close timing to meet the design specifications.
- Export the level of hierarchy for the IP core into a single .qxp.
- Provide the .qxp to the customer. Note that you do not have to send any of your design source code to the customer; the design netlist and placement and routing information is contained within the .qxp.
Incorporate IP Core
As the customer in this example, incorporate the IP core in your design by performing the following steps:
- Create a Intel® Quartus® Prime project for the top-level design that targets the same device and instantiate a copy or multiple copies of the IP core. Use a black box wrapper file to define the port interface of the IP core.
- Perform Analysis and Elaboration to identify the design hierarchy.
- Create a design partition for each instance of the IP core with the netlist type set to Empty.
- You can now continue work on your part of the design and accept the IP core from the IP provider when it is ready.
.qxp from the IP provider in your project to replace the empty
wrapper-file for the IP instance. Or, if you are importing multiple copies of
the design block and want to import relative placement, follow these additional
Import command to select each
appropriate partition hierarchy. You can import a .qxp from the GUI, the
command-line, or with Tcl commands:
- If you are using the Intel® Quartus® Prime GUI, use the Import Design Partition command.
- If you are using command-line executables, run quartus_cdb with the incremental_compilation_import option.
- If you are using Tcl commands, use the following command:execute_flow -incremental_compilation_import.
you have multiple instances of the IP block, you can set the imported LogicLock
regions to floating, or move them to a new location, and the software preserves
the relative placement for each of the imported modules (relative to the origin
of the LogicLock region). Routing information is preserved whenever
Note: The Fitter ignores relative placement assignments if the LogicLock region’s location in the top-level design is not compatible with the locations exported in the .qxp.
- Use the Import command to select each appropriate partition hierarchy. You can import a .qxp from the GUI, the command-line, or with Tcl commands:
You can control
the level of results preservation with the
Netlist Type setting.
If the IP provider did not define a LogicLock region in the exported partition, the software preserves absolute placement locations and this leads to placement conflicts if the partition is imported for more than one instance
This scenario describes how to use incremental compilation in a team-based design environment where each designer has access to the top-level project framework, but wants to optimize their design in a separate Intel® Quartus® Prime project before integrating their design block into the top-level design.
As the project lead in this scenario, perform the following steps to prepare the top‑level design:
- Create a new Intel® Quartus® Prime project to ultimately contain the full implementation of the entire design and include a "skeleton" or framework of the design that defines the hierarchy for the subdesigns implemented by separate designers. The top-level design implements the top-level entity in the design and instantiates wrapper files that represent each subdesign by defining only the port interfaces, but not the implementation.
- Make project-wide settings. Select the device, make global assignments such as device I/O ports, define the top-level timing constraints, and make any global signal allocation constraints to specify which signals can use global routing resources.
- Make design partition assignments for each subdesign and set the netlist type for each design partition to be imported to Empty in the Design Partitions window.
- Create LogicLock regions to create a design floorplan for each of the partitions that will be developed separately. This floorplan should consider the connectivity between partitions and estimates of the size of each partition based on any initial implementation numbers and knowledge of