[AP] General Fixed/Unfixed Blocks Cleanup

[AlexandreSinger]

Fixed a couple of small known issues around the AP flow related to how we handle fixed blocks.

Offset the fixed block locations by 0.5 such that they are no longer on the edge. Previously, fixed blocks were placed at the root location of tiles. This was a problem since atoms would want to be generally close to the fixed block and may be biased to the bottom/left tiles to the fixed-block tile. This does not handle large tiles, but will help in general.

If no fixed blocks are provided, the AP solver will always produce the trivial solution (all blocks placed on top of one another anywhere on the device). We were wasting time running bound2bound to solve this and the solution was probably being put on the bottom-left corner (0,0) which is not ideal. Instead of running bound2bound during the first iteration in this case, just placed all blocks in the center of the device. This greatly speeds up the first iteration when no fixed blocks are provided.

Offsetting the fixed blocks seemed to have practically no affect on the results, but I think the offset makes sense to have in the context of flat placement.

By updating how the Bound2Bound solver handles the first iteration, I found that the VTR benchmarks improved a suprising amount (especially the largest ones) in post-fl HPWL. I think that putting everything at the center of the device is easier to partially legalize and is falling on a better solution. Will need to run Titan to be sure.

[AlexandreSinger]

Results on Titan (no fixed blocks):

Metric	Change over baseline
post_gp_hpwl	0.975
post_fl_hpwl	0.743
total_wirelength	0.994
post_fl_avg_disp	0.656
post_fl_max_disp	0.793
total_runtime	0.983

I am actually surprised by how much of a profound affect putting blocks into the center of the device had on the quality of the solution. My guess is that putting blocks in the center of the device make it easier for the partial legalizer to legalize. I have noticed that the partial legalizer does not converge on a fully mass-legal solution. I always chocked that up to numerical issues, but I wonder if there may be an issue with that code.

Regardless, this change is nothing but good!

@vaughnbetz FYI

[vaughnbetz]

Nice improvement!

[vaughnbetz]

Do you look up pin offsets (i.e. where a pin is on a large block) when computing where a net is attracted to a fixed pin? (It will be elsewhere in the code.) I think that should be done.
Same question for floating block too -- do you take pin offsets into account?
For 1x1 tiles a (0.5,0.5) offset seems right. When pin_offsets are taken into account for large blocks it would be good to check though; I think a (0.5,0.5) offset would still make sense but am not sure -- it depends how we set the offsets for pins on the periphery of a large block.

[AlexandreSinger]

That is a good point! We currently do absolutely nothing with pin offsets. All blocks in the AP Netlist are currently treated as points of zero area which have mass. I will raise an issue to track this as a strong TODO item to look into. This would be a good long-term fix for the 0.5 offset and it would improve the mass-legalized solution.

[AlexandreSinger]

Issue raised: #2995

[amin1377]

Results on Titan (no fixed blocks):

Metric Change over baseline
post_gp_hpwl 0.975
post_fl_hpwl 0.743
total_wirelength 0.994
post_fl_avg_disp 0.656
post_fl_max_disp 0.793
total_runtime 0.983
I am actually surprised by how much of a profound affect putting blocks into the center of the device had on the quality of the solution. My guess is that putting blocks in the center of the device make it easier for the partial legalizer to legalize. I have noticed that the partial legalizer does not converge on a fully mass-legal solution. I always chocked that up to numerical issues, but I wonder if there may be an issue with that code.

Regardless, this change is nothing but good!

@vaughnbetz FYI

Thanks, Alex! Quick question: I assume that for these results, timing analysis was not enabled, and the reported total wirelength is the post-routing wirelength. Is that correct?

[AlexandreSinger]

Thanks, Alex! Quick question: I assume that for these results, timing analysis was not enabled, and the reported total wirelength is the post-routing wirelength. Is that correct?

@amin1377 That is correct. I literally just ran the Nightly Test which has timing analysis disabled and total_wirelength is the final, post-routing wirelength.