Reduce MUXF Mapping - 2023.2 English

UltraFast Design Methodology Guide for FPGAs and SoCs (UG949)

Document ID
Release Date
2023.2 English
Tip: This optimization technique is automatically applied by the report_qor_suggestions Tcl command.

Using MUXF* primitives helps critical paths with many logic levels or a tight clock requirement while also reducing power. MUXF* includes MUXF7, MUXF8, and MUXF9, which are dedicated multiplexer resources located within the CLB. These resources are grouped with up to eight LUTs during placement. This grouping forces high CLB input utilization with higher routing demand and limits placement flexibility when the netlist connectivity is complex, leading to potential higher routing congestion and timing degradation.

In addition, the opt_design command provides an optional MUX optimization phase to remap MUXF* structures to LUT3 primitives to improve routability. You can use the -muxf_remap option to remap all of the MUXF* cells. Alternatively, set the MUXF_REMAP property to TRUE on a select number of cells in the congested region to limit the scope of the MUX remapping. Any MUXF* cells with the MUXF_REMAP property set to TRUE automatically trigger the MUX optimization phase during opt_design and are remapped to LUT3s.

Note: Disabling these resources can result in increased power. Use this method only when needed to achieve timing closure.

The following figure shows a 16-1 MUX before and after the MUXF* optimization.

Figure 1. Netlist Before and After MUX Optimization

To further optimize the netlist after performing MUX optimization, use the -remap option with the -muxf_remap option. This combines the LUT3 primitives that are generated by the MUXF* optimization with connected logic if possible.

You can determine whether timing closure is impacted by routing congestion by reviewing the Router Initial Estimated Congestion table in the log files or in the Design Analysis report (report_design_analysis -congestion) after place or route is complete.

In the following figure, the Design Analysis report shows that 7% of the device is impacted by Short congestion level 5 (32x32 CLBs) in the South direction while 26% MUXF are utilized in the corresponding congested area.

Figure 2. South Short Congestion in the report_design_analysis Congestion Table

In the Vivado IDE, you can select a row in the table of the Design Analysis congestion report to highlight the corresponding congested area in the Device window. The following figure shows that the congestion overlaps with a higher MUXF density area. The MUXF cells are highlighted in magenta using the following command in the Vivado IDE Tcl Console:

highlight_objects -color magenta [get_cells -hier -filter REF_NAME=~MUXF*]

MUXF* includes MUXF7/MUXF8/MUXF9, which are dedicated multiplexer resources located within the CLB. These resources are grouped with up to 8 LUTs during placement, forcing high CLB input utilization with higher routing demand and limiting placement flexibility. The estimated congestion per CLB is displayed using the Vivado IDE metrics.

Figure 3. MUXF Congestion Highlighted in the Vivado IDE Device Window

When high MUXF* utilization overlaps with areas of higher congestion, AMD recommends reducing the number of MUXF* by mapping their corresponding functionality to LUTs, which have higher placement and routing flexibility. You can use the following command in the XDC synthesis constraints to modify the netlist:

set_property BLOCK_SYNTH.MUXF_MAPPING 0 [get_cells inst_name4]

After rerunning synthesis, place, and route, the updated congestion table in the Design Analysis report now shows that the South Short congestion is lower (level 4), which typically improves the timing quality of results.

Figure 4. Initial Router Congestion Table after Reducing MUXF Usage on a Module