[Place] Expand search range for sparse blocks #2960
Conversation
github-actions
bot
added
VPR
vpr/src/place/move_utils.cpp
Outdated
| y_upper_iter = block_rows.end(); | ||
|
|
||
| search_range.ymin = y_lower_iter->first; | ||
| search_range.ymax = (y_upper_iter - 1)->first; |
There was a problem hiding this comment.
I think it is better to update the search range outside this function and leave this function as is. For example, intersect_range_limit_with_floorplan_constraints() updates the search range before this function is called. I suggest you add another function to modify the search range for this case as well.
There was a problem hiding this comment.
Agreed. I will write another function (adjust_search_range) to expand the search range.
vpr/src/base/vpr_types.h
Outdated
| @@ -442,6 +455,7 @@ struct t_bb { | |||
| int ymax = OPEN; | |||
| int layer_min = OPEN; | |||
| int layer_max = OPEN; | |||
| bool is_fixed = false; | |||
There was a problem hiding this comment.
I don't think this extra member variable is necessary. Instead of expanding the search range in find_compatible_compressed_loc_in_range(), you can modify it in another function before trying to find a compatible location.
vpr/src/place/move_utils.cpp
Outdated
| * for IO blocks which are on the perimeter of the device. This would allow the IO blocks to | ||
| * moved between top and bottom edges even when the rlim is small. | ||
| */ | ||
| size_t G_MIN_NUM_BLOCKS_IN_COLUMN = 3; |
There was a problem hiding this comment.
Why is this global? If a single function uses it, it would be better to move it inside the function where it is used.
There was a problem hiding this comment.
I think it would be better to define magic numbers globally so people can easily spot them and modify them.
There was a problem hiding this comment.
I also think it would be better to make this local if it is only used in one spot.
|
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 |
…rilog-to-routing into placement_search_range
|
@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! |
|
You should add QoR data on a couple of big benchmark suites. |
|
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! |
|
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 ? |
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).
