Incremental Design Overview

The Incremental Design flow is a new methodology for processing designs in a hierarchical way that reuses results for unchanging portions of the design. This can save many hours of processing or manual intervention each iteration; therefore, greatly reducing the Time to Market for large and high speed designs. The Incremental Design flow uses hierarchical design practices to preserve results and decrease runtimes in design compiles. In a simple, productive way, Incremental Design takes advantage of the Xilinx guide methodology, which uses output results from previous implementations as guide files for preserving unchanged logic results.

Incremental Design requires that the design follow good hierarchical design methodologies by using an “Incremental Synthesis” approach to partition the design into separate logic groups., which are then constrained with an AREA GROUP constraint. The logic partitions are floorplanned into regions of the device, which physically separate them. When a design change is made, using an Incremental Synthesis approach, to one of the logic groups, ensures that unchanged logic groups are preserved in the synthesis output. This saves valuable time when debugging a design because the implementation tools then re-place and re-route only the changed logic group, while the unchanged logic groups are guided using the output files from a previous implementation. By guiding unchanged logic groups, the performance in those logic groups is preserved, and place and route runtimes are decreased.

Note: Setting up a design using an Incremental Synthesis approach may be beneficial. It ensures that an Incremental Design flow can be used if your design has issues that can be resolved using Incremental Design.

It is important to define some of the terminology that is used with Incremental Design:

A logic group is a hierarchical portion of the design that can be synthesized separately. Each logic group is a module in Verilog or an entity in VHDL that is instantiated in the top level of the design. Logic groups are identified in the implementation tools using an AREA GROUP constraint. See the AREA GROUP section of the Constraints Guide for more information.

The AREA GROUP RANGE constraint specifies the physical location in the FPGA. See the AREA GROUP section of the Constraints Guide for more information.

Guide files are MAP and PAR output .ncd files from a previous implementation. Guide files are used to guide unchanged logic groups from one implementation to the next when you run in Incremental Guide Mode.

An incremental design change is a change that affects only a few logic groups in a design. It does not drastically alter the size, nor adversely affect the timing of the whole design. Changes to state machines or control logic, and adding registers to improve performance are examples of incremental design changes.

Note: Larger design changes like adding and removing an AREA GROUP, modifying ungrouped top level logic and changing AREA GROUP port connections are not considered incremental design changes because they are likely to compromise reduced runtime and timing preservation by crossing AREA GROUP boundaries and affecting multiple area groups. Runtime and logic group timing preservation cannot be guaranteed when large design changes are made.

Incremental Design Benefits

Logic Group Timing Preservation

Incremental Design preserves the timing results (placement and routing) of unchanged logic groups that remain stable. Unchanged logic is guided from one implementation to the next with guide files from the previous run. This means that when a logic group with critical timing requirements meets its timing and does not change, it can be quickly guided from iteration to iteration.

Runtime Reduction

Incremental Design reduces implementation runtimes by only reimplementing changed logic. Separating a design into logic groups isolates any changes to a specific part of the design. The more grouped a design is, the better the runtime advantage when a change is made during Incremental Guide Mode. When changes are limited to one logic group, all of the other (unchanged) logic groups are guided from the previous implementation; therefore, PAR runtime is reduced.

Note: All top-level logic that is not located is reimplemented each time PAR is run. Limiting top-level logic is recommended for this reason.

PAR Effort Level Control

Incremental Design offers additional user control for preserving design performance versus improving runtimes. When logic groups with difficult timing requirements are being implemented or reimplemented, the PAR effort level can be set higher to help automatically meet the timing requirements, which is a trade-off with runtime. Alternatively, if the logic being implemented or reimplemented is easy for PAR to handle, then the effort level may be reduced to improve the PAR runtime.