Intel® Hyperflex™ Architecture High-Performance Design Handbook

Download PDF
ID 683353
Date 10/04/2021
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. Intel® Hyperflex™ FPGA Architecture Introduction 2. Intel® Hyperflex™ Architecture RTL Design Guidelines 3. Compiling Intel® Hyperflex™ Architecture Designs 4. Design Example Walk-Through 5. Retiming Restrictions and Workarounds 6. Optimization Example 7. Intel® Hyperflex™ Architecture Porting Guidelines 8. Appendices 9. Intel® Hyperflex™ Architecture High-Performance Design Handbook Archive 10. Intel® Hyperflex™ Architecture High-Performance Design Handbook Revision History
1. Intel® Hyperflex™ FPGA Architecture Introduction x
1.1. Intel® Hyperflex™ Architecture Design Concepts
2. Intel® Hyperflex™ Architecture RTL Design Guidelines x
2.1. High-Speed Design Methodology 2.2. Hyper-Retiming (Facilitate Register Movement) 2.3. Hyper-Pipelining (Add Pipeline Registers) 2.4. Hyper-Optimization (Optimize RTL)
2.1. High-Speed Design Methodology x
2.1.1. Set a High-Speed Target 2.1.2. Experiment and Iterate 2.1.3. Compile Components Independently 2.1.4. Optimize Sub-Modules 2.1.5. Avoid Broadcast Signals
2.1.1. Set a High-Speed Target x
2.1.1.1. Speed and Timing Closure 2.1.1.2. Speed and Latency
2.2. Hyper-Retiming (Facilitate Register Movement) x
2.2.1. Reset Strategies 2.2.2. Clock Enable Strategies 2.2.3. Preserving Registers During Synthesis 2.2.4. Timing Constraint Considerations 2.2.5. Clock Synchronization Strategies 2.2.6. Metastability Synchronizers 2.2.7. Initial Power-Up Conditions 2.2.8. Retiming through RAMs and DSPs
2.2.1. Reset Strategies x
2.2.1.1. Removing Asynchronous Resets 2.2.1.2. Synchronous Resets on Global Clock Trees 2.2.1.3. Synchronous Resets on I/O Ports 2.2.1.4. Duplicate and Pipeline Synchronous Resets
2.2.2. Clock Enable Strategies x
2.2.2.1. Localized Clock Enable 2.2.2.2. High Fan-Out Clock Enable 2.2.2.3. Clock Enable with Timing Exceptions
2.2.4. Timing Constraint Considerations x
2.2.4.1. Optimize Multicycle Paths 2.2.4.2. Overconstraints
2.2.5. Clock Synchronization Strategies x
2.2.5.1. Clock Domain Crossing Constraint Guidelines
2.2.7. Initial Power-Up Conditions x
2.2.7.1. Specifying Initial Memory Conditions 2.2.7.2. Initial Conditions and Retiming 2.2.7.3. Initial Conditions and Hyper-Registers 2.2.7.4. Retiming Reset Sequences
2.2.7.3. Initial Conditions and Hyper-Registers x
2.2.7.3.1. Implementing Clock Gating 2.2.7.3.2. Intel® Quartus® Prime Settings for Initial Conditions
2.3. Hyper-Pipelining (Add Pipeline Registers) x
2.3.1. Conventional Versus Hyper-Pipelining 2.3.2. Pipelining and Latency 2.3.3. Use Registers Instead of Multicycle Exceptions
2.3.2. Pipelining and Latency x
2.3.2.1. Pipelining at Variable Latency Locations 2.3.2.2. Automatic Pipeline Insertion
2.3.2.1. Pipelining at Variable Latency Locations x
2.3.2.1.1. Specifying a Latency-Insensitive False Path
2.3.2.2. Automatic Pipeline Insertion x
2.3.2.2.1. Step 1: Create the Variable Latency Module 2.3.2.2.2. Step 2: Instantiate the Variable Latency Module Instantiating Variable Latency at Clock Domain Boundaries Instantiating Variable Latency Adjacent to Complex Combinational Functions Instantiating Variable Latency Between Independent Functional Blocks Applying False Path or Exception Constraints Apply Variable Latency Constraints -from or -to 2.3.2.2.3. Step 3: Verify Automatic Pipeline Insertion Option 2.3.2.2.4. (Optional) Auto-Pipeline Insertion without a Variable Latency Module
2.4. Hyper-Optimization (Optimize RTL) x
2.4.1. General Optimization Techniques 2.4.2. Optimizing Specific Design Structures
2.4.1. General Optimization Techniques x
2.4.1.1. Shannon’s Decomposition 2.4.1.2. Time Domain Multiplexing 2.4.1.3. Loop Unrolling 2.4.1.4. Loop Pipelining 2.4.1.5. Precomputation
2.4.1.1. Shannon’s Decomposition x
2.4.1.1.1. Shannon’s Decomposition Example 2.4.1.1.2. Identifying Circuits for Shannon’s Decomposition
2.4.1.4. Loop Pipelining x
2.4.1.4.1. Loop Pipelining Theory 2.4.1.4.2. Loop Pipelining Demonstration 2.4.1.4.3. Loop Pipelining and Synthesis Optimization
2.4.2. Optimizing Specific Design Structures x
2.4.2.1. High-Speed Clock Domains 2.4.2.2. Restructuring Loops 2.4.2.3. Control Signal Backpressure 2.4.2.4. Flow Control with FIFO Status Signals 2.4.2.5. Flow Control with Skid Buffers 2.4.2.6. Read-Modify-Write Memory 2.4.2.7. Counters and Accumulators 2.4.2.8. State Machines 2.4.2.9. Memory 2.4.2.10. DSP Blocks 2.4.2.11. General Logic 2.4.2.12. Modulus and Division 2.4.2.13. Resets 2.4.2.14. Hardware Re-use 2.4.2.15. Algorithmic Requirements 2.4.2.16. FIFOs 2.4.2.17. Ternary Adders
2.4.2.1. High-Speed Clock Domains x
2.4.2.1.1. Visualizing Clock Networks 2.4.2.1.2. Viewing Clock Networks in the Fitter Report 2.4.2.1.3. Viewing Clocks in the Timing Analyzer
2.4.2.9. Memory x
2.4.2.9.1. Intel® Hyperflex™ Architecture True Dual-Port Memory 2.4.2.9.2. Use Simple Dual-Port Memories 2.4.2.9.3. Intel® Hyperflex™ Architecture Simple Dual-Port Memory Example 2.4.2.9.4. Memory Mixed Port Width Ratio Limits 2.4.2.9.5. Unregistered RAM Outputs
3. Compiling Intel® Hyperflex™ Architecture Designs x
3.1. Compiling Submodules Independently 3.2. Design Assistant Design Rule Checking
3.2. Design Assistant Design Rule Checking x
3.2.1. Running Design Assistant During Compilation 3.2.2. Running Design Assistant in Analysis Mode
3.2.2. Running Design Assistant in Analysis Mode x
3.2.2.1. Cross-Probing from Design Assistant to Visualization Tools 3.2.2.2. Launching Design Assistant from Chip Planner 3.2.2.3. Launching Design Assistant from Timing Analyzer
4. Design Example Walk-Through x
4.1. Median Filter Design Example
4.1. Median Filter Design Example x
4.1.1. Step 1: Compile the Base Design 4.1.2. Step 2: Add Pipeline Stages and Remove Asynchronous Resets 4.1.3. Step 3: Add More Pipeline Stages and Remove All Asynchronous Resets 4.1.4. Step 4: Optimize Short Path and Long Path Conditions
5. Retiming Restrictions and Workarounds x
5.1. Setting the dont_merge Synthesis Attribute 5.2. Interpreting Critical Chain Reports
5.2. Interpreting Critical Chain Reports x
5.2.1. Insufficient Registers 5.2.2. Short Path/Long Path 5.2.3. Fast Forward Limit 5.2.4. Loops 5.2.5. One Critical Chain per Clock Domain 5.2.6. Critical Chains in Related Clock Groups 5.2.7. Complex Critical Chains 5.2.8. Extend to locatable node 5.2.9. Domain Boundary Entry and Domain Boundary Exit 5.2.10. Critical Chains with Dual Clock Memories 5.2.11. Critical Chain Bits and Buses 5.2.12. Delay Lines
5.2.1. Insufficient Registers x
5.2.1.1. Insufficient Registers Example 5.2.1.2. Optimizing Insufficient Registers 5.2.1.3. Critical Chains with Dual Clock Memories
5.2.2. Short Path/Long Path x
5.2.2.1. Hyper-Register Locations Not Available 5.2.2.2. Example for Hold Optimization 5.2.2.3. Optimizing Short Path/Long Path 5.2.2.4. Add Registers 5.2.2.5. Duplicate Common Nodes 5.2.2.6. Data and Control Plane
5.2.3. Fast Forward Limit x
5.2.3.1. Optimizing Path Limit
5.2.4. Loops x
5.2.4.1. Example of Loops Limiting the Critical Chain
6. Optimization Example x
6.1. Round Robin Scheduler
7. Intel® Hyperflex™ Architecture Porting Guidelines x
7.1. Design Migration and Performance Exploration 7.2. Top-Level Design Considerations
7.1. Design Migration and Performance Exploration x
7.1.1. Black-boxing Verilog HDL Modules 7.1.2. Black-boxing VHDL Modules 7.1.3. Clock Management 7.1.4. Pin Assignments 7.1.5. Transceiver Control Logic 7.1.6. Upgrade Outdated IP Cores
8. Appendices x
8.1. Appendix A: Parameterizable Pipeline Modules 8.2. Appendix B: Clock Enables and Resets
8.2. Appendix B: Clock Enables and Resets x
8.2.1. Synchronous Resets and Limitations 8.2.2. Retiming with Clock Enables 8.2.3. Resolving Short Paths
8.2.1. Synchronous Resets and Limitations x
8.2.1.1. Synchronous Resets Summary
8.2.2. Retiming with Clock Enables x
8.2.2.1. Example for Broadcast Control Signals
1. Intel® Hyperflex™ FPGA Architecture Introduction
2. Intel® Hyperflex™ Architecture RTL Design Guidelines
3. Compiling Intel® Hyperflex™ Architecture Designs
4. Design Example Walk-Through
5. Retiming Restrictions and Workarounds
6. Optimization Example
7. Intel® Hyperflex™ Architecture Porting Guidelines
8. Appendices
9. Intel® Hyperflex™ Architecture High-Performance Design Handbook Archive
10. Intel® Hyperflex™ Architecture High-Performance Design Handbook Revision History

2.3.2.2.2. Step 2: Instantiate the Variable Latency Module

You can use the Fast Forward Compilation feature to help identify suitable locations for automatic pipeline insertion. The following locations are typically suitable for automatic pipeline insertion:
  • Clock boundaries that are transferring constantly changing data allow the Fitter to spread the blocks far apart when advantageous.
  • Locations adjacent to a complex combinational function are suitable for a function that has trouble meeting timing.
  • Locations between two independent functional blocks on the same clock domain allow the Fitter to spread the blocks far apart when advantageous.

Instantiating Variable Latency at Clock Domain Boundaries

Fast Forward Compilation recommends adding pipeline stages at clock domain boundaries, where additional latency can be simple to accommodate. Instantiating variable latency at clock boundaries allows the Fitter to spread these blocks far apart when advantageous. In such cases, you can simply instantiate the hyperpipe_vlat module either before or after a synchronizer or FIFO. Instantiate hyperpipe_vlat with no other registers or logic between the comb function and hyperpipe_vlat, with respect to netlist connectivity.

This instantiation allows the Hyper-Retimer to automatically insert just enough pipeline registers to meet the timing requirement. A latency-insensitive false path is inappropriate in this case because the data is constantly changing.

Instantiating Variable Latency Adjacent to Complex Combinational Functions

