[Place] Expand search range for sparse blocks

[amin1377]

This PR addresses Issue #2959. The solution to fix the problem is a bit different from the one stated there, though. To ensure moving sparse blocks (e.g., IO blocks), we expand the search range to include the whole column if the number of compatible blocks in the given column is less than a certain threshold (currently, this number is set to 3)

The above update changed the placement of the top picture to the placement of the bottom one (where there is only one IO block left on the top).

---

[soheilshahrouz]

I think the implementation can be made more modular by adding another function to modify the search limit instead of modifying when you're searching for a compatibale location.

[soheilshahrouz]

Does the described problem happen only when IO blocks are located at the top/bottom rows? What if they are initially placed at left/right sides of the device?

[amin1377]

Does the described problem happen only when IO blocks are located at the top/bottom rows? What if they are initially placed at left/right sides of the device?

I'm not entirely sure, but given that the x-axis of the compressed grid is fully dense, I don't think this happens for the x-axis.

[amin1377]

Does the described problem happen only when IO blocks are located at the top/bottom rows? What if they are initially placed at left/right sides of the device?

I'm not entirely sure, but given that the x-axis of the compressed grid is fully dense, I don't think this happens for the x-axis.

Upon further discussion with @soheilshahrouz, it seems likely that the same issue occurs along the x-axis. So, it would make sense to expand the x-axis range limit if the number of compatible blocks in a given row falls below a certain threshold. Otherwise, there’s a bias toward placing IO blocks on the top and bottom edges rather than on the left and right.

I’ll look into this in a separate PR.

@tpagarani FYI

[amin1377]

@soheilshahrouz: I’ve addressed all your comments and implemented the changes you requested. Since the code has changed significantly since your last review, I’d appreciate it if you could take another look. Thanks!

[vaughnbetz]

You should add QoR data on a couple of big benchmark suites.

[vaughnbetz]

Also summarize the QoR-related regtest failrues (basic has two failing QoR, but it is because the wirelength improved a lot (45%) on two small circuits which is certainly fine!
I'd run at least one more benchmark suite if Titan shows some degradation, to see if it's real or not. We can accept a degradation and retune if needed but I'd like to understand it.

[vaughnbetz]

Results on 3 seeds show the cpd degradation isn't consistent (the other 2 seeds were fine). I think this is good to merge. Can you also add a link to the 3 seed data here for posterity @amin1377 ?

[vaughnbetz]

It looks like some golden results need to be updated. I looked at the parmys basic failure and it is a single small design that improved too much, so it's not a problem (actually it's good news):
[Fail]
k6_frac_N10_mem32K_40nm.xml/multiclock_separate_and_latch.v/common routed_wirelength relative value 0.4 outside of range [0.6,1.5], above absolute threshold 5.0 and not equal to golden value: 10.0

[amin1377]

@vaughnbetz:

I updated the code to expand the search range if the number of blocks in the selected column is less than 3. I ran both the Titan benchmarks and the VTR large set with 5 seeds (note that runtime isn't reliable since I ran it on Wintermute).

Overall, the QoR hasn't changed significantly. I compared the results circuit by circuit, and for those where the default seed (seed 1) showed a significant QoR increase, there were other seeds where the QoR improved noticeably. I’ve applied color formatting to the "ratio" tab so you can easily see the results on a per-circuit basis.

Titan: Link
VTR: Link

[amin1377]

@soheilshahrouz

I had to revert the commit that implemented your suggestion about adjusting the search range before calling find_compatible_compressed_loc_in_range, since I need to know which column is selected to expand the search range accordingly.

[vaughnbetz]

LGTM, thanks!

[vaughnbetz]

There are a few CI failures. I looked at the strong failures and it is 4 small circuits with larger than bounds QoR changes, all of which look harmless. So you can check in new golden results, or widen the ranges for those smaller tests if you prefer. Then it's good to merge.

[amin1377]

There are a few CI failures. I looked at the strong failures and it is 4 small circuits with larger than bounds QoR changes, all of which look harmless. So you can check in new golden results, or widen the ranges for those smaller tests if you prefer. Then it's good to merge.

Thanks, Vaughn! I'm running the nightly tests to check if there are any results that need updating. I'll merge the PR afterward.