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.

• 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.

Figure 2. Compilation Report

• Processing tab—displays messages from the most recent process
• System tab—displays messages unrelated to design processing
• Search—locates specific messages

Messages are written to stdout when you use command-line executables.

Figure 3. Messages Window

You can suppress display of unimportant messages so they do not obscure valid messages.

Figure 4. Message Suppression by Message ID Number

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.

Figure 5. Settings Dialog Box for Global Project Settings

The Assignment Editor (Tools > Assignment Editor) provides a spreadsheet-like interface for assigning all instance-specific settings and constraints.

Figure 6. Assignment Editor Spreadsheet

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.

Figure 7. Design Space Explorer II

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 f_MAX 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.

Figure 8. Comparing Project Revisions

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.

Figure 9. Design and IP Files in Project Navigator

Right-click files in the Project Navigator to:

• Open and edit the file
• Remove File from Project
• Set as Top-Level Entity for the project revision
• Create a Symbol File for Current File for display in schematic editors
• Edit file Properties

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.

Figure 10. Timing Analyzer and SDC Syntax Example

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.

The Intel^® Quartus^® Prime software installs IP cores in the following locations by default:

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:

1. Generate simulation model, testbench (or example design), and simulator setup script files.
2. Set up your simulator environment and any simulation scripts.
3. Compile simulation model libraries.
4. Run your simulator.

• 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.

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.

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).

Figure 21. 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.

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.

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.

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.

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.

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.

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.

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.

• 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.

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.

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.

or

• Use the Design Partitions window to modify the design partition properties and turn on Ignore changes in source files and strictly use the specified netlist, if available.

The Fitter applies the same design flow to all partitions that belong to the same safety IP. If more than one safety IP is used in the design, the Fitter may evoke different flows for different safety IPs.

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

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.

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.

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 optimize partitions.
  • If designers are part of the same design environment, they can check out the required project files from the same source control system. This is the recommended way to share a set of project files.
  • Otherwise, the project lead can provide a copy of the top-level project framework so that each design develops their partition within the same project framework.
• If a partition designer does not have access to the top-level project framework, the project lead can give the partition designer a Tcl script or other documentation to create the separate 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 Controls under More Settings on the Fitter page in the Settings dialog box. Alternatively, you can set the Global Signal assignment to Off for signals that should not be placed on global routing lines.

    Placement for LABs depends on whether the inputs to the logic cells within the LAB use a global clock. You may encounter problems if signals do not use global lines in the partition, but use global routing in the top-level design.

• Use the Virtual Pin assignment to indicate pins of a partition that do not drive pins in the top-level design. This is critical when a partition has more output ports than the number of pins available in the target device. Using virtual pins also helps optimize cross-partition paths for a complete design by enabling you to provide more information about the partition ports, such as location and timing assignments.
• When partitions are compiled independently without any information about each other, you might need to provide more information about the timing paths that may be affected by other partitions in the top-level design. You can apply location assignments for each pin to indicate the port location after incorporation in the top-level design. You can also apply timing assignments to the I/O ports of the partition to perform timing budgeting.

• 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.

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.

• 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.

• 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 Origin to Floating, the following conditions apply:
  • If the region’s member placement is preserved with an imported partition, the Fitter chooses a new Origin and re-places the logic, preserving the relative placement of the member logic within the region.
  • If the region’s member placement is preserved with a Post-Fit netlist type, the Fitter does not change the Origin location, and reuses the previous placement results.

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.

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.

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.

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.

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.

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

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.

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;