You can instantiate the hyperpipe_vlat module adjacent to a complex combinational module to allow the Hyper-Retimer to insert just enough registers to meet the timing requirement. Instantiate the hyperpipe_vlat module after the complex combinational module because backwards retiming does not require additional reset cycles to accommodate any initial conditions. You cannot control whether a register in the hyperpipe_vlat module retimes forward, into the logic following it, or backward, into the combinational module.

Instantiating Variable Latency Between Independent Functional Blocks

You can instantiate the hyperpipe_vlat module between two independent functional blocks in the same clock domain. This instantiation allows the functional blocks to spread apart during placement, while only adding the number of pipeline stages between the blocks necessary to meet the timing requirements.

Note: Do not place the variable latency module directly adjacent to a partition boundary. Rather, place a register between the latency module and the partition port to separate them. The variable latency module does not autopipeline during retiming if you place the hyperpipe_vlat module immediately adjacent to a partition boundary, as Improper Variable Latency Module Placement Prevents Autopipelining shows.
Figure 37. Improper Variable Latency Module Placement Prevents Autopipelining
Figure 38. Place Registers Between Variable Latency Module and Partition to Allow Autopipelining

Applying False Path or Exception Constraints

If instantiating the hyperpipe_vlat module between independent functional blocks, you must add a false path (set_false_path) or other timing exception to allow the connected blocks to float apart during placement. You apply the false path or exception to the vlat_r register in the hyperpipe_vlat module. By placing the timing exception within a conditional if statement, the Timing Analyzer does not use the exception when the vlat adds registers, nor during final timing sign-off, ensuring each register meets the clock requirement.

