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
Note: For Intel® Arria® 10 designs, you can use the Intel® Quartus® Prime software to automatically create a combined simulator setup script. Refer to Scripting IP Simulation in the Introduction to Intel® FPGA IP Cores for more information.
|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|
- 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 10. 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 26. 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
synthesis.Note: You can add the Signal Tap Logic Analyzer as a separate design partition for incremental compilation to minimize recompilation times.
Table 12. 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 the design specifications.
top-level project framework to partition designers using one of the following
- Allow access to the full project for all designers through a source control system. Each designer can check out the projects files as read-only and work on their blocks independently. This design flow provides each designer with the most information about the full design, which helps avoid resource conflicts and makes design integration easy.
- Provide a copy of the top-level Intel® Quartus® Prime project framework for each designer. You can use the Copy Project command on the Project menu or create a project archive.
Exporting Your Partition
As the designer of a lower-level design block in this scenario, design and optimize your partition in your copy of the top-level design, and then follow these steps when you have achieved the desired compilation results:
- On the Project menu, click Export Design Partition.
- In the Export Design Partition dialog box, choose the netlist(s) to export. You can export a Post-synthesis netlist if placement or performance preservation is not required, to provide the most flexibility for the Fitter in the top-level design. Select Post-fit netlist to preserve the placement and performance of the lower-level design block, and turn on Export routing to include the routing information, if required. One .qxp can include both post-synthesis and post-fitting netlists.
- Provide the .qxp to the project lead.
Integrating Your Partitions
Finally, as the project lead in this scenario, perform these steps to integrate the .qxp files received from designers of each partition:
- Add the .qxp as a source file in the Intel® Quartus® Prime project, to replace any empty wrapper file for the previously Empty partition.
- Change the netlist type for the partition from Empty to the required level of results preservation.
This scenario assumes that there are several design blocks being developed independently (instead of just one IP block), and the project lead can provide some information about the design to the individual designers.
This scenario describes how to use incremental compilation in a team-based design environment where designers or IP developers want to fully optimize the placement and routing of their design independently in a separate Intel® Quartus® Prime project before sending the design to the project lead. This design flow requires more planning and careful resource allocation because design blocks are developed independently.
- 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 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. This floorplan should consider the connectivity between partitions and estimates of the size of each partition based on any initial implementation numbers and knowledge of the design specifications.
constraints from the top-level design to partition designers using one of the
- Use design partition scripts to pass constraints and generate separate Intel® Quartus® Prime projects. On the Project menu, use the Generate Design Partition Scripts command, or run the script generator from a Tcl or command prompt. Make changes to the default script options as required for your project. Altera recommends that you pass all the default constraints, including LogicLock regions, for all partitions and virtual pin location assignments. If partitions have not already been created by the other designers, use the partition script to set up the projects so that you can easily take advantage of makefiles. Provide each partition designer with the Tcl file to create their project with the appropriate constraints. If you are using makefiles, provide the makefile for each partition.
- Use documentation or manually-created scripts to pass all constraints and assignments to each partition designer.
If you are using makefiles with the design partition scripts, perform the following steps:
- Use the make command and the makefile provided by the project lead to create a Intel® Quartus® Prime project with all design constraints, and compile the project.
- The information about which source file should be associated with which partition is not available to the software automatically, so you must specify this information in the makefile. You must specify the dependencies before the software rebuilds the project after the initial call to the makefile.
- When you have achieved the desired compilation results and the design is ready to be imported into the top-level design, the project lead can use the master_makefile command to export this partition and create a .qxp, and then import it into the top-level design.
Exporting Without Makefiles
If you are not using makefiles, perform the following steps:
If you are using
design partition scripts, source the Tcl script provided by the Project Lead to
create a project with the required settings:
- To source the Tcl script in the Intel® Quartus® Prime software, on the Tools menu, click Utility Windows to open the Tcl console. Navigate to the script’s directory, and type the following command: source <filename>.
- To source the Tcl script at the system command prompt, type the following command: quartus_cdb -t <filename>.tcl
If you are not
using design partition scripts, create a new
Quartus® Prime project for the
subdesign, and then apply the following settings and constraints to ensure
- Make LogicLock region assignments and global assignments (including clock settings) as specified by the project lead.
- Make Virtual Pin assignments for ports which represent connections to core logic instead of external device pins in the top‑level design.
- Make floorplan location assignments to the Virtual Pins so they are placed in their corresponding regions as determined by the top‑level design. This provides the Fitter with more information about the timing constraints between modules. Alternatively, you can apply timing I/O constraints to the paths that connect to virtual pins.
- Proceed to compile and optimize the design as needed.
- When you have achieved the desired compilation results, on the Project menu, click Export Design Partition.
- In the Export Design Partition dialog box, choose the netlist(s) to export. You can export a Post-synthesis netlist instead if placement or performance preservation is not required, to provide the most flexibility for the Fitter in the top-level design. Select Post-fit to preserve the placement and performance of the lower-level design block, and turn on Export routing to include the routing information, if required. One .qxp can include both post-synthesis and post-fitting netlists.
- Provide the .qxp to the project lead.
- Use the master_makefile command to export each partition and create .qxp files, and then import them into the top‑level design.
- The software does not have all the information about which source files should be associated with which partition, so you must specify this information in the makefile. The software cannot rebuild the project if source files change unless you specify the dependencies.
Importing Without Makefiles
If you are not using makefiles, perform the following steps:
- Add the .qxp as a source file in the Intel® Quartus® Prime project, to replace any empty wrapper file for the previously Empty partition.
- Change the netlist type for the partition from Empty to the required level of results preservation.
- Allow new assignments to be imported
- Allow existing assignments to be replaced or updated
When LogicLock region assignment conflicts occur, the project lead may take one of the following actions:
- Allow the imported region to replace the existing region
- Allow the imported region to update the existing region
- Skip assignment import for regions with conflicts
If the placement of different lower-level design blocks conflict, the project lead can also set the set the partition’s Fitter Preservation Level to Netlist Only, which allows the software to re-perform placement and routing with the imported netlist.
If you import multiple instances of a lower-level design block into the top-level design, the imported LogicLock regions are automatically set to Floating status.
If you resolve conflicts manually, you can use the import options and manual LogicLock assignments to specify the placement of each instance in the top-level design.
After trying various optimizations in the top-level design, the project lead determines that the design cannot meet the timing requirements given the current partition placements that were imported. The project lead decides to pass additional information to the lower-level partitions to improve the placement.
Use this flow if you re-optimize partitions exported from separate Intel® Quartus® Prime projects by incorporating additional constraints from the integrated top-level design.
- For all partitions other than the one(s) being optimized by a designer(s) in a separate Intel® Quartus® Prime project(s), set the netlist type to Post-Fit.
- Make the top-level design directory available in a shared source control system, if possible. Otherwise, copy the entire top-level design project directory (including database files), or create a project archive including the post-compilation database.
- Provide each partition designer with a checked-out version or copy of the top‑level design.
- The partition designers recompile their designs within the new project framework that includes the rest of the design's placement and routing information as well top-level resource allocations and assignments, and optimize as needed.
- When the results are satisfactory and the timing requirements are met, export the updated partition as a .qxp.
- In the top-level design, on the Project menu, click Generate Design Partition Scripts, or launch the script generator from Tcl or the command line.
- If lower-level projects have already been created for each partition, you can turn off the Create lower-level project if one does not exist option.
- Make additional changes to the default script options, as necessary. Altera recommends that you pass all the default constraints, including LogicLock regions, for all partitions and virtual pin location assignments. Altera also recommends that you add a maximum delay timing constraint for the virtual I/O connections in each partition.
software generates Tcl scripts for all partitions, but in this scenario, you
would focus on the partitions that make up the cross-partition critical paths.
The following assignments are important in the script:
- Virtual pin assignments for module pins not connected to device I/O ports in the top-level design.
- Location constraints for the virtual pins that reflect the initial top-level placement of the pin’s source or destination. These help make the lower-level placement “aware” of its surroundings in the top-level design, leading to a greater chance of timing closure during integration at the top level.
- INPUT_MAX_DELAY and OUTPUT_MAX_DELAY timing constraints on the paths to and from the I/O pins of the partition. These constrain the pins to optimize the timing paths to and from the pins.
designers source the file provided by the project lead.
- To source the
Tcl script from the
Quartus® Prime GUI, on the Tools menu, click
Utility Windows and open the Tcl console.
Navigate to the script’s directory, and type the following command:
- To source the
Tcl script at the system command prompt, type the following command:
quartus_cdb -t <filename>.tcl
- To source the Tcl script from the Intel® Quartus® Prime GUI, on the Tools menu, click Utility Windows and open the Tcl console. Navigate to the script’s directory, and type the following command:
designers recompile their designs with the new project information or
assignments and optimize as needed. When the results are satisfactory and the
timing requirements are met, export the updated partition as a
The project lead obtains the updated .qxp files from the partition designers and adds them to the top-level design. When a new .qxp is added to the files list, the software will detect the change in the “source file” and use the new .qxp results during the next compilation. If the project uses the advanced import flow, the project lead must perform another import of the new .qxp.You can now analyze the design to determine whether the timing requirements have been achieved. Because the partitions were compiled with more information about connectivity at the top level, it is more likely that the inter‑partition paths have improved placement which helps to meet the timing requirements.
- To avoid resource conflicts between partitions, predominantly when partitions are imported from another Intel® Quartus® Prime project
- To ensure a good quality of results when recompiling individual timing-critical partitions
Design floorplan assignments prevent the situation in which the Fitter must place a partition in an area of the device where most resources are already used by other partitions. A physical region assignment provides a reasonable region to re-place logic after a change, so the Fitter does not have to scatter logic throughout the available space in the device.
Floorplan assignments are not required for non-critical partitions compiled as part of the top-level design. The logic for partitions that are not timing-critical (such as simple top-level glue logic) can be placed anywhere in the device on each recompilation, if that is best for your design.
The simplest way to create a floorplan for a partitioned design is to create one LogicLock region per partition (including the top-level partition). If you have a compilation result for a partitioned design with no LogicLock regions, you can use the Chip Planner with the Design Partition Planner to view the partition placement in the device floorplan. You can draw regions in the floorplan that match the general location and size of the logic in each partition. Or, initially, you can set each region with the default settings of Auto size and Floating location to allow the Intel® Quartus® Prime software to determine the preliminary size and location for the regions. Then, after compilation, use the Fitter-determined size and origin location as a starting point for your design floorplan. Check the quality of results obtained for your floorplan location assignments and make changes to the regions as needed. Alternatively, you can perform synthesis, and then set the regions to the required size based on resource estimates. In this case, use your knowledge of the connections between partitions to place the regions in the floorplan.
Once you have created an initial floorplan, you can refine the region using tools in the Intel® Quartus® Prime software. You can also use advanced techniques such as creating non‑rectangular regions by merging LogicLock regions.
You can use the Incremental Compilation Advisor to check that your LogicLock regions meet Altera’s guidelines.
Options in the Layer Settings panel in the Chip Planner allow you to create, delete, and modify tasks to determine which objects, including LogicLock regions and design partitions, to display in the Chip Planner.
Similarly, if a partition’s placement is preserved, and the partition is assigned to a LogicLock region, the Fitter always reuses the corresponding LogicLock region size specified in the post-fit netlist. That is, changes to the LogicLock Size setting do not initiate refitting if a partition’s placement is preserved with the Post-Fit netlist type, or with .qxp that includes post-fit information.
However, you can use the LogicLock Origin location assignment to change or fine‑tune the previous Fitter results. When you change the Origin setting for a region, the Fitter can move the region in the following manner, depending upon how the placement is preserved for that region's members:
- When you set a new region Origin, the Fitter uses the new origin and replaces the logic, preserving the relative placement of the member logic.
- When you set the region
Floating, the following conditions apply:
- If the region’s member placement is preserved with an imported partition, the Fitter chooses a new Origin and re-places the logic, preserving the relative placement of the member logic within the region.
- If the region’s member placement is preserved with a Post-Fit netlist type, the Fitter does not change the Origin location, and reuses the previous placement results.
To ensure that a partition continues to meet its timing requirements when other partitions change, a very small timing margin might be required. The Fitter automatically works to achieve such margin when compiling any design, so you do not need to take any action.
If you want to re-use post-synthesis or post-fitting results, include the database files in the Archive Project dialog box so compilation results are preserved. Click Advanced, and choose a file set that includes the compilation database, or turn on Incremental compilation database files to create a Custom file set.
When you include the database, the file size of the .qar archive file may be significantly larger than an archive without the database.
The netlist information for imported partitions is already saved in the corresponding .qxp. Imported .qxp files are automatically saved in a subdirectory called imported_partitions, so you do not need to archive the project database to keep the results for imported partitions. When you restore a project archive, the partition is automatically reimported from the .qxp in this directory if it is available.
For new device families with advanced support, a version-compatible database might not be available. In this case, the archive will not include the compilation database. If you require the database files to reproduce the compilation results in the same Intel® Quartus® Prime version, you can use the following command-line option to archive a full database:
quartus_sh --archive -use_file_set full_db [-revision <revision name>]<project name>
When incremental compilation is turned on and your design contains one or more design partitions, partition boundaries are ignored while making ECO changes and Signal Probe signal settings. However, the presence of ECO and/or Signal Probe changes does not affect partition boundaries for incremental compilation. During subsequent compilations, ECO and Signal Probe changes are not preserved regardless of the Netlist Type or Fitter Preservation Level settings. To recover ECO changes and Signal Probe signals, you must use the Change Manager to re-apply the ECOs after compilation.
For partitions developed independently in separate Intel® Quartus® Prime projects, the exported netlist includes all currently saved ECO changes and Signal Probe signals. If you make any ECO or Signal Probe changes that affect the interface to the lower-level partition, the software issues a warning message during the export process that this netlist does not work in the top-level design without modifying the top-level HDL code to reflect the lower-level change. After integrating the .qxp partition into the top-level design, the ECO changes will not appear in the Change Manager.
When incremental compilation is turned on, debugging logic is added to your design incrementally and you can tap post-fitting nodes and modify triggers and configuration without recompiling the full design. Use the appropriate filter in the Node Finder to find your node names. Use Signal Tap: post-fitting if the netlist type is Post-Fit to incrementally tap node names in the post-fit netlist database. Use Signal Tap: pre-synthesis if the netlist type is Source File to make connections to the source file (pre-synthesis) node names when you synthesize the partition from the source code.
If incremental compilation is turned off, the debugging logic is added to the design during Analysis and Elaboration, and you cannot tap post-fitting nodes or modify debug settings without fully compiling the design.
For design partitions that are being developed independently in separate Intel® Quartus® Prime projects and contain the logic analyzer, when you export the partition, the Intel® Quartus® Prime software automatically removes the Signal Tap logic analyzer and related SLD_HUB logic. You can tap any nodes in a Intel® Quartus® Prime project, including nodes within .qxp partitions. Therefore, you can use the logic analyzer within the full top-level design to tap signals from the .qxp partition.
You can also instantiate the Signal Tap IP core directly in your lower‑level design (instead of using an .stp file) and export the entire design to the top level to include the logic analyzer in the top-level design.
When using the wildcard to represent a level of hierarchy, only single wildcards are supported. This means assignments such as Top|A:inst|*|B:inst|* are not supported. The Intel® Quartus® Prime software issues a warning in these cases.
This issue is of particular importance for clock pins that require timing constraints and clock group settings. Problems can occur if your design uses logic or inversion to derive a new clock from a clock input pin. Make appropriate timing assignments in your lower-level Intel® Quartus® Prime project to ensure that clocks are not unconstrained.
If the lower-level design uses the top-level project framework from the project lead, the design will have all the required information about the clock and PLL settings. Otherwise, if you use a PLL in your top-level design and connect it to lower-level partitions, the lower-level partitions do not have information about the multiplication or phase shift factors in the PLL. Make appropriate timing assignments in your lower‑level Intel® Quartus® Prime project to ensure that clocks are not unconstrained or constrained with the incorrect frequency. Alternatively, you can manually duplicate the top‑level derived clock logic or PLL in the lower-level design file to ensure that you have the correct multiplication or phase-shift factors, compensation delays and other PLL parameters for complete and accurate timing analysis. Create a design partition for the rest of the lower-level design logic for export to the top level. When the lower‑level design is complete, export only the partition that contains the relevant logic.
This clock domain assignment means that there may be some paths constrained and reported by the timing analysis engine that are not required.
To restrict which clock domains are included in these assignments, edit the generated scripts or change the assignments in your lower‑level Intel® Quartus® Prime project. In addition, because there is no known clock associated with the delay assignments, the software assumes the worst‑case skew, which makes the paths seem more timing critical than they are in the top-level design. To make the paths appear less timing‑critical, lower the delay values from the scripts. If required, enter negative numbers for input and output delay values.
The Intel® Quartus® Prime software does not support creating a partition for inferred IP cores (that is, where the software infers an IP core to implement logic in your design). If you have a module or entity for the logic that is inferred, you can create a partition for that hierarchy level in the design.
The Intel® Quartus® Prime software does not support creating a partition for any Intel® Quartus® Prime internal hierarchy that is dynamically generated during compilation to implement the contents of an IP core.
The following specific circumstances are required for input pin cross‑partition register packing:
- The input pin feeds exactly one register.
- The path between the input pin and register includes only input ports of partitions that have one fan-out each.
The following specific circumstances are required for output register cross-partition register packing:
- The register feeds exactly one output pin.
- The output pin is fed by only one signal.
- The path between the register and output pin includes only output ports of partitions that have one fan-out each.
Output pins with an output enable signal cannot be packed into the device I/O cell if the output enable logic is part of a different partition from the output register. To allow register packing for output pins with an output enable signal, structure your HDL code or design partition assignments so that the register and tri-state logic are defined in the same partition.
Bidirectional pins are handled in the same way as output pins with an output enable signal. If the registers that need to be packed are in the same partition as the tri-state logic, you can perform register packing.
The restrictions on tri-state logic exist because the I/O atom (device primitive) is created as part of the partition that contains tri‑state logic. If an I/O register and its tri‑state logic are contained in the same partition, the register can always be packed with tri-state logic into the I/O atom. The same cross-partition register packing restrictions also apply to I/O atoms for input and output pins. The I/O atom must feed the I/O pin directly with exactly one signal. The path between the I/O atom and the I/O pin must include only ports of partitions that have one fan-out each.
Create Design Partition
create_partition [-h | -help] [-long_help] -contents <hierarchy name> -partition <partition name>
-h | -help
Long help with examples and possible return values
|-contents <hierarchy name>||
Partition contents (hierarchy assigned to Partition)
|-partition <partition name>||
Enable or Disable Partition Assignments During Compilation
set_global_assignment -name IGNORE_PARTITIONS <value>
The Intel® Quartus® Prime software recognizes the design partitions assignments set in the current Intel® Quartus® Prime project and recompiles the partition in subsequent compilations depending on their netlist status.
The Intel® Quartus® Prime software does not recognize design partitions assignments set in the current Intel® Quartus® Prime project and performs a compilation without regard to partition boundaries or netlists.
Set Partition Netlist Type
set_global_assignment -name PARTITION_NETLIST_TYPE <value> -section_id <partition name>
Set Fitter Preservation Level
set_global_assignment -name PARTITION_FITTER_PRESERVATION_LEVEL <value> -section_id <partition name>
Preserve High-Speed Optimization
set_global_assignment -name PARTITION_PRESERVE_HIGH_SPEED_TILES_ON
Specify Netlist and Ignore Source File Changes
set_global_assignment -name PARTITION_IGNORE_SOURCE_FILE_CHANGES ON -section_id "<partition name>"
Set Up and Compile AB_project
set project AB_project load_package incremental_compilation load_package flow project_open $project # Ensure that design partition assignments are not ignored set_global_assignment -name IGNORE_PARTITIONS \ OFF # Set up the partitions create_partition -contents A -name "Partition_A" create_partition -contents B -name "Partition_B" # Set the netlist types to post-fit for subsequent # compilations (all partitions are compiled during the # initial compilation since there are no post-fit netlists) set_partition -partition "Partition_A" -netlist_type POST_FIT set_partition -partition "Partition_B" -netlist_type POST_FIT # Run initial compilation export_assignments execute_flow -full_compile project_close
Fitter Optimization for AB_project
set project AB_project load_package flow load_package incremental_compilation load_package project project_open $project # Turn on Physical Synthesis Optimization set_high_effort_fmax_optimization_assignments # For A, set the netlist type to post-synthesis set_partition -partition "Partition_A" -netlist_type POST_SYNTH # For B, set the netlist type to post-fit set_partition -partition "Partition_B" -netlist_type POST_FIT # Also set Top to post-fit set_partition -partition "Top" -netlist_type POST_FIT # Run incremental compilation export_assignments execute_flow -full_compile project_close
Generate Partition Script
# load required package load_package database_manager # name and open the project set project <project_path/project_name> project_open $project # generate the design partition scripts generate_bottom_up_scripts <options> #close project project_close
# load required package load_package incremental_compilation # open project project_open <project name> # export partition to the .qxp and set preservation level export_partition -partition <partition name> -qxp <.qxp file name> -<options> #close project project_close
Import .qxp into Top-Level Design
# load required packages load_package incremental_compilation load_package project load_package flow # open project project_open <project name> #import partition import_partition -partition <partition name> -qxp <.qxp file> <-options> #close project project_close
When using a team-based incremental compilation design flow, the Generate Design Partition Scripts dialog box can write makefiles that automatically export lower‑level design partitions and import them into the top-level design whenever design files change.
|2016.05.03||16.0.0||Stated limitations about deprecated physical synthesis options.|
|2015.11.02||15.1.0||Changed instances of Quartus II to Intel® Quartus® Prime .|
|2015.05.04||15.0.0||Removed Early Timing Estimate feature support.|
Added restriction about smart compilation in Arria 10 devices.
Removed HardCopy device information. Revised information about Rapid Recompile. Added information about functional safety. Added information about flattening sub-partition hierarchies.
Added Turning On Supported Cross-boundary Optimizations.
Removed survey link.
The Partial Reconfiguration (PR) feature in the Intel® Quartus® Prime software allows you to reconfigure a portion of the FPGA dynamically, while the remainder of the device continues to operate.
This chapter assumes a basic knowledge of Altera’s FPGA design flow, incremental compilation, and LogicLock™ region features available in the Intel® Quartus® Prime software. It also assumes knowledge of the internal FPGA resources such as logic array blocks (LABs), memory logic array blocks (MLABs), memory types (RAM and ROM), DSP blocks, clock networks.
The Intel® Quartus® Prime software supports the PR feature for the Intel® Stratix® V device family and Cyclone® V devices whose part number ends in "SC", for example, 5CGXFC9E6F35I8NSC.
project: A Intel® Quartus® Prime project contains the design files, settings, and constraints files required for the compilation of your design.
revision: In the Intel® Quartus® Prime software, a revision is a set of assignments and settings for one version of your design. A Intel® Quartus® Prime project can have several revisions, and each revision has its own set of assignments and settings. A revision helps you to organize several versions of your design into a single project.
incremental compilation: This is a feature of the Intel® Quartus® Prime software that allows you to preserve results of previous compilations of unchanged parts of the design, while changing the implementation of the parts of your design that you have modified since your previous compilation of the project. The key benefits include timing preservation and compile time reduction by only compiling the logic that has changed.
partition: You can partition your design along logical hierarchical boundaries. Each design partition is independently synthesized and then merged into a complete netlist for further stages of compilation. With the Intel® Quartus® Prime incremental compilation flow, you can preserve results of unchanged partitions at specific preservation levels. For example, you can set the preservation levels at post-synthesis or post-fit, for iterative compilations in which some part of the design is changed. A partition is only a logical partition of the design, and does not necessarily refer to a physical location on the device. However, you may associate a partition with a specific area of the FPGA by using a floorplan assignment.
For more information on design partitions, refer to the Best Practices for Incremental Compilation Partitions and Floorplan Assignments chapter in the Intel® Quartus® Prime Handbook.
LogicLock region: A LogicLock region constrains the placement of logic in your design. You can associate a design partition with a LogicLock region to constrain the placement of the logic in the partition to a specific physical area of the FPGA.
For more information about LogicLock regions, refer to the Analyzing and Optimizing the Design Floorplan chapter in the Intel® Quartus® Prime Handbook Volume 2.
PR project: Any Intel® Quartus® Prime design project that uses the PR feature.
PR region: A design partition with an associated contiguous LogicLock region in a PR project. A PR project can have one or more PR regions that can be partially reconfigured independently. A PR region may also be referred to as a PR partition.
static region: The region outside of all the PR regions in a PR project that cannot be reprogrammed with partial reconfiguration (unless you reprogram the entire FPGA). This region is called the static region, or fixed region.
persona: A PR region has multiple implementations. Each implementation is called a persona. PR regions can have multiple personas. In contrast, static regions have a single implementation or persona.
PR control block: Dedicated block in the FPGA that processes the PR requests, handshake protocols, and verifies the CRC.
PR IP Core: Altera soft IP that can be used to configure the PR control block in the FPGA to mange the PR bitstream source.
The functions in the periphery, such as GPIOs or I/O Registers, are controlled by I/O configuration bits and therefore cannot be partially reconfigured. Clock multiplexers for GCLK and QCLK are also not partially reconfigurable because they are controlled by I/O periphery bits.
These are the types of resource blocks in a Stratix V device.
Hardware Resource Block
Digital Signal Processing
Dynamic Reconfiguration ALTGX_Reconfig
Dynamic Reconfiguration ALTGX_Reconfig
Clock network sources cannot be changed, but a PLL driving a clock network can be dynamically reconfigured
I/O Blocks and Other Periphery
The transceivers and PLLs in Altera FPGAs can be reconfigured using dynamic reconfiguration. For more information on dynamic reconfiguration, refer to the Dynamic Reconfiguration in Stratix V Devices chapter in the Stratix V Handbook.
Each PR region can have different design personas, that change with partial reconfiguration.
PR Region A has three personas associated with it; A1, A2, and A3. PR Region B has two personas; B1 and B2. Each persona for the two PR regions can implement different application specific logic, and using partial reconfiguration, the persona for each PR region can be modified without interrupting the operation of the device in the static or other PR region.
The following figure shows the top-level of a PR design, which includes a static region and two PR regions.
You can use partial reconfiguration in the SCRUB mode or the AND/OR mode. The mode you select affects your PR flow in ways detailed later in this chapter.
The CRAM bits control individual LABs, MLABs, M20K memory blocks, DSP blocks, and routing multiplexers in a design. The CRAM bits are organized into a frame structure representing vertical areas that correspond to specific locations on the FPGA. If you change a design and reconfigure the FPGA in a non-PR flow, the process reloads all the CRAM bits to a new functionality.
Configuration bitstreams used in a non-PR flow are different than those used in a PR flow. In addition to standard data and CRC check bits, configuration bitstreams for partial reconfiguration also include instructions that direct the PR control block to process the data for partial reconfiguration.
The configuration bitstream written into the CRAM is organized into configuration frames. If a LAB column passes through multiple PR regions, those regions share some programming frames.
The static regions controlled by the CRAM bits from the same programming frame as the PR region continue to operate. All the CRAM bits corresponding to a PR region are overwritten with new data, regardless of what was previously contained in the region.
The SCRUB mode of partial reconfiguration involves re-writing all the bits in an entire LAB column of the CRAM, including bits controlling any part of the static region above and below the PR region boundary being reconfigured. You can choose to scrub the values of the CRAM bits to 0, and then rewrite them by turning on the Use clear/set method along with Enable SCRUB mode. The Use clear/set method is the more reliable option, but can increase the size of your bitstream. You can also choose to simply Enable SCRUB mode.
If there are more than one PR regions along a LAB column, and you are trying to reconfigure one of the PR regions, it is not not possible to correctly determine the bits associated with the PR region that is not changing. For this reason, you can not use the SCRUB mode when you have two PR regions that have a vertically overlapping column in the device. This restriction does not apply to the static bits because they never change and you can rewrite them with the same value of the configuration bit.
If you turn on Enable SCRUB mode and do not turn on Use clear/set method, then the scrub is done in a single pass, writing new values of the CRAM without clearing all the bits first. The advantage of using the SCRUB mode is that the programming file size is much smaller than the AND/OR mode.
This is the floorplan of a FPGA using SCRUB mode, with two PR regions, whose columns do not overlap.
Simplistically, this can be compared to bits being ANDed with a MASK, and ORed with new values, allowing multiple PR regions to vertically overlap a single column. In the first pass, all the bits in the CRAM frame for a column passing through a PR region are ANDed with '0's while those outside the PR region are ANDed with '1's. After the first pass, all the CRAM bits corresponding to the PR region are reset without modifying the static region. In the second pass for each CRAM frame, new data is ORed with the current value of 0 inside the PR region, and in the static region, the bits are ORed with '0's so they remain unchanged. The programming file size of a PR region using the AND/OR mode could be twice the programming file size of the same PR region using SCRUB mode.
A partial reconfiguration programming bitstream for AND/OR mode makes two passes on the PR region; the first pass clears all relevant bits, and the second pass sets the necessary bits. Due to this two-pass sequence, the size of a partial bitstream can be larger than a full FPGA programming bitstream depending on the size of the PR region.
When using the AND/OR mode for partial reconfiguration, the formula which describes the approximate file size within ten percent is:PR bitstream size = ((Size of region in the horizontal direction) /(full horizontal dimension of the part)) * 2 * (size of full bitstream)
The way the Fitter reserves routing for partial reconfiguration increases the effective size for small PR regions from a bitstream perspective. PR bitstream sizes in designs with a single small PR region will not match the file size computed by this equation.
Turn on Partial reconfiguration, Reserved, Enabled, and Constrain routing to stay within region boundaries.
You can also control expansion of the routing regions by adding the following two assignments to your Intel® Quartus® Prime Settings file (.qsf):set_global_assignment -name LL_ROUTING_REGION Expanded -section_id <region name> set_global_assignment -name LL_ROUTING_REGION_EXPANSION_SIZE 0 -section_id <region name>
Adding these to your .qsf disables expansion and minimizes the bitstream size.
Two types of revisions are specific to partial reconfiguration: reconfigurable and aggregate. Both import the persona for the static region from the base revision. A reconfigurable revision generates personas for PR regions. An aggregate revision is used to combine personas from multiple reconfigurable revisions to create a complete design suitable for timing analysis.
The design flow for partial reconfiguration also utilizes the Intel® Quartus® Prime incremental compilation flow. To take advantage of incremental compilation for partial reconfiguration, you must organize your design into logical and physical partitions for synthesis and fitting. The partitions for which partial reconfiguration is enabled (PR partitions) must also have associated LogicLock assignments.
Revisions make use of personas, which are subsidiary archives describing the characteristics of both static and reconfigurable regions, that contain unique logic which implements a specific set of functions to reconfigure a PR region of the FPGA. Partial reconfiguration uses personas to pass this logic from one revision to another.
The PR design flow requires more initial planning than a standard design flow. Planning requires setting up the design logic for partitioning, and determining placement assignments to create a floorplan. Well-planned partitions can help improve design area utilization and performance, and make timing closure easier. You should also decide whether your system requires partial reconfiguration to originate from the FPGA pins or internally, and which mode you are using; the AND/OR mode or the SCRUB mode, because this influences some of the planning steps described in this section.
You must structure your source code or design hierarchy to ensure that logic is grouped correctly for optimization. Implementing the correct logic grouping early in the design cycle is more efficient than restructuring the code later. The PR flow requires you to be more rigorous about following good design practices. The guidelines for creating partitions for incremental compilation also include creating partitions for partial reconfiguration.
Use the following best practice guidelines for designing in the PR flow, which are described in detail in this section:
- Determining resources for partial reconfiguration
- Partitioning the design for partial reconfiguration
- Creating incremental compilation partitions for partial reconfiguration
- Instantiating the PR IP core in the design
- Creating wrapper logic for PR regions
- Creating freeze logic for PR regions
- Planning clocks and other global signals for the PR design
- Creating floorplan assignments for the PR design
You must create design partitions for each PR region that you want to partially reconfigure. Optionally, you can also create partitions for the static parts of the design for timing preservation and/or for reducing compilation time.
There is no limit on the number of independent partitions or PR regions you can create in your design. You can designate any partition as a PR partition by enabling that feature in the LogicLock Regions window in the Intel® Quartus® Prime software.
- In-System Memory Content EditorI
- In-System Signals & Probes
- Virtual JTAG
- Nios II with debug module
- Signal Tap tap or trigger sources
- Register all partition boundaries; register all inputs and outputs of each partition when possible. This practice prevents any delay penalties on signals that cross partition boundaries and keeps each register-to-register timing path within one partition for optimization.
- Minimize the number of paths that cross partition boundaries.
- Minimize the timing-critical paths passing in or out of PR regions. If there are timing-critical paths that cross PR region boundaries, rework the PR regions to avoid these paths.
- The Intel® Quartus® Prime software can optimize some types of paths between design partitions for non-PR designs. However, for PR designs, such inter-partition paths are strictly not optimized.
For more information about incremental compilation, refer to the following chapter in the Intel® Quartus® Prime Handbook.
If you perform PR in internal host mode, you do not have to instantiate the PR control block and the CRC block, since they are are instantiated for you by the PR IP core. Instantiation of the partial reconfiguration controller is required only if your design includes partial reconfiguration in external host mode. Please refer to the Partial Reconfiguration with an External Host topic for more details.
When you are manually instantiating the Stratix® V Control Block and CRC block, you may want to add the PR control and CRC blocks at the top level of the design.
For example, in a design named Core_Top, all the logic is contained under the Core_Top module hierarchy. Create a wrapper (Chip_Top) at the top-level of the hierarchy that instantiates this Core_Top module, the Stratix® V PR control block, and the Stratix® V CRC check modules.
If you are performing partial reconfiguration from pins, then the required pins should be on the I/O list for the top-level (Chip_Top) of the project, as shown in the code in the following examples. If you are performing partial reconfiguration from within the core, you may choose another configuration scheme, such as Active Serial, to transmit the reconfiguration data into the core, and then assemble it to 16-bit wide data inside the FPGA within your logic. In such cases, the PR pins are not part of the FPGA I/O.
-- The Stratix V control block interface component stratixv_prblock is port( clk: in STD_LOGIC := '0'; corectl: in STD_LOGIC := '0'; data: in STD_LOGIC_VECTOR(15 downto 0) := (others => '0'); done: out STD_LOGIC; error: out STD_LOGIC; externalrequest: out STD_LOGIC; prrequest: in STD_LOGIC := '0'; ready: out STD_LOGIC ); end component; -- The Stratix V CRC block for diagnosing CRC errors component stratixv_crcblock is port( shiftnld: in STD_LOGIC ; clk: in STD_LOGIC ; crcerror: out STD_LOGIC ); end component;
The following rules apply when connecting the PR control block to the rest of your design:
- The corectl signal must be set to ‘1’ (when using partial reconfiguration from core) or to ‘0’ (when using partial reconfiguration from pins).
- The corectl signal has to match the Enable PR pins option setting in the Device and Pin Options dialog box on the Setting page; if you have turned on Enable PR pins, then the corectl signal on the PR control block instantiation must be toggled to ‘0’.
- When performing partial reconfiguration from pins the Intel® Quartus® Prime software automatically assigns the PR unassigned pins. If you so choose, you can make pin assignments to all the dedicated PR pins in Pin Planner or Assignment Editor.
- When performing partial reconfiguration from core, you can connect the prblock signals to either core logic or I/O pins, excluding the dedicated programming pin such as DCLK.
entity Chip_Top is port ( --User I/O signals (excluding PR related signals) .. .. ); end Chip_Top; -- Following shows the architecture behavior of Chip_Top m_pr : stratixv_prblock port map( clk => dclk, corectl =>'0', --1 - when using PR from inside --0 - for PR from pins; You must also enable -- the appropriate option in Intel® Quartus® Prime settings prrequest => pr_request, data => pr_data, error => pr_error, ready => pr_ready, done => pr_done ); m_crc : stratixv_crcblock port map( shiftnld => '1', --If you want to read the EMR register when clk => dummy_clk, --error occurrs, refer to AN539 for the --connectivity forthis signal. If you only want --to detect CRC errors, but plan to take no --further action, you can tie the shiftnld --signal to logical high. crcerror => crc_error );
For more information on port connectivity for reading the Error Message Register (EMR), refer to the following application note.
module Chip_Top ( //User I/O signals (excluding PR related signals) .. .. //PR interface & configuration signals pr_request, pr_ready, pr_done, crc_error, dclk, pr_data, init_done ); //user I/O signal declaration .. .. //PR interface and configuration signals declaration input pr_request; output pr_ready; output pr_done; output crc_error; input dclk; input [15:0] pr_data; output init_done stratixv_prblock stratixv_prblock_inst ( .clk (dclk), .corectl (1'b0), .prrequest(pr_request), .data (pr_data), .error (pr_error), .ready (pr_ready), .done (pr_done) ); stratixv_crcblock stratixv_crcblock_inst ( .clk (clk), .shiftnld (1'b1), .crcerror (crc_error) ); endmodule
For more information on port connectivity for reading the Error Message Register (EMR), refer to the following application note.
Implementing the same boundary ports ensures that all ports of a PR region remain stationary regardless of the underlying persona, so that the routing from the static logic does not change with different PR persona implementations.
If one persona of your PR region has a different number of ports than others, then you must create a wrapper so that the static region always communicates with this wrapper. In this wrapper, you can create dummy ports to ensure that all of the PR personas of a PR region have the same connection to the static region.
The sample code below each create two personas; persona_1 and persona_2 are different functions of one PR region. Note that one persona has a few dummy ports. The first example creates partial reconfiguration wrapper logic in Verilog HDL:
// Partial Reconfiguration Wrapper in Verilog HDL module persona //this module is persona_1 ( input reset, input [2:0] a, input [2:0] b, input [2:0] c, output [3:0] p, output [7:0] q ); reg [3:0] p, q; always@(a or b) begin p = a + b ; end always@(a or b or c or p) begin q = (p*a - b*c ) end endmodule module persona //this module is persona_2 ( input reset, input [2:0] a, input [2:0] b, input [2:0] c, //never used in this persona output [3:0] p, output [7:0] q //never assigned in this persona ); reg [3:0] p, q; always@(a or b) begin p = a * b; // note q is not assigned value in this persona end endmodule
The following example creates partial reconfiguration wrapper logic in VHDL.
-- Partial Reconfiguration Wrapper in VHDL -- this module is persona_1 entity persona is port( a:in STD_LOGIC_VECTOR (2 downto 0); b:in STD_LOGIC_VECTOR (2 downto 0); c:in STD_LOGIC_VECTOR (2 downto 0); p: out STD_LOGIC_VECTOR (3 downto 0); q: out STD_LOGIC_VECTOR (7 downto 0) ); end persona; architecture synth of persona is begin process(a,b) begin p <= a + b; end process; process (a, b, c, p) begin q <= (p*a - b*c); end process; end synth; -- this module is persona_2 entity persona is port( a:in STD_LOGIC_VECTOR (2 downto 0); b:in STD_LOGIC_VECTOR (2 downto 0); c:in STD_LOGIC_VECTOR (2 downto 0); --never used in this persona p:out STD_LOGIC_VECTOR (3 downto 0); q:out STD_LOGIC_VECTOR (7 downto 0) --never used in this persona ); end persona_2; architecture synth of persona_2 is begin process(a, b) begin p <= a *b; --note q is not assigned a value in this persona end process; end synth;
When you instantiate the Altera PR IP core in your design, the IP incudes a freeze port which you can use to freeze the non-global inputs of the PR region. In case your design has multiple PR regions, you must create decoding logic to freeze only the inputs of the PR region being partially reconfigured.
If you are not using the Altera PR IP, you must include logic to freeze the inputs of the PR regions in the design as required for proper operation.
Freezing all non-global inputs for the PR region ensures there is no contention between current values that may result in unexpected behavior of the design after partial reconfiguration is complete. Global signals going into the PR region should not be frozen to high. The Intel® Quartus® Prime software freezes the outputs from the PR region; therefore the logic outside of the PR region is not affected.
During partial reconfiguration, the static region logic should not depend on the outputs from PR regions to be at a specific logic level for the continued operation of the static region.
The easiest way to control the inputs to PR regions is by creating a wrapper around the PR region in RTL. In addition to freezing all inputs high, you can also drive the outputs from the PR block to a specific value, if required by your design. For example, if the output drives a signal that is active high, then your wrapper could freeze the output to GND. The idea is to make sure the static region will not stall or go to indeterminate state, when the PR region is getting a new persona through PR.
The following example implements a freeze wrapper in Verilog HDL, on a module named pr_module.
module freeze_wrapper ( input reset, // global reset signal input freeze, // PR process active, generated by user logic input clk1, // global clock signal input clk2, // non-global clock signal input [3:0] control_mode, input [3:0] framer_ctl, output [15:0] data_out ); wire [3:0]control_mode_wr, framer_ctl_wr; wire clk2_to_wr; //instantiate pr_module pr_module pr_module ( .reset (reset), //input .clk1 (clk1), //input, global clock .clk2 (clk2_to_wr), // input, non-global clock .control_mode (control_mode_wr), //input .framer_ctl (framer_ctl_wr), //input .pr_module_out (data_out) // collection of outputs from pr_module ); // Freeze all inputs assign control_mode_wr = freeze ? 4'hF: control_mode; assign framer_ctl_wr = freeze ? 4'hF: framer_ctl; assign clk2_to_wr = freeze ? 1'b1 : clk2; endmodule
The following example implements a freeze wrapper in VHDL, on a module named pr_module.
entity freeze_wrapper is port( reset:in STD_LOGIC; -- global reset signal freeze:in STD_LOGIC; clk1: in STD_LOGIC; -- global signal clk2: in STD_LOGIC; -- non-global signal control_mode: in STD_LOGIC_VECTOR (3 downto 0); framer_ctl: in STD_LOGIC_VECTOR (3 downto 0); data_out: out STD_LOGIC_VECTOR (15 downto 0) ); end freeze_wrapper; architecture behv of freeze_wrapper is component pr_module port( reset:in STD_LOGIC; clk1:in STD_LOGIC; clk2:in STD_LOGIC; control_mode:in STD_LOGIC_VECTOR (3 downto 0); framer_ctl:in STD_LOGIC_VECTOR (3 downto 0); pr_module_out:out STD_LOGIC_VECTOR (15 downto 0) ); end component signal control_mode_wr: in STD_LOGIC_VECTOR (3 downto 0); signal framer_ctl_wr : in STD_LOGIC_VECTOR (3 downto 0); signal clk2_to_wr : STD_LOGIC; signal data_out_temp : STD_LOGIC_VECTOR (15 downto 0); signal logic_high : STD_LOGIC_VECTOR (3 downto 0):="1111"; begin data_out(15 downto 0) <= data_out_temp(15 downto 0); m_pr_module: pr_module port map ( reset => reset, clk1 => clk1, clk2 => clk2_to_wr, control_mode =>control_mode_wr, framer_ctl => framer_ctl_wr, pr_module_out => data_out_temp); -- freeze all inputs control_mode_wr <= logic_high when (freeze ='1') else control_mode; framer_ctl_wr <= logic_high when (freeze ='1') else framer_ctl; clk2_to_wr <= logic_high(0) when (freeze ='1') else clk2; end architecture;
There are 16 global clock networks in a Stratix V device. However, only six unique clocks can drive a row clock region limiting you to a maximum of six global signals in each PR region. The Intel® Quartus® Prime software must ensure that any global clock can feed every location in the PR region.
The limit of six global signals to a PR region includes the GCLK, QCLK and PCLKs used inside of the PR region. Make QSF assignments for global signals in your project's Intel® Quartus® Prime Settings File (.qsf), based on the clocking requirements for your design. In designs with multiple clocks that are external to the PR region, it may be beneficial to align the PR region boundaries to be within the global clock boundary (such as QCLK or PCLK).
If your PR region requires more than six global signals, modify the region architecture to reduce the number of global signals within this to six or fewer. For example, you can split a PR region into multiple regions, each of which uses only a subset of the clock domains, so that each region does not use more than six.
Every instance of a PR region that uses the global signals (for example, PCLK, QCLK, GCLK, ACLR) must use a global signal for that input.
Global signals can only be used to route certain secondary signals into a PR region and the restrictions for each block are listed in the following table. Data signals and other secondary signals not listed in the table, such as synchronous clears and clock enables are not supported.
Supported Signals for Global/Periphery/Quadrant Clock Networks
|Clock, ACLR, Write Enable(WE), Read Enable(RE)|
- If a global signal feeds both static and reconfigurable logic, the restrictions in the table also apply to destinations in the static region. For example, the same global signal cannot be used as an SCLR in the static region and an ACLR in the PR region.
- A global signal used for a PR region should only feed core blocks inside and outside the PR region. In particular you should not use a clock source for a PR region and additionally connect the signal to an I/O register on the top or bottom of the device. Doing so may cause the Assembler to give an error because it is unable to create valid programming mask files.
There is no minimum or maximum size for the LogicLock region assigned for a PR region. Because wire-LUTs are added on the periphery of a PR region by the Intel® Quartus® Prime software, the LogicLock region for a PR region must be slightly larger than an equivalent non-PR region. Make sure the PR regions include only the resources that can be partially reconfigured; LogicLock regions for PR can only contain only LABs, DSPs, and RAM blocks. When creating multiple PR regions, make sure there is at least one static region column between each PR region. When multiple PR regions are present in a design, the shape and alignment of the region determines whether you use the SCRUB or AND/OR PR mode.
You can use the default Auto size and Floating location LogicLock region properties to estimate the preliminary size and location for the PR region.
You can also define regions in the floorplan that match the general location and size of the logic in each partition. You may choose to create a LogicLock region assignment that is non-rectangular, depending on the design requirements, but disjoint LogicLock regions are not allowed for PR regions in your first compilation of the project.
After compilation, use the Fitter-determined size and origin location as a starting point for your design floorplan. Check the quality of results obtained for your floorplan location assignments and make changes to the regions as needed.
Alternatively, you can perform Analysis and Synthesis, and then set the regions to the required size based on resource estimates. In this case, use your knowledge of the connections between partitions to place the regions in the floorplan.
For more information on making design partitions and using an