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 Intel^® Quartus^® Prime incremental compilation feature allows you to partition a design, compile partitions separately, and reuse results for unchanged partitions. Incremental compilation provides the following benefits:

• Reduces compilation times by an average of 75% for large design changes
• Preserves performance for unchanged design blocks
• Provides repeatable results and reduces the number of compilations
• Enables team-based design flows

To prepare your design for incremental compilation, you first determine which logical hierarchy boundaries should be defined as separate partitions in your design, and ensure your design hierarchy and source code is set up to support this partitioning. You can then create design partition assignments in the Intel^® Quartus^® Prime software to specify which hierarchy blocks are compiled independently as partitions (including empty partitions for missing or incomplete logic blocks).

During compilation, Intel^® Quartus^® Prime Analysis & Synthesis and the Fitter create separate netlists for each partition. Netlists are internal post-synthesis and post-fit database representations of your design.

In subsequent compilations, you can select which netlist to preserve for each partition. You can either reuse the synthesis or fitting netlist, or instruct the Intel^® Quartus^® Prime software to resynthesize the source files. You can also use compilation results exported from another Intel^® Quartus^® Prime project.

When you make changes to your design, the Intel^® Quartus^® Prime software recompiles only the designated partitions and merges the new compilation results with existing netlists for other partitions, according to the degree of results preservation you set with the netlist for each design partition.

In some cases, Altera recommends that you create a design floorplan with placement assignments to constrain parts of the design to specific regions of the device.

You must use the partial reconfiguration (PR) feature in conjunction with incremental compilation for Stratix^® V device families. Partial reconfiguration allows you to reconfigure a portion of the FPGA dynamically, while the remainder of the device continues to operate as intended.

Use the following general guidelines to set the netlist type for each partition:

• Source File—Use this setting to resynthesize the source code (with any new assignments, and replace any previous synthesis or Fitter results).
  • If you modify the design source, the software automatically resynthesizes the partitions with the appropriate netlist type, which makes the Source File setting optional in this case.
  • Most assignments do not trigger an automatic recompilation, so you must set the netlist type to Source File to compile the source files with new assignments or constraints that affect synthesis.
• Post-Synthesis (default)—Use this setting to re-fit the design (with any new Fitter assignments), but preserve the synthesis results when the source files have not changed. If it is difficult to meet the required timing performance, you can use this setting to allow the Fitter the most flexibility in placement and routing. This setting does not reduce compilation time as much as the Post-Fit setting or preserve timing performance from the previous compilation.
• Post-Fit—Use this setting to preserve Fitter and performance results when the source files have not changed. This setting reduces compilation time the most, and preserves timing performance from the previous compilation.
• Post-Fit with Fitter Preservation Level set to Placement—Use the Advanced Fitter Preservation Level setting on the Advanced tab in the Design Partition Properties dialog box to allow more flexibility and find the best routing for all partitions given their placement.

The Intel^® Quartus^® Prime software Rapid Recompile feature instructs the Compiler to reuse the compatible compilation results if most of the design has not changed since the last compilation. This feature reduces compilation time and preserves performance when there are small and isolated design changes within a partition, and works with all netlist type settings. With this feature, you do not have control over which parts of the design are recompiled; the Compiler determines which parts of the design must be recompiled.

Compiling all design partitions in a single Intel^® Quartus^® Prime project ensures that all design logic is compiled with a consistent set of assignments, and allows the software to perform global placement and routing optimizations. Compiling all design logic together is beneficial for FPGA design flows because all parts of the design must use the same shared set of device resources. Therefore, it is often easier to ensure good quality of results when partitions are developed within a single top-level Intel^® Quartus^® Prime project.

If any partitions are developed independently, the project lead must ensure that top-level constraints (such as timing constraints, any relevant floorplan or pin assignments, and optimization settings) are consistent with those used by all designers.

Planning involves setting up the design logic for partitioning and may also involve planning placement assignments to create a floorplan. Not all design flows require floorplan assignments. If you decide to add floorplan assignments later, when the design is close to completion, well-planned partitions make floorplan creation easier. Poor partition or floorplan assignments can worsen design area utilization and performance and make timing closure more difficult.

As FPGA devices get larger and more complex, following good design practices become more important for all design flows. Adhering to recommended synchronous design practices makes designs more robust and easier to debug. Using an incremental compilation flow adds additional steps and requirements to your project, but can provide significant benefits in design productivity by preserving the performance of critical blocks and reducing compilation time.

When partitions are placed together, the Fitter can perform placement optimizations on the design as a whole to optimize the placement of cross-boundary paths. However, the Fitter can never perform logic optimizations such as physical synthesis across the partition boundary. If partitions are fit separately in different projects, or if some partitions use previous post-fitting results, the Fitter does not place and route the entire cross-boundary path at the same time and cannot fully optimize placement across the partition boundaries. Good design partitions can be placed independently because cross-partition paths are not the critical timing paths in the design.

• Partitions can increase resource utilization due to cross-boundary optimization limitations if the design does not follow partitioning guidelines. Floorplan assignments can also increase resource utilization because regions can lead to unused logic. If your device is full with the flat version of your design, you can focus on creating partitions and floorplan assignments for timing-critical or 
often-changing blocks to benefit most from incremental compilation.
• Partitions and floorplan assignments might increase routing utilization compared to a flat design. If long compilation times are due to routing congestion, you might not be able to use the incremental flow to reduce compilation time. Review the Fitter messages to check how much time is spent during routing optimizations to determine the percentage of routing utilization. When routing is difficult, you can use incremental compilation to lock the routing for routing-critical blocks only (with other partitions empty), and then compile the rest of the design after the critical blocks meets their requirements.
• Partitions can reduce timing performance in some cases because of the optimization and resource effects described above, causing longer logic delays. Floorplan assignments restrict logic placement, which can make it more difficult for the Fitter to meet timing requirements. Use the guidelines in this manual to reduce any effect on your design performance.

You can turn on the cross-boundary optimizations for your design partitions on the Advanced tab of the Design Partition Properties dialog box. Once you change the optimization settings, the Intel^® Quartus^® Prime software recompiles your partition from source automatically. Cross-boundary optimizations include the following: propagate constants, propagate inversions on partition inputs, merge inputs fed by a common source, merge electrically equivalent bidirectional pins, absorb internal paths, and remove logic connected to dangling outputs.

Cross-boundary optimizations are implemented top-down from the parent partition into the child partition, but not vice-versa. The cross-boundary optimization feature cannot be used with partitions with multiple personas (partial reconfiguration partitions).

Although more partitions allow for a greater reduction in compilation time, consider limiting the number of partitions to prevent degradation in the quality of results. Creating good design partitions and good floorplan location assignments helps to improve the design resource utilization and timing performance results for cross-partition paths.

• When planning your design hierarchy, keep logic in the “leaves” of the hierarchy instead of having logic at the top-level of the design so that you can isolate partitions if required.
• Create entities that can form partitions of approximately equal size. For example, do not instantiate small entities at the same hierarchy level, because it is more difficult to group them to form reasonably-sized partitions.
• Create each entity in an independent file. The Intel^® Quartus^® Prime software uses a file checksum to detect changes, and automatically recompiles a partition if its source file changes and its netlist type is set to either post-synthesis or post-fit. If the design entities for two partitions are defined in the same file, changes to the logic in one partition initiates recompilation for both partitions.
• Design dependencies also affect which partitions are compiled when a source file changes. If two partitions rely on the same lower-level entity definition, changes in that lower-level entity affect both partitions. Commands such as VHDL use and Verilog HDL include create dependencies between files, so that changes to one file can trigger recompilations in all dependent files. Avoid these types of file dependencies if possible. The Partition Dependent Files report for each partition in the Analysis & Synthesis section of the Compilation report lists which files contribute to each partition.

• Consider how many partitions you want to maintain in your design to determine the size of each partition. Your compilation time reduction goal is also a factor, because compiling small partitions is typically faster than compiling large partitions.
• There is no minimum size for partitions; however, having too many partitions can reduce the quality of results by limiting optimization. Ensure that the design partitions are not too small. As a general guideline, each partition should contain more than approximately 2,000 logic elements (LEs) or adaptive logic modules (ALMs). If your design is incomplete when you partition the design, use previous designs to help estimate the size of each block.

Try to isolate timing-critical logic from logic that you expect to easily meet timing requirements. Doing so allows you to preserve the satisfactory results for non-critical partitions and focus optimization iterations on only the timing-critical portions of the design to minimize compilation time.

As a general rule, create partitions to isolate logic that will change from logic that will not change. Partitioning a design in this way maximizes the preservation of unchanged logic and minimizes compilation time.

The design partition guidelines include examples of the types of optimizations that are prevented by partition boundaries, and describes how you can structure or modify your partitions to avoid these limitations.

If every partition boundary has a register as shown in the figure, every register-to-register timing path between partitions includes only routing delay. Therefore, the timing paths between partitions are likely not timing-critical, and the Fitter can generally place each partition independently from other partitions. This advantage makes it easier to create floorplan location assignments for each separate partition, and is especially important for flows in which partitions are placed independently in separate Intel^® Quartus^® Prime projects. Additionally, the partition boundary does not affect combinational logic optimization because each register-to-register logic path is contained within a single partition.

If a design cannot include both input and output registers for each partition due to latency or resource utilization concerns, choose to register one end of each connection. If you register every partition output, for example, the combinational logic that occurs in each cross-partition path is included in one partition so that it can be optimized together.

It is a good synchronous design practice to include registers for every output of a design block. Registered outputs ensure that the input timing performance for each design block is controlled exclusively within the destination logic block.

This guideline is most important for timing-critical and high-speed connections between partitions, especially in cases where the input and output of each partition is not registered. Slow connections that are not timing-critical are acceptable because they should not impact the overall timing performance of the design. If there are timing-critical paths between partitions, rework or merge the partitions to avoid these inter-partition paths.

When dividing your design into partitions, consider the types of functions at the partition boundaries. The figure shows an expansive function with more outputs than inputs in the left diagram, which makes a poor partition boundary, and, on the right side, a better place to assign the partition boundary that minimizes 
cross-partition I/Os. Adding registers to one or both sides of the cross-partition path in this example would further improve partition quality.

