Skip to content

[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

Merged

Conversation

AlexandreSinger
Copy link
Contributor

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.

@github-actions github-actions bot added VPR VPR FPGA Placement & Routing Tool lang-cpp C/C++ code labels Mar 20, 2025
Copy link
Contributor

@amin1377 amin1377 left a 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;
Copy link
Contributor

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.

Copy link
Contributor Author

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.
@AlexandreSinger
Copy link
Contributor Author

Titan result:

Circuit WL Total Runtime
LU230_stratixiv_arch_timing.blif 0.9786185746 1.401593625
LU_Network_stratixiv_arch_timing.blif 0.9769511381 1.709277304
SLAM_spheric_stratixiv_arch_timing.blif 0.9176000783 1.526879015
bitcoin_miner_stratixiv_arch_timing.blif 0.9569008506 1.177313375
bitonic_mesh_stratixiv_arch_timing.blif 0.9431755656 1.355941761
cholesky_bdti_stratixiv_arch_timing.blif 0.9372937905 1.55164387
cholesky_mc_stratixiv_arch_timing.blif 1.015132133 1.697624454
dart_stratixiv_arch_timing.blif 0.9704425312 1.365579848
denoise_stratixiv_arch_timing.blif 0.9742311058 1.323674367
des90_stratixiv_arch_timing.blif 0.9371638479 1.292131597
directrf_stratixiv_arch_timing.blif 0.9935070632 1.311922985
gsm_switch_stratixiv_arch_timing.blif 0.9466840119 1.424273477
mes_noc_stratixiv_arch_timing.blif 1.010185738 1.312011408
minres_stratixiv_arch_timing.blif 0.9521186112 1.670725001
neuron_stratixiv_arch_timing.blif 0.9741259505 1.892778915
openCV_stratixiv_arch_timing.blif 0.9758560488 1.481990185
segmentation_stratixiv_arch_timing.blif 0.9940167809 1.408195085
sparcT1_chip2_stratixiv_arch_timing.blif 0.9181174685 1.310779168
sparcT1_core_stratixiv_arch_timing.blif 0.8378267906 1.266755734
sparcT2_core_stratixiv_arch_timing.blif 0.9324631827 1.276679304
stap_qrd_stratixiv_arch_timing.blif 1.02513424 1.419902993
stereo_vision_stratixiv_arch_timing.blif 0.9771664477 1.621280537
Geomean 0.9602787721 1.435306822

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.

@amin1377 amin1377 merged commit b3d9694 into verilog-to-routing:master Mar 21, 2025
36 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lang-cpp C/C++ code VPR VPR FPGA Placement & Routing Tool
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants