UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Adventurer
Adventurer
507 Views
Registered: ‎07-30-2013

Fanout rule of thumb

I have a design with pretty bad congestion (level 7) and timing.  I suspect part of both is related to fanout.  Utilization does not seem to be a problem, so I ought to be able to throw some FFs at it.

Does anyone have a rule of thumb as to what max fan-out should be set to globally?  Or is it more often done within each module file locally? Does anyone have experience with "rebuilt" hierarchy?  I see in the logs that max fan-out is ignored in the case of crossing hierarchy, so makes sense to flatten but I don't want to lose hierarchy (in the short term so I don't have a redo constraints).

 

0 Kudos
6 Replies
Teacher drjohnsmith
Teacher
486 Views
Registered: ‎07-09-2009

Re: Fanout rule of thumb

Remember the tools will do register duplication for you , as well as push back / forward and combining,

Im always amazed to see what the tools actuality do with my "beautiful" code , but the tools are very clever and do better than I can.

Id suggest that you get more bang for the buck by looking at the algorithm level to put more in parallel,
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Scholar richardhead
Scholar
472 Views
Registered: ‎08-01-2012

Re: Fanout rule of thumb

if you have low utilization but high congestion, you probably have a design with very poor pipelining. Do you have some very complicated logic relying on a lot fo inputs?

I would consider a fanout >1000 to be rather large. and > 500 can make timing harder, but it really depends on the clock speed and the design.
Can you post your code?

0 Kudos
Highlighted
Scholar markcurry
Scholar
465 Views
Registered: ‎09-16-2009

Re: Fanout rule of thumb

 

Fanout goals are generally discouraged within Vivado Synthesis.  Currently UG901 indicates the tool many even ignore any fanout_limits that a user places on the design.  Xilinx does this as the fanout problem is better solved by the back end tools during place and route, and other implementation steps.  Those steps, actually have to sometimes work to undo the duplication done by synthesis (or those done manually by hand).  Yes, the back-end tools sometime work against the front-end tools.  We've removed all fanout goals from synthesis years ago based on suggestions from Xilinx, and haven't had any trouble.

I suggest reviewing the UltraFast Design Methodology Guide for the Vivado Design Suite (UG949).  There's lots of good info in there about tackling hard to implement designs.

Regards,

Mark

 

Tags (1)
Adventurer
Adventurer
401 Views
Registered: ‎07-30-2013

Re: Fanout rule of thumb

Thank you all so far for your advice.

I'm trying to go through UltraFast Methodology for ideas.

It is an extremely parallel design.  (doing something like 20K+ similar operations per cycle).   Because of the type of algorithm, there is a large interconnection between many of the operations before the next set of operations.  I think this is causing much of the congestion.  

I tend never to worry about fan-out, but this particular design, because of the congestion, I've been looking in that direction.  I'm using timing and congestion reports as a guide as to where to look, and I may manually replicate where necessary.  Since the bus/array is so large, for any conditional statement (e.g. if valid_in, case state=something) that affects the large arrays, whatever logic is created, applies to the 20K+ bits, which is why I thought to focus on fanout.  The tool may automatically replicate where necessary, but in this case can't find a solution for routing.

Pipelining makes sense, and I'm thinking about it, but I'm limited on how many cycles I have to complete the entire algorithm. Tough one.

Thanks again.

 

0 Kudos
Scholar richardhead
Scholar
385 Views
Registered: ‎08-01-2012

Re: Fanout rule of thumb

you could try to add attributes to the signal  in the code to minimise fanout. for example, in VHDL

attribute max_fanout : integer;
attribute max_fanout of <your_signal> : signal is N;

Assuming register duplication is turned on, this will force duplication when the fanout goes beyond your specified limit for that signal only.

0 Kudos
Adventurer
Adventurer
375 Views
Registered: ‎07-30-2013

Re: Fanout rule of thumb

Richard,

Thank you.  I've started that and had some initial success so may try to extend to more signals and see how it goes. 

I've noticed that in some cases the tool may not know the total fanout if much of the fanout happens in lower levels of hierarchy than the level of hierarchy that created the flipflop (e.g. an input valid mapped into 20 instances of a block).  So, I may have to explicitly create my own duplication.

I'm trying the "rebuilt" synthesis option, which I had hoped would flatten so that max_fanout would have best effect, but still have hierarchy for implementation constraints.   

0 Kudos