You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am noticing in the VTR and Titan runs that many of the designs have some very high fanout nets which are not labelled as clock or global.
In the AP flow, I explicitly remove nets from the AP netlist which are clock / global since they do not contribute much to the solution (clocks / global signals go all over the chip, so their HPWL will not change much during GP). This was also done to improve performance, since high-fanout connections add many terms to the connectivity matrix.
Below is a part of the GP report for MCML from the VTR benchmarks (in this case with fixed IOs, but it should not matter):
As you can see, the max fanout of any net in the AP netlist is 51,878, while the average is only around 5. Based on my intuition, the solver should be faster than the legalizer; however, I believe that these high-fanout nets are causing the solver to slow-down dramatically with very little gain.
We should investigate adding a threshold to the solver to have it ignore nets that are "high-fanout". We should be able to just ignore the nets which are above this threshold when we are building the connectivity matrices.
The text was updated successfully, but these errors were encountered:
I am noticing in the VTR and Titan runs that many of the designs have some very high fanout nets which are not labelled as clock or global.
In the AP flow, I explicitly remove nets from the AP netlist which are clock / global since they do not contribute much to the solution (clocks / global signals go all over the chip, so their HPWL will not change much during GP). This was also done to improve performance, since high-fanout connections add many terms to the connectivity matrix.
Below is a part of the GP report for MCML from the VTR benchmarks (in this case with fixed IOs, but it should not matter):

As you can see, the max fanout of any net in the AP netlist is 51,878, while the average is only around 5. Based on my intuition, the solver should be faster than the legalizer; however, I believe that these high-fanout nets are causing the solver to slow-down dramatically with very little gain.
We should investigate adding a threshold to the solver to have it ignore nets that are "high-fanout". We should be able to just ignore the nets which are above this threshold when we are building the connectivity matrices.
The text was updated successfully, but these errors were encountered: