About Incremental Compilation

The Quartus II incremental compilation feature supports various design flows. In a standard incremental compilation flow, the top-level design is divided into design partitions, which can then be compiled and optimized together in a single Quartus II project. Throughout the development cycle, you can preserve satisfactory compilation results and performance of unchanged partitions to reduce design iteration time by focusing subsequent compilations on partitions in the design that change. Incremental compilation is useful for designs where you want to focus on developing certain partitions of the design while preserving performance from a previous compilation in other partitions. For example, you can use incremental compilation to achieve timing closure for a particular partition that does not meet timing requirements, while preserving the compilation results for partitions that have met design requirements. The incremental compilation design flow reduces design iteration time by an average of 75% for large design changes, allowing you to perform design iterations more quickly. The incremental compilation feature is turned on by default in the Quartus II software.

In a team-based incremental compilation design flow, a team member or IP provider can develop the source code for a partition in the top-level design, and then functionally verify their partition independently in a separate Quartus II project. When the team member or IP provider completes their work, they can then export their partition with the

To prepare your design for an incremental compilation flow, you must first perform in order to identify the hierarchical entities in your design. You can then create design partitions from entities with options in the Project Navigator, Design Partitions window, or Design Partition Planner. When you set a design entity as a partition, hierarchical entities below are also assigned to that partition. By default, the Quartus II software designates the top-level entity as a design partition. A design entity designated as a partition appears with a partition icon (

) in the Hierarchy tab in the Project Navigator, and also appears in the Design Partitions window.

You can use LogicLock regions to create a floorplan for your design; assigning a particular partition in your design to a specific location on the target device. Floorplan location planning can be important for a design that uses incremental compilation to avoid resource conflicts between partitions. When integrating partitions exported from another Quartus II project, floorplanning helps to ensure a good quality of results when recompiling individual timing-critical partitions. Floorplan assignments are not required for non-critical partitions. Design partitions that cross partition boundaries can be placed independently because cross-partition paths are not critical-timing paths in the design.

Design partitions are logical design blocks that are preserved or recompiled during incremental compilation. It is important to distinguish between logical partitions and physical regions for the purpose of understanding incremental compilation.

A logical partition does not refer to a physical location on the device, and you do not use it to directly control the placement of nodes; rather, a logical partition sets up a virtual boundary between design hierarchies so that logical optimizations cannot occur between them.

Physical regions have an associated size and location on a device. You can implement physical regions with LogicLock regions and view the results in the Chip Planner. A floorplan shows the layout of the physical regions on the device. When you design your floorplan, you can assign multiple nodes to a physical region and place them close to each other to help optimize performance. Floorplan location planning helps avoid resource conflicts between partitions when integrating partitions in a team-based design flow, and can also be useful for isolating timing-critical partitions to achieve timing closure.

When you compile a top-level design with missing or incomplete design partitions, or when a designer compiles their separate Quartus II project without information about the entire design, the Compiler may not be able to fully optimize paths that cross partition boundaries. To avoid reducing the timing performance of these paths, you can register both the input and the output ports of all partitions to prevent timing-critical paths from crossing partition boundaries. At a minimum, Altera recommends registering either the input, or the output ports. Timing performance might degrade and area might increase as you increase the number of partitions because cross-boundary optimizations cannot occur. With the TimeQuest Timing Analyzer, you can use the Report Partitions command to find the number of failing paths and worst-case slack per partition, and analyze paths between partitions.

You can use the Merge command to combine hierarchical partitions into a single partition, as long as they have the same immediate parent partition. Merging partitions allows for additional optimizations for partition I/O ports that connect between or feed more than one of the merged hierarchical design blocks. When all partitions for a design are compiled at the same time, the Fitter can perform placement optimizations on the design as a whole to optimize the placement of cross-partition paths. However, the Fitter can never perform logic optimizations such as physical synthesis across partition boundaries. If partitions are fit separately in different Quartus II 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.

When you use incremental compilation for your Quartus II project, you can enable cross-boundary optimizations for each partition. You can select individual assignments for each supported cross-boundary optimization, which allows you to customize the optimizations to fit your design needs. Cross-boundary optimization performs tasks such as propagating constants and removing dangling logic; thereby, producing a smaller and more efficient design. You can find the optimization settings on the Advanced tab of the Design Partition Properties dialog box. Changes to optimization settings, or modification of the HDL source that exposes cross-boundary optimizations, causes the Quartus II software to recompile the partition from the HDL source automatically.

Cross-boundary optimizations are implemented top-down from the parent partition into the child partition, but not vice-versa. If these optimizations change, the Compiler automatically recompiles the partition, unless the partition is set to post-fit strict. If there are changes to a cross-boundary optimization in a post-fit strict partition, the Quartus II software generates a critical warning.

If changes to cross-boundary optimizations trigger synthesis of a partition, the Compiler creates a Cross-Boundary Optimization Changes for Partition report in the Design Partition Status folder of the Analysis and Synthesis Partition Reports.

Cross-boundary optimizations cannot be enabled for partitions that allow multiple personas, such as partial reconfiguration (PR) partitions, because these partitions have a hard boundary. If you attempt to enable cross-boundary optimizations for these partitions, the Quartus II software issues a warning message.

The Quartus II Design Partition Planner helps you visualize a design's structure and helps you create effective design partitions for use with incremental compilation. The Design Partition Planner displays a visual representation of design connectivity and hierarchy, as well as partitions and entity relationships. When you use the Design Partition Planner with the TimeQuest Timing Analyzer and the Chip Planner, you can see entity relationships, the timing paths between entities, partitions, LogicLock regions, and physical resource placement, and you can use that information to effectively partition your design.

The Partition Merge report lists statistics about each partition in your design, including the number of logic cells it contains, and a list of registered and unconnected input and output ports. The Partition Merge report is useful when optimizing partitions, or evaluating the use of resources between partitions.

You can use the Incremental Compilation Advisor to verify that your design follows the recommended guidelines that allow you to effectively partition your design, as well as recommendations on how to implement a team-based design flow. Design recommendations are provided, and each recommendation is accompanied by an explanation and instructions.

When you use Parallel Synthesis to synthesize your design, the Quartus II software displays messages that pertain to design partitions in the Messages window as they are synthesized in parallel. Therefore, messages from different partitions are not sequenced together, but instead interspersed throughout the Messages window. After compilation, you can use the Partition column in the Messages window to sort messages according to the partition that generated the message, thus grouping all the messages for a particular partition.

SignalTap II Logic Analyzer—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. When 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 developed independently in separate Quartus II projects and contain the logic analyzer and SLD_HUB related logic, when you export the partition, the Quartus II software automatically removes the SignalTap II logic.

For more information about using the SignalTap II Logic Analyzer in an incremental compilation design flow, refer to the Design Debugging Using the SignalTap II Logic Analyzer chapter in volume 3 of the Quartus II Handbook.

SignalProbe Pins and Post-Compilation Design Changes—When incremental compilation is turned on and your design contains one or more partitions, partition boundaries are ignored while making ECO changes. During subsequent compilations, ECO changes are not preserved regardless of the Netlist Type or Fitter Preservation settings. To recover ECO changes, you must use the Change Manager to re-apply the ECOs after compilation.

For partitions developed independently in separate Quartus II projects that contain the logic analyzer and SLD_HUB related logic, the exported netlist includes all currently saved ECO changes and SignalProbe pins, though after integrating the partition into the top-level design, the ECO changes will not appear in the Change Manager.