[WIP] Use compressed grid locations in windowed bimatching detailed placer - #3742
[WIP] Use compressed grid locations in windowed bimatching detailed placer#3742AthavanBalakumar wants to merge 1 commit into
Conversation
github-actions
Bot
added
VPR
|
Compared the compressed-grid windowed detailed placer against --ap_detailed_placer none on a hetero test (using k6_frac_N10_frac_chain_mem32K_40nm.xml). Routed wirelength improved on the three tested circuits, min channel width improved on or1200 and sha but worsened on ch_intrinsics.
|
AlexandreSinger
left a comment
AlexandreSinger
left a comment
There was a problem hiding this comment.
Some comments below. You should take some time to think about where you want to go with this algorithm. We seem to have the infrastructure we need now to get a good understanding of what is possible.
| // Currently: only handle 1x1 physical tiles | ||
| if (physical_type->width != 1 || physical_type->height != 1) { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
Why have this limitation? Currently the Flagship architecture's DSP and RAM blocks are not 1x1. Should probably add a TODO to relax this or else you may never optimize those blocks.
| return true; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
This is a very expensive way to check for this information. I think a lookup from blocks to placement macros may already exist. You should either use that, or make one if it does not exist (that you can store locally in your class).
Basically you just want a lookup between a ClusterBlockId -> MacroId / Idx
You can populate the lookup at the start of your detailed placer and use it throughout.
The reason I am worried is that this lookup is linear with the number of macros, and the number of macros is linear with the number of clusters. This makes this lookup O(n); and I think you call this for each cluster in the design, making your overall algorithm potentially O(n^2).
| blk_loc_registry.commit_move_blocks(blocks_affected); | ||
| blocks_affected.clear_move_blocks(); | ||
| return true; | ||
| } |
There was a problem hiding this comment.
As I mentioned in person; I recommend sometimes allowing the cost to be bad. At least at the start of your windowed algorithm, you can allow some bad swaps in an attempt to make them better later (so you would reduce this as you iterate).
| // block may have moved, so update its current location. | ||
| current_loc = blk_loc_registry.block_locs()[block_id].loc; | ||
| } | ||
| } |
There was a problem hiding this comment.
This algorithm is now a bit backwards from our original goals. I recall you wanted to sweep windows across the device and do local optimal moves of blocks to improve quality. This appears to go through each block and create the windows from around them. I am not necessarily against this idea, but I do recommend taking a step back and thinking about where you want to go with this algorithm.
2 participants
Updating windowed bipartite matching detailed placer to generate candidate moves using VTR's compressed block grids instead of fixed physical-grid neighbor locations.
The placer now searches compatible locations in compressed-grid space based on each block's logical type. Currently the scope is conservative, skips placement macro members, restricts occupied swaps to blocks of the same logical type, allows moves into empty compatible locations, and keeps floorplan legality checks.
This is a step towards heterogeneous architecture support.