Innovations in field programmable gate array (FPGA) architecture and the move to 90-nm process technologies have delivered a dramatic increase in both FPGA density and performance. Besides higher logic densities and faster performance, FPGA designers demand more complex device features such as embedded memory, digital signal processing (DSP) blocks and other hard IP structures. However, as FPGA designs have become larger and more complex, designers have less time to complete their designs before their market opportunity vanishes.

FPGA device vendors have been trying to keep up with improvements in compilation time efficiency and timing closure flows. Unfortunately, these improvements have not kept pace with the need for increased designer productivity. Altera’s Quartus® II software version 5.0 incremental compilation technology delivers that productivity improvement by offering dramatically shorter design iteration times and unprecedented ability to target design optimizations to critical performance paths and preserve performance in areas where performance requirements are already satisfactory.

Incremental Compilation Advantages

In a standard compilation flow for today’s advanced FPGAs, including RTL synthesis and place and route, each design compilation for a high-density FPGA can take anywhere from 45 minutes to more than 4 hours. This typically limits designers to as little as 2 iterations per day, dramatically slowing the design process. Another delay to design productivity occurs when designers using a standard compilation design flow attempt to improve the timing performance in one part of the design. Often this optimization negatively affects logic placement and therefore, performance, in other parts of the design. These effects force additional design iterations.

For today’s high-density, high-performance FPGA designs, the ability to iterate rapidly during the design and debugging stages is critical. Altera’s Quartus II software version 5.0 delivers the most advanced technology for designing with high-density FPGAs, including the incremental design and compilation capabilities previously available only with application specific integrated circuits (ASICs). FPGA compilations provide even more value than their ASIC counterparts, however, taking only minutes to hours for FPGA compilations versus hours to days for ASIC compilations even with incremental methodologies.

Using Quartus II incremental compilation, designers can incrementally compile a partition of their design up to 70% faster than when performing a standard compilation on an entire design. Preserving performance is another major benefit of incremental compilation technologies. By compiling only one partition in a design, the results and performance of the remaining partitions remain unchanged. This performance preservation feature allows the designer to reach timing closure more efficiently by requiring fewer design iterations.

Figure 1. The Quartus II version 5.0 incremental compilation design flow.

Incremental compilation allows designers to organize their design in logical and physical partitions for synthesis and fitting. Design iteration time can be dramatically reduced by focusing new compilations on a particular design partition. Incremental compilation facilitates block-based design and allows designers to preserve performance for unchanged design blocks. Designers also can target optimization techniques, such as physical synthesis, to specific design partitions while leaving other blocks untouched.

Conventionally, a hierarchical design is flattened into a single netlist before logic synthesis and fitting, and the entire design is recompiled every time there is a change in the design, slowing the entire design process. However, incremental compilation allows designers to partition a design along any of its hierarchical boundaries. With Altera’s Quartus II software, the individual hierarchical design partitions are synthesized and fit separately. The partitions are combined, or merged, to form a netlist for further stages of the Quartus II compilation flow. When recompiling the design, designers can choose to use new source code, post-synthesis results, or post-fitting results for each partition.

Incremental Compilation Design Flows

Quartus II incremental compilation enhances the standard Quartus II design flow, allowing designers to reuse and thus preserve previous compilation results, saving compilation time. In a standard compilation flow, the source code is processed, then all the logic is placed whenever the design is recompiled after any change in any part of the design. One reason for this behavior is to obtain optimal quality of results. By processing the entire design, the compiler can perform global optimizations to improve area and performance. However, there are situations in which a more incremental compilation flow is desirable. When the partitions in a design are well chosen and placed in the device floorplan, designers can speed up their design compilation time while maintaining or even improving the quality of results.

Designers may want to use incremental compilation later in the design cycle to make changes or optimize one specific block after the majority of the design is complete. In this case, they can preserve the performance of modules that are unmodified and reduce compilation time on subsequent iterations. There also are situations in which incremental compilation is useful both for reducing compilation time and for achieving timing closure. The feature also can be used to compile and optimize some design partitions when other partitions are missing or incomplete.

Design Partitions vs. Design Hierarchy

It is common design practice to create modular or hierarchical designs in which entities are designed separately and then instantiated in a higher-level project to form a complete design. Each entity in a design is not automatically considered a design partition for incremental compilation; designers must designate one or more design hierarchies below the top level project as such. Creating partitions prevents the compiler from performing optimizations across partition boundaries, but it also allows incremental compilation by enabling each partition to separately be synthesized and placed.

Figure 2. Hierarchical designs made independent with partition boundaries enable incremental compilation.

Since partitions must be separated by hierarchical boundaries, they cannot be a portion of the logic within a hierarchical entity. When a partition is declared, every hierarchical entity within that partition becomes part of the same partition. Designers can create new partitions for hierarchical entities within an existing partition, in which case the entities within the new partition are no longer part of the higher-level partition.

Design Partition vs. Physical Region

Design partitions for incremental compilation are logical partitions, different from physical regions in the device floorplan, which specify a size and location. A logical design partition does not refer to a physical section of the device and is not used to directly control logic placement

A logical design partition sets up a virtual boundary between design hierarchies so that each partition is compiled separately and no logical optimizations can occur between them. It is recommended that designers assign each design partition to a physical region to improve quality of results when setting up a design for incremental compilation.

Recommendations for Creating Design Partitions

When planning a design, designers should keep in mind the size and scope of each partition, and how likely it is that different parts of the design change as the design develops. Since cross-boundary optimizations cannot occur when using partitions, the quality of results or performance of the design may decrease as the number of partitions increases. So, while having more partitions allows for greater reduction in compilation time, designers should limit the number of partitions to prevent degradation of the quality of results.

As in ASIC design flows, designers should register the input and output ports of each partition, whenever possible, to avoid any delay on signals that cross partition boundaries. In addition, designers should try to minimize the number of paths that cross partition boundaries to ease the timing closure process, and also separate partitions by clock domain where possible.

Creating a Design Floorplan

Once the design is partitioned, designers should assign each partition to a physical location on the device. The simplest way to create a floorplan for a partitioned design is to create a physical location constraint for each partition (including the top-level partition).

Floorplan location planning is very important for a design that uses incremental compilation because it helps avoid the situation that arises when the fitter is directed to place or replace a portion of the design in an area of the device where most resources have already been claimed. In this case, the placement of the post-fit netlists of other partitions forces the fitter to place the new or modified partition in the empty parts of the device. There are two immediate disadvantages to this situation. First, the fitter must work harder because of the higher number of physical constraints, and therefore compilation time typically increases. Second, the quality of results often decreases, sometimes dramatically, because the placement of the target partition is now scattered throughout the device.

Figures 3 and 4. A typical device floorplan with and without location assignments.

Taking Advantage of the Quartus II Early Timing Estimator

The Early Timing Estimator feature provides an accurate design timing estimate without performing a full design compilation, On average, the estimate is within 11 percent of the actual design performance. Designers can use the Timing Closure Floorplan editor to view the “placement estimate” created by this feature, identify critical paths and, if necessary, add or modify floorplan constraints. The Early Timing Estimator can then quickly assess the impact of any floorplan location assignments or logic changes, enabling rapid iterations on design variants to help designers find the best solution.

Criteria for Successful Partition and Floorplan Schemes

Designers should compare the results before creating floorplan location assignments to the results afterwards, and consider using another scheme if any of the following guidelines are not met:

• No degradation in fMAX should be observed after the design is partitioned and floorplan location assignments are created. In many cases, a slight increase in fMAX is possible.

• The area increase should be no more than 5 percent after the design is partitioned and floorplan location assignments are created.

• The time spent in the routing stage should not significantly increase. If there is a dramatic increase in routing time, the floorplan location assignments may be creating substantial routing congestion.

To help modify and optimize the location assignments for each partition, designers can identify areas of congested routing using the Timing Closure Floorplan in the Quartus II software.

Conclusion

Altera’s Quartus II incremental compilation technology delivers the productivity improvement designers need by offering dramatically shorter design iteration times and unprecedented features that preserve performance. Designers using this technology can perform 4 to 5 iterations per day for high-density FPGAs versus just 1 to 2 iterations using traditional compilation methods, shortening design iteration time up to 70% and dramatically reducing overall development time. The performance preservation achieved through incremental compilation saves even more design time by allowing designers to reach timing closure more efficiently with fewer design iterations.

by Robert Kruger and Jennifer Stephenson, Altera Corporation

May 26, 2005

[back to top]

Comments on this article? Send them to comments@fpgajournal.com