Visible to Intel only — GUID: gbi1587408101912
Ixiasoft
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
Visible to Intel only — GUID: gbi1587408101912
Ixiasoft
2.2.5.1. Clock Domain Crossing Constraint Guidelines
You must apply appropriate timing constraints to any multi-bit clock domain crossing. The set_false_path constraint has a higher precedence than all other path-based constraints. Therefore, when a clock domain crossing has a set_false_path constraint, timing analysis can ignore other lower precedence constraints like skew.
Follow these guidelines to properly constrain a clock domain crossing:
- Review the SDC timing constraints to ensure that no set_false_path constraint exists between the two clock domains.
- To remove any false paths between two clock domains from setup and hold timing analysis, apply the set_clock_groups constraint, rather than set_false_path constraint. set_clock_groups has a lower precedence than set_false_path.
- Constrain the paths between the two clock domains with set_net_delay to make the nets as short as possible.
- Constrain the nets between the two clock domains with set_max_skew. You can view the results in comparison to your constraint in the Timing Analyzer reports.
The following shows example constraints for a clock domain crossing between data_a in clk_a clock domain, and data_b in clk_b clock domain:
create_clock -name clk_a -period 4.000 [get_ports {clk_a}] create_clock -name clk_b -period 4.500 [get_ports {clk_b}] set_clock_groups -asynchronous -group [get_clocks {clk_a}] -group \ [get_clocks {clk_b}] set_net_delay -from [get_registers {data_a[*]}] -to [get_registers \ {data_b[*]}] -max -get_value_from_clock_period dst_clock_period \ -value_multiplier 0.8 set_max_skew -from [get_keepers {data_a[*]}] -to [get_keepers {data_b[*]}] \ -get_skew_value_from_clock_period src_clock_period \ -skew_value_multiplier 0.8