-
Notifications
You must be signed in to change notification settings - Fork 414
[AP][Solver] Supporting Unfixed Blocks #2944
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[AP][Solver] Supporting Unfixed Blocks #2944
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, Alex!
|
||
// Update the guess. The guess for the next iteration is the solution in | ||
// this iteration. | ||
guess_x = x; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the way, did this update affect the results? Given how fast the solver already is, I wouldn’t expect to see any significant improvement in runtime, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It improved the runtime. The QoR does change, but I would not expect it to change by much. I will run Titan to see!
When no fixed blocks are provided by the user, the AP flow can still work. Currently, in the first iteration, the solver will put all blocks at 0,0 and use the legalized solution in the next iteration as fixed points. Instead of (0,0), it makes more sense to put the blocks in the center of the device. Also added a guess to the solver to help CG converge faster each iteration. Added a regression test to ensure that not describing the fixed blocks is supported.
b1b766d
to
b26c2d2
Compare
Titan result:
The runtime seems to be the same; but on the largest circuits, the runtime improved. One thing I noticed is that some of the larger circuits are getting better results now. My guess is that some of the larger circuits are hitting the iteration limits of the CG solver which may be causing them to converge on slightly different answers. It seems to have made some better and some worst, but overall the WL remained the same relative to baseline. I think this is good to merge. |
When no fixed blocks are provided by the user, the AP flow can still work. Currently, in the first iteration, the solver will put all blocks at 0,0 and use the legalized solution in the next iteration as fixed points. Instead of (0,0), it makes more sense to put the blocks in the center of the device.
Also added a guess to the solver to help CG converge faster each iteration.
Added a regression test to ensure that not describing the fixed blocks is supported.