Without the corresponding false path or exception constraint, hyperpipe_vlat provides little benefit. Without a false path or exception constraint, the Hyper-Retimer only recognizes a single pipeline stage in hyperpipe_vlat during placement and routing. The Hyper-Retimer only adds the additional pipeline stages after placement and routing completes. The Compiler tends to place two functional blocks connected by a single pipeline stage close together, unless the paths between them are cut.

The following lines show the appropriate .sdc syntax to apply a set_false_path exception for the hyperpipe_vlat instance at my|top|design|hyperpipe_vlat_inst. Add similar lines to your .sdc for any hyperpipe_vlat instances that connect to independent functional blocks: 

if { ! [is_post_route] } {
     set_false_path -to my|top|design|hyperpipe_vlat_inst|vlat_r[*]}

Furthermore, if you limit the number of pipelines with the MAX_PIPE parameter, consider applying the max_delay or multicycle exception, rather than a set_false_path exception. If there is a MAX_PIPE constraint on the vlat instance, then a set_false_path exception may move the logic so far away, that the MAX_PIPE constraint is insufficient. For this reason, the multicycle exception is better. For example, If NUM_PIPES=3, you can add a multicycle exception equal to NUM_PIPES(3). 

if {![is_post_route]} {
set_multicycle_path -setup –to my|top|design|hyperpipe_vlat_inst|vlat_r[*] 3
set_multicycle_path –hold –to my|top|design|hyperpipe_vlat_inst|vlat_r[*] 2}

Apply Variable Latency Constraints -from or -to

You can use the variable latency module to add Hyper-Registers forward or backward in the register chain. Use the following constraint methods when pushing registers through combinational logic:
  • -from—place vlat_r before combinational logic that you want to pipeline, then apply the multicycle or false path –from constraint.
    Figure 39. Inserting vlat_hr Before Combinational Logic
  • -to—place vlat_r after combinational logic that you want to pipeline, then apply the multicycle or false path –to constraint
    Figure 40. Inserting vlat_r After Combinational Logic
Level Two Title