Intel® Quartus® Prime Pro Edition User Guide: Design Compilation

Download PDF
ID 683236
Date 3/28/2022
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents
Document Table of Contents x
1. Answers to Top FAQs 2. Design Compilation 3. Reducing Compilation Time 4. Intel® Quartus® Prime Pro Edition User Guide Design Compilation Archives A. Intel® Quartus® Prime Pro Edition User Guides
2. Design Compilation x
2.1. Compilation Overview 2.2. Using the Compilation Dashboard 2.3. Design Synthesis 2.4. Design Place and Route 2.5. Incremental Optimization Flow 2.6. Fast Forward Compilation Flow 2.7. Full Compilation Flow 2.8. Exporting Compilation Results 2.9. Integrating Other EDA Tools 2.10. Synthesis Language Support 2.11. Compiler Optimization Techniques 2.12. Synthesis Settings Reference 2.13. Fitter Settings Reference 2.14. Design Compilation Revision History
2.1. Compilation Overview x
2.1.1. Compilation Flows 2.1.2. Compilation Hierarchy 2.1.3. Compilation Monitoring
2.3. Design Synthesis x
2.3.1. Running Synthesis 2.3.2. Viewing Synthesis Reports
2.3.1. Running Synthesis x
2.3.1.1. Preserving Registers During Synthesis 2.3.1.2. Preserving Signals for Monitoring and Debugging
2.4. Design Place and Route x
2.4.1. Running the Fitter 2.4.2. Viewing Fitter Reports
2.4.1. Running the Fitter x
2.4.1.1. Fitter Commands 2.4.1.2. Disabling or Enabling Physical Synthesis Optimization
2.4.2. Viewing Fitter Reports x
2.4.2.1. Plan Stage Reports 2.4.2.2. Place Stage Reports 2.4.2.3. Route Stage Reports 2.4.2.4. Retime Stage Reports 2.4.2.5. Finalize Stage Reports
2.4.2.2. Place Stage Reports x
2.4.2.2.1. Global Signal Visualization Report
2.4.2.3. Route Stage Reports x
2.4.2.3.1. Global Router Congestion Hotspot Summary Report 2.4.2.3.2. Global Router Wire Utilization Map Report
2.5. Incremental Optimization Flow x
2.5.1. Concurrent Analysis During Synthesis or Fitting 2.5.2. Analyzing Compiler Snapshots 2.5.3. Validating Periphery (I/O) after the Plan Stage
2.5.2. Analyzing Compiler Snapshots x
2.5.2.1. Running Snapshot Viewer
2.5.2.1. Running Snapshot Viewer x
2.5.2.1.1. Analyzing Failing Paths with Snapshot Viewer 2.5.2.1.2. Analyzing Clocking with Snapshot Viewer 2.5.2.1.3. Analyzing High Fan-out Nets with Snapshot Viewer 2.5.2.1.4. Validating Timing Constraints with Snapshot Viewer 2.5.2.1.5. Analyzing Congestion with Snapshot Viewer
2.6. Fast Forward Compilation Flow x
2.6.1. Step 1: Run Register Retiming 2.6.2. Step 2: Review Retiming Results 2.6.3. Step 3: Run Fast Forward Compile 2.6.4. Step 4: Review Fast Forward Results 2.6.5. Step 5: Implement Fast Forward Recommendations 2.6.6. Retiming Restrictions and Workarounds
2.6.2. Step 2: Review Retiming Results x
2.6.2.1. Locate Critical Chains
2.6.3. Step 3: Run Fast Forward Compile x
2.6.3.1. Fast Forward Compile By Hierarchy 2.6.3.2. HyperFlex Settings
2.6.4. Step 4: Review Fast Forward Results x
2.6.4.1. Clock Fmax Summary Report 2.6.4.2. Fast Forward Details Report
2.7. Full Compilation Flow x
2.7.1. Full Compilation Flow with Temporary Optimization Mode
2.8. Exporting Compilation Results x
2.8.1. Exporting a Version-Compatible Compilation Database 2.8.2. Importing a Version-Compatible Compilation Database 2.8.3. Creating a Design Partition 2.8.4. Exporting a Design Partition 2.8.5. Reusing a Design Partition 2.8.6. Viewing Quartus Database File Information 2.8.7. Clearing Compilation Results
2.8.6. Viewing Quartus Database File Information x
2.8.6.1. QDB File Attribute Types
2.9. Integrating Other EDA Tools x
2.9.1. Generating a VQM Netlist for other EDA Tools
2.10. Synthesis Language Support x
2.10.1. Verilog and SystemVerilog Synthesis Support 2.10.2. VHDL Synthesis Support
2.10.1. Verilog and SystemVerilog Synthesis Support x
2.10.1.1. Verilog HDL Input Settings (Settings Dialog Box) 2.10.1.2. Design Libraries 2.10.1.3. Verilog HDL Configuration 2.10.1.4. Initial Constructs and Memory System Tasks 2.10.1.5. Verilog HDL Macros
2.10.1.3. Verilog HDL Configuration x
2.10.1.3.1. Hierarchical Design Configurations
2.10.2. VHDL Synthesis Support x
2.10.2.1. VHDL Input Settings (Settings Dialog Box) 2.10.2.2. VHDL Standard Libraries and Packages 2.10.2.3. VHDL wait Constructs 2.10.2.4. VHDL-2019 Conditional Analysis Tool Directives
2.11. Compiler Optimization Techniques x
2.11.1. Compiler Optimization Modes 2.11.2. Allow Register Retiming 2.11.3. Automatic Gated Clock Conversion 2.11.4. Enable Intermediate Fitter Snapshots 2.11.5. Fast Preserve Option 2.11.6. Fractal Synthesis Optimization
2.11.6. Fractal Synthesis Optimization x
2.11.6.1. Enabling or Disabling Fractal Synthesis
2.12. Synthesis Settings Reference x
2.12.1. Advanced Synthesis Settings
3. Reducing Compilation Time x
3.1. Factors Affecting Compilation Results 3.2. Strategies to Reduce the Overall Compilation Time 3.3. Reducing Synthesis Time and Synthesis Netlist Optimization Time 3.4. Reducing Placement Time 3.5. Reducing Routing Time 3.6. Reducing Static Timing Analysis Time 3.7. Setting Process Priority 3.8. Reducing Compilation Time Revision History
3.2. Strategies to Reduce the Overall Compilation Time x
3.2.1. Running the ECO Compilation Flow 3.2.2. Enabling Multi-Processor Compilation 3.2.3. Using Block-Based Compilation
3.3. Reducing Synthesis Time and Synthesis Netlist Optimization Time x
3.3.1. Settings to Reduce Synthesis Time and Synthesis Netlist Optimization Time 3.3.2. Use Appropriate Coding Style to Reduce Synthesis Time
3.4. Reducing Placement Time x
3.4.1. Placement Effort Multiplier Settings
3.5. Reducing Routing Time x
3.5.1. Identifying Routing Congestion with the Chip Planner
3.5.1. Identifying Routing Congestion with the Chip Planner x
3.5.1.1. Areas with Routing Congestion 3.5.1.2. Congestion due to HDL Coding style
1. Answers to Top FAQs
2. Design Compilation
3. Reducing Compilation Time
4. Intel® Quartus® Prime Pro Edition User Guide Design Compilation Archives
A. Intel® Quartus® Prime Pro Edition User Guides

2.6.6. Retiming Restrictions and Workarounds

The Compiler identifies the register chains in your design that limit further optimization through Hyper-Retiming. The Compiler refers to these related register-to-register paths as a critical chain. The fMAX of the critical chain and its associated clock domain is limited by the average delay of a register-to-register path, and quantization delays of indivisible circuit elements like routing wires. There are a variety of situations that cause retiming restrictions. Retiming restrictions exist because of hardware characteristics, software behavior, or are inherent to the design. The Retiming Limit Details report the limiting reasons preventing further retiming, and the registers and combinational nodes that comprise the chain. The Fast Forward recommendations list the steps you can take to remove critical chains and enable additional register retiming.

In the diagram of a simple critical chain that follows, the red line represents the same critical chain. Timing restrictions prevent register A from retiming forward. Timing restrictions also prevent register B from retiming backwards. A loop occurs when register A and register B are the same register.

Figure 47. Sample Critical Chain

Fast Forward recommendations for the critical chain include:

  • Reduce the delay of ‘Long Paths’ in the chain. Use standard timing closure techniques to reduce delay. Combinational logic, sub-optimal placement, and routing congestion, are among the reasons for path delay.
  • Insert more pipeline stages in ‘Long Paths’ in the chain. Long paths are the parts of the critical chain that have the most delay between registers.
  • Increase the delay (or add pipeline stages to ‘Short Paths’ in the chain).

Particular registers in critical chains can limit performance for many other reasons. The Compiler classifies the following types of reasons that limit further optimization by retiming:

  • Insufficient Registers
  • Loop
  • Short path/long path
  • Path limit

After understanding why a particular critical chain limits your design’s performance, you can then make RTL changes to eliminate that bottleneck and increase performance.

Table 15.  Hyper-Register Support for Various Design Conditions
Design Condition Hyper-Register Support
Initial conditions that cannot be preserved Hyper-Registers do have initial condition support. However, you cannot perform some retiming operations while preserving the initial condition stage of all registers (that is, the merging and duplicating of Hyper-Registers). If this condition occurs in the design, the Fitter does not retime those registers. This retiming limit ensures that the register retiming does not affect design functionality.
Register has an asynchronous clear Hyper-Registers support only data and clock inputs. Hyper-Registers do not have control signals such as asynchronous clears, presets, or enables. The Fitter cannot retime any register that has an asynchronous clear. Use asynchronous clears only when necessary, such as state machines or control logic. Often, you can avoid or remove asynchronous clears from large parts of a datapath.
Register drives an asynchronous signal This design condition is inherent to any design that uses asynchronous resets. Focus on reducing the number of registers that are reset with an asynchronous clear.
Register has don’t touch or preserve attributes The Compiler does not retime registers with these attributes. If you use the preserve attribute to manage register duplication for high fan-out signals, try removing the preserve attribute. The Compiler may be able to retime the high fan-out register along each of the routing paths to its destinations. Alternatively, use the dont_merge attribute. The Compiler retimes registers in ALMs, DDIOs, single port RAMs, and DSP blocks.
Register is a clock source This design condition is uncommon, especially for performance-critical parts of a design. If this retiming restriction prevents you from achieving the required performance, consider whether a PLL can generate the clock, rather than a register.
Register is a partition boundary This condition is inherent to any design that uses design partitions. If this retiming restriction prevents you from achieving the required performance, add additional registers inside the partition boundary for Hyper-Retiming.
Register is a block type modified by an ECO operation This restriction is uncommon. Avoid the restriction by making the functional change in the design source and recompiling, rather than performing an ECO.
Register location is an unknown block This restriction is uncommon. You can often work around this condition by adding extra registers adjacent to the specified block type.
Register is described in the RTL as a latch Hyper-Registers cannot implement latches. The Compiler infers latches because of RTL coding issues, such as incomplete assignments. If you do not intend to implement a latch, change the RTL.
Register location is at an I/O boundary All designs contain I/O, but you can add additional pipeline stages next to the I/O boundary for Hyper-Retiming.
Combinational node is fed by a special source This condition is uncommon, especially for performance-critical parts of a design.
Register is driven by a locally routed clock Only the dedicated clock network clocks Hyper-Registers. Using the routing fabric to distribute clock signals is uncommon, especially for performance-critical parts of a design. Consider implementing a small clock region instead.
Register is a timing exception end-point The Compiler does not retime registers that are sources or destinations of .sdc constraints.
Register with inverted input or output This condition is uncommon.
Register is part of a synchronizer chain The Fitter optimizes synchronizer chains to increase the mean time between failure (MTBF), and the Compiler does not retime registers that are detected or marked as part of a synchronizer chain. Add more pipeline stages at the clock domain boundary adjacent to the synchronizer chain to provide flexibility for the retiming. Alternatively, you can reduce the detection number for that particular synchronizer chain Synchronization Register Chain Length (default is 3). In some cases a synchronizer chain isn't necessary, and shouldn't be inferred.
Register with multiple period requirements for paths that start or end at the register (cross-clock boundary) This situation occurs at any cross-clock boundary, where a register latches data on a clock at one frequency, and fans out to registers running at another frequency. The Compiler does not retime registers at cross-clock boundaries. Consider adding additional pipeline stages at one side of the clock domain boundary, or the other, to provide flexibility for retiming.
Level Two Title