Handling High Fanouts

When a signal has a high fanout, it may have higher path delays and therefore reduced performance. Additionally, when you have optimized the depth of the design so that there are very few levels of logic on the critical path, even modest high-fanout nets may be limiting. In these cases, you can tweak the synthesis to address high fanout either globally or manually.

Limit Fanout Globally

You can set the maximum fanout using the --fanout-limit synthesis setting. You set this option in the Project Editor > Synthesis tab. This option is a global project setting and affects your whole design.

To identify signals with high fanout:

  1. Perform a full compile.
  2. Open the timing report (<project name>.timing.rpt) by double-clicking the filename under Result > Routing or opening the file in the outflow directory.
  3. By default, the timing report shows the most critical path. Fanout is reported in the pins on net column.
Data Path
pin name            model name    delay (ns)   cumulative delay (ns)    pins on net   location
===============================================================================================
 Fled[1]~FF|Q        ff               0.650                  0.650          300        (55,78)
 Fled[1]~FF|O_seq    eft              5.210                  5.861          300        (55,78)
   Routing elements:  
     Manhattan distance of X:55, Y:14
 Fled[1]             io               0.420                  6.281          300        (0,92)

If the pins on net is a large number (300 in the above example) and there is a large delay, try setting the --fanout-limit to a lower number. The software duplicates the logic as needed to limit the fanout. This setting trades off area for delay; it may use more logic but run faster.

Set Fanout Limit to 100

1. Open the Project Editor.
2. Click the Synthesis tab.
3. Set the Value for --fanout-limit to 100.
4. Click OK.
5. Recompile.

Limit Fanout Manually

If you do not want to limit the fanout with a global setting, you can limit it manually by duplicating logic and using the syn_preserve synthesis attribute to tell synthesis not to minimize the duplicated logic.

This attribute applies to signals. When it is set to true, yes, or 1, synthesis keeps the signal through optimization, that is, synthesis does not minimize or remove the signal. This attribute can be helpful when you want to simulate or view a signal in the Debugger. Although the signal is kept, synthesis may still choose to implement downstream functions that depend on this signal independent of this preserved signal.

In the Efinity software v2022.2 and higher, the syn_preserve attribute is supported on a user hierarchy instance. The effect is equivalent to tagging all boundary signals of the instance with syn_preserve.

Verilog HDL: 
(* syn_preserve = "true" *) wire x;
VHDL: 
attribute syn_preserve: boolean;
attribute syn_preserve of x : signal is true;
Note: A signal with syn_preserve usually has it’s name preserved through synthesis flow. However, if the signal is connected directly to a top-level port, the name in the map.v netlist may be changed to that of the top-level port name.