It is expected that fanout optimization cannot go across a preserved hierarchy boundary.
Vivado Synthesis tends to break the hierarchy in order to count for the fanout in another hierarchy and perform replication of nets.
However, when the hierarchy boundary is preserved by -flatten_hierarchy "none" or other attributes, Vivado Synthesis will not break the hierarchy.
- When a flip-flop with MAX_FANOUT has load fanout in the same hierarchy, MAX_FANOUT works, even with the flatten_hierachy "none" option.
- When a flip-flop with MAX_FANOUT has load fanout in a different hierarchy and flatten_hierachy=rebuild, MAX_FANOUT works.
- When a flip-flop with MAX_FANOUT has load fanout in a different hierarchy and flatten_hierachy=none, MAX_FANOUT does NOT work.
Below are some scenarios in which MAX_FANOUT will not reduce the fanout as expected due to preserved or solid hierarchy boundary.
- Fanout in EDIF or NGC netlists will not be counted for when performing fanout optimization based on max_fanout. See also (Xilinx Answer 51163).
- Fanout in DCPs will not be counted for when performing fanout optimization based on max_fanout.
- When max_fanout is applied to objects outside the IP, the fanout in IPs, either RTL based or out-of-context mode, will not be counted for when performing fanout optimization based on max_fanout as long as the IPs are added into design sources using a .xci file.
This is because a dont_touch attribute will be applied for each IP during Synthesis.
- The keep_hierarchy attribute also prevents fanout optimization across hierarchy during Synthesis.
- The security attributes preserve the hierarchy like keep_hierarchy and are generally used in IPs.
When max_fanout is applied to objects inside the IP (using IP in non-OOC mode or in the IP OOC Synthesis run), max_fanout value may not be met due to security attributes used in the IP source code.
See (Xilinx Answer 65212).
- Before 2014.3, module level attributes such as use_dsp48 and rom_style that are applied on the module/entity level prevent fanout optimization across the hierarchy.
This is fixed starting from Vivado 2014.3.
Work-arounds that can be tried when you encounter the above scenarios:
- Try to apply max_fanout inside the hierarchy that needs to be preserved.
For example, by regenerating the EDIF/NGC/DCP with max_fanout added in the original code, or by modifying the IP source code to apply max_fanout inside the IP.
- Use the fanout optimization of phys_opt_design.
For example, "phys_opt_design -force_replication_on_nets [get_nets <net name>], "phys_opt_design -fanout_opt", "phys_opt_design -fanout_opt_nets [get_nets <list of nets>]".