Refactor init place for floorplanning #1817
Conversation
…re also placed in order of most to least difficult, like other non-macro blocks. Also, called sorting blocks functions after propogating place constraints, so that the accurate floorplan regions are used for macros
…l block score so that blocks with tighter constraints get placed first
| // Sorting blocks to place to have most constricted ones to be placed first | ||
| std::vector<t_pl_macro> sorted_pl_macros(pl_macros.begin(), pl_macros.end()); | ||
|
|
||
| auto criteria = [block_scores](const t_pl_macro lhs, t_pl_macro rhs) { |
There was a problem hiding this comment.
I think this should be refactored to place blocks & macros in one loop, with the sorted_blocks vector controlling it all.
… in grids for each logical block type, to be used when calculating region size
…btile_size function to ensure accurate grid tile counting in the subtile and non subtile case. Functions tested to ensure correctness
… unnecessary lines
|
QoR Results Comparison between this branch and the master branch: Overall, the total runtime, place time, and pack time do not show any significant differences between this branch and the master branch. However, there are slight differences noticeable in the total wirelength and critical path delay for three circuits: LU8PEEng.v, LU32PEEng.v, and mcml.v. The rest of the circuits show no difference in wirelength or critical path delay. The difference in wirelength and critical path delay in the above-mentioned 3 circuits comes from the fact that macros are placed in a different order during initial placement. On this branch, code was added that sorted macros from biggest (most blocks) to smallest (least blocks) and placed them in that order during initial placement. The 3 circuits are the only circuits to have macros of different sizes, which is why they are the only ones showing differences in wirelength and critical path delay. |
|
QoR looks good. Small changes make sense and are not a problem. To be thorough you should do a titan quick qor comparison too. |
|
Titan_quick_qor comparison: |
|
@vaughnbetz Does this PR look ok to merge? I added the results comparison from titan_quick_qor runs as well, and those results look okay. |
… in grid tile lookup class
…nts, and changed type grids to only store subtile totals, not subtile ranges
|
New qor comparison after code changes: |
|
The changes look good; I just have one suggestion for improved commenting of the data members in your new class, and perhaps a name change for a member variable. You can make that change after we merge if CI finishes soon and you want to get this in, but I'd like the data structure comments added in any case. |
The 3rd nightly test seemed to be stuck on pending so I added the comments to the GridTileLookup class and pushed to the PR again. |
|
Looks good; will merge when CI is green. |
|
@vaughnbetz The 3rd nightly test had one qor failure - vtr_reg_qor_chain_predictor_off. This test has failed a couple of times on this branch, it has passed some times as well. I remember you said that it was a noisy test and we could update the golden results for it. Would it be ok to merge this branch and update the golden results on another PR? |
|
It's OK to update the golden results for that test. I'd update them here (in this PR) if possible though so others don't hit spurious QoR failures once this change goes in. |
Makes sense, I'll update it here. |
|
@vaughnbetz I think this can be merged now - I updated the golden results for vtr_reg_qor_chain_predictor_off. All the tests have passed except for the Yosys+Odin ones. |
Description
During initial placement, the blocks are sorted according to how difficult they are to place according to three criteria - whether they are part of a macro, the floorplan constraints they have, and the number of equivalent tiles they have. Based on these criteria, the blocks are placed in order from most difficult to place to least difficult to place.
In this pull request, the sorting of the blocks was made more robust in the following ways:
The exact number of compatible grid tiles covered by each floorplan region is calculated so that the blocks constrained to regions with less tiles can be placed first.
The macros are also placed in a sorted order based on the three criteria above. Previously, they were just sorted by the number of equivalent tiles.
Related Issue
Part of adding floorplan placement constraints to VPR #932
Motivation and Context
In some cases, the placer would get stuck during initial placement, because the blocks that had tight floorplan constraints would be impossible to place when all of their valid locations had already been taken up by previous blocks.