Hyperflex® Architecture High-Performance Design Handbook
ID
683353
Date
7/07/2025
Public
Answers to Top FAQs
1. Hyperflex® FPGA Architecture Introduction
2. Hyperflex® Architecture RTL Design Guidelines
3. Compiling Hyperflex® Architecture Designs
4. Design Example Walk-Through
5. Retiming Restrictions and Workarounds
6. Optimization Example
7. Hyperflex® Architecture Porting Guidelines
8. Appendices
9. Hyperflex® Architecture High-Performance Design Handbook Archive
10. Hyperflex® Architecture High-Performance Design Handbook Revision History
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
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
7.1. Design Migration and Performance Exploration
You can migrate to an Hyperflex® architecture FPGA to evaluate performance improvement. Migrating a design for an Hyperflex® architecture FPGA requires only minor changes. However, you can apply additional non-required changes for further performance improvement. This performance improvement helps you to close timing and add functionality to your design.
Any device migration typically requires some common design changes. These changes include updating PLLs, high-speed I/O pins, and other device resources. The Hyperflex® architecture versions of these components have the same general functionality as in previous device families. However, the Hyperflex® architecture IP components include features to enable higher operational speeds:
- DSP blocks include pipeline registers and support a floating point mode.
- Memory blocks include additional logic for coherency, and width restrictions.
The high level steps in the migration process are:
- Select for migration a lower-level block in the design, without any specialized IP.
- Black-box any special IP component and only retain components that the current level requires. Only retain the following key blocks for core performance evaluation:
- PLLs for generating clocks
- Core blocks (logic, registers, memories, DSPs)
Note: If you migrate a design from a previous version of the Quartus® Prime software, some IP may require replacement if incompatible with the current software version. For example, you cannot upgrade IP based transceivers that a different between different device families.
- Maintain module port definitions when black-boxing components. Do not simply remove the source file from the project.
- Specify the port definition and direction of every component that the design uses to the synthesis software. Failure to define the ports results in compilation errors.
- During design synthesis, review the error messages and correct any missing port or module definitions.
The easiest way to black-box a module is to empty the functional content. The following examples show black-boxing in Verilog HDL or VHDL.