In FPGA development and design, we may experience high resource usage, such as the utilization of key resources such as BRAM, LUT, and URAM reaching or exceeding 80%, and timing violations are common at this time, even due to congestion. The routing fails, and the entire FPGA project is in danger of not being able to generate a bit file.
So, is there a way to solve this kind of problem? lcd panel tft
Such problems are more difficult problems in FPGA design and implementation. Xilinx proposes UltraFast design methodology for 7 series and later UltraScale/UltraScale+, etc., which is used to guide the successful design and implementation of this series of devices and complete complex system design.
Timing closure means that the design meets all timing requirements. Using the correct HDL and constraints for synthesis makes timing closure easier. Iterating through multiple synthesis stages is also critical by choosing more appropriate HDL, constraints, and synthesis options, as shown in the figure below.
Design Methodology for Fast Convergence Proposed by Xilinx
How to deal with FPGA routing congestion?
If the critical path is in the congested area or close to the congested area, or the resource utilization rate is high, it will cause timing closure difficulties. In many cases, congestion consumes a lot of routing time or even routing failures. If routing delays are significantly greater than expected, then we have to consider reducing the congestion level of the design.
With the timing constraints and physical constraints correct, we can solve the congestion problem in the following ways.
1. Congestion Type
The Xilinx FPGA routing structure includes interconnection resources of different lengths in four directions: east, south, west, and north. Congested areas are represented by the smallest squares that cover adjacent interconnect resources or CLB cells.
Congestion Levels and Congestion Areas in the ” Device ” View
There are three types of congestion: global congestion, short-term congestion and long-term congestion.
Congestion Type
2. Generate Design Congestion Report
To check the congestion level, we can generate a Design Congestion Report by the following Tcl command based on the DCP generated after placement.
report_design_analysis -congestion -name cong
When analyzing congestion, the levels reported by the tool can be categorized as shown in the table below. Congestion levels of 5 or higher typically impact QoR and necessarily result in longer router runtimes.
To help identify congestion, the Report Design Analysis command supports the generation of a congestion report showing the congested regions of the device and the names of the design blocks that exist within those regions. The congestion table in this report shows the congested areas discovered by the placer and router algorithms. The figure below shows an example of a congestion table.
congestion table
The “Placed Maximum”, “Initial Estimated Router Congestion”, and “Router Maximum” congestion tables provide information about the most congested areas in the four directions, east, west, north and south. When a window in this table is selected, the corresponding congested area is highlighted in the Device window.
3. Generate a Design Complexity Report
We can also predict whether congestion occurs by designing a complexity report. We can generate a design complexity report on the DCP generated by the layout through the following Tcl commands.
report_design_analysis -complexity -name comp
The Complexity Report displays the Rent Exponent, Average Fanout, and distribution by type of leaf node element of the top-level design and/or hierarchical element. The Rent index refers to the relationship between the number of ports and the number of cells in a netlist partition when partitioning the design recursively using the min-cut algorithm. It is calculated similarly to the algorithm used by the placer during global placement. Therefore, it provides an accurate indication of the difficulties faced by the placer, especially when the hierarchy of the design matches well with the physical partitions found during global placement.
A design with a high Rent index indicates that the design contains logically closely connected groupings that are equally well connected to other groupings. This is usually understood as higher utilization of global routing resources and higher routing complexity. The Rent Index provided in this report is calculated from the unplaced and unrouted netlist. After the placement is complete, the Rent index for the same design may change because it is based on physical rather than logical partitions.
complexity report
Typical Range of Rent Index
Typical range for “average fan-out”
4. Solve congestion problems
According to the causes of congestion mentioned above, we can use the following methods to solve the problem of wiring congestion.
Congestion Cause 1: Excessive MUXF (Convert MUXF to LUT)
Method 1: Use the modular synthesis technique to set MUXF_REMAPPING for a specific mode:
set_property BLOCK_SYNTH. MUXF_MAPPING 1 [get_cells top/instance]
Method 2: Use the -remap option in the opt_design stage:
opt_design -mux_remap -remap
Method 3: Set the MUXF_REMAP attribute to true for a specific MUXF
set_property MUXF_REMAP 1 [get_cells -hier-filter {NAME=~cpu*&&REF_NAME=~MUXF*}]
Congestion cause 2: Too long carry chain (convert carry chain to LUT)
Method 1: Use the -remap option in the opt_design stage:
opt_design -carry_remap -remap
Method 2: Set the CARRY_REMAP property for a specific MUXF
set_property CARRY_REMAP 2 [get_cells -hier-filter {REF_NAME==CARRY8}]
Congestion Cause 3: Too Many Control Sets (Merge Control Sets)
Method 1: Use modular synthesis technology to set CONTROL_SET_THRESHOLD for a specific mode:
set_property BLOCK_SYNTH. CONTROL_SET_THRESHOLD 10 [get_cells top/instance]
Method 2: In the opt_design stage, use -control_set_merge to merge equivalent control sets
opt_design -control_set_merge
Method 3: In opt_design phase, use merge_equivalent_drivers to merge equivalent control sets, including non-control logic
opt_design-merge_equivalent_drivers
Congestion cause 4: Excessive LUT integration (prevents LUT integration)
Method 1: Use modular synthesis technology to set LUT_COMBI NI NG for a specific mode:
set_property BLOCK_SYNTH. LUT_COMBINING 0 [get_cells top/instance]
Method 2: Set the LUTNM property of the LUT to be empty:
set_property LUTNM “” [get_cells hier-filter {REF_NAME=～LUT*&&NAME=～inst}]
In the synthesis stage, in addition to using the above methods, for IP, we’d better use the OOC synthesis method.
During the implementation phase, an appropriate implementation strategy can be selected to alleviate congestion. For UltraScale series chips, you can try to use the “Congestion_*” strategy to alleviate congestion; for UltraScale+ series chips, you can try to use the “performance_NetDelay_*” strategy to alleviate congestion. As shown below.
implementation-time congestion resolution strategy
Of course, we also try to use the “performance_ExtraTimingOpt” strategy for timing optimization, but it may not solve the congestion problem.
What problems did you encounter in the process of FPGA layout and routing? Welcome to share or leave a message.