Another way to minimize connections between partitions is to avoid using combinational ”glue logic” between partitions. You can often move the logic to the partition at one end of the connection to keep more logic paths within one partition. For example, the bottom diagram includes a new level of hierarchy C defined as a partition instead of block B. Clearly, there are fewer I/O connections between partitions A and C than between partitions A and B.

In some cases, especially if part of the design is complete or comes from another designer, the designer might not have followed these guidelines when the source code was created. These guidelines are not mandatory to implement an incremental compilation flow, but can improve the quality of results. If assigning a partition affects resource utilization or timing performance of a design block as compared to the flat design, it might be due to one of the issues described in the logic optimization across partitions guidelines below. Many of the examples suggest simple changes to your partition definitions or hierarchy to move the partition boundary to improve your results.

The following guidelines ensure that your design does not require logic optimization across partition boundaries:

Within the single merged partition, the Intel^® Quartus^® Prime software can use the constants to optimize and remove much of the logic in block B (shown in gray), as shown in the figure.

If your design has these types of connections, redefine the partition boundaries to remove the affected ports. If one signal from a higher-level partition feeds two input ports of the same partition, feed the one signal into the partition, and then make the two connections within the partition. If an output port drives an input port of the same partition, the connection can be made internally without going through any I/O ports. If an input port drives an output port directly, the connection can likely be implemented without the ports in the lower-level partition by connecting the signals in a higher-level partition.

The figure shows the clock signal inversion in the destination partitions.

Notice that this diagram also shows another example of a single pin feeding two ports of a partition boundary. In the left diagram, partition B does not have the information that the clock and inverted clock come from the same source. In the right diagram, partition B has more information to help optimize the design because the clock is connected as one port of the partition.

Input pin cross-partition register packing requires the following specific circumstances:

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

Output pin cross-partition register packing requires the following specific circumstances:

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

The following examples of I/O register packing illustrate this point using Block Design File (.bdf) schematics to describe the design logic.

If the top-level design instantiates the subdesign with a single fan-out directly feeding an output pin, and designates the subdesign as a separate design partition, the Intel^® Quartus^® Prime software can perform cross-partition register packing because the single partition port feeds the output pin directly.

In this example, the top-level design instantiates the subdesign as an output register with more than one fan-out signal.

In this case, the Intel^® Quartus^® Prime software does not perform output register packing. If there is a Fast Output Register assignment on pin out, the software issues a warning that the Fitter cannot pack the node to an I/O pin because the node and the I/O cell are connected across a design partition boundary.

This type of cross-partition register packing is not allowed because it requires modification to the interface of the subdesign partition. To perform incremental compilation, the Intel^® Quartus^® Prime software must preserve the interface of design partitions.

To allow the Intel^® Quartus^® Prime software to pack the register in the subdesign with the output pin out in the figure, restructure your HDL code so that output registers directly connect to output pins by making one of the following changes:

• Place the register in the same partition as the output pin. The simplest method is to move the register from the subdesign partition into the partition containing the output pin. Doing so guarantees that the Fitter can optimize the two nodes without violating partition boundaries.
• Duplicate the register in your subdesign HDL so that each register feeds only one pin, and then connect the extra output pin to the new port in the top-level design. Doing so converts the cross-partition register packing into the simplest case where each register has a single fan-out.

In these cases, the Intel^® Quartus^® Prime software does not perform register packing. If there is a Fast Input Register assignment on pin in, as shown in the top figure, or a Fast Output Register assignment on pin out, as shown in the bottom figure, the Intel^® Quartus^® Prime software issues a warning that the Fitter cannot pack the node to an I/O pin because the node and I/O cell are connected across a design partition boundary.

This type of register packing is not allowed because it requires moving logic across a design partition boundary to place into a single I/O device atom. To perform register packing, either the register must be moved out of the subdesign partition, or the inverter must be moved into the subdesign partition to be implemented in the register.

To allow the Intel^® Quartus^® Prime software to pack the single register in the subdesign with the input pin in, as shown in top figure or the output pin out, as shown in the bottom figure, restructure your HDL code to place the register in the same partition as the inverter by making one of the following changes:

• Move the register from the subdesign partition into the top-level partition containing the pin. Doing so ensures that the Fitter can optimize the I/O register and inverter without violating partition boundaries.
• Move the inverter from the top-level block into the subdesign, and then connect the subdesign directly to a pin in the top-level design. Doing so allows the Fitter to optimize the inverter into the register implementation, so that the register is directly connected to a pin, which enables register packing.

The figures below show a design with partitions that are not supported for incremental compilation due to the internal tri-state output logic on the partition boundaries. Instead of using internal tri-state logic for partition outputs, implement the correct logic to select between the two signals. Doing so is good practice even when there are no partitions, because such logic explicitly defines the behavior for the internal signals instead of relying on the Intel^® Quartus^® Prime software to convert the tri-state signals into logic.

Do not use tri-state signals or bidirectional ports on hierarchical partition boundaries, unless the port is connected directly to a top-level I/O pin on the device. If you must use internal tri-state logic, ensure that all the control and destination logic is contained in the same partition, in which case the Intel^® Quartus^® Prime software can convert the internal tri-state signals into combinational logic as in a flat design. In this example, you can also merge all three partitions into one partition, as shown in the bottom figure, to allow the Intel^® Quartus^® Prime software to treat the logic as internal tri-state and perform the same type of optimization as a flat design. If possible, you should avoid using internal 
tri-state logic in any Altera FPGA design to ensure that you get the desired implementation when the design is compiled for the target device architecture.

The figure shows a design with tri-state output signals that feed a device bidirectional I/O pin (assuming that the input connection feeds elsewhere in the design and is not shown in the figure). In the left diagram below, the tri-state output signals appear as the outputs of two separate partitions. In this case, the Intel^® Quartus^® Prime software cannot implement the specified logic and maintain incremental functionality. In the right diagram, partitions A and B are merged to group the logic from the two blocks. With this single partition, the Intel^® Quartus^® Prime software can merge the two tri-state output signals and implement them in the tri-state logic available in the device I/O element.

• Include logic in the same partition for optimization and merging
• Include constants in the same partition as logic
• Avoid signals that drive multiple partition I/O or connect I/O together
• Invert clocks in destination partitions
• Connect I/O directly to I/O register for packing across partition boundaries
• Do not use internal tri-states
• Include all tri-state and enable logic in the same partition

Remember that these guidelines are not mandatory when implementing an incremental compilation flow, but can improve the quality of results. When creating source design code, follow these guidelines and organize your HDL code to support good partition boundaries. For designs that are complete, assess whether assigning a partition affects the resource utilization or timing performance of a design block as compared to the flat design. Make the appropriate changes to your design or hierarchy, or merge partitions as required, to improve your results.

In some cases, having one global reset signal can lead to recovery and removal time problems. This issue is not specific to incremental flows; it could be applicable in any large high-speed design. In an incremental flow, the global reset signal creates a timing dependency between the top-level partition and lower-level partitions.

For incremental compilation, it is helpful to minimize the impact of global structures. To isolate each partition, consider adding reset synchronizers. Using cascaded reset structures, the intent is to reduce the inter-partition fan-out of the reset signal, thereby minimizing the effect of the global signal. Reducing the fan-out of the global reset signal also provides more flexibility in routing the cascaded signals, and might help recovery and removal times in some cases.

This recommendation can help in large designs, regardless of whether you are using incremental compilation. However, if one global signal can feed all the logic in its domain and meet recovery and removal times, this recommendation may not be applicable for your design. Minimizing global structures is more relevant for 
high-performance designs where meeting timing on the reset logic can be challenging. Isolating each partition and allowing more flexibility in global routing structures is an additional advantage in incremental flows.

If you add additional reset synchronizers to your design, latency is also added to the reset path, so ensure that this is acceptable in your design. Additionally, parts of the design may come out of the reset state in different clock cycles. You can balance the latency or add hand-shaking logic between partitions, if necessary, to accommodate these differences.

The signal is first synchronized on the chip following good synchronous design practices, meaning that the design asynchronously resets, but synchronously releases from reset to avoid any race conditions or metastability problems. Then, to minimize the impact of global structures, the circuit employs a divide-and-conquer approach for the reset structure. By implementing a cascaded reset structure, the reset paths for each partition are independent. This structure reduces the effect of inter-partition dependency because the inter-partition reset signals can now be treated as false paths for timing analysis. In some cases, the reset signal of the partition can be placed on local lines to reduce the delay added by routing to a global routing line. In other cases, the signal can be routed on a regional or quadrant clock signal.

The figure shows a cascaded reset structure.

This circuit design can help you achieve timing closure and partition independence for your global reset signal. Evaluate the circuit and consider how it works for your design.

Alternatively, an IP designer can export just the post-synthesis results to be integrated in the top-level design when the post-fitting results from the IP project are not required. Using a post-synthesis netlist provides more flexibility to the Intel^® Quartus^® Prime Fitter, so that less resource allocation is required. If a common project is not possible, especially when the project lead plans to integrate the IP's post-fitting results, it is important that the project lead and IP designer clearly communicate their requirements.

You can constrain logic utilization for the IP core using design floorplan location assignments. The design should specify I/O pin locations with pin assignments.

You can also specify limits for Intel^® Quartus^® Prime synthesis to allocate and balance resources. This procedure can also help if device resources are overused in the individual partitions during synthesis.

In the standard synthesis flow, the Intel^® Quartus^® Prime software can perform automated resource balancing for DSP blocks or RAM blocks and convert some of the logic into regular logic cells to prevent overuse.

You can use the Intel^® Quartus^® Prime synthesis options to control inference of IP cores that use the DSP, or RAM blocks. You can also use the IP Catalog and Parameter Editor to customize your RAM or DSP IP cores to use regular logic instead of the dedicated hardware blocks.

Global routing signals can cause conflicts when independent partitions are integrated into a top-level design. The Intel^® Quartus^® Prime software automatically promotes high fan-out signals to use global routing resources available in the device. Third-party partitions can use the same global routing resources, thus causing conflicts in the top-level design. Additionally, LAB placement depends on whether the inputs to the logic cells within the LAB use a global clock signal. Problems can occur if a design does not use a global signal in a lower-level partition, but does use a global signal in the top-level design.

If the exported IP core is small, you can reduce the potential for problems by using constraints to promote clock and high fan-out signals to regional routing signals that cover only part of the device, instead of global routing signals. In this case, the Intel^® Quartus^® Prime software is likely to find a routing solution in the top-level design because there are many regional routing signals available on most Altera devices, and designs do not typically overuse regional resources.

To ensure that an IP block can utilize a regional clock signal, view the resource coverage of regional clocks in the Chip Planner, and then align LogicLock regions that constrain partition placement with available global clock routing resources. For example, if the LogicLock region for a particular partition is limited to one device quadrant, that partition’s clock can use a regional clock routing type that covers only one device quadrant. When all partition logic is available, the project lead can compile the entire design at the top level with floorplan assignments to allow the use of regional clocks that span only a part of the device.

If global resources are heavily used in the overall design, or the IP designer requires global clocks for their partition, you can set up constraints to avoid signal overuse at the top-level by assigning the appropriate type of global signals or setting a maximum number of clock signals for the partition.

You can use the Global Signal assignment to force or prevent the use of a global routing line, making the assignment to a clock source node or signal. You can also assign certain types of global clock resources in some device families, such as regional clocks. For example, if you have an IP core, such as a memory interface that specifies the use of a dual regional clock, you can constrain the IP to part of the device covered by a regional clock and change the Global Signal assignment to use a regional clock. This type of assignment can reduce clocking congestion and conflicts.

Alternatively, partition designers can specify the number of clocks allowed in the project using the maximum clocks allowed options in the Advanced Settings (Fitter) dialog box. Specify Maximum number of clocks of any type allowed, or use the Maximum number of global clocks allowed, Maximum number of regional clocks allowed, and Maximum number of periphery clocks allowed options to restrict the number of clock resources of a particular type in your design.

If you require more control when planning a design with integrated partitions, you can assign a specific signal to use a particular clock network in newer device families by assigning the clock control block instance called CLKCTRL. You can make a point-to-point assignment from a clock source node to a destination node, or a single-point assignment to a clock source node with the Global Clock CLKCTRL Location logic option. Set the assignment value to the name of the clock control block: CLKCTRL_G <global network number> for a global routing network, or CLKCTRL_R <regional network number> for a dedicated regional routing network in the device.

If you want to disable the automatic global promotion performed in the Fitter to prevent other signals from being placed on global (or regional) routing networks, turn off the Auto Global Clock and Auto Global Register Control Signals options in the Advanced Settings (Fitter) dialog box.

If you are using design partition scripts for independent partitions, the Intel^® Quartus^® Prime software can automatically write the commands to pass global constraints and turn off automatic options.

Alternatively, to avoid problems when integrating partitions into the top-level design, you can direct the Fitter to discard the placement and routing of the partition netlist by using the post-synthesis netlist, which forces the Fitter to reassign all the global signals for the partition when compiling the top-level design.

You can create a virtual pin assignment in the Assignment Editor for partition I/Os that will become internal nodes in the top-level design. When you apply the Virtual Pin assignment to an input pin, the pin no longer appears as an FPGA pin, but is fixed to GND or VCC in the design. The assigned pin is not an open node. Leave the clock pins mapped to I/O pins to ensure proper routing.

You can specify locations for the virtual pins that correspond to the placement of other partitions, and also make timing assignments to the virtual pins to define a timing budget. Virtual pins are created automatically from the top-level design if you use design partition scripts. The scripts place the virtual pins to correspond with the placement of the other partitions in the top-level design.

To ensure that the software correctly optimizes the input and output logic in any independent partitions, you might be required to perform some manual timing budgeting. For each unregistered timing path that crosses between partitions, make timing assignments on the corresponding I/O path in each partition to constrain both ends of the path to the budgeted timing delay. Assigning a timing budget for each part of the connection ensures that the software optimizes the paths appropriately.

When performing manual timing budgeting in a partition for I/O ports that become internal partition connections in a top-level design, you can assign location and timing constraints to the virtual pin that represents each connection to further improve the quality of the timing budget.

Connecting the clock signal directly avoids any timing analysis difficulties with gated clocks. Clock gating is never recommended for FPGA designs because of potential glitches and clock skew. Clock gating can be especially problematic with exported partitions because the partitions have no information about gating that takes place at the top-level design or in another partition. If a gated clock is required in a partition, perform the gating within that partition.

Direct connections to input clock pins also allows design partition scripts to send constraints from the top-level device pin to lower-level partitions.

If the project lead creates a copy of the top-level project framework that includes 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 you use a separate Intel^® Quartus^® Prime project for an independent design block (such as when a designer or third-party IP provider does not have access to the entire design framework), include a copy of the top-level PLL in the lower-level partition as shown in figure.

In either case, the IP partition in the separate Intel^® Quartus^® Prime project should contain just the partition logic that will be exported to the top-level design, while the full project includes more information about the top-level design. When the partition is complete, you can export just the partition without exporting the auxiliary PLL components to the top-level design. When you export a partition, the Intel^® Quartus^® Prime software exports any hierarchy under the specified partition into the Intel^® Quartus^® Prime Exported Partition File (.qxp), but does not include logic defined outside the partition (the PLL in this example).

To view a design and create design partitions in the Design Partition Planner, you must first compile the design, or perform Analysis & Synthesis. In the Design Partition Planner, the design appears as a single top-level design block, with lower-level instances displayed as color-specific boxes.

In the Design Partition Planner, you can show connectivity between blocks and extract instances from the top-level design block. When you extract entities, connection bundles are drawn between entities, showing the number of connections existing between pairs of entities. When you have extracted a design block that you want to set as a design partition, right-click that design block, and then click Create Design Partition.

The Design Partition Planner also has an auto-partition feature that creates partitions based on the size and connectivity of the hierarchical design blocks. You can right-click the design block you want to partition (such as the top-level design hierarchy), and then click Auto-Partition Children. You can then analyze and adjust the partition assignments as required.

The figure shows the Design Partition Planner after making a design partition assignment to one instance and dragging another instance away from the top-level block within the same partition (two design blocks in the pale blue shaded box). The figure shows the connections between each partition and information about the size of each design instance.

Figure 27. Design Partition Planner

You can switch between connectivity display mode and hierarchical display mode, to examine the view-only hierarchy display. You can also remove the connection lines between partitions and I/O banks by turning off Display connections to I/O banks, or use the settings on the Connection Counting tab in the Bundle Configuration dialog box to adjust how the connections are counted in the bundles.

To optimize design performance, confine failing paths within individual design partitions so that there are no failing paths passing between partitions. In the top-level entity, child entities that contain failing paths are marked by a small red dot in the upper right corner of the entity box.

To view the critical timing paths from a timing analyzer report, first perform a timing analysis on your design, and then in the Design Partition Planner, click Show Timing Data on the View menu.

To view the Design Partition Planner and Chip Planner side-by-side, open the Design Partition Planner, and then open the Chip Planner and select the Design Partition Planner task. The Design Partition Planner task displays the physical locations of design entities with the same colors as in the Design Partition Planner.

In the Design Partition Planner, you can extract instances of interest from their parents by dragging and dropping, or with the Extract from Parent command. Evaluate the physical locations of instances in the Chip Planner and the connectivity between instances displayed in the Design Partition Planner. An entity is generally not suitable to be set as a separate design partition or constrained in a LogicLock region if the Chip Planner shows it physically dispersed over a noncontiguous area of the device after compilation. Use the Design Partition Planner to analyze the design connections. Child instances that are unsuitable to be set as separate design partitions or placed in LogicLock regions can be returned to their parent by dragging and dropping, or with the Collapse to Parent command.

The figure shows a design displayed in the Design Partition Planner and the Chip Planner with different colors for the top-level design and the three major design instances.

Figure 28. Design Partition Planner and Chip Planner

The Partition Merge Partition Statistics report in the Partition Merge section of the Compilation report lists statistics about each partition. The statistics for each partition (each row in the table) include the number of logic cells, as well as the number of input and output pins and how many are registered. This report also lists how many ports are unconnected, or driven by a constant V_CC or GND. You can use this information to assess whether you have followed the guidelines for partition boundaries.

You can also view statistics about the resource and port connections for a particular partition on the Statistics tab of the Design Partition Properties dialog box. The Show All Partitions button allows you to view all the partitions in the same report. The Partition Merge Partition Statistics report also shows statistics for the Internal Congestion: Total Connections and Registered Connections. This information represents how many signals are connected within the partition. It then lists the inter-partition connections for each partition, which helps you to see how partitions are connected to each other.

You can use these reports to analyze the location of the critical timing paths in the design in relation to partitions. If a certain partition contains many failing paths, or failing inter-partition paths, you might be able to change your partitioning scheme and improve timing performance.

1. Start with a complete design that is not partitioned and has no location or LogicLock region assignments.

   To run a full compilation, use the Start Compilation command.

2. Record the quality of results from the Compilation report (timing slack or f_MAX, area and any other relevant results).
3. Create design partitions following the guidelines described in this manual.
4. Recompile the design.
5. Record the quality of results from the Compilation report. If the quality of results is significantly worse than those obtained in the previous compilation, repeat step 3 through step 5 to change your partition assignments and use a different partitioning scheme.
6. Even if the quality of results is acceptable, you can repeat step 3 through step 5 by further dividing a large partition into several smaller partitions, which can improve compilation time in subsequent incremental compilations. You can repeat these steps until you achieve a good trade-off point (that is, all critical paths are localized within partitions, the quality of results is not negatively affected, and the size of each partition is reasonable).

You can also remove or disable partition assignments defined in the top-level design at any time during the design flow to compile the design as one flat compilation and get all possible design optimizations to assess the results. To disable the partitions without deleting the assignments, use the Ignore partition assignments during compilation option on the Incremental Compilation page of the Settings dialog box in the Intel^® Quartus^® Prime software. This option disables all design partition assignments in your project and runs a full compilation, ignoring all partition boundaries and netlists. This option can be useful if you are using partitions to reduce compilation time as you develop various parts of the design, but can run a long compilation near the end of the design cycle to ensure the design meets its timing requirements.

Passing additional timing constraints from a partition to the top-level design must be managed carefully. You can design within a single Intel^® Quartus^® Prime project or a copy of the top-level design to simplify constraint management.

To ensure that there are no conflicts between the project lead’s top-level constraints and those added by the third-party IP designer, use two .sdc files for each separate Intel^® Quartus^® Prime project: an .sdc created by the project lead that includes project-wide constraints, and an .sdc created by the IP designer that includes partition-specific constraints.

The example design shown in the figure below is used to illustrate recommendations for managing the timing constraints in a third-party IP delivery flow. The top-level design instantiates a lower-level design block called module_A  that is set as a design partition and developed by an IP designer in a separate Intel^® Quartus^® Prime project.

In this top-level design, there is a single clock setting called clk associated with the FPGA input called top_level_clk. The top-level .sdc contains the following constraint for the clock:

create_clock -name {clk} -period 3.000 -waveform { 0.000 1.500 } \
[get_ports {TOP_LEVEL_CLK}]

The .sdc with project-wide constraints is used in the partition, but is not exported back to the top-level design. The partition designer should not modify this file. If changes are necessary, they should be communicated to the project lead, who can then update the SDC constraints and distribute new files to all partition designers as required.

The .sdc should include clock creation and clock constraints for any clock used by more than one partition. These constraints are particularly important when working with complex clocking structures, such as the following:

• Cascaded clock multiplexers
• Cascaded PLLs
• Multiple independent clocks on the same clock pin
• Redundant clocking structures required for secure applications
• Virtual clocks and generated clocks that are consistently used for source synchronous interfaces
• Clock uncertainties

Additionally, the .sdc with project-wide constraints should contain all project-wide timing exception assignments, such as the following:

• Multicycle assignments, set_multicycle_path
• False path assignments, set_false_path
• Maximum delay assignments, set_max_delay
• Minimum delay assignments, set_min_delay

The project-wide .sdc can also contain any set_input_delay or set_output_delay constraints that are used for ports in separate Intel^® Quartus^® Prime projects, because these represent delays external to a given partition. If the partition designer wants to set these constraints within the separate Intel^® Quartus^® Prime projects, the team must ensure that the I/O port names are identical in all projects so that the assignments can be integrated successfully without changes.

Similarly, a constraint on a path that crosses a partition boundary should be in the project-wide .sdc, because it is not completely localized in a separate Intel^® Quartus^® Prime project.

The device input top_level_clk in Figure 29 drives the input_clk port of module_A. To make sure the clock constraint is passed correctly to the partition, the project lead creates an .sdc with project-wide constraints for module_A that contains the following command:

create_clock -name {clk} -period 3.000 -waveform { 0.000 1.500 } [get_ports {INPUT_CLK}]

The designer of module_A includes this .sdc as part of the separate Intel^® Quartus^® Prime project.

The partition-specific .sdc should be maintained by the partition designer; they must add any constraints required to properly compile and analyze their partition.

The partition-specific .sdc is used in the separate Intel^® Quartus^® Prime project and must be exported back to the project lead for the top-level design. The project lead must use the partition-specific constraints to properly constrain the placement, routing, or both, if the partition logic is fit at the top level, and to ensure that final timing sign-off is accurate. Use the following guidelines in the partition-specific .sdc to simplify these export and integration steps:

• Create a hierarchy variable for the partition (such as module_A_hierarchy) and set it to an empty string because the partition is the top-level instance in the separate Intel^® Quartus^® Prime project. The project lead modifies this variable for the top-level hierarchy, reducing the effort of translating constraints on lower-level design hierarchies into constraints that apply in the top-level hierarchy. Use the following Tcl command first to check if the variable is already defined in the project, so that the top-level design does not use this empty hierarchy path: if {![info exists module_A_hierarchy]}.
• Use the hierarchy variable in the partition-specific .sdc as a prefix for assignments in the project. For example, instead of naming a particular instance of a register reg:inst, use ${module_A_hierarchy}reg:inst. Also, use the hierarchy variable as a prefix to any wildcard characters (such as ” * ”).
• Pay attention to the location of the assignments to I/O ports of the partition. In most cases, these assignments should be specified in the .sdc with project-wide constraints, because the partition interface depends on the top-level design. If you want to set I/O constraints within the partition, the team must ensure that the I/O port names are identical in all projects so that the assignments can be integrated successfully without changes.
• Use caution with the derive_clocks and derive_pll_clocks commands. In most cases, the .sdc with project-wide constraints should call these commands. Because these commands impact the entire design, integrating them unexpectedly into the top-level design might cause problems.

If the design team follows these recommendations, the project lead should be able to include the .sdc with the partition-specific constraints provided by the partition designer directly in the top-level design.

if {![info exists module_A_hierarchy]} {
	set module_A_hierarchy ""
} 
set_false_path -from [get_registers ${module_A_hierarchy}reg_in_1] \
-to [get_registers ${module_A_hierarchy}*]

To set up the top-level .sdc constraint file to accept the .sdc files from the separate Intel^® Quartus^® Prime projects, the top-level .sdc should define the hierarchy variables specified in the partition .sdc files. List the variable for each partition and set it to the hierarchy path, up to and including the instantiation of the partition in the top-level design, including the final hierarchy character ”|”.

To ensure that the .sdc files are used in the correct order, the project lead can use the Tcl Source command to load each .sdc.

create_clock -name {clk} -period 3.000 -waveform { 0.000 1.500 } \
[get_ports {TOP_LEVEL_CLK}]
# Include the lower-level SDC file
set module_A_hierarchy "module_A:inst|"  # Note the final '|' character
source <partition-specific constraint file such as ..\module_A\module_A_constraints>.sdc

When the project lead performs top-level timing analysis, the false path assignment from the lower-level module_A project expands to the following:

set_false_path -from module_A:inst|reg_in_1 -to module_A:inst|*

Adding the hierarchy path as a prefix to the SDC command makes the constraint legal in the top-level design, and ensures that the wildcard does not affect any nodes outside the partition that it was intended to target.

In the Intel^® Quartus^® Prime software, LogicLock regions can be used to constrain blocks of a design to a particular region of the device. LogicLock regions represent an area on the device with a user-defined or Fitter-defined size and location in the device layout.

A common misconception is that logic from a design partition is always grouped together on the device when you use incremental compilation. Actually, logic from a partition can be placed anywhere in the device if it is not constrained to a LogicLock region, although the Fitter can pack related logic together to improve timing performance. A logical design partition does not refer to any physical area on the device and does not directly control where instances are placed on the device.

If you want to control the placement of logic from a design partition and isolate it to a particular part of the device, you can assign the logical design partition to a physical region in the device floorplan with a LogicLock region assignment. Altera recommends creating a design floorplan by assigning design partitions to LogicLock regions to improve the quality of results and avoid placement conflicts in some situations for incremental compilation.

Another misconception is that LogicLock assignments are used to preserve placement results for incremental compilation. Actually, LogicLock regions only constrain logic to a physical region on the device. Incremental compilation does not use LogicLock assignments or any location assignments to preserve the placement results; it simply reuses the results stored in the database netlist from a previous compilation.

• To avoid resource conflicts between partitions, predominantly when integrating partitions exported from another Intel^® Quartus^® Prime project.
• To ensure good quality of results when recompiling individual timing-critical partitions.

Location assignments for each partition ensure that there are no placement conflicts between partitions. If there are no LogicLock region assignments, or if LogicLock regions are set to auto-size or floating location, no device resources are specifically allocated for the logic associated with the region. If you do not clearly define resource allocation, logic placement can conflict when you integrate the partitions in the top-level design if you reuse the placement information from the exported netlist.

Creating a floorplan is also recommended for timing-critical partitions that have little timing margin to maintain good quality of results when the design changes.

Floorplan assignments are not required for non-critical partitions compiled in the same Intel^® Quartus^® Prime project. The logic for partitions that are not timing-critical can be placed anywhere in the device on each recompilation if that is best for your design.

Design floorplan assignments prevent the situation in which the Fitter must place a partition in an area of the device where most resources are used by other partitions. A LogicLock region 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.

The figure illustrates the problems that may be associated with refitting designs that do not have floorplan location assignments. The left floorplan shows the initial placement of a four-partition design (P1-P4) without any floorplan location assignments. The right floorplan shows the device if a change occurs to P3. After removing the logic for the changed partition, the Fitter must re-place and reroute the new logic for P3 in the scattered white space. The placement of the post-fit netlists for other partitions forces the Fitter to implement P3 with the device resources that have not been used.

The Fitter has a more difficult task because of more difficult physical constraints, and as a result, compilation time often increases. The Fitter might not be able to find any legal placement for the logic in partition P3, even if it could in the initial compilation. Additionally, if the Fitter can find a legal placement, the quality of results often decreases in these cases, sometimes dramatically, because the new partition is now scattered throughout the device.

The figure below shows the initial placement of a four-partition design with floorplan location assignments. Each partition is assigned to a LogicLock region. The second part of the figure shows the device after partition P3 is removed. This placement presents a much more reasonable task to the Fitter and yields better results.

Altera recommends that you create a LogicLock floorplan assignment for timing-critical blocks with little timing margin that will be recompiled as you make changes to the design.

When you have compiled your complete design, or after you have integrated the first versions of partitions developed in separate Intel^® Quartus^® Prime projects, you can use the design information and Intel^® Quartus^® Prime features to tune and improve the floorplan .

• Capture correct resources in each region.
• Use good region placement to maintain design performance compared to flat compilation.

A common misconception is that creating a floorplan enhances timing performance, as compared to a flat compilation with no location assignments. The Fitter does not usually require guidance to get optimal results for a full design.

Floorplan assignments can help maintain good performance when designs change incrementally. However, poor placement assignments in an incremental compilation can often adversely affect performance results, as compared to a flat compilation, because the assignments limit the options for the Fitter. Investing time to find good region placement is required to match the performance of a full flat compilation.

