Modern FPGA architectures include a wide range of embedded functions, supporting high-speed serial communication, DSP functions and large memory arrays, in additional to a large logic fabric. While these large FPGAs have made the task of solving the system problem easier, they have also greatly complicated the task of the FPGA designer.

The increase in functionality has led to difficulties in achieving timing closure and resulted in long synthesis, simulation and place-and-route runtimes. As designs move into the final debug stages where multiple iterations through syntheses, simulation and place and route are required, the time required for these iterations can be costly, resulting in project delays and increased development costs. The only viable solution today is to adopt a truly incremental design approach.

Designing Incrementally Today

FPGA design is by its nature iterative, and increasing design size and complexity adds to the number of iterations and their length. Designers find problems with functionality and performance at different stages of the design process. Fixes for functional or timing violations in one area can cause problems in other parts of the design. These fixes can result in a large number of design iterations without any way to control their number or length.

In an attempt to solve this problem, a number of companies offering FPGA design tools provide a block-based (partitioning-based) incremental design flow. The expectation is that partitioning will enable designers to preserve performance for those logic blocks not undergoing a design change. This approach requires designers to partition the design early in the design process and set partitioning constraints on each block. These constraints are then used throughout the design process to isolate the different design blocks. The goal is to shorten the design cycle time while not degrading the performance of the final design.

While a block-based incremental flow is certainly useful for partial reconfiguration solutions, it is not being used as widely as expected — possibly because the promised benefits of improved runtime and preserved performance are not being realized by the marketplace.

Limitations of the Current Approach

With a block-based incremental design process, the user has to decide up front on the number and size of the partitions and then set needed constraints. This partitioning is required because synthesis and place-and-route tools, by default, perform design optimizations across block boundaries. If cross-boundary optimizations are performed without proper tracking, then the design may not be preserved as expected when design blocks are incrementally updated.

So to be efficient, design errors need to be localized to the block level. If errors are allowed to straddle block boundaries, then multiple blocks are affected. However, there is no way to predict where in the design, timing and functional problems will arise, preventing designers from creating optimal partitions. So in the end, the total design time has only been reduced marginally.

The other limitation is the loss in design performance (both in terms of timing and area) due to the lack of cross-boundary optimization of the partitioned design. Often timing closure and fitting a design in a device are difficult to achieve and any reduction in design performance only worsen these problems.

Need For a Truly Incremental Design Flow

FPGA users expect the design process to be relatively easy, allowing them to hit their design goals quickly and easily. Since the block-based incremental design flow has not been widely adopted as it requires much manual effort and tends to reduce QoR. The market wants an incremental design solution that provides all the benefits of the block- based incremental design flow without any manual design partitioning. With such a solution, the user would not have to perform any up front manual tasks. The synthesis and place-and-route tools would automatically determine design changes and try to preserve as much design as possible based on a previous implementation.

What would a synthesis tool need to truly support incremental design? This tool should:

• Recognize a true design change based on parse tree comparison rather than timestamps to avoid false design updates. Changes such as adding comments, spaces and indentations should be automatically filtered out.
• Perform appropriate cross-boundary optimizations in incremental flow to maintain high QoR.
• Not require the need for user-set attributes.
• Preserve netlist object names to allow for name matching with place-and-route tools.

These capabilities would let place-and-route tools to incrementally update only the needed logic, placement and routing. In addition, these capabilities would enable the synthesis and place-and-route tools to provide a flexible and complete incremental design solution, reducing the number of design iterations and time per iteration.

Summary

Due to the increased size and complexity of FPGA devices and designs, iterating through the synthesis and place-and-route flow is both time consuming and costly. FPGA designers can tackle these issues by adopting a reliable incremental design process that:

• Reduces synthesis and place-and-route runtimes
• Preserves the performance for unchanged portions of the design
• Provides a focused timing closure and design debug capability

Have an incremental comment? Share your thoughts by writing the editor at jkobylecky@extensionmedia.com and our editorial director: jblyler@extensionmedia.com.