Visible to Intel only — GUID: nfb1575668004587
Ixiasoft
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.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
Visible to Intel only — GUID: nfb1575668004587
Ixiasoft
3.1. Compiling Submodules Independently
You can independently compile submodules of a larger design. Compiling a larger submodule independently allows you to obtain submodule performance information, and to optimize the submodule for better performance. Depending on your goals in compiling the submodule, you may choose to handle the I/Os differently, as the following techniques describe:
- If you require additional Hyper-Optimization for the submodule during compilation, instantiate the submodule within a wrapper, adding two or more register stages at each input and output. This technique allows retiming of those additional registers into the circuit. If the Compiler retimes the additional registers into the submodule, then you can modify the full design to provide extra registers to the submodule. This method is useful when testing Hyper-Optimization on your submodule to determine the impact of retiming when the submodule is part of the larger design.
- If you do not require further submodule Hyper-Optimization, but want to isolate a module to save compile time and mimic the module timing budget in the full design, define virtual pin constraints to enable retiming of the registers connecting directly to the submodule. Specify appropriate set_input_delay or set_ouput_delay SDC constraints to account for the clock skew of the internal clock tree. Account for the clock skew of the internal clock tree by specifying either a reference_pin or a static maximum constraint, according to the following guidelines and examples:
SDC Argument | Guideline | Example |
---|---|---|
clock | Specify the internal clock domain name (no virtual clock). This argument causes the Compiler to treat external and internal clocks the same, allowing retiming of I/O registers no longer on the boundary. | reference_pin argument: static maximum constraint: |
delay | Specify one of the following to account for the clock skew of the internal clock tree:
|
Figure 83. Submodule Compilation Input Constraint Example
set_input_delay -clock [get_clocks clk_in] \
0 [get_ports data] \
-reference_pin [get_pins [int_reg|clk]
Or:
set insert_delay 1.3
set_input_delay -clock [get_clocks clk_in] \
$insert_delay [get_ports data]