cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
241 Views
Registered: ‎02-13-2012

does max_fanout result in more control sets?

We had problems with timing closure due to very high fanout of reset or clock enable signals to flops.  By adding local copies of those and giving them a max_fanout, we were able to get timing closure.

We are now moving to a newer version of Vivado.  And the Synthesis QOR report suggests reducing the number of control sets.

Does the use of max_fanout to force replication cause Vivado to think of each replication as a separate control set?

For example, assume the original local reset signal (out of a flop) was connected to 8000 flops.  Then the max_fanout was set to 1000.  So Vivado replicate the driving flop 8 times and give each a load of 1000 destinations.  Does this cause the 1 control set to become 8 control sets?

0 Kudos
3 Replies
Highlighted
194 Views
Registered: ‎01-22-2015

@melkin 

As you describe, MAX_FANOUT can significantly increase the number of control sets (see page 252 of UG949(v2019.2)).

I also recommend reading pages 46-50 in UG949 which talk about reducing the use of resets in your design.

Mark

0 Kudos
Highlighted
Scholar
Scholar
168 Views
Registered: ‎08-01-2012

I would say a high fanout is likely to do more harm than high control sets. High control sets means the place and route finds it harder to place logic because it cannot put logic with different control sets in the same slice. But a high fanout is already going to mean you're sending the signal a long way and limiting where it can be placed.

a 1000 limit will be benefician - we've had to limit this even further before.

But with resets - do you really need it? Data path signals that have a valid should NOT need resetting (when valid is low, data is meaningless) so this might give you some large savings. Just reset the valid 0 and your data is already handled.

Similary, ensure you havent got any resets accidently connected to clock enable. Using the traditional template can easily lead to this when you forget to put all signals inside the reset and the sync logic branch:

elsif rising_edge(clk) then
if reset then
--reset logic here
else --sync logic here
end if end if;

This template can help fix that because the reset logic acts last only on the signals inside the reset:

if rising_edge(clk) then
  -- logic here

  if reset then
    -- sync reset goes last.
  end if;
end if;
0 Kudos
Highlighted
Explorer
Explorer
74 Views
Registered: ‎02-13-2012

Thanks for the info and comments. I see I forgot to mention that I do not control all the RTL involved. So my ability to remove unneeded resets is limited. I am working my way through UG949 to do what I can do. One of those is to increase the max_fanout for replicated signals (especially resets). It will increase the distribution and increase routing delay to further away flops. But as long as it meets timing, it is reasonable to try that. And concurrently reduce control sets.
0 Kudos