[Place] Centriod Initial Placement

[amin1377]

WIP

[amin1377]

@vaughnbetz:

In this PR, I updated the initial placement logic as we discussed. Instead of choosing a random location within a fixed range of 15 around the centroid, the new approach gradually increases the search range from 1 up to half the device size. The function will now exhaust all available locations within the current range before expanding it.

Here are the results for Titan (including initial placement WL and CPD).

• Initial placement WL and CPD improved significantly — reduced by 48% and 27%, respectively.
• Final placement WL remained about the same, while placed CPD increased by 1%.
• Routed WL was roughly a tie, and routed CPD increased by ~2%.

For the large VTR benchmarks (results):

• Min channel width increased by 5%.
• Routed WL and CPD increased by 1% and 5%, respectively.
• However, initial placement WL and CPD still improved by 46% and 18%.

I was expecting the QoR to at least stay the same, if not improve overall. Do you think it would be worth digging into the circuits with the most degradation to better understand what's going on?

@tpagarani, FYI.

[vaughnbetz]

I wonder if the final result quality drop off is due to making a very dense placement with a deep local minimum? You fill in around a seed block completely.
It's a bit more complicated, but you could choose a target porosity based on how full the design is and search in a ring only a certain percentage (matching the target porosity) of the locations around it. Or you could directly try to hit a certain porosity by rejecting locations that had an overly dense local region, compared to the overall average density that will be needed.

[vaughnbetz]

@soheil also suggests checking if the initial temperature is appropriate, or if it should be lowered.

[vaughnbetz]

Looking at the circuits with the most degradation makes sense to me too, to see if you can see what happened with them.

[amin1377]

@soheil also suggests checking if the initial temperature is appropriate, or if it should be lowered.

I considered doing that, but since the initial temperature is determined by performing some moves and assigning a value based on the resulting cost changes, I'm not sure how effective it would be.

[vaughnbetz]

For Titan, LU_Network is a clear outlier, and is responsible for most or all of the degradation I think. Worth looking at it. For VTR, the trend is a more consistent, moderate degradation, but there are also fewer circuits. Vaughn

…

On Mon, May 12, 2025 at 12:41 PM Amin Mohaghegh ***@***.***> wrote: *amin1377* left a comment (verilog-to-routing/vtr-verilog-to-routing#3018) <#3018 (comment)> @vaughnbetz <https://github.com/vaughnbetz>: In this PR, I updated the initial placement logic as we discussed. Instead of choosing a random location within a fixed range of 15 around the centroid, the new approach gradually increases the search range from 1 up to half the device size. The function will now exhaust all available locations within the current range before expanding it. Here <https://docs.google.com/spreadsheets/d/1j6t3k_e-fHOn443mhq6XpB4Sqp2hcE9yiqRBXyORVgs/edit?usp=sharing> are the results for Titan (including initial placement WL and CPD). - *Initial placement WL* and *CPD* improved significantly — reduced by 48% and 27%, respectively. - *Final placement WL* remained about the same, while *placed CPD* increased by 1%. - *Routed WL* was roughly a tie, and *routed CPD* increased by ~2%. For the large VTR benchmarks (results <https://docs.google.com/spreadsheets/d/1ckKr_Mz8Ut2yrdR9BSuUQi6PBay-f5hZVLxZgbOfiys/edit?usp=sharing> ): - *Min channel width* increased by 5%. - *Routed WL* and *CPD* increased by 1% and 5%, respectively. - However, *initial placement WL* and *CPD* still improved by 46% and 18%. I was expecting the QoR to at least stay the same, if not improve overall. Do you think it would be worth digging into the circuits with the most degradation to better understand what's going on? @tpagarani <https://github.com/tpagarani>, FYI. — Reply to this email directly, view it on GitHub <#3018 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNDPJZ7DOD45WGNDFPAM7T26DFNJAVCNFSM6AAAAAB4I2V6DSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNZTGI3DEMRZGM> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>