In most cases, you should include logic from one partition in each LogicLock region. This organization helps to prevent resource conflicts when partitions are exported and can lead to better performance preservation when locking down parts of a design in a single project.

The Intel^® Quartus^® Prime software is flexible and allows exceptions to this rule. For example, you can place more than one partition in the same LogicLock region if the partitions are tightly connected, but you do not want to merge the partitions into one larger partition. For best results, ensure that you recompile all partitions in the LogicLock region every time the logic in one partition changes. Additionally, if a partition contains multiple lower-level entities, you can place those entities in different areas of the device with multiple LogicLock regions, even if they are defined in the same partition.

You can use the Reserved LogicLock option to ensure that you avoid conflicts with other logic that is not locked into a LogicLock region. This option prevents other logic from being placed in the region, and is useful if you have empty partitions at any point during your design flow, so that you can reserve space in the floorplan. Do not make reserved regions too large to prevent unused area because no other logic can be placed in a region with the Reserved LogicLock option.

In a late floorplan, when the design is complete, you can use locations or regions chosen by the Fitter as a guideline. If you have compiled the full design, you can view the location of the partition logic in the Chip Planner. You can use the natural grouping of each unconstrained partition as a starting point for a LogicLock region constraint. View the placement for each partition that requires a floorplan constraint, and create a new LogicLock region by drawing a box around the area on the floorplan, and then assigning the partition to the region to constrain the partition placement.

Instead of creating regions based on the previous compilation results, you can start with the Fitter results for a default auto size and floating origin location for each new region when the design logic is complete. After compilation, lock the size and origin location.

Alternatively, if the design logic is complete with auto-sized or floating location regions, you can specify the size based on the synthesis results and use the locations chosen by the Fitter with the Set to Estimated Size command. Like the previous option, start with floating origin location. After compilation, lock the origin location. You can also enable the Fast Synthesis Effort setting to reduce synthesis time.

After a compilation, save the Fitter size and origin location of the Fitter with the Set Size and Origin to Previous Fitter Results command.

The easiest way to move and resize regions is to drag the region location and borders in the Chip Planner. Make sure that you select the User-Defined region in the floorplan (as opposed to the Fitter-Placed region from the last compilation) so that you can change the region.

Generally, you can keep the Fitter-determined relative placement of the regions, but make adjustments if required to meet timing performance. Performing a full compilation ensures that the Fitter can optimize for a full placement and routing.

If two LogicLock regions have several connections between them, ensure they are placed near each other to improve timing performance. By placing connected regions near each other, the Fitter has more opportunity to optimize inter-region paths when both partitions are recompiled. Reducing the criticality of inter-region paths also allows the Fitter more flexibility when placing other logic in each region.

If resource utilization is low in the overall device, enlarge the regions. Doing so usually improves the final results because it gives the Fitter more freedom to place additional or modified logic added to the partition during subsequent incremental compilations. It also allows room for optimizations such as pipelining and logic duplication.

Try to have each region evenly full, with the same ”fullness” that the complete design would have without LogicLock regions; Altera recommends approximately 75% full.

Allow more area for regions that are densely populated, because overly congested regions can lead to poor results. Allow more empty space for timing-critical partitions to improve results. However, do not make regions too large for their logic. Regions that are too large can result in wasted resources and also lead to suboptimal results.

Ideally, almost the entire device should be covered by LogicLock regions if all partitions are assigned to regions.

Regions should not overlap in the device floorplan. If two partitions are allocated on an overlapping portion of the chip, each may independently claim common resources in this region. This leads to resource conflicts when integrating results into a top-level design. In a single project, overlapping regions give more difficult constraints to the Fitter and can lead to reduced quality of results.

You can create hierarchical LogicLock regions to ensure that the logic in a child partition is physically placed inside the LogicLock region for its parent partition. This can be useful when the parent partition does not contain registers at the boundary with the lower-level child partition and has a lot of signal connectivity. To create a hierarchical relationship between regions in the LogicLock Regions window, drag and drop the child region to the parent region.

Place regions close to the appropriate I/O, if necessary. For example, DDR memory interfaces have very strict placement rules to meet timing requirements. Incorporate any specific placement requirements into your floorplan as required. You should create LogicLock regions for internal logic only, and provide pin location assignments for external device I/O pins (instead of including the I/O cells in a LogicLock region to control placement).

If your design contains memory or Digital Signal Processing (DSP) elements, you may want to exclude these elements from the LogicLock region. LogicLock resource exceptions prevent certain types of elements from being assigned to a region. Therefore, those elements are not required to be placed inside the region boundaries. The option does not prevent them from being placed inside the region boundaries unless the Reserved property of the region is turned on.

Resource exceptions are useful in cases where it is difficult to place rectangular regions for design blocks that contain memory and DSP elements, due to their placement in columns throughout the device floorplan. Exclude RAMs, DSPs, or logic cells to give the Fitter more flexibility with region sizing and placement. Excluding RAM or DSP elements can help to resolve no-fit errors that are caused by regions spanning too many resources, especially for designs that are memory-intensive, DSP-intensive, or both. The figure shows an example of a design with an odd-shaped region to accommodate DSP blocks for a region that does not contain very much logic. The right side of the figure shows the result after excluding DSP blocks from the region. The region can be placed more easily without wasting logic resources.

To view any resource exceptions, right-click in the LogicLock Regions window, and then click LogicLock Regions Properties. In the LogicLock Regions Properties dialog box, select the design element (module or entity) in the Members box, and then click Edit. In the Edit Node dialog box, to set up a resource exception, click the Edit button next to the Excluded element types box, and then turn on the design element types to be excluded from the region. You can choose to exclude combinational logic or registers from logic cells, or any of the sizes of TriMatrix memory blocks, or DSP blocks.

If the excluded logic is in its own lower-level design entity (even if it is within the same design partition), you can assign the entity to a separate LogicLock region to constrain its placement in the device.

You can also use this feature with the LogicLock Reserved property to reserve specific resources for logic that will be added to the design.

set_logiclock_contents -region <LogicLock region name> \
-to <block> -exceptions \"<keyword>:<keyword>"

• <LogicLock region name>—The name of the LogicLock region to which the code block is assigned.
• <block>—A code block in a Intel^® Quartus^® Prime project hierarchy, which can also be a design partition.
• <keyword>—The list of exceptions made during assignment. For example, if DSP was in the keyword list, the named block of code would be assigned to the LogicLock region, except for any DSP block within the code block. You can include the following exceptions in the set_logiclock_contents command:

Keyword variables:

• REGISTER—Any registers in the logic cells.
• COMBINATIONAL—Any combinational elements in the logic cells.
• SMALL_MEM—Small TriMatrix memory blocks (M512 or MLAB).
• MEDIUMEM_MEM—Medium TriMatrix memory blocks (M4K or M9K).
• LARGE_MEM—Large TriMatrix memory blocks (M-RAM or M144K).
• DSP—Any DSP blocks.
• VIRTUAL_PIN—Any virtual pins.

set_instance_assignment -name LL_MEMBER_RESOURCE_EXCLUDE \
"DSP:SMALL_MEM" -to "alu:alu_unit" -section_id ALU

For devices that do not support the Merge command (MAX^TM II devices), you can limit entity placement to a sub-area of a LogicLock region to create non-rectangular constraints. In these devices, construct a LogicLock hierarchy by creating child regions inside of parent regions, and then use the Reserved option to control which logic can be placed inside these child regions. Setting the Reserved option for the region prevents the Fitter from placing nodes that are not assigned to the region inside the boundary of the region.

The statistics report the number of resources used and the total resources covered by the region, and also lists the number of I/O connections and how many I/Os are registered (good), as well as the number of internal connections and the number of inter-region connections (bad).

In the Chip Planner, red LAB blocks indicate higher routing congestion. You can position the mouse pointer over a LAB to display a tooltip that reports the logic and routing utilization information.

• You should see only minor degradation in f_MAX after the design is partitioned and floorplan location assignments are created. There is some performance cost associated with setting up a design for incremental compilation; approximately 3% is typical.
• The area increase should be no more than 5% after the design is partitioned and floorplan location assignments are created.
• The time spent in the routing stage should not significantly increase.

The amount of compilation time spent in the routing stage is reported in the Messages window with an Info message that indicates the elapsed time for Fitter routing operations. If you notice a dramatic increase in routing time, the floorplan location assignments may be creating substantial routing congestion. In this case, decrease the number of LogicLock regions, which typically reduces the compilation time in subsequent incremental compilations and may also improve design performance.

As programmable logic designs become more complex and require increased performance, advanced synthesis becomes an important part of a design flow. The Altera^® Quartus^® II software includes advanced Integrated Synthesis that fully supports VHDL, Verilog HDL, and Altera-specific design entry languages, and provides options to control the synthesis process. With this synthesis support, the Intel^® Quartus^® Prime software provides a complete, easy-to-use solution.

The Intel^® Quartus^® Prime Analysis & Synthesis stage of the compilation flow runs Integrated Synthesis, which fully supports Verilog HDL, VHDL, and Altera-specific languages, and major features of the SystemVerilog language.

In the synthesis stage of the compilation flow, the Intel^® Quartus^® Prime software performs logic synthesis to optimize design logic and performs technology mapping to implement the design logic in device resources such as logic elements (LEs) or adaptive logic modules (ALMs), and other dedicated logic blocks. The synthesis stage generates a single project database that integrates all your design files in a project (including any netlists from third-party synthesis tools).

You can use Analysis & Synthesis to perform the following compilation processes:

Intel^® Quartus^® Prime Integrated Synthesis supports HDL. You can specify the Verilog HDL or VHDL language version in your design.

To ensure that the Intel^® Quartus^® Prime software reads all associated project files, add each file to your Intel^® Quartus^® Prime project by clicking Add/Remove Files in Project on the Project menu. You can add design files to your project. You can mix all supported languages and netlists generated by third-party synthesis tools in a single Intel^® Quartus^® Prime project.

The Intel^® Quartus^® Prime Compiler’s Analysis & Synthesis module fully supports the Altera Hardware Description Language (AHDL).

AHDL designs use Text Design Files (.tdf). You can import AHDL Include Files (.inc) into a .tdf with an AHDL include statement. Altera provides .inc files for all IP cores shipped with the Intel^® Quartus^® Prime software.

The Intel^® Quartus^® Prime Compiler’s Analysis & Synthesis module fully supports .bdf for schematic design entry.

The VHDL language provides several ways to map or bind an instance to an entity in a specific library.

The Intel^® Quartus^® Prime software supports parameters (known as generics in VHDL) and you can pass these parameters between design languages.

Click Assignments > Settings > Compiler Settings > Default Parameters to enter default parameter values for your design. In AHDL, the Intel^® Quartus^® Prime software inherits parameters, so any default parameters apply to all AHDL instances in your design. You can also specify parameters for instantiated modules in a .bdf. To specify parameters in a .bdf instance, double-click the parameter value box for the instance symbol, or right-click the symbol and click Properties, and then click the Parameters tab.

You can specify parameters for instantiated modules in your design source files with the provided syntax for your chosen language. Some designs instantiate entities in a different language; for example, they might instantiate a VHDL entity from a Verilog HDL design file. You can pass parameters or generics between VHDL, Verilog HDL, AHDL, and BDF schematic entry, and from EDIF or VQM to any of these languages. You do not require an additional procedure to pass parameters from one language to another. However, sometimes you must specify the type of parameter you are passing. In those cases, you must follow certain guidelines to ensure that the Intel^® Quartus^® Prime software correctly interprets the parameter value.

Default parameter values and BDF instance parameter values do not have an explicitly declared type. Usually, the Intel^® Quartus^® Prime software can correctly infer the type from the value without ambiguity. For example, the Intel^® Quartus^® Prime software interprets “ABC” as a string, 123 as an integer, and 15.4 as a floating-point value. In other cases, such as when the instantiated subdesign language is VHDL, the Intel^® Quartus^® Prime software uses the type of the parameter, generic, or both in the instantiated entity to determine how to interpret the value, so that the Intel^® Quartus^® Prime software interprets a value of 123 as a string if the VHDL parameter is of a type string. In addition, you can set the parameter value in a format that is legal in the language of the instantiated entity. For example, to pass an unsized bit literal value from .bdf to Verilog HDL, you can use '1 as the parameter value, and to pass a 4-bit binary vector from .bdf to Verilog HDL, you can use 4'b1111 as the parameter value.

In a few cases, the Intel^® Quartus^® Prime software cannot infer the correct type of parameter value. To avoid ambiguity, specify the parameter value in a type-encoded format in which the first or first and second characters of the parameter indicate the type of the parameter, and the rest of the string indicates the value in a quoted sub-string. For example, to pass a binary string 1001 from .bdf to Verilog HDL, you cannot use the value 1001, because the Intel^® Quartus^® Prime software interprets it as a decimal value. You also cannot use the string "1001" because the Intel^® Quartus^® Prime software interprets it as an ASCII string. You must use the type-encoded string B"1001" for the Intel^® Quartus^® Prime software to correctly interpret the parameter value.

This table lists valid parameter strings and how the Intel^® Quartus^® Prime software interprets the parameter strings. Use the type-encoded format only when necessary to resolve ambiguity.

You can select the parameter type for global parameters or global constants with the pull-down list in the Parameter tab of the Symbol Properties dialog box. If you do not specify the parameter type, the Intel^® Quartus^® Prime software interprets the parameter value and defines the parameter type. You must specify parameter type with the pull-down list to avoid ambiguity.

The Intel^® Quartus^® Prime software supports the following parameter types:

• Unsigned Integer
• Signed Integer
• Unsigned Binary
• Signed Binary
• Octal
• Hexadecimal
• Float
• Enum
• String
• Boolean
• Char
• Untyped/Auto

When passing a parameter between two different languages, a design block that is higher in the design hierarchy instantiates a lower-level subdesign block and provides parameter information. The subdesign language (the design entity that you instantiate) must correctly interpret the parameter. Based on the information provided by the higher-level design and the value format, and sometimes by the parameter type of the subdesign entity, the Intel^® Quartus^® Prime software interprets the type and value of the passed parameter.

When passing a parameter whose value is an enumerated type value or literal from a language that does not support enumerated types to one that does (for example, from Verilog HDL to VHDL), you must ensure that the enumeration literal is in the correct spelling in the language of the higher-level design block (block that is higher in the hierarchy). The Intel^® Quartus^® Prime software passes the parameter value as a string literal, and the language of the lower-level design correctly convert the string literal into the correct enumeration literal.

If the language of the lower-level entity is SystemVerilog, you must ensure that the enum value is in the correct case. In SystemVerilog, two enumeration literals differ in more than just case. For example, enum {item, ITEM} is not a good choice of item names because these names can create confusion and is more difficult to pass parameters from case-insensitive HDLs, such as VHDL.

Arrays have different support in different design languages. For details about the array parameter format, refer to the Parameter section in the Analysis & Synthesis Report of a design that contains array parameters or generics.

The following code shows examples of passing parameters from one design entry language to a subdesign written in another language.

type fruit is (apple, orange, grape);
entity vhdl_sub is
generic (
name : string := "default",
width : integer := 8,
number_string : string := "123",
f : fruit := apple,
binary_vector : std_logic_vector(3 downto 0) := "0101",
signed_vector : signed (3 downto 0) := "1111");

vhdl_sub inst (...);
defparam inst.name = "lower";
defparam inst.width = 3;
defparam inst.num_string = "321";
defparam inst.f = "grape"; // Must exactly match enum value
defparam inst.binary_vector = 4'b1010;
      defparam inst.signed_vector = 4'sb1010;

module veri_sub (...)
parameter name = "default";
parameter width = 8;
parameter number_string = "123";
parameter binary_vector = 4'b0101;
parameter signed_vector = 4'sb1111;

inst:veri_sub
generic map (
name => "lower",
width => 3,
number_string => "321"
binary_vector = "1010"
signed_vector = "1010")

To use an HDL subdesign such as the one shown in Table 13 in a top-level .bdf design, you must generate a symbol for the HDL file, as shown in Figure 34. Open the HDL file in the Intel^® Quartus^® Prime software, and then, on the File menu, point to Create/Update, and then click Create Symbol Files for Current File.

To specify parameters on a .bdf instance, double-click the parameter value box for the instance symbol, or right-click the symbol and click Properties, and then click the Parameters tab. Right-click the symbol and click Update Design File from Selected Block to pass the updated parameter to the HDL file.

You can also preserve the placement and routing information for unchanged partitions. This feature allows you to preserve performance of unchanged blocks in your design and reduces the time required for placement and routing, which significantly reduces your design compilation time.

If you want to preserve the Optimization Technique and Restructure Multiplexers logic options in any entity, you must create new partitions for the entity instead of using the Preserve Hierarchical Boundary logic option. If you have settings applied to specific existing design hierarchies, particularly those created in the Intel^® Quartus^® Prime software versions before 9.0, you must create a design partition for the design hierarchy so that synthesis can optimize the design instance independently and preserve the hierarchical boundaries.

The Parallel Synthesis logic option reduces compilation time for synthesis. The option enables the Intel^® Quartus^® Prime software to use multiple processors to synthesize multiple partitions in parallel.

This option is available when you perform the following tasks:

• Specify the maximum number of processors allowed under Parallel Compilation options in the Compilation Process Settings page of the Settings dialog box.
• Enable the incremental compilation feature.
• Use two or more partitions in your design.
• Turn on the Parallel Synthesis option.

By default, the Intel^® Quartus^® Prime software enables the Parallel Synthesis option. To disable parallel synthesis, click Assignments > Settings > Compiler Settings > Advanced Settings (Synthesis) > Parallel Synthesis.

You can also set the Parallel Synthesis option with the following Tcl command:

set_global_assignment -name parallel_synthesis off

If you use the command line, you can differentiate among the interleaved messages by turning on the Show partition that generated the message option in the Messages page. This option shows the partition ID in parenthesis for each message.

You can view all the interleaved messages from different partitions in the Messages window. The Partition column in the Messages window displays the partition ID of the partition referred to in the message. After compilation, you can sort the messages by partition.

You can use a .qxp as a source file in incremental compilation. The .qxp contains the precompiled design netlist exported as a partition from another Intel^® Quartus^® Prime project, and fully defines the entity. Project team members or intellectual property (IP) providers can use a .qxp to send their design to the project lead, instead of sending the original HDL source code. The .qxp preserves the compilation results and instance-specific assignments. Not all global assignments can function in a different Intel^® Quartus^® Prime project. You can override the assignments for the entity in the .qxp by applying assignments in the top-level design.

The Intel^® Quartus^® Prime software offers several options to help you control the synthesis process and achieve optimal results for your design.

The Intel^® Quartus^® Prime logic options control many aspects of the synthesis and placement and routing process. To set logic options in the Intel^® Quartus^® Prime software, on the Assignments menu, click Assignment Editor. You can also use a corresponding Tcl command to set global assignments. The Intel^® Quartus^® Prime logic options enable you to set instance or node-specific assignments without editing the source HDL code.

The Intel^® Quartus^® Prime software supports synthesis attributes for Verilog HDL and VHDL, also commonly called pragmas. These attributes are not standard Verilog HDL or VHDL commands. Synthesis tools use attributes to control the synthesis process. The Intel^® Quartus^® Prime software applies the attributes in the HDL source code, and attributes always apply to a specific design element. Some synthesis attributes are also available as Intel^® Quartus^® Prime logic options via the Intel^® Quartus^® Prime software or scripting. Each attribute description indicates a corresponding setting or a logic option that you can set in the Intel^® Quartus^® Prime software. You can specify only some attributes with HDL synthesis attributes.

Attributes specified in your HDL code are not visible in the Assignment Editor or in the .qsf. Assignments or settings made with the Intel^® Quartus^® Prime software, the .qsf, or the Tcl interface take precedence over assignments or settings made with synthesis attributes in your HDL code. The Intel^® Quartus^® Prime software generates warning messages if the software finds invalid attributes, but does not generate an error or stop the compilation. This behavior is necessary because attributes are specific to various design tools, and attributes not recognized in the Intel^® Quartus^® Prime software might be for a different EDA tool. The Intel^® Quartus^® Prime software lists the attributes specified in your HDL code in the Source assignments table of the Analysis & Synthesis report.

The Verilog-2001, SystemVerilog, and VHDL language definitions provide specific syntax for specifying attributes, but in Verilog-1995, you must embed attribute assignments in comments. You can enter attributes in your code using the syntax in Specifying Synthesis Attributes in Verilog-1995 through Synthesis Attributes in VHDL, in which <attribute>, <attribute type>, <value>, <object>, and <object type> are variables, and the entry in brackets is optional. These examples demonstrate each syntax form.

In addition to the synthesis keyword shown above, the Intel^® Quartus^® Prime software supports the pragma, synopsys, and exemplar keywords for compatibility with other synthesis tools. The software also supports the altera keyword, which allows you to add synthesis attributes that the Intel^® Quartus^® Prime Integrated Synthesis feature recognizes and not by other tools that recognize the same synthesis attribute.

The Intel^® Quartus^® Prime software supports synthesis directives, also commonly called compiler directives or pragmas. You can include synthesis directives in Verilog HDL or VHDL code as comments. These directives are not standard Verilog HDL or VHDL commands. Synthesis tools use directives to control the synthesis process. Directives do not apply to a specific design node, but change the behavior of the synthesis tool from the point in which they occur in the HDL source code. Other tools, such as simulators, ignore these directives and treat them as comments.

// synthesis <directive> [ <value> ]
or
/* synthesis <directive> [ <value> ] */

-- synthesis <directive> [ <value> ]

/* synthesis <directive> [<value>] */

In addition to the synthesis keyword shown above, the software supports the pragma, synopsys, and exemplar keywords in Verilog HDL and VHDL for compatibility with other synthesis tools. The Intel^® Quartus^® Prime software also supports the keyword altera, which allows you to add synthesis directives that only Intel^® Quartus^® Prime Integrated Synthesis feature recognizes, and not by other tools that recognize the same synthesis directives.

The Optimization Technique logic option specifies the goal for logic optimization during compilation; that is, whether to attempt to achieve maximum speed performance or minimum area usage, or a balance between the two.

Clock gating is a common optimization technique in ASIC designs to minimize power consumption. You can use the Auto Gated Clock Conversion logic option to optimize your prototype ASIC designs by converting gated clocks into clock enables when you use FPGAs in your ASIC prototyping. The automatic conversion of gated clocks to clock enables is more efficient than manually modifying source code. The Auto Gated Clock Conversion logic option automatically converts qualified gated clocks (base clocks as defined in the Synopsys Design Constraints [SDC]) to clock enables. Click Assignments Settings Compiler Settings Advanced Settings (Synthesis) to enable Auto Gated Clock Conversion.

The gated clock conversion occurs when all these conditions are met:

• Only one base clock drives a gated-clock
• For one set of gating input values, the value output of the gated clock remains constant and does not change as the base clock changes
• For one value of the base clock, changes in the gating inputs do not change the value output for the gated clock

The option supports combinational gates in clock gating network.

The Info tab in the Messages window lists all the converted gated clocks. You can view a list of converted and nonconverted gated clocks from the Compilation Report under the Optimization Results of the Analysis & Synthesis Report. The Gated Clock Conversion Details table lists the reasons for nonconverted gated clocks.

The SDC Constraint Protection option specifies whether Analysis & Synthesis should protect registers from merging when they have incompatible timing constraints. For example, when you turn on this option, the software does not merge two registers that are duplicates of each other but have different multicycle constraints on them. When you turn on the Timing-Driven Synthesis option, the software detects registers with incompatible constraints, and you do not need to turn on SDC Constraint Protection. Click Assignments > Settings > Compiler Settings > Advanced Settings (Synthesis) to enable the SDC constraint protection option.

The PowerPlay Power Optimization logic option controls the power-driven compilation setting of Analysis & Synthesis and determines how aggressively Analysis & Synthesis optimizes your design for power.

Resource balancing is important when performing Analysis & Synthesis. During resource balancing, Intel^® Quartus^® Prime Integrated Synthesis considers the amount of used and available DSP and RAM blocks in the device, and tries to balance these resources to prevent no-fit errors.

For DSP blocks, Resource balancing is important when performing Analysis & Synthesis. During resource balancing, Intel^® Quartus^® Prime Integrated Synthesis considers the amount of used and available DSP and RAM blocks in the device, and tries to balance these resources to prevent no-fit errors. resource balancing converts the remaining DSP blocks to equivalent logic if there are more DSP blocks in your design that the software can place in the device. For RAM blocks, resource balancing converts RAM blocks to different types of RAM blocks if there are not enough blocks of a certain type available in the device; however, Intel^® Quartus^® Prime Integrated Synthesis does not convert RAM blocks to logic.

By default, Intel^® Quartus^® Prime Integrated Synthesis considers the information in the targeted device to identify the number of available DSP or RAM blocks. However, in incremental compilation, each partition considers the information in the device independently and consequently assumes that the partition has all the DSP and RAM blocks in the device available for use, resulting in over allocation of DSP or RAM blocks in your design, which means that the total number of DSP or RAM blocks used by all the partitions is greater than the number of DSP or RAM blocks available in the device, leading to a no-fit error during the fitting process.

The Restructure Multiplexers logic option restructures multiplexers to create more efficient use of area, allowing you to implement multiplexers with a reduced number of LEs or ALMs.

When multiplexers from one part of your design feed multiplexers in another part of your design, trees of multiplexers form. Multiplexers may arise in different parts of your design through Verilog HDL or VHDL constructs such as the “if,” “case,” or “?:” statements. Multiplexer buses occur most often as a result of multiplexing together arrays in Verilog HDL, or STD_LOGIC_VECTOR signals in VHDL. The Restructure Multiplexers logic option identifies buses of multiplexer trees that have a similar structure. This logic option optimizes the structure of each multiplexer bus for the target device to reduce the overall amount of logic in your design.

Results of the multiplexer optimizations are design dependent, but area reductions as high as 20% are possible. The option can negatively affect your design’s f_MAX.

Specifies the starting value the Fitter uses when randomly determining the initial placement for the current design. The value can be any non-negative integer value. Changing the starting value may or may not produce better fitting. Specify a starting value only if the Fitter is not meeting timing requirements by a small amount. Use the Design Space Explorer to sweep many seed values easily and find the best value for your project. Modifying the design or Quartus settings even slightly usually changes which seed is best for the design.

To set the Synthesis Seed option, click Assignments > Settings > Compiler Settings > Advanced Settings (Fitter). The default value is 1. You can specify a positive integer value.

The Intel^® Quartus^® Prime software infers state machines from enumerated types and automatically assigns state encoding based on State Machine Processing.

With this logic option, you can choose the value User-Encoded to use the encoding from your HDL code. However, in standard VHDL code, you cannot specify user encoding in the state machine description because enumeration literals have no numeric values in VHDL.

To assign your own state encoding for the User-Encoded State Machine Processing setting, use the syn_encoding synthesis attribute to apply specific binary encodings to the elements of an enumerated type or to specify an encoding style. The Intel^® Quartus^® Prime software can implement Enumeration Types with different encoding styles, as listed in this table.

The syn_encoding attribute must follow the enumeration type definition, but precede its use.

The Safe State Machine logic option and corresponding syn_encoding attribute value safe specify that the software must insert extra logic to detect an illegal state, and force the transition of the state machine to the reset state.

A finite state machine can enter an illegal state—meaning the state registers contain a value that does not correspond to any defined state. By default, the behavior of the state machine that enters an illegal state is undefined. However, you can set the syn_encoding attribute to safe or use the Safe State Machine logic option if you want the state machine to recover deterministically from an illegal state. The software inserts extra logic to detect an illegal state, and forces the transition of the state machine to the reset state. You can use this logic option when the state machine enters an illegal state. The most common cause of an illegal state is a state machine that has control inputs that come from another clock domain, such as the control logic for a clock-crossing FIFO, because the state machine must have inputs from another clock domain. This option protects only state machines (and not other registers) by forcing them into the reset state. You can use this option if your design has asynchronous inputs. However, Altera recommends using a synchronization register chain instead of relying on the safe state machine option.

The safe state machine value does not use any user-defined default logic from your HDL code that corresponds to unreachable states. Verilog HDL and VHDL enable you to specify a behavior for all states in the state machine explicitly, including unreachable states. However, synthesis tools detect if state machine logic is unreachable and minimize or remove the logic. Synthesis tools also remove any flag signals or logic that indicate such an illegal state. If the software implements the state machine as safe, the recovery logic added by Intel^® Quartus^® Prime Integrated Synthesis forces its transition from an illegal state to the reset state.

You can set the Safe State Machine logic option globally, or on individual state machines. To set this logic option, click Assignments > Settings > Compiler Settings > Advanced Settings (Synthesis).

reg [2:0] my_fsm /* synthesis syn_encoding = "safe" */;

(* syn_encoding = "safe" *) reg [2:0] my_fsm;

ATTRIBUTE syn_encoding OF my_fsm : TYPE IS "safe";

If you specify an encoding style, separate the encoding style value in the quotation marks with the safe value with a comma, as follows: "safe, one-hot" or "safe, gray".

Safe state machine implementation can result in a noticeable area increase for your design. Therefore, Altera recommends that you set this option only on the critical state machines in your design in which the safe mode is necessary, such as a state machine that uses inputs from asynchronous clock domains. You may not need to use this option if you correctly synchronize inputs coming from other clock domains.

This logic option causes a register (flipflop) to power up with the specified logic level, either high (1) or low (0). The registers in the core hardware power up to 0 in all Altera devices. For the register to power up with a logic level high, the Compiler performs an optimization referred to as NOT-gate push back on the register. NOT-gate push back adds an inverter to the input and the output of the register, so that the reset and power-up conditions appear to be high and the device operates as expected. The register itself still powers up to 0, but the register output inverts so the signal arriving at all destinations is 1.

The Power-Up Level option supports wildcard characters, and you can apply this option to any register, registered logic cell WYSIWYG primitive, or to a design entity containing registers, if you want to set the power level for all registers in your design entity. If you assign this option to a registered logic cell WYSIWYG primitive, such as an atom primitive from a third-party synthesis tool, you must turn on the Perform WYSIWYG Primitive Resynthesis logic option for the option to take effect. You can also apply the option to a pin with the logic configurations described in the following list:

• If you turn on this option for an input pin, the option transfers to the register that the pin drives, if all these conditions are present:
  • No logic, other than inversion, between the pin and the register.
  • The input pin drives the data input of the register.
  • The input pin does not fan-out to any other logic.
• If you turn on this option for an output or bidirectional pin, the option transfers to the register that feeds the pin, if all these conditions are present:
  • No logic, other than inversion, between the register and the pin.
  • The register does not fan out to any other logic.

This logic option allows the Compiler to optimize registers in your design that do not have a defined power-up condition.

For example, your design might have a register with its D input tied to V_CC, and with no clear signal or other secondary signals. If you turn on this option, the Compiler can choose for the register to power up to V_CC. Therefore, the output of the register is always V_CC. The Compiler can remove the register and connect its output to V_CC. If you turn this option off or if you set a Power-Up Level assignment of Low for this register, the register transitions from GND to V_CC when your design starts up on the first clock signal. Thus, the register is at V_CC and you cannot remove the register. Similarly, if the register has a clear signal, the Compiler cannot remove the register because after asserting the clear signal, the register transitions again to GND and back to V_CC.

If the Compiler performs a Power-Up Don’t Care optimization that allows it to remove a register, it issues a message to indicate that it is doing so.

This project-wide option does not apply to registers that have the Power-Up Level logic option set to either High or Low.

This attribute and logic option directs the Compiler not to minimize or remove a specified register during synthesis optimizations or register netlist optimizations. Optimizations can eliminate redundant registers and registers with constant drivers; this option prevents the software from reducing a register to a constant or merging with a duplicate register. This option can preserve a register so you can observe the register during simulation or with the Signal Tap. Additionally, this option can preserve registers if you create a preliminary version of your design in which you have not specified the secondary signals. You can also use the attribute to preserve a duplicate of an I/O register so that you can place one copy of the I/O register in an I/O cell and the second in the core.

The Preserve Registers logic option prevents the software from inferring a register as a state machine.

You can set the Preserve Registers logic option in the Intel^® Quartus^® Prime software, or you can set the preserve attribute in your HDL code. In these examples, the Intel^® Quartus^® Prime software preserves the my_reg register.

reg my_reg /* synthesis syn_preserve = 1 */;

(* syn_preserve = 1 *) reg my_reg;

signal my_reg : stdlogic;
attribute preserve : boolean;
attribute preserve of my_reg : signal is true;

This logic option and attribute prevents the specified register from merging with other registers and prevents other registers from merging with the specified register. When applied to a design entity, it applies to all registers in the entity.

You can set the Disable Register Merging logic option in the Intel^® Quartus^® Prime software, or you can set the dont_merge attribute in your HDL code, as shown in these examples. In these examples, the logic option or the attribute prevents the my_reg register from merging.

reg my_reg /* synthesis dont_merge */;

(* dont_merge *) reg my_reg;

signal my_reg : stdlogic;
attribute dont_merge : boolean;
attribute dont_merge of my_reg : signal is true;

This synthesis attribute and corresponding logic option direct the Compiler to preserve a fan-out-free register through the entire compilation flow. This option is different from the Preserve Registers option, which prevents the Intel^® Quartus^® Prime software from reducing a register to a constant or merging with a duplicate register. Standard synthesis optimizations remove nodes that do not directly or indirectly feed a top-level output pin. This option can retain a register so you can observe the register in the Simulator or the Signal TapAdditionally, this option can retain registers if you create a preliminary version of your design in which you have not specified the fan-out logic of the register.

You can set the Preserve Fan-out Free Register Node logic option in the Intel^® Quartus^® Prime software, or you can set the noprune attribute in your HDL code, as shown in these examples. In these examples, the logic option or the attribute preserves the my_reg register.

The software supports the attribute name syn_noprune for compatibility with other synthesis tools.

reg my_reg /* synthesis syn_noprune */;

(* noprune *) reg my_reg;

signal my_reg : stdlogic;
attribute noprune: boolean;
attribute noprune of my_reg : signal is true;

This synthesis attribute and corresponding logic option direct the Compiler to keep a wire or combinational node through logic synthesis minimizations and netlist optimizations. A wire that has a keep attribute or a node that has the Implement as Output of Logic Cell logic option applied becomes the output of a logic cell in the final synthesis netlist, and the name of the logic cell remains the same as the name of the wire or node. You can use this directive to make combinational nodes visible to the Signal Tap.

You can use the Ignore LCELL Buffers logic option to direct Analysis & Synthesis to ignore logic cell buffers that the Implement as Output of Logic Cell logic option or the LCELL primitive created. If you apply this logic option to an entity, it affects all lower-level entities in the hierarchy path.

You can turn off the Ignore LCELL Buffers logic option for a specific entity to override any assignments inherited from higher-level entities in the hierarchy path if logic cell buffers created by the Implement as Output of Logic Cell logic option or the LCELL primitive are required for correct behavior.

You can set the Implement as Output of Logic Cell logic option in the Intel^® Quartus^® Prime software, or you can set the keep attribute in your HDL code, as shown in these tables. In these tables, the Compiler maintains the node name my_wire.

wire my_wire /* synthesis keep = 1 */;

(* keep = 1 *) wire my_wire;

signal my_wire: bit;
attribute syn_keep: boolean;
attribute syn_keep of my_wire: signal is true;

This attribute disables synthesis retiming optimizations on the register you specify. When applied to a design entity, it applies to all registers in the entity.

You can turn off retiming optimizations with this option and prevent node name changes, so that the Compiler can correctly use your timing constraints for the register.

You can set the Netlist Optimizations logic option to Never Allow in the Intel^® Quartus^® Prime software to disable retiming along with other synthesis netlist optimizations, or you can set the dont_retime attribute in your HDL code, as shown in the following table. In the following table, the code prevents my_reg register from being retimed.

reg my_reg /* synthesis dont_retime */;

(* dont_retime *) reg my_reg;

signal my_reg : std_logic;
attribute dont_retime : boolean;
attribute dont_retime of my_reg : signal is true;

This attribute disables synthesis replication optimizations on the register you specify. When applied to a design entity, it applies to all registers in the entity.

You can turn off register replication (or duplication) optimizations with this option, so that the Compiler uses your timing constraints for the register.

You can set the Netlist Optimizations logic option to Never Allow in the Intel^® Quartus^® Prime software to disable replication along with other synthesis netlist optimizations, or you can set the dont_replicate attribute in your HDL code, as shown in these examples. In these examples, the code prevents the replication of the my_reg register.

reg my_reg /* synthesis dont_replicate  */;

(* dont_replicate *) reg my_reg;

signal my_reg : std_logic;
attribute dont_replicate : boolean;
attribute dont_replicate of my_reg : signal is true;

This Maximum Fan-Out attribute and logic option direct the Compiler to control the number of destinations that a node feeds. The Compiler duplicates a node and splits its fan-out until the individual fan-out of each copy falls below the maximum fan-out restriction. You can apply this option to a register or a logic cell buffer, or to a design entity that contains these elements. You can use this option to reduce the load of critical signals, which can improve performance. You can use the option to instruct the Compiler to duplicate a register that feeds nodes in different locations on the target device. Duplicating the register can enable the Fitter to place these new registers closer to their destination logic to minimize routing delay.

To turn off the option for a given node if you set the option at a higher level of the design hierarchy, in the Netlist Optimizations logic option, select Never Allow. If not disabled by the Netlist Optimizations option, the Compiler acknowledges the maximum fan-out constraint as long as the following conditions are met:

• The node is not part of a cascade, carry, or register cascade chain.
• The node does not feed itself.
• The node feeds other logic cells, DSP blocks, RAM blocks, and pins through data, address, clock enable, and other ports, but not through any asynchronous control ports (such as asynchronous clear).

The Compiler does not create duplicate nodes in these cases, because there is no clear way to duplicate the node, or to avoid the small differences in timing which could produce functional differences in the implementation (in the third condition above in which asynchronous control signals are involved). If you cannot apply the constraint because you do not meet one of these conditions, the Compiler issues a message to indicate that the Compiler ignores the maximum fan-out assignment. To instruct the Compiler not to check node destinations for possible problems such as the third condition, you can set the Netlist Optimizations logic option to Always Allow for a given node.

You can set the Maximum Fan-Out logic option in the Intel^® Quartus^® Prime software. This option supports wildcard characters. You can also set the maxfan attribute in your HDL code, as shown in these examples. In these examples, the Compiler duplicates the clk_gen register, so its fan-out is not greater than 50.

reg clk_gen /* synthesis syn_maxfan = 50 */;

(* maxfan = 50 *) reg clk_gen;

signal clk_gen : stdlogic;
attribute maxfan : signal ;
attribute maxfan of clk_gen : signal is 50;

The Auto Clock Enable Replacement logic option allows the software to find logic that feeds a register and move the logic to the register’s clock enable input port. To solve fitting or performance issues with designs that have many clock enables, you can turn off this option for individual registers or design entities. Turning the option off prevents the software from using the register’s clock enable port. The software implements the clock enable functionality using multiplexers in logic cells.

If the software does not move the specific logic to a clock enable input with the Auto Clock Enable Replacement logic option, you can instruct the software to use a direct clock enable signal. The attribute ensures that the signal drives the clock enable port, and the software does not optimize or combine the signal with other logic.

These tables show how to set this attribute to ensure that the attribute preserves the signal and uses the signal as a clock enable.

wire my_enable /* synthesis direct_enable = 1 */ ;

attribute direct_enable: boolean;
attribute direct_enable of my_enable: signal is true;

(* syn_direct_enable *) wire my_enable;