AN 584: Timing Closure Methodology for Advanced FPGA Designs

Download PDF
ID 683145
Date 10/08/2021
Public
Document Table of Contents
Document Table of Contents x
1. AN 584: Timing Closure Methodology for Advanced FPGA Designs
1. AN 584: Timing Closure Methodology for Advanced FPGA Designs x
1.1. Plan Early for Timing Closure 1.2. Customize Settings Per Application 1.3. Change Fitter Placement Seeds 1.4. Planning for Timing Closure 1.5. Best Practices for Timing Closure 1.6. Resolving Common Timing Issues 1.7. Conclusion 1.8. Document Revision History for AN 584: Timing Closure Methodology for Advanced FPGA Designs
1.4. Planning for Timing Closure x
1.4.1. Timing Closure Planning at Specification Stage 1.4.2. Timing Closure Planning at Coding and Compilation Stage
1.4.1. Timing Closure Planning at Specification Stage x
1.4.1.1. Plan for the Target FPGA Device 1.4.1.2. Plan for On-Chip Debugging
1.4.2. Timing Closure Planning at Coding and Compilation Stage x
1.4.2.1. Plan for Design Hierarchy and Block Partitioning 1.4.2.2. Plan for Early Compilation of Design Blocks 1.4.2.3. Plan for Verification
1.5. Best Practices for Timing Closure x
1.5.1. Performance Planning General Guidelines 1.5.2. Follow Synchronous Design Practices 1.5.3. Follow Recommended Coding Styles 1.5.4. Constraining and Compiling Your Design
1.5.4. Constraining and Compiling Your Design x
1.5.4.1. Setting Location Constraints 1.5.4.2. Setting Proper Timing Constraints 1.5.4.3. Using Optimal Compiler Settings for Your Design
1.6. Resolving Common Timing Issues x
1.6.1. Excessive Logic Levels 1.6.2. Improper Timing Constraints 1.6.3. Handling High Fan-Out Registers 1.6.4. Metastability Issues 1.6.5. Reset Signal Related Issues 1.6.6. Small Margin Timing Constraint Failures 1.6.7. Long Compilation Times
1.6.2. Improper Timing Constraints x
1.6.2.1. Check Constraint Diagnostics
1.6.4. Metastability Issues x
1.6.4.1. Check CDC Design Assistant Rule Violations 1.6.4.2. Check CDC Report
1.6.5. Reset Signal Related Issues x
1.6.5.1. Recovery and Removal Issues
1. AN 584: Timing Closure Methodology for Advanced FPGA Designs

1.5.3. Follow Recommended Coding Styles

Your coding style has a significant impact on implementation in the FPGA because synthesis tools can optimize and interpret the design differently based on style. Therefore, you must decide how to code the design to assist the optimizations done by the synthesis tool.

FPGA devices are register rich, so pipelining your design can help you meet required performance, without adversely affecting resource use. Adding adequate pipeline registers can help you avoid a large amount of combinational logic between registers.

Another practice to avoid is unintended latch inference. Intel® Quartus® Prime Synthesis issues a warning message when unintended latch inference occurs. The FPGA architecture is not optimized for latch implementation. Latches generally have slower timing performance compared to equivalent registered circuitry.

Improper use of latch schemes can also cause glitches to pass from input to output when signals are enabled, putting latches in transparent mode. You must design such structures properly to avoid this unexpected circumstance. However, timing analysis cannot identify these safe applications.

Refer to HDL Design Guidelines in Intel® Quartus® Prime Pro Edition User Guide: Design Recommendations for information on how to avoid latches, combinational loops, and other styles that are not suitable for FPGA implementation.

If you use unsupported operations (such as asynchronously clearing of RAM content) with memory blocks, the Intel® Quartus® Prime software may implement the code with logic cells rather than more suitable RAM blocks.

If you are unaware of your hardware resources, you can easily underutilize some of the available resources. In general, do not use constructs that lack the equivalent hardware implementation available in the device. For example, if you infer RAM locations and use synchronous resets on RAM locations to clear the contents, or to initialize the values, your code might not be mapped to any of the available RAM blocks in the device.

This condition occurs because the RAM locations in the FPGA device do not have asynchronous or synchronous resets available for RAM cells. Instead, logic that models a memory with a reset is implemented in logic cells. Review your device specifications to confirm whether having a known initial value in the RAMs is necessary for proper design function. This condition is not typically required. If RAM cells must initialize to certain known values (such as all 0’s), you can perform write cycles to the RAM immediately after power up.

You must consider hardware mapping when writing your HDL. Changes in the HDL code can affect the number of logic levels and the corresponding timing. Although the Compiler optimizes your design, unnecessary optimizations can affect software performance. Modifying the HDL can improve the quality of results.

Improper coding of RAM blocks can also cause inference of the native RAM surrounded by an unnecessary cloud of logic cells and registers required to implement the equivalent functionality. This cloud of logic is barely noticeable, but can cause extra resource utilization and worsen timing closure in the area.

Refer to Recommended HDL Coding Styles in Intel® Quartus® Prime Pro Edition User Guide: Design Recommendations for information on inferring memories, multiplier blocks, DSP blocks, and how to use provided HDL RAM templates.

Related Information
Level Two Title