Skip to content

[AP][GP] High-Fanout Nets Handling #2974

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
AlexandreSinger opened this issue Apr 13, 2025 · 0 comments
Open

[AP][GP] High-Fanout Nets Handling #2974

AlexandreSinger opened this issue Apr 13, 2025 · 0 comments
Assignees

Comments

@AlexandreSinger
Copy link
Contributor

AlexandreSinger commented Apr 13, 2025

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):
Image

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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants