[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

[vaughnbetz]

Some fragile code in there that I think should be changed.

[vaughnbetz]

Shouldn't do this.

1. We have a function to check if a physical tile type is an IO type in physical_type_util.h (is_io_type). You could use that to build a check of whether a logical block type is an IO type (by checking what blocks are compatible with that physical tile). Perhaps we already have such a function; if not we should make one as it is a useful utility. See

   vtr-verilog-to-routing/vpr/src/place/initial_placement.cpp

   Line 982 in 444b9ac

   if (is_io_type(type) && pad_loc_type == e_pad_loc_type::RANDOM) {

   for an example of is_io_type.

2. Some devices have IOs in columns (area IO). You should check what happens on stratix 10, which has column IO, and I think you should test this code on it and make sure it makes sense (I suspect it should be modified or turned off in that case). Possibly you should just change the whole test for whether you do this or not to check a condition on whether the current block type has a perimeter style, and you could precompute a table of which IO types have perimeter style locations with a preprocessing step that looks at the grid.

[amin1377]

Good point, thanks! I added a function to check for that and am now testing it to make sure it works as expected. I’ll post the results for both SIV and S10 once I have them.

[vaughnbetz]

Should explain a bit about why and how you adjust the search range.

[amin1377]

Added the following:

* If the block is an IO block, we expand the search range to cover the whole column
 * We found empirically that this is a good strategy for IO blocks, given they are located in
 * the periphery for most FPGA architectures

[vaughnbetz]

Here's a Stratix 10 architecture with two columns of IO: https://raw.githubusercontent.com/verilog-to-routing/vtr-verilog-to-routing/refs/heads/master/vtr_flow/arch/titan/stratix10_arch.timing.xml

[vaughnbetz]

I'm OK with this if S10 works well, but see my comment on removing the IO check and instead checking for < SPARSE_BLOCK_THRESHOLD (which you could set to 3 or so). Should be a little simpler and more general.

[vaughnbetz]

You could make this code work well for area-IO (e.g. stratix 10 where IOs are in columns) and for other sparse blocks by just checking if the number of blocks in the compressed columns is less than some threshold. I suspect you don't actually need to check if it is an IO block -- IOs are just an example of this kind of pattern.

(I still like the utility to check if a logical block type is an IO though).

[amin1377]

I actually tried that a while ago by not specifying the block type and simply expanding the search range if the number of blocks in the chosen column was less than 3. However, after making that change, in the example I mentioned earlier, we encountered the same issue where the IO blocks became scattered between the top and bottom edges.

[vaughnbetz]

That’s strange. If you only tried one seed I suggest trying a few to see if this is a consistent effect. I’d also print out a message to check the code is activating.VaughnOn Apr 28, 2025, at 9:23 AM, Amin Mohaghegh ***@***.***> wrote: @amin1377 commented on this pull request. In vpr/src/place/move_utils.cpp:

+ if (block_constrained) {

+ bool intersect = intersect_range_limit_with_floorplan_constraints(block_id, + search_range, + delta_cx, + to_layer_num); + if (!intersect) { + return false; + } + } + + if (is_io_type(block_type) && !block_constrained) { + /* We empirically found that for the IO blocks, + * Given their sparsity, we expand the y-axis search range + * to include all blocks in the column + */ + const t_compressed_block_grid& compressed_block_grid = g_vpr_ctx.placement().compressed_block_grids[block_type->index]; I actually tried that a while ago by not specifying the block type and simply expanding the search range if the number of blocks in the chosen column was less than 3. However, after making that change, in the example I mentioned earlier, we encountered the same issue where the IO blocks became scattered between the top and bottom edges. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because your review was requested.Message ID: ***@***